ios客户端发一条消息 怎么判断这条消息已经成功发送给服务端了  
- (int) sendCommonDataWithStrNSString *)dataContentWidthStr toUserIdNSString *)to_user_id withTypeuint)typeu;  这个方法返回的成功,只是表示消息发送成功了,还是说已经确认后台收到消息了

引用：ym_im 发表于 2018-01-11 18:16
可不可以只要四步 客户端 A MSG:R 服务器收到后，服务器发送msg到cl_B,
cl_b ack 给 服务器， 服务器ack响 ...

可以，MobileIMSDK框架就是这么干的。

可不可以只要四步 客户端 A MSG:R 服务器收到后，服务器发送msg到cl_B,
cl_b ack 给 服务器， 服务器ack响应给 客户端A？？？？？？？？

引用：x931609201 发表于 2017-11-17 11:11
我们公司现在的消息必达是这么设计的，不需要6步那么复杂，只有Msg:R, Msg:A,MsgN。
上半场：
客户端cl_A ...

你的设计，理论上可以这样做。但有一个前提，那就是你用的协议一定是TCP的，因为如果是UDP的话，MsgN被服务端送出，到底cl_B有没有被收到，其实服务端是不知道的，这UDP协议的先天特性，无法改变。

MobileIMSDK用的是UDP协议，用的是4步，而且不管是从算法还是逻辑是都非常简单易懂，比你的TCP这个流程多了一步，有兴趣的话可以去看看。

我们公司现在的消息必达是这么设计的，不需要6步那么复杂，只有Msg:R, Msg:A,MsgN。
上半场：
客户端cl_A发送Msg:R,服务端收到后回Msg:A，此时客户端cl_A认为消息已经送达，但是提示未读。
下半场：
服务端发送Msg:N给cl_B，无论是否送达cl_B都不给服务端回ack，而服务端认为消息是已经到达cl_B。

那下半场怎么保证消息必达呢？用客户端上线同步。
如果服务点Msg:N在发送给cl_B的过程中丢失，那么cl_B一定不在线或者网络有问题，因此如果cl_B再次上线就会向服务端拉取离线期间有没有新的消息，来保证消息不会丢失。

总体看来这种方法，大大简化了消息流程，不用超时不用队列，各位大神看看这种设计有何问题？@JackJiang@JackJiang

引用：researchboy 发表于 2017-09-25 21:21
A端是否重发不应该依赖B端的ack，A把消息成功上报给服务器就应该认为消息投递成功，至于消息是否真的发给了 ...

你的理解其实也是方案的一种，但一个现实情况是：
在高并发的场景下有些逻辑能放到客户端做的就尽量别放到服务端做，因为一个客户端面对的正在聊天中的好友数了不起几十人吧（我说的是正在聊天中的，离线或静默的好友不在此列），这样的计算或资源占用没什么大不了。

但服务端对于动辄10万、百万的同时在线的情况下，多出任何一个业务和处理逻辑那动用的服务端资源都是非常可观的，你把上面的有些可以放到服务端的逻辑试着想想，假如现在放到服务端去实现该面临什么情况呢？

如果你是服务端开发者，你所面对的如此大的并发压力的情况下，你会怎么去做呢？

A端是否重发不应该依赖B端的ack，A把消息成功上报给服务器就应该认为消息投递成功，至于消息是否真的发给了B，以及消息的超时重试机制，应该由后端保障。我觉得这样比较好一些。B端的网络状况的好坏，不应该影响到A用户的感知，否则用户体验会比较差。

引用：JackJiang 发表于 2017-08-02 11:03
你说的还是比较笼统，可以具体的说说

1000个人的群，对于一个群发，就是一条消息被发了1000次，而我们离线存储肯定就存储这一条消息啊，这条消息不但有消息的内容，消息的时间，还会有超时时间。。。这是我的方案

引用：zjjishitongxun 发表于 2017-08-02 10:20
这个可以利用共享模式，对于这种情况只分配一个单元就可以了，减少内存的分配

你说的还是比较笼统，可以具体的说说

引用：kezhaoyuan 发表于 2016-05-10 14:31
有群聊的实现思路吗？群聊要保证到达的话，成本比较大啊。
我之前看过，微信是把群聊分发后，当成个人聊 ...

这个可以利用共享模式，对于这种情况只分配一个单元就可以了，减少内存的分配

讲解的非常清楚，对于个人对个人很清楚，去重机制good

收藏学习啦

学习了

收藏收藏

学习了，楼主牛逼

收藏先·

引用：kezhaoyuan 发表于 2016-05-12 18:49
我们还没正式推出使用，现在还是内部运用。
峰值的问题，是我用机器人压测的时候出现的。我用的vm虚拟机 ...

先把单机性能优化到极致，然后果断考虑集群吧

引用：JackJiang 发表于 2016-05-11 11:23
第2点，要想完美肯定只能集群来解决，不然没有伸缩性，单机的话怎么优化总归是要到终点的，而且不能出现 ...

我们还没正式推出使用，现在还是内部运用。
峰值的问题，是我用机器人压测的时候出现的。我用的vm虚拟机，个人聊天可以达到2k人没问题。群聊300左右就到达峰值了。后面我就用了任务队列，牺牲用户体验了，每个人发消息都要排队，超时就发送失败。

引用：kezhaoyuan 发表于 2016-05-11 11:17
你说的跟微信的设计是一致的，把群消息当个人消息处理。
而2个问题我在实际中确实遇到了。
第1个还好解 ...

第2点，要想完美肯定只能集群来解决，不然没有伸缩性，单机的话怎么优化总归是要到终点的，而且不能出现峰值，一旦出现峰值，单机很快就雪崩了。你们的用户量应该是越来越大了吧，单机终归不是最终解决方案，要自已做好IM，只能持续不断优化架构和设计。

引用：JackJiang 发表于 2016-05-10 15:13
我认为群消息和个人消息，其实以现在的移动端体验来说，应该是没有区别的，所以你不应该从思维里就把群消 ...

你说的跟微信的设计是一致的，把群消息当个人消息处理。
而2个问题我在实际中确实遇到了。
第1个还好解决，通过消息id来排序；
第2个就很麻烦了，群消息对服务器压力实在太大。个人消息，1s顶多两三条消息，而群消息，1s峰值可能达到上百条消息，而且要扩散处理，一下子就指数级暴涨。
对于这一点，请问大大有没有比较好的解决思路，或者应该用什么算法？