LiveChat消息可靠性

[linhtV]

基于长轮询消息可靠性分析

系统逻辑架构

1. user/agent 通过长轮询与user connector和agent connector进行通信。
2. connector 与 chat可以分开部署或一起部署，connector 主要屏蔽各个接入者由于接入渠道不同产生的差异，将各个渠道的消息转化为chat可以识别的消息。connector与chat，chat与redis cluster集群调用均采用远程rpc调用，为了架构的一致性与减少各个服务的状态，各个服务间均不采用连接。
3. user可以是web客户端，也可以是第三方平台如wechat。那么如果是第三方平台则user与user connector间的消息可靠，去重由第三方保证。

   可靠性解决方案

     传统方式im系统会在接收到接收方成功处理消息的应答后，向消息发送方发送确认，消息的可靠性主要由消息发送方来保证，这样会增加第三方用户的开发成本。   出于chat的定位，以及基于系统中connector与chat之间通过长轮询方式首发消息，只要user/agent发送的消息到达chat，接受者agent/user一定能通过轮询的方式将消息取走，因此解决思路主要是保证connector与chat两两之间的消息可靠投递。以防止传统解决方案中，由于网络或接收方的异常，不能轮询走发送方已经成功投递到chat的消息，而对已经成功投递到chat的消息进行重复重发。简而言之就是消息的可靠性由chat 进行保证。

   chat消息缓存设计

     发送方向chat发送消息，chat成功处理消息后同步返回确认消息。   发送方提供一个消息发送序列，可以采用本地时间戳，chat以此对消息进行排序。如a-local-timestamp chat根据消息接收方的唯一标识在redis上维护三个队列，分别是消息实体队列，待确认消息队列，待接收消息队列。

   轮询接口定义

     chat提供轮询消息接口：getMsgs(receiverId:String,preAcks:list) 其中receiverid为消息接收者唯一标识，preAcks是接收方对上一轮轮询收到消息的确认。

   消息队列说明

   • TO-BE-REV-MSG-B:带接收与待确认消息实体列表。
   • TO-BE-REV-B:待轮询消息，接收方还未轮询取走的消息列表，根据发送方的发送序列进行排序。
   • TO-BE-ACK-B:待接收方确认的消息，0为消息未确认，1为已确认。

     消息接收流程：

4. 发送方发送消息到chat，chat成功存储消息(写入redis及数据库)后同步返回确认。
5. 等待接收方进行轮询消息。

• 消息001是已经接收方确认过的消息，实际处理过程中对已经确认的消息会从缓存中清除，这里为便于理解把它显示出来，实际是根据preAcks将消息从TO-BE-ACK-B,TO-BE-REV-MSG-B中清除。
• 消息002是上一轮已经取走但还未被接收方确认的消息。若下一轮接收方成功发挥对该消息的确认id，那么该消息也会如001一样处理。若没有返回该消息的确认id则会从新将该消息的id写入到TO-BE-REV-B中。待下一次轮询。
• 消息003是发送方最新发送的消息，待下一次轮询。

[linhtV]

user connector 与第三方平台(wechat)之间的调用流程，细节。