关于实时消息推送系统的架构之浅见

最近，有一个朋友问了一个问题：如何实现实时消息推送架构，当时只是说了比较笼统的概念，并没有进行深入的探讨。再加上时间比较也就没有进行一个归总。刚好今天进行一个梳理。具体内容如下

那么整体的设计如上。接下来我们针对每一块进行剖析

1、协议的选择

   关于协议的选择这块，现在比较常用的方式：XMPP、MQTT、自定义协议等，那么关于每种协议的优缺点，这里面我们不进行细致描述。只要知道最终的目的：

   （1）、协议轻量、编解码速度快捷；

   （2）、流量消耗小

2、连接方式 常用的连接方式：

      轮询、长连接、websocket等各种方式同样具有不同的优缺点，具体的目的

    （1）、连接稳定；

    （2）、不同网络环境使用不同的心跳间隔；

    （3）、app连接消耗平衡；

3、海量连接 针对海量连接都会使用到负载均衡；常见的方式：

    lvs/nginx做负载均衡、服务端负载均衡、客户端负载均衡；首先我们应该明白国内的网络环境关于dns的问题；可以通过ip来直接完成；通过预埋ip或者提供webservice来获取相关的ip等方式；

 关于负载均衡：

          (1)、lvs负载均衡存在单点问题：可通过提供一个vip来做高可用

          (2)、服务端负载均衡：选择负载低的服务器

          (3)、客户端负载均衡：采用跑马策略来完成负载均衡，同时也解决跨运营商网络慢的问题

4、消息重复 一般情况下，在网络正常的情况下，消息的发送可能一个平衡的状态。但是在不同网络环境2G/3G/4G/WIFI等，可能我们就面临消息重复的问题。在这个问题上我们一般采取的方式通过将回执--响应转为

        (1)、第一阶段欲请求：服务端发送通知到客户端，客户端接收到通知之后返回最近接收消息的最大序列号（将msg绑定序列号）；

        (2)、服务端验证序列号避免消息重复；

        (3)、第二阶段正式发送消息:发送消息

5、运维、扩展 在上图的架构中并没有存在 服务管理、运营监控以及预埋服务（解决dns问题）

6、架构介绍 整个架构在逻辑上，划分四层：

    （1）、接口服务：提供推送服务接入

    （2）、分发服务：主要完成下行消息和上行消息的路由；同时提供一个对应的路由表，主要提供 clientId、GroupId、ServerId之间的关系映射。

    （3）、订阅信息：通过订阅的不同的消息，完成对应的消息的推送

    （4）、存储：防止消息的丢失 基本上整个架构就这样。其中有很多细节并没有进行一个很详细的阐述。同时在构建一个实时推送系统存在很多坑。这里面也没有进行详细描述和分析。