app消息推送实现原理，app消息推送实现原理和规则？

随着 iPhone 和安卓手机这类超级手机的兴起，现在完全可以绕过运营商，通过标准 TCP/IP 网络直接向这些手机发送消息，这些消息就称为推送消息。
推送消息是通过 Apple 和 Google 掌控的互联网服务器发送的，推送消息从根本上就是设计用于与应用程序通信的，它们可以发送文本、多媒体文件和特定于应用程序的数据，例如：警告声音和显示在应用程序图标上的标记等。
推送通知非常适合智能手机应用，但与基于运营商的移动消息传递相比，它们的普及性和可靠性都较差。
消息推送的分类和方式等，如下图：
（1）消息提醒的流程
输入消息》进入消息仓库》发送消息》消息流水》消息详情
（2）消息发送的时间
（3）消息推送的类型
（4）消息推送的规则
移动端获得消息通知主要有两种方式：pull（拉）方式和push（推）方式，下面分别对这两种方式做简要介绍。
pull方式：
pull方式即“拉方式”，这种方式中手机上的应用程序在启动时及经过一定周期会定时连接应用的服务端来获得服务器需要传递给终端的消息，因为此处是终端从服务端主动获得消息，因此称为拉方式。此方式服务端实现简单，只需要在终端连接上之后把需要发送的消息发送给终端即可，但是此方式有如下弊端：
每个应用终端都需要建立到自己服务器的socket连接，移动终端需要维护多个socket连接，较为耗电，不易于管理。
采用拉的方式，应用在启动的时候会从应用的服务器上拉取消息；启动之后，应用会周期性的连接服务器去检查是否有消息需要拉取，这种方式并不实时，需要等到终端主动拉取的时候服务器才能把消息传递到终端。如果应用频繁检查是否有消息需要拉取，那么耗电会增加，如果检查周期过长，那么会影响消息的实时性。
综上，采用pull方式进行通知消息的传递并不是一个很好的方法。
【app消息推送实现原理，app消息推送实现原理和规则？】push方式：
消息推送示意图

文章插图
消息推送系统逻辑设计图

文章插图
此图中，推送应用1，2，3为推送应用的服务端，其负责把需要推送的消息放入推送系统。这些应用服务端通过负载均衡服务器来连接到具体的推送服务器。
服务端是Socket.io的集群，供客户端（Web、移动端）连接。集群后面是一个Redis服务器，保存集群中每个节点（我们称之为Cluster）连接的客户端ID 。同时Redis里面为每一个Cluster分配了一个队列，保存推送到这个Cluster的消息。
当有消息从某个客户端发出后，所连接的Cluster从Redis里面获取这个消息的目标客户端ID（由于我们同时支持一对一私聊和群组，因此一条消息可能会被推送到多个客户端），然后把消息Push到每个Cluster的消息队列里面。
每一个Cluster都会以阻塞方式读取它所对应的消息队列，一旦发现有消息，就获取并且查看其目标客户端ID是不是连接在这个Cluster上。如果是，就通过Socket.io发送，如果不是就丢弃。然后继续阻塞读取，直到下一条消息到达。
总结其实粗略来讲，即时通讯-消息推送只是一种实现，比如：你可以用第三方产品，很轻易的就可以实现点对点、甚至点对多的消息收发。
但是在用户需求很个性化，比如：我要对用户的聊天内容进行监控，涉及到敏感的关键字不让消息推送出去、或者我要对开通会员的用户给予“尊贵的身份” 。