关于实时消息推送系统的架构之浅见
最近，有一个朋友问了一个问题：如何实现实时消息推送架构，当时只是说了比较笼统的概念，并没有进行深入的探讨。再加上时间比较也就没有进行一个归总。刚好今天进行一个梳理。具体内容如下
那么整体的设计如上。接下来我们针对每一块进行剖析
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）、存储：防止消息的丢失 基本上整个架构就这样。其中有很多细节并没有进行一个很详细的阐述。同时在构建一个实时推送系统存在很多坑。这里面也没有进行详细描述和分析。
