为什么PUSH 推送要经常背锅？

前言

只有光头才能变强。

文本已收录至我的GitHub精选文章，欢迎Star：https://github.com/ZhongFuCheng3y/3y

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

你问我做开发的慌不慌，我当然慌得一批了。

为什么经常会有推送事故

为什么会经常出现类似的事故呢？我认为最主要的原因是：预发和线上的环境是同一套。

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

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

科普一下推送是怎么做的

之前写过一篇关于推送的文章，也算是科普了一把什么是推送消息，有兴趣的同学可以去看看： 三歪带你了解什么是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）：https://github.com/ZhongFuCheng3y/3y

如果大家想要实时关注我更新的文章以及分享的干货的话，微信搜索Java3y。

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