引用：肥猫布里奇高 发表于 2023-04-09 20:04
捉虫：
原文："首先：不能像一对聊天那样利用发送方的绝对时序来保证消息顺序，因为群聊发送方不单点，时 ...

已修订，非常感谢

捉虫：
原文："首先：不能像一对聊天那样利用发送方的绝对时序来保证消息顺序，因为群聊发送方不单点，时间也不一致"
应该是："首先：不能像一对一聊天那样利用发送方的绝对时序来保证消息顺序，因为群聊发送方不单点，时间也不一致"

我觉的LB的时候用一致性hash会好些，加减服务器影响面小

催跟催跟！

引用：weixiaoyao 发表于 2021-03-25 11:38
群聊时，server去单点拿seq做序列化，这里也有些问题。多个sender发到server的消息，server收到后也可能是 ...

在im的场景下，这样其实也没太大问题。
我昨天又回看了作者的另一篇时序的文章，2年前我也提过类似的问题，作者给过解答。
O了

群聊时，server去单点拿seq做序列化，这里也有些问题。多个sender发到server的消息，server收到后也可能是乱序的，此时拿到seq得到的顺序不能保证一定和发送方顺序一样，只可以保证多个接收者之间的展示顺序是一样的。

好的。明白了

引用：某非著名程序 发表于 2021-03-14 19:56
又看了一遍。我们功能支持多端、漫游。
每次客户端重连服务端都会推送最近的10个会话10条消息或者未读会话 ...

ACK是为了保证百分百准确性，你在初期的版本时，先不用考虑这个，能把功能逻辑实现了再说，后绪版本再逐步精进

又看了一遍。我们功能支持多端、漫游。
每次客户端重连服务端都会推送最近的10个会话10条消息或者未读会话的10条消息，用于展示会话的最近一条和进聊天界面的一屏消息。滑动会加载历史数据。
如果有新消息，服务端会推送到端。用于实时显示。
这样的逻辑会有问题吗？看了楼主的一系列文章，发现我们这种做法根本没有ack，我自己也是很疑惑。

引用：某非著名程序 发表于 2021-03-10 13:42
现在的做法都是服务端存储，没有所谓的ack确认，是不是和IM跑偏了。

实时消息，必须得实时传啊

现在的做法都是服务端存储，没有所谓的ack确认，是不是和IM跑偏了。

第五章呢 看着上瘾了 无法自拔 咋整

感谢～通俗易懂，催更后续，哈哈～

同一个人如果是以TCP与服务端连接，任一时刻客户端总是与某1台服务器连接，只需在接入服务器为每一条消息打上时间戳，毫秒或微秒级的，更极致的：时间戳相同时，加上序列号。对发送者是唯一了。这样，与后面有多少个服务、多少个并发线程都不相关。

引用：Rayman 发表于 2020-11-30 17:59
催更第五章~哈哈哈哈哈

先别催，我还得酝酿一下。。。

催更第五章~哈哈哈哈哈