请选择 进入手机版 | 继续访问电脑版

默认
打赏 发表评论 43
想开发IM:买成品怕坑?租第3方怕贵?找开源自已撸?尽量别走弯路了... 找站长给点建议
好文章,收藏了
原文发表在知乎专栏:https://zhuanlan.zhihu.com/p/32710413,分享NoSQL的各种技术场景,包括IM。
深度好文,学习了
很不错的分享,支持群主
消息同步库中的消息如果只保留一段时间的话,清空后不就丢消息了吗,客户端再也不知道和谁产生过会话
引用:1mok 发表于 2018-08-01 20:33
消息同步库中的消息如果只保留一段时间的话,清空后不就丢消息了吗,客户端再也不知道和谁产生过会话

微信官方也只承诺保存消息72小时。im的聊天消息一般都是热数据,时间久了确实没有意义了。
打个比方,你想知道某人1个星期或1个月前对你说什么了吗,或者说不知道的话也不重要的吧。因为常理来说,如果是重要消息,一定会有其它渠道让你再知道,否则无关痛痒的消息,错过了也就错过了
签名: 《IM开发快速入门(一):什么是IM系统?》:http://www.52im.net/thread-3065-1-1.html
引用:JackJiang 发表于 2018-08-01 21:07
微信官方也只承诺保存消息72小时。im的聊天消息一般都是热数据,时间久了确实没有意义了。
打个比方,你 ...

微信72小时不打开的话,72小时前的消息就收不到? (这个待验证)。 那类似钉钉这种企业微信,消息历史漫游是很重要的功能,同步库清除不要紧,关键是需要知道用户和谁产生过会话,可以进行消息漫游
引用:1mok 发表于 2018-08-02 09:57
微信72小时不打开的话,72小时前的消息就收不到? (这个待验证)。 那类似钉钉这种企业微信,消息历史漫 ...

这是微信官方文档上写的:
QQ图片20180802102835.png
签名: 《IM开发快速入门(一):什么是IM系统?》:http://www.52im.net/thread-3065-1-1.html
good job
想问一下你们最终采用的是什么数据库来做这个消息同步库和消息存储库的。如果不用文中推荐的tableStore的话
引用:summer4 发表于 2018-09-21 10:59
想问一下你们最终采用的是什么数据库来做这个消息同步库和消息存储库的。如果不用文中推荐的tableStore的话

文章其实讲的是一种思路,并不用具体往什么数据库上套用,必竟思路是相通的。
你可以用你根据的业务需求,使用你最擅长的数据库来实现
签名: 《IM开发快速入门(一):什么是IM系统?》:http://www.52im.net/thread-3065-1-1.html
学习了!
楼主,请教两个事情:1. 消息同步库to-A 中是否会存储 A的不同的端发送的消息?
2. 消息同步库 读能力 十万级TPS,消息存储库 读能力 少范围读,千级TPS。根据“典型架构设计” 端同步消息的链路,发现每次同步消息,需要读取消息存储库和消息同步库,为啥两者的读能力相差如此之多呢?
签名: now start 。。。
引用:JackJiang 发表于 2017-11-29 14:15
原作者其实是在推介阿里云的TableStore这个NoSQL数据库,本文在引用时为了让阅读者不会因广告嫌疑而产生 ...

你好我用的是mongodb保存消息的,一个表保存了所有的单聊消息,我想问下文章中提到的timeline我能不能直接理解mongodb的自增id,即所有的A,B,C,D,E,F,H他们之间发送的消息认为是一个大的timeline,我会根据发送id来分组成小的timeline,这样行吗?会有问题吗?我想就是他们直接的序列不是连续的而已,想不到会出现别的什么问题,请指教.谢谢~
引用:榴莲与狗 发表于 2020-02-10 19:01
你好我用的是mongodb保存消息的,一个表保存了所有的单聊消息,我想问下文章中提到的timeline我能不能直 ...

它这个timeline应该是兼有队列和存储的作用,所以技术上应该不仅仅主Mongodb这种持久化存储技术,很可能还包含了内存数据库的技术概念,不然性能无法保证。如果是内存数据库的话,这个timeline就能很好的实现顺序性、订阅和分发。
签名: 《IM开发快速入门(一):什么是IM系统?》:http://www.52im.net/thread-3065-1-1.html
引用:封宇_ynOMz 发表于 2018-01-30 15:31
这个问题我这边已经解决了,我近期会在我公众号上放出方案。欢迎版主转过来

老哥, 我目前也遇到你说的这个问题, 离线消息还没拉取完, 在线状态时发的消息又推送过来了..  可能导致离线消息没全部拉取到. 不知道您这边最后是怎样解决的.

目前我能想到的方案就是在线推送的时候不直接推送, 而是发送一个推送的事件, 然后后端程序监听到这个事件后从每个涉及到的客户的上一次客户端ack的地方获取后续的消息, 再推送到客户端,  但这样带来的问题是群聊本来一个消息+多个接收人就能搞定的事情, 需要n次操作才能完成一条消息的推送.
消息同步库用于存储所有用于消息同步的Timeline,每个Timeline对应一个接收端  -------->
如果a和b单聊,a发了一条信息,是否会在to-a和to-b的Timeline里面,各写一条记录。
如果abcd群聊,a发了一条信息,是否会在to-a/b/c/d的Timeline里面,各写一条记录。

@JackJiang 谢谢。
消息存储是按照会话来的,比方a/b的单聊,a/c的单聊,某个组的群聊,在数据库设计的时候,怎么来表示这个Timeline。@JackJiang   谢谢
引用:danielstock 发表于 2020-05-27 23:10
消息存储是按照会话来的,比方a/b的单聊,a/c的单聊,某个组的群聊,在数据库设计的时候,怎么来表示这个Ti ...

你问的是本地sqlite怎么设计还是服务端?
签名: 《IM开发快速入门(一):什么是IM系统?》:http://www.52im.net/thread-3065-1-1.html
引用:danielstock 发表于 2020-05-27 21:47
消息同步库用于存储所有用于消息同步的Timeline,每个Timeline对应一个接收端  -------->
如果a和b单聊,a ...

单聊肯定是各写一条,群聊有两种方式:各写一条叫“扩散写”、只写一条叫“扩散读”,各有各有好处,具体你看看这篇《IM群聊消息究竟是存1份(即扩散读)还是存多份(即扩散写)?》。
签名: 《IM开发快速入门(一):什么是IM系统?》:http://www.52im.net/thread-3065-1-1.html
打赏楼主 ×
使用微信打赏! 使用支付宝打赏!

返回顶部