消息推送设计原理和规则

　　推送消息是通过Apple和Google掌控的互联网服务器发送的，推送消息从根本上就是设计用于与应用程序通信的，它们可以发送文本、多媒体文件和特定于应用程序的数据。那么，消息推送的的设计原理和规则是什么？
　　随着iPhone和安卓手机这类超级手机的兴起，现在完全可以绕过运营商，通过标准TCPIP网络直接向这些手机发送消息，这些消息就称为推送消息。
　　推送消息是通过Apple和Google掌控的互联网服务器发送的，推送消息从根本上就是设计用于与应用程序通信的，它们可以发送文本、多媒体文件和特定于应用程序的数据，例如：警告声音和显示在应用程序图标上的标记等。
　　推送通知非常适合智能手机应用，但与基于运营商的移动消息传递相比，它们的普及性和可靠性都较差。
　　消息推送的分类和方式等，如下图：
　　（1）消息提醒的流程
　　输入消息》进入消息仓库》发送消息》消息流水》消息详情
　　（2）消息发送的时间
　　一般为上午9点10点
　　中午12点14点
　　下午5点6点
　　晚上21点22点
　　（3）消息推送的类型
　　优惠券到期通知
　　客服即时消息
　　抽奖商品到期通知
　　收藏降价通知
　　抽奖机会提醒
　　订单发货提醒
　　订单退货提醒
　　购物车商品过期通知
　　拼团到期通知
　　各大活动通知
　　（4）消息推送的规则
　　移动端获得消息通知主要有两种方式：pull（拉）方式和push（推）方式，下面分别对这两种方式做简要介绍。
　　pull方式：
　　pull方式即拉方式，这种方式中手机上的应用程序在启动时及经过一定周期会定时连接应用的服务端来获得服务器需要传递给终端的消息，因为此处是终端从服务端主动获得消息，因此称为拉方式。
　　此方式服务端实现简单，只需要在终端连接上之后把需要发送的消息发送给终端即可，但是此方式有如下弊端：
　　每个应用终端都需要建立到自己服务器的socket连接，移动终端需要维护多个socket连接，较为耗电，不易于管理。
　　采用拉的方式，应用在启动的时候会从应用的服务器上拉取消息；启动之后，应用会周期性的连接服务器去检查是否有消息需要拉取，这种方式并不实时，需要等到终端主动拉取的时候服务器才能把消息传递到终端。如果应用频繁检查是否有消息需要拉取，那么耗电会增加，如果检查周期过长，那么会影响消息的实时性。
　　综上，采用pull方式进行通知消息的传递并不是一个很好的方法。
　　push方式：
　　采用push方式，移动终端只需要和推送服务器之间保持一个长连接即可。这样移动终端用于推送的socket连接数量就与需要推送服务的应用数量无关了，只需要维持一个终端与推送服务器之间的长连接即可，所有应用的服务端都是直接连接推送服务器并通过推送服务器来把消息推送到终端。而终端也只与推送服务器进行连接即可获得推送的通知消息。
　　推送服务器通过长连接，在消息到来的时候可以立即把消息推送到连接上来的终端上，实时性比较高。
　　消息推送示意图
　　消息推送系统逻辑设计图
　　此图中，推送应用1，2，3为推送应用的服务端，其负责把需要推送的消息放入推送系统。这些应用服务端通过负载均衡服务器来连接到具体的推送服务器。
　　服务端是Socket。io的集群，供客户端（Web、移动端）连接。集群后面是一个Redis服务器，保存集群中每个节点（我们称之为Cluster）连接的客户端ID。同时Redis里面为每一个Cluster分配了一个队列，保存推送到这个Cluster的消息。
　　当有消息从某个客户端发出后，所连接的Cluster从Redis里面获取这个消息的目标客户端ID（由于我们同时支持一对一私聊和群组，因此一条消息可能会被推送到多个客户端），然后把消息Push到每个Cluster的消息队列里面。
　　每一个Cluster都会以阻塞方式读取它所对应的消息队列，一旦发现有消息，就获取并且查看其目标客户端ID是不是连接在这个Cluster上。如果是，就通过Socket。io发送，如果不是就丢弃。然后继续阻塞读取，直到下一条消息到达。
　　总结
　　其实粗略来讲，即时通讯消息推送只是一种实现，比如：你可以用第三方产品，很轻易的就可以实现点对点、甚至点对多的消息收发。
　　但是在用户需求很个性化，比如：我要对用户的聊天内容进行监控，涉及到敏感的关键字不让消息推送出去、或者我要对开通会员的用户给予尊贵的身份。
　　相比于免费用户，可以在云端保存时效更久的聊天记录或者可以添加的好友数、群数更多或者无上限，这时候对定制化的要求就非常高，毕竟数据是宝贵的。这时候我们就需要自行开发不能依赖第三方服务。