目前大多数消息推送系统都通过建立TCP长连接的方式主动进行消息推送，服务端需要做连接管理，心跳管理，离线消息等，我们现在只讨论客户端的实现，权当服务端已万事俱备，只欠客户端。
方式一：每一个（应用）SDK都建立一个TCP长连接。如图：
这种属于比较原始的方式，也是国内移动端推送刚刚开始使用的方式。每一个应用都需要建立一个长连接，在设备端，特别是移动端是特别耗资源的，服务器也要同时管理很多连接，也不清闲。所以目前这个方式已经基本不再使用了。
方式二：另外安装一个代理服务程序，连接的连接，请求，下发都由其代理。如图：
这种方式比方式一节省资源，无论是服务端还是客户端，只需要建立一个TCP长连接。但是代理程序不是你想安装就能安装的，特别实在移动端，用户使用你的软件，居然还要下载一个用户不知道的东西，体验很不好。就像有一些用C#写的安卓应用，安装之后，还要弹出一个框，让我去下载一个mono运行环境，不能忍，直接卸载掉。但凡事都有例外，这种方式虽然在移动端体验不好，但是在电视，盒子这种系统是自家公司定制的地方却大有用处，自己公司定制的系统，直接将代理服务程序弄成系统服务程序，说白了那就是系统级推送，稳定性比用户级推送有很大的提升，维护起来也比较容易和方便。
方式三：目前的普遍做法,SDK集群。如图：
这种方式是通过应用集群实现的，其参照了服务端集群的思想，比如zookeeper集群（ZAB），etcd（RAFT），consul（RAFT）等，甚至还有比较难以理解的paxos实现。核心思想就是大家一起投票选举出老大，之后的流程都由老大代理，后续流程和方式二是一样的。这个方式结合第一种和第二种的优点，又避免了它们各自的缺点，因此现在的推送平台（友盟，极光等）基本都实现了这种推送方式。
基本介绍就到这里，下次我们再来讨论心跳系统的实现方式。
