前言
只有光頭才能變強。
文本已收錄至我的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服務器下發推送消息
- 安卓端由於接入成本的問題，更多的是接入各個第三方推送服務提供商，第三方推送服務提供商也會接入對應的手機廠商來實現對消息的下發
我們做了什么預防推送事故？
在大多數情況下，推送事故往往是「運營」的推送導致的。運營要推送消息給用戶，首先需要圈選一個人群去推送。
人群量需要管控：我們在圈選的時候，如果運營圈定的人數大於一個閾值，我們會走郵箱讓主管確認是否需要圈選這么一個大的人群去推送。
這塊有兩個目的：
- 首先我們是認為推送的人群應該是精細化的，什么標簽的人群應該收到什么的推送。不應該圈定一個龐大的人群去推送同一條文案的消息（新聞APP除外）。
- 即便出了事故，也只是一部分用戶能收到，而不是全體用戶。
在我們的系統是沒有全體用戶推送的。
在運營圈定人群后，我們會有單獨的測試功能去「測試單個用戶」是否能正常下發消息，文案鏈接是否存在問題。
這一個步驟是必須要做的，給用戶發出的消息，首先要經過自己的校驗。如果確認鏈接和文案都無問題后，則提交任務，走工單審批后才能發送。
如果在啟動之后發現文案/鏈接存在問題，還可以攔截剩余未發的消息。
針對於通知類的消息（技術方推送），我們在預發環境下配置了「白名單」才能收到消息。
線上消息有「去重」的邏輯：
- 在某段時間內，過濾掉重復消息
- 運營類消息推送（圈定人群的方式去下發消息）同一個用戶需要相隔一段時間才能下發一次。
雖然說，我們制定了很多的規則去盡量避免事故的發生，但不得不說推送還是一個容易出現事故的功能。
我的牛逼已經吹完了，如果某天發現我的推送出了事故，不要@我，當沒見過這篇文章就好。
各類知識點總結
下面的文章都有對應的原創精美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。