引用：1mok 发表于 2019-01-28 15:58
存一份的想法是很好，但作者还是没有解答文章开头评论提出的疑问，类似微信这种无限建群的方式，如何知道哪 ...

我个人觉得解决方案是建立在实际用户场景里的，对于im而言主要纠结在实时推送【多端问题、及时性、数据不丢】，离线存储【主要是漫游、数据存储】。2种场景各有侧重点，实时推送注重消息的及时性，数据可靠不丢，客户端尽可能快速有效获取数据，所以解决思路是一般采用写扩散的模型，再加上ack应答的机制基本上可以解决。至于多端实时推送也认为只是一个数据推送纬度的问题。而无法成功推送的消息，为保证数据不丢一般采用离线存储，根据漫游和长时间离线的场景，此处考虑的是数据不丢，让用户能看到它想看到的数据才是第一要务。至于用户上线后，能瞬时同步海量消息的需求和百万在线弹幕系统一样，个人感觉都是伪需求，试想手机一登录，海量数据瞬时而来，手机就算不被卡死了，估计用户也看不到数据。这肯定是不对的。一般来说长时间不登录用户关心的是谁给我发过消息，发了几条消息。而不是具体的内容，在查看具体消息时，一般也是查看最新的若干条，同时要支持用户查询历史消息的功能，比如只显示最近100条数据，通过向上滚屏查看其它数据。至于作者说的数据偏向，只存一份数据，其实从设计上讲，每一条信息都应该我3个纬度的标识，一个是用户标识，一个是session标识，一个序列标识（或者是时间标识）。根据前面阐述，服务端需要维护不同会话最新消息的id，客户端需要维护已经同步消息的最新id，单调递增。实时推送时，用户id到端，sessionid到会话。但服务端注意推得量，最好有滑动窗口做适配或者降级方案。离线抽取数据时，首先获取最新的id计算出哪些人有消息，有多少消息。在根据操作动态抽取即可。这是当初我们设计【数据泵】时的思路，当时遇到难点数据显示顺序问题和id生成问题，推翻了很多设计，当时纠结了很久。

引用：1mok 发表于 2019-01-28 15:58
存一份的想法是很好，但作者还是没有解答文章开头评论提出的疑问，类似微信这种无限建群的方式，如何知道哪 ...

我个人觉得解决方案是建立在实际用户场景里的，对于im而言主要纠结在实时推送【多端问题、及时性、数据不丢】，离线存储【主要是漫游、数据存储】。2种场景各有侧重点，实时推送注重消息的及时性，数据可靠不丢，客户端尽可能快速有效获取数据，所以解决思路是一般采用写扩散的模型，再加上ack应答的机制基本上可以解决。至于多端实时推送也认为只是一个数据推送纬度的问题。而无法成功推送的消息，为保证数据不丢一般采用离线存储，根据漫游和长时间离线的场景，此处考虑的是数据不丢，让用户能看到它想看到的数据才是第一要务。至于用户上线后，能瞬时同步海量消息的需求和百万在线弹幕系统一样，个人感觉都是伪需求，试想手机一登录，海量数据瞬时而来，手机就算不被卡死了，估计用户也看不到数据。这肯定是不对的。一般来说长时间不登录用户关心的是谁给我发过消息，发了几条消息。而不是具体的内容，在查看具体消息时，一般也是查看最新的若干条，同时要支持用户查询历史消息的功能，比如只显示最近100条数据，通过向上滚屏查看其它数据。至于作者说的数据偏向，只存一份数据，其实从设计上讲，每一条信息都应该我3个纬度的标识，一个是用户标识，一个是session标识，一个序列标识（或者是时间标识）。根据前面阐述，服务端需要维护不同会话最新消息的id，客户端需要维护已经同步消息的最新id，单调递增。实时推送时，用户id到端，sessionid到会话。但服务端注意推得量，最好有滑动窗口做适配或者降级方案。离线抽取数据时，首先获取最新的id计算出哪些人有消息，有多少消息。在根据操作动态抽取即可。这是当初我们设计【数据泵】时的思路，当时遇到难点数据显示顺序问题和id生成问题，推翻了很多设计，当时纠结了很久。