版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/gx_1983/article/details/79461979
移动设备获得通知的两种方式
随着移动互联网的发展，越来越多的移动端应用得到普及，此处的移动端不仅仅限于手机，还有很多设备也参与到移动互联中来。比较典型如微软的xbox等，这些设备上运行的应用都需要具有一定的消息通知功能。那么消息是如何从应用的服务端到达应用终端，也就是各种移动设备上呢？目前，移动端获得消息通知主要有两种方式：pull(拉)方式和push(推)方式，下面分别对这两种方式做简要介绍。
pull方式
pull方式即“拉方式”，这种方式中手机上的应用程序在启动时及经过一定周期会定时连接应用的服务端来获得服务器需要传递给终端的消息，因为此处是终端从服务端主动获得消息，因此称为拉方式。
此方式服务端实现简单，只需要在终端连接上之后把需要发送的消息发送给终端即可，但是此方式有如下弊端：- 每个应用终端都需要建立到自己服务器的socket连接，移动终端需要维护多个socket连接，较为耗电，不易于管理。
- 采用拉的方式，应用在启动的时候会从应用的服务器上拉取消息；启动之后，应用会周期性的连接服务器去检查是否有消息需要拉取，这种方式并不实时，需要等到终端主动拉取的时候服务器才能把消息传递到终端。如果应用频繁检查是否有消息需要拉取，那么耗电会增加，如果检查周期过长，那么会影响消息的实时性。
- 综上，采用pull方式进行通知消息的传递并不是一个很好的方法。
push方式
采用push方式主要有点如下：
- 采用push方式，移动终端只需要和推送服务器之间保持一个长连接即可。这样移动终端用于推送的socket连接数量就与需要推送服务的应用数量无关了，只需要维持一个终端与推送服务器之间的长连接即可，所有应用的服务端都是直接连接推送服务器并通过推送服务器来把消息推送到终端。而终端也只与推送服务器进行连接即可获得推送的通知消息。
- 推送服务器通过长连接，在消息到来的时候可以立即把消息推送到连接上来的终端上，实时性比较高。
一个典型的消息推送系统设计
设计通知推送系统需要考虑的几个问题
- 推送应用认证问题：使用推送系统的应用首先需要认证，只有认证通过的应用才允许使用推送系统推送消息。
- 多个推送服务器的负载均衡问题：通过在推送应用服务端程序与推送服务器之间放置tcp负载均衡服务器来实现。
- 移动端服务器连接负载均衡问题：通过DNS负载均衡来实现。
- 推送消息时，移动终端在线，则消息应该立即送达。
- 推送消息时，移动终端不在线，那么分两种情况：对于按序消息，应该每条消息都保存，在移动终端上线时按照顺序由移动终端主动拉取，此时，新的推送消息要等待之前的消息都被接收之后再实时推送；对于覆盖消息，只保留最后一条消息，在移动终端上线之后直接实时推送消息。
消息推送系统示意图
- 此图展示了实际应用场景中消息推送的关系。
- 在实际应用场景中，需要推送的应用服务端只与推送系统进行交互，它并不知道是否有及有多少终端需要被推送消息。服务端把需要推送的消息交给推送系统，其余的就不是应用服务端需要关心的事情了。
消息推送系统逻辑设计图
- 此图中，推送应用1，2，3为推送应用的服务端，其负责把需要推送的消息放入推送系统。这些应用服务端通过负载均衡服务器来连接到具体的推送服务器。负载均衡服务器在应用连接过来时，首先会通过