为何PUSH推送常常要背锅？

前言

只有光头才能变强。

文本已收录至个人GitHub精选文章，欢迎Star：github.com/ZhongFuChen…

自从作了推送之后，每隔一段时间就发现有各大的公司推送事故出现。

你问我作开发的慌不慌，我固然慌得一批了。

为何常常会有推送事故

为何会常常出现相似的事故呢？我认为最主要的缘由是：预发和线上的环境是同一套。

众所周知，咱们的系统都有几套的环境（好比说本地/线下/预发/线上 环境），其中大多数公司的预发和线上环境数据库是同一套的，只是预发环境调用的是预发环境的接口，线上环境调用的是线上环境的接口而已。

推送这种系统的线上和预发环境其实没多大的区别，由于在底层是调用外部的接口来实现发送的，因此预发和线上环境其实调的都是同一个接口。

科普一下推送是怎么作的

以前写过一篇关于推送的文章，也算是科普了一把什么是推送消息，有兴趣的同窗能够去看看： 三歪带你了解什么是Push消息推送。此次在上面的文章基础上补全一下。

Push推送消息可以在你手机闭屏时(即使你没有打开APP)，经过通知来给你推送信息，是一种可以直接触达用户的消息推送

要给用户下发消息，咱们得维护APP 客户端和服务端的「长链接心跳」。这个长链接心跳若是由咱们自行来维护，难度会很大，绝大部分的公司不会自建推送服务。

目前咱们手机类型分为两种：安卓和iOS。

• iOS咱们默认走的是官方推送的渠道 APNS。iOS 在系统层面与苹果 APNs（Apple Push Notification service）服务器创建链接，系统收到 APNs 服务器消息后会帮咱们转发到相应的APP上
• 安卓因为Google在国内访问不稳定，在国内 暂未统一掉推送服务。目前更多的是众多的手机厂商在其 定制的系统中也内置了推送功能，如小米、华为等。因为接入成本的问题，也出现了大量的第三方推送服务提供商，好比个推、极光、友盟。

  • 工信部牵头成立的“安卓统一推送联盟”还在期待中

总结：

• iOS端咱们更多用的是APNs服务器下发推送消息
• 安卓端因为接入成本的问题，更多的是接入各个第三方推送服务提供商，第三方推送服务提供商也会接入对应的手机厂商来实现对消息的下发

咱们作了什么预防推送事故？

在大多数状况下，推送事故每每是「运营」的推送致使的。运营要推送消息给用户，首先须要圈选一我的群去推送。

人群量须要管控：咱们在圈选的时候，若是运营圈定的人数大于一个阈值，咱们会走邮箱让主管确认是否须要圈选这么一个大的人群去推送。

这块有两个目的：

1. 首先咱们是认为推送的人群应该是精细化的，什么标签的人群应该收到什么的推送。不该该圈定一个庞大的人群去推送同一条文案的消息（新闻APP除外）。
2. 即使出了事故，也只是一部分用户能收到，而不是全体用户。

在咱们的系统是没有全体用户推送的。

在运营圈定人群后，咱们会有单独的测试功能去「测试单个用户」是否能正常下发消息，文案连接是否存在问题。

这一个步骤是必需要作的，给用户发出的消息，首先要通过本身的校验。若是确认连接和文案都无问题后，则提交任务，走工单审批后才能发送。

若是在启动以后发现文案/连接存在问题，还能够拦截剩余未发的消息。

针对于通知类的消息（技术方推送），咱们在预发环境下配置了「白名单」才能收到消息。

线上消息有「去重」的逻辑：

• 在某段时间内，过滤掉重复消息
• 运营类消息推送（圈定人群的方式去下发消息）同一个用户须要相隔一段时间才能下发一次。

虽说，咱们制定了不少的规则去尽可能避免事故的发生，但不得不说推送仍是一个容易出现事故的功能。

个人牛逼已经吹完了，若是某天发现个人推送出了事故，不要@我，当没见过这篇文章就好。

各种知识点总结

下面的文章都有对应的原创精美PDF，在持续更新中，能够来找我催更~

• 92页的Mybatis
• 129页的多线程
• 141页的Servlet
• 158页的JSP
• 76页的集合
• 64页的JDBC
• 105页的数据结构和算法
• Spring家族
• Hibernate
• AJAX
• 监听器和过滤器
• ......

涵盖Java后端全部知识点的开源项目（已有7 K star）：github.com/ZhongFuChen…

若是你们想要实时关注我更新的文章以及分享的干货的话，微信搜索Java3y。

PDF文档的内容均为手打，有任何的不懂均可以直接来问我（公众号有个人联系方式）。