电脑
生活常识
解决办法如何保证实时性我们可以接收生产者传来的消息：内部会为每条消息生成一个全局唯一、与业务无关的消息id，当接收到消息时，会先根据该id判断消息是否重复发送，再决定是否接收该消息。
问题产生的原因然后就是面对于生产者已把消息发送到mq，在mq给生产者返回ack的时候网络中断，故生产者未收到确定信息，生产者认为消息未发送成功，但实际情况是，mq已成功接收到了消息，在网络重连后，生产者会重新发送刚才的消息，造成mq接收了重复的消息消费者在消费mq中的消息时，mq已把消息发送给消费者，消费者在给mq返回ack时网络中断，故mq未收到确认信息，该条消息会重新发给其他的消费者，或者在网络重连后再次发送给该消费者，但实际上该消费者已成功消费了该条消息，造成消费者消费了重复的消息；
我们都知道当我们在处理大群消息推送时，写离线消息也是一个非常影响性能的地方。现有的逻辑是先为每个人写一条离线消息，再执行推送。这样做的初衷是确保消息投递绝对可靠（参看《一个海量在线用户即时通讯系统（IM）的完整设计》的离线消息章节）。由于大群人数较多，写离线消息也有较多时间开销。优化思路是现将消息及时推送给用户，再异步写离线消息，同时处理好写离线消息和推送消息的ack时序。
具体怎么做现阶段，当消息（尤其是大群消息）量大的时候，Deliver节点会成为瓶颈。红包对时效性要求很高，架构上采用独立为红包部署Deliver节点的方式确保红包消息走单独通道进行推送。即使其他消息出现延迟，红包消息依然能保证即使送达。 处理一条群消息，服务端要进行大量的工作，需要查询所有群成员的路由表、在线状态，在线人员需要推送及时消息，离线人员需要推送第三方push（比如IOS的apns）。这些工作逐条执行，性能会非常差，如果遇到大群，系统会不可用。批处理可以较好解决这个问题。比如用户状态及路由表数据，采用hash算法分布在几台服务器上。收到群消息后，根据群成员，计算出用户状态及路由表数据的分布情况，从缓存服务器中一次检索出该服务器可能存在的所有群成员状态及路由信息。这样可以极大减少RPC调用次数，及计算量。推送操作也类似，批量向接入层投递消息即可
合理安排与操作
不要急于求成