之前做Android开发，选择了几家即时通讯的方案，这里进行做比较，通常市面上的选择方案还是比较多的，主要是这几个解决方案

使用SessionID替代UserID 当前消息采用用户ID作为发送对象，而不是会话ID，这就造成了在同一个聊天窗口里，A 发的消息和 B 发的消息，使用的是两套完全不相关的序列号体系 。你无法简单地

消息唯一Uuid生成 消息在客户端会生成一个唯一的Uuid，这个Uuid是使用Uuidv4算法生成的128位随机，服务端收到上行之后就会根据消息的Uuid进行去重处理，不是重复请求的话就把消息落库然后

上一节我们实现了上行消息的可靠性，这次我们分析下行消息可靠性应该怎么实现，实现一个可运行的上下行消息通路。 下行消息序列号 我们实现了上行消息可靠性，保证服务端处理消息的顺序和用户期待的顺序一致，服务

上一节中我们分析了消息可靠性应该怎么做，这次我们进行具体实现。 上行消息可靠回顾 要保证客户端发送消息可靠的话，我们就必须在客户端与服务端交互的protocal.proto文件中添加几种新的消息类型，

上一节我们实现了消息协议的定义和交互测试，这一节我们需要实现消息的可靠性。 从端到端的设计思想来看，无论底层依赖何种通信协议（无论是 TCP、UDP 还是 QUIC），业务层都必须对自己业务数据的可靠

在网关层我们通过Epoll实现了对于用户长连接FD的监听，大大减少了协程数的消耗，还通过gateWay将消息转发给StateServer进行处理，这样网关层就只负责维护长连接FD和用户ID与长连接FD

在网关层（上）中我们实现了多Reactor模型监听用户连接的FD，不需要再为每个连接FD开启两个阻塞监听的读写协程，大大节省了服务器的资源。在这一节中我们需要实现网关层的核心逻辑，收发消息和转发请求给

上一节我们讲过要实现epoll监听用户建立的收发消息的FD，这样可以通过一个epoll协程监听多个FD，然而在大规模并发场景下， 单个协程监听所有 FD 依然存在明显的性能瓶颈。 当大量FD活跃的时候