即时IM系统

使用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活跃的时候

我们在之前已经实现了ipconfig和etcd服务发现的分析和代码，客户端经过ipconfig找到合适的网关机器然后在上面建立长连接，之后就通过这个网关机器发送和接收消息，网关服务器再转发给后台服务器

本节给大家带来前两节中负载均衡相关代码实现。 网关层 首先是网关层，这里我抽象出了网关层中对负载均衡有用的字段作为结构体： 第一个字段不要说返回的是网关节点的ip和端口，用于定位。之后的就是负载均衡相

上一讲中提到了IM系统中需要拆分出一个接入层网关，这个网关维护了客户端的长链接和用户ID与socket的map关系。拆分完长连接网关层之后我们为了让客户端连接到对应的网关并且使其负载均衡，我们还需要一

数据量或者并发量大到单机承受不住时，就进行多机器部署，此时为了分摊负载压力，我们就需要进行负载均衡和服务发现的处理，下面开始针对即时IM项目进行相关分析，得出重构方案。 一说到负载均衡我们就可以想到n

笔者之前在网上参考了一个IM即时通讯的项目，但是在看完DDIA之后发现这个项目还是太玩具了，虽然支持IM系统中的互发消息，群聊，好友功能和会话功能，但实际实现上相当暴力，就是单机的CRUD加上简单的r