引用：Frank 发表于 2023-04-25 20:14
很佩服站长，几年如一日坚持

很佩服站长，几年如一日坚持

从0～1确实不太好，但没做过也正常。
但是 讲的细节较多，挺好；
并且还讲了钉钉的

引用：Feng_N7pwQ 发表于 2021-10-25 14:47
问题确实很多，大厂的IM系统能架构成这样，确实让人汗颜但是也有值得学习的地方，

应该当时只是临时应急搞的

问题确实很多，大厂的IM系统能架构成这样，确实让人汗颜但是也有值得学习的地方，

引用：椎锋陷陈 发表于 2021-09-26 14:14
谢谢JackJiang大佬解答，的确整篇文章看下来，就感觉很多地方的实现有点迷惑。。。

通常看起来很绕的算法或逻辑，要么就是非常精巧，要么就是非常笨拙，这个算法应该不是前者，所以没有必要太纠结

引用：JackJiang 发表于 2021-09-26 12:14
1）其实它还是有个双向互通的长连接，只是为了发送时省掉QoS送达保证机制，就用http了，因为http是请求响 ...

谢谢JackJiang大佬解答，的确整篇文章看下来，就感觉很多地方的实现有点迷惑。。。

引用：逍遥小子 发表于 2021-09-26 10:17
推拉隔离的设计，避免多次网络请求的问题。
没有明白是怎么避免多次网络请求的

文章中的意思，应该是通过缓存队列将消息进行了批量合并拉取，不用每次都一条条拉，是这个意思

引用：椎锋陷陈 发表于 2021-09-26 10:14
文章信息量较多，阅读后产生的疑问也比较多，望Jack Jiang大佬不吝赐教：

1）其实它还是有个双向互通的长连接，只是为了发送时省掉QoS送达保证机制，就用http了，因为http是请求响应机制，代码编写起来简单而且通用。其实你看文章内容就知道，闲鱼的这套im核心，还是比较凑活的，可能当初设计时也没有太重视，设计的人实时通信这方面的经验也不是特别足。

2）这个version看起来有点蛋疼，说的很绕，我也懒得仔细去理解了，反正不管怎么说，这肯定不是最佳实践。

推拉隔离的设计，避免多次网络请求的问题。
没有明白是怎么避免多次网络请求的

文章信息量较多，阅读后产生的疑问也比较多，望Jack Jiang大佬不吝赐教：

引用：客户端发送的逻辑是直接基于http的所以暂时不用做重试，主要是在服务端往客户端推送的时候，会加上重试的逻辑。

基于Http的意思是闲鱼的发送消息流程是通过Http请求进行的？但又说服务端能往客户端推送，所以闲鱼的消息系统是基于SSE这种单向通信的吗？
基于Http所以暂时不用做重试的意思是当HTTP请求成功就表示消息发送成功就不用重试了吗？

引用：当A发送的消息（黄色）首先到达服务端，因为前面没有其他version的消息，所以会将原数据返回给A，客户端A接收到消息的时候，再跟本地的消息做合并，只会保留一条消息。同时服务端也会将此消息发送给B，因为B本地也有一个version=1的消息，所以服务端过来的消息就会被过滤掉，这就出现消息丢失的问题。

为什么要将原数据返回给A？是拿原数据充当ACK包的作用吗？还是仅仅为了将服务端实际递增生成的version返回给客户端让客户端进行更新，保证消息时序性？