[已回复] MobileIMSDK的C2C消息逻辑优化讨论

我觉得现在C2C（用户给用户发私聊消息）流程有待优化，不知道我说的对不对，可以一起讨论，理由如下：

现在用户1（U1）给用户2（U2）发送私聊消息的逻辑如下的逻辑如下：
1、U1发给服务器S
2、服务器S转发给U2
3、U2发应答包给服务器S
4、服务器S转发应答包给U1
其中1和2是消息本身发送流程，3和4是消息应答包发送流程。

问题：U2已经掉线，可能导致U1本身在网络良好的情况下会发送不成功。
我这里解释下为什么是可能发送成功也可能是发送不成功，下面先设定一些条件：
如果服务端“模感度类型”设置的是3*10+1（即session多久过期），即心跳是10秒一次，即客户端心跳丢包容忍度为3个包。
如果客户客户设置QoS设置的隔10秒重发一次，且用户U2是发送了心跳包后马上退出
发送成功的情况：
客户端至少要再重发3次（一共4次），在第4次时服务器才发现U2掉线，然后走离线消息，
这种情况用户U1发消息给U2要等30秒才提示发送成功。（这种情况就是服务器设置的session多久过期和客户端重发间隔、次数要保持一次）
发送不成功的情况：
如果重发少于3次，那么会提示用户U1发送失败，但此时U1的网络环境很了。


这种情况可能不多见，但如果出现了，对用户U1来说不管是发送成功或发送不成功，体验都是不好的。


所以我觉得可以优化如下逻辑（就是桥接的逻辑）：
1、U1发给服务器S
2、服务器S直接给U1应答包
3、服务器S消息转发给U2
4、U2发应答包给服务器S
这样U2掉线就是服务器QoS消息重发（之前是客户端QoS重发）及离线消息这块的逻辑了。


不知道我这样有没有问题，当时JackJiang是基于什么原因没这么做，可以一起讨论下。

你对MobileIMSDK这一块的代码理解的很到位，赞一个！但就事论事来说，MobileIMSDK的有些东西是经过权衡后决定的。

抛开MobileIMSDK现在的实现方案不说，你可以假设一下，如果这些逻辑你来做，并把它们都放到服务端来实现的话，那会是什么样的？

我们随便来展开一下便可知：

1）假设按照每秒4万吞吐的满载情况来计算，最理想的情况下，重传列表每秒钟将稳定维护在大约20万个；
2）由此导致，每个C2C的消息包的去重判断、超时判断，都将在这以几十万消息中进行，性能损耗会是非常明显，尤其IM这种讲究高吞吐、高性能的应用；
3）毫无疑问，理想情况下，这个QoS列表，每秒都在高效地进和出，大量小对象都在不断地进行分配和释放操作，稍有不健壮的代码让服务器抽个风，几秒内的消息堆积都是惊人的，那么以IM这种高吞吐、高并发场景，很容易就让服务器发生雪崩（连锁反应啊）；
4）还有一个比较严重的问题，因为这个QoS由服务端保证，那么万一服务端崩溃或意外情况，导致停机、掉电，这消息马上就丢了，影响的是大量用户的QoS消息，你可以说我再做持久化，当然这肯定是可以做，但你的代码只会越来越复杂。跟QoS只在客户端做相比，即使发生意外，影响的也只是这个用户自已，再说一个用户频繁聊天的话，根据经验，一个人5秒能完成一条消息的发送就很快了（你可以拉一个秒表，以真实情况来手机上打字、发一条消息试试看）。

综上所述：MobileIMSDK的设计原则（尤其是服务端），就是为了保持极简的逻辑，因为IM核心回归到本质就是消息从这头到达那头，而MobileIMSDK的服务端始终给自已的定位就是一个消息通道，各种复杂的逻辑能在客户端做的（或许并非完美，但QQ的设计原则也同样是允许万有一失，这就是取舍）绝不放到服务端。

总之：服务端一旦变的复杂，它的扩展性一定会是噩梦。一个胖子做什么事都是笨拙的，而一个瘦子作什么事都更敏捷，就是这个道理。同样的设计理念，你回头看看redis为何能始终保持轻量级和高性能，也是这个道理。