爲何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文檔的內容均爲手打，有任何的不懂均可以直接來問我（公衆號有個人聯繫方式）。