一会回复你

你所说的重复处理，就是重传了。我以前跟手Q团队的人交流过，重传在主流IM里很正常，至于怎么重传，这就是算法策略问题了，各家实现基于种种考虑可能会略有不同。

MobileIMSDK里的重传策略：包括什么时候发回执、什么时候该重传、重传几次、多久重传一次等都是由客户端来决定的，服务端不涉及这些算法和策略，目的是减化算法并降低服务端负载（保持服务端简单性，就等于给未来的性能优化提供更多可能性）。但服务端唯一要做的就是将客户端决定的重传消息再次尝试投递给另一个客户端而已，因为现在的即时退讯文字消息都是通过服务端中转，这一关是省不了的。

好在重传并非常态，只是正常通讯时以非常小的几率发生而已，整体来说，对服务端的负载没有多大影响，即使有影响，从算法的角度来说也是可以优化的。

一个误解是UDP理论上可能丢包，但丢包几率并没有那么夸张，否则它就真没有存在的价值了（比如实时音视频聊天，大家都首选UDP，而且几乎不重传，如真如大家所想的丢包这么平常，那还能正常玩吗）。

引用：kezhaoyuan 发表于 2016-06-24 09:56
你的意思，是不是说：
1、重传无法避免，即客户端收不到服务端回执的情况是存在的。所以会产生用户只发 ...

1）客户端收不到回执的可能性理论上也同样存在（你概率已经越来越小了），但对方收到重复消息在MobileIMSDK里绝不可能存在，因为算法层面已经做了处理。
2）服务端只管左手进右手出，算法由客户端完成，最大效率进行网络吞吐才是它最要作的事；
3）丢包概率没法优化，因为这是你的网络状况决定的，但重传的策略可以优化，这就是你算法要解决的事了。

关于MobileIMSDK的QoS关达保证机制原理，我已在这个帖子里回过了：http://www.52im.net/thread-129-1-3.html

引用：Liven 发表于 2017-10-31 15:58
学习了，我现在也是遇到这个问题。但是如果是按照楼7方法处理出现消息重复的概率太高了。请问有没有解决的 ...

去看下MobileIMSDK的实现源码，几乎没有重复的可能性。