zpf124 最近的时间轴更新
zpf124

zpf124

懒~~~
V2EX 第 164342 号会员,加入于 2016-03-22 09:03:34 +08:00
zpf124 最近回复了
@xiayushengfan mongodb ,我们用的也不是很有心得,我们还是按照关系型数据库的用法或者 k-v 缓存的用法在用。

比如我们如果用 mongodb 存站内信的话,就是一个集合是所有消息,或者一个集合是一个月的消息之类的维度,每个文档包含文档的全部内容包括所有的接受用户 id ,以及已读状态, 查询的时候 直接查当前用户 id 的文档数据。
@kaiki 最后我们是发多条了,没有组的概念,这种情况下按照你说的方式确实能优化一些存储。

针对后面的问题,我们的文章表有 n 多字段,对于消息来说都是完全没用的,而且文章没有记录多少人已读的。
最后我们的站内信不是用户给用户发送的,基本都是系统通知,"你订阅的 某个资源更新了,url " 类似这种,所以我们和楼主的也不完全相似,因为我们的消息大多数是分组的,个别是全站群发,没有用户间私信。
最后说说你的需求
1 、数据肯定要落库的,虽然这个数据重要性不高丢了就丢了,但发消息偶尔会出现收不到肯定最起码业务领导会不爽。
所以如果想要性能那就用搜索引擎 es 或者其他非关系数据库如 mongoDB ,数据读取层面还可以加 redis 。

2 ,3 、阅读很少那就把阅读单独建表, 就像我们那种, 阅读表包含消息 id 、用户 id 、是否已读、已读时间、创建时间啥的。
本来当时打算有个消息发送组的概念,消息分为发给个人还是发给某个组, 然后组里面有个魔法值是群发。
结果这个功能对于我们本事不是很重要,而且人手要优先干其他的,所以这里就简化了,有给某个组群发的需求,就 foreach ,创建多条信息发送给指定的人。
我先说个我之前设计的实现,不一定好,而且当时我们的在线用户量级很小都不担心这个问题。

一张用户表,一张站内信表,一张站内信已读表。

站内信表中有 sendUserId 字段 魔法值 0 代表发送给所有人,其他值代表只发给某人。
因为我们数据量不大,所以消息是直接 join 查的,order 排序未读的展示在前。
@GoodRui 那就改呗,其实不改也无所谓,有 ssh 密钥还知道生产内网数据库密码的就那么两三个人,而且离职率也不高,就你离职了然后公司的生产环境就被黑了那不是找死么...
我离职的时候是直接把我电脑格式化了,密钥和电脑里记密码的笔记都一起格式化了,我也不想知道。
我们的方案很粗糙很简单,除了主要几个人其他人不知道生产服务器密码,测试服务器密码就知道了。

生产配置文件不在 git 里存在 jenkins 里,
每次发版时候有权限那几个人肉眼核对配置文件的修改,然后去 jenkins 里修改对应生产配置文件。
104 天前
回复了 ETONG 创建的主题 程序员 armv8 和 arm64 啥区别?
是两个维度的定义,以电脑端 cpu 举例。

armv8 = intel 奔腾,i3, amd 速龙,Ryzen
arm64 = amd64(x86_64)
120 天前
回复了 mrgeneral 创建的主题 问与答 电动自行车车到底如何转弯?
对,只有行人是没有强制的正逆行要求的,其他的车道都需要遵守靠右行驶的规则。
133 天前
回复了 x940727 创建的主题 职场话题 专升本进大厂?
歪个题。

专升本是专科近邻毕业去考某个大学的本科专升本专业(但这考试难度不咋大),然后直接续上,接着上 2 年学。 总共 5 年。

自考,成考,那个不叫专升本,那是重新参加教育,你高中学历可以去考。
关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2059 人在线   最高记录 5497   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 16ms · UTC 00:35 · PVG 08:35 · LAX 16:35 · JFK 19:35
♥ Do have faith in what you're doing.