我们目前的离线思路是另一种，从业务层面弱化离线和在线的区别，群消息表内只存1条消息，send_id, group_id, msg_id。离线用户登录后不会拉取离线消息，只会获取所有会话的最新msgid或者时间，只有当用户进入特定的聊天界面时，才会实时触发拉取消息流程，此时根据最新msgid分页往前倒推获取，没有截止时间点，只要用户在界面上拉刷新，就会获取上一页msg。
1.这里其实是获取历史消息，将离线消息拉取场景也当做了历史消息拉取的一种
2.实时触发拉取，因为就算是登录时拉取了离线消息，也只有在用户点击进去相应的聊天界面这些消息才有用处（即用户点进去看这些消息）
3.假设有大量离线客户端同时登录，这里将登录时的大量统一拉取分散到了登录后的实时拉取，理论上应该是分散和随机的，可减少服务端的瞬时请求量

其实有没有更加详细的ACK层的实现？目前离线消息基本都是 客户端主动调用 api 分页去拉取。然后客户端存储之后把 msg_id 发回去告诉server 我已经接收到了。

引用：rickding 发表于 2017-11-23 13:48
谢谢大神的点拨，按照您的思路准备搭建一个im应用

谢谢大神的点拨，按照您的思路准备搭建一个im应用

引用：JackJiang 发表于 2017-05-10 13:38
建议你好好读读NAT原理：http://www.52im.net/thread-50-1-1.html
你这种方式是行不通的。

是啊，我知道是行不通的，所以想寻求一种可行，低耦合的解决办法。或者说QQ的udp消息是怎么做的。

引用：不吃香蕉的猴子 发表于 2017-05-10 13:17
大神好，目前遇到一个坑，我用message_server接收所有的udp消息,push_server往客户端转发消息，messs ...

建议你好好读读NAT原理：http://www.52im.net/thread-50-1-1.html
你这种方式是行不通的。

引用：JackJiang 发表于 2017-04-18 11:25
不要系统还没开始做，就把数据想成海量的情况，这是自已吓自已。
暂时的设计够用就行，保留设计的前瞻性 ...

大神好，目前遇到一个坑，我用message_server接收所有的udp消息,push_server往客户端转发消息，messsage和push用rabbit解耦，但是目前的情况是内网测试没问题，服务一上公网，NAT就使得message可以收到消息，而push发出的消息被NAT拦截了。我不想通过客户端往push先发消息建立通道的方式来解决。而都是用message又会让message变得很重，而且还难以横向拓展。有没有关于udp做消息服务的好的建议和设计思路。message使用netty作为网络层通信框架。

讲的很清楚 问题分析的很透彻 作为新人看懂了 多谢分享

这个还是非常值得学习参考的

引用：。面向阳光. 发表于 2017-04-18 11:16
嗯，最近一直在学习IM相关的东西，技术细节看了很多了，但是到了系统设计的时候，太纠结了，想的太长远， ...

不要系统还没开始做，就把数据想成海量的情况，这是自已吓自已。
暂时的设计够用就行，保留设计的前瞻性和扩展性即可。

引用：JackJiang 发表于 2017-04-18 09:38
根据你的实际情况决定就行了，不需要纠结太多，先把逻辑实现能再考虑表数据量的问题，因为你的系统用户数 ...

嗯，最近一直在学习IM相关的东西，技术细节看了很多了，但是到了系统设计的时候，太纠结了，想的太长远，就比较复杂了，适可而止又不太甘心，不是说20倍设计，3倍实现么。。。别人的设计也看了很多，但是一般都是大的架构，很多细节都不会讲或者不屑于讲，大学狗还没毕业，目前在实习，求大神指条明路。。。。

引用：。面向阳光. 发表于 2017-04-17 18:46
干货，学习了
我有一个问题想请教一下：
在实际应用中群消息和单聊消息分别存在不同的表中好吗？会不会让 ...

根据你的实际情况决定就行了，不需要纠结太多，先把逻辑实现能再考虑表数据量的问题，因为你的系统用户数是一定的，而每个用户的群数量也差不多可以估算的出来，意味着相关表的数据量也能大致估算，你再根据表数据量的情况决定如何提升查询性能即可，不需要拘泥于别人的设计。

干货，学习了
我有一个问题想请教一下：
在实际应用中群消息和单聊消息分别存在不同的表中好吗？会不会让业务更复杂了？
文章中是群消息业务单独存了一个表是为了举例子还是说您就是这么设计的呢？
还有，最后一条确认的消息ID存在群成员表里合适么？实际情况下一个人会拥有多个群，同一个用户有多条记录，是每一条记录的最后确认msg_id是相同的（不区分是哪个群），还是说每个群成员记录都只是存了这个用户在这个群的最后确认的msg_id，如果是前者，数据一样会有冗余，如果是后者，是否没有这个必要，所有群消息都存在一个表里，只要记录一个msg_id，拉去属于用户自己的未读msg就可以了吧，到了客户端再区分是哪个群的，不需要单独拉某个群的未读消息吧？
谢谢🙏

引用：JackJiang 发表于 2017-04-10 19:44
做im这种应用，尽全力保证消息送达是肯定需要的，但有的时候费了很大劲、可能要消耗很多的性能、增大很多 ...

嗯嗯，您说的对，非常感谢。

引用：不吃香蕉的猴子 发表于 2017-04-10 17:54
那么问题来了：在批量ACK的时候，如果server给client发消息就出现了丢失，那么server端是不是需要重发，这 ...

做im这种应用，尽全力保证消息送达是肯定需要的，但有的时候费了很大劲、可能要消耗很多的性能、增大很多复杂性才解决了某种极小几率才可能出现的情况，那么可以考虑放弃解决，腾讯的设计原则就是允许“万有一失”，而且im消息并非电商这种高价值数据，丢一两条消息并不会产生什么严重的后果，所以不需要太钻牛角尖。

那么问题来了：在批量ACK的时候，如果server给client发消息就出现了丢失，那么server端是不是需要重发，这样的话又需要设置重发的触发条件，得在一段时间内判断在线用户是否需要重发。应对这样的场景有没有好的解决办法呢？

受教了，感谢楼主

谢谢分享，思路很不错

这个系列文章不错，多谢群主分享过来