前言 在解決了上一次關於超級話題積分bug後，又接到超級話題簽到提醒的產品需求。這是一篇偏於技術實現的文章，講述的比較籠統，業務圍繞超級話題的簽到提醒進行展開。如果，您對超級話題簽到提醒的技術背景與實現感興趣，那麼這篇文章希望對你有幫助。 產品 最近，在忙活超級話題的簽到提醒產品的開發。首先，這是第 ...
前言
在解決了上一次關於超級話題積分bug後，又接到超級話題簽到提醒的產品需求。這是一篇偏於技術實現的文章，講述的比較籠統，業務圍繞超級話題的簽到提醒進行展開。如果，您對超級話題簽到提醒的技術背景與實現感興趣，那麼這篇文章希望對你有幫助。
產品
最近，在忙活超級話題的簽到提醒產品的開發。首先，這是第一次比較熱切的關註用戶反應的產品。雖然說，對於產品的參與和認知並沒有多麼深入的理解，但是愈發的覺得這件事很有意識，也更想參與其中。
超級話題打破了傳統話題的模式，以社區的形式展現，提高用戶互動與粘性。其中，簽到是不可或缺的一項功能。然而在前期，簽到功能在給用戶帶來了高回訪的情況下，也有著苦惱。作為研發同學，更是備受折磨。為什麼？產品總是拿著反饋中自稱經簽過但卻莫名斷簽的用戶ID找我排查問題所在。然而，幾乎都是一些凌晨時分簽到而次日未簽的情形。儘管是這樣，用戶的反感也是無法消除的。
為了不再做反覆的排查勞動，只好做了一個相關查詢後臺。
產品同學為了召回用戶，提供話題的UV和PV，提出了簽到提醒的概念。
簽到提醒會根據當前用戶的簽到行為，進行提醒私信的推送。目前為止，基本上每日需要提醒的量大約在85w左右。然而，在發送私信的過程中並非如此順利。
技術
- 準備數據
首先，要進行數據的準備。利用crontab定時將DB中的數據寫入磁碟文件。之所以這麼做，主要是由於DB中的數據是動態的，需要將數據寫成靜態的形式以更好的分批處理。
- 發送私信
然仍採用crontab定時啟動發送私信的腳本。將啟動n個進程，同時處理上述步驟生成的n個文件。以curl_multi的方式批量調用話題粉絲服務的內部介面。
數據
超級話題提醒私信下發量：85W/日
超級話題提醒倒流UV：可觀
下麵的Redis服務中Key的曲線圖，可以約等於下發的私信量：
- 超級話題簽到提醒redis-key優美的曲線圖
問題
在形成上面的技術流程之前，也是經過了幾番周折。
- 單進程
最初，以單進程的方式直接從DB讀取數據，單次調用粉絲服務的介面進行發送私信。然而，在這種情況下，每日（2.5個小時）卻只能發送5-6w的私信量。
- 批量調用
由於壓力主要在外部粉絲服務介面上，所以採取了批量調用的方式。利用PHP中的curl_multi，逢10批量調用粉絲服務介面。這樣下來，每日（5.5個小時）能發送51w左右的私信。
- 多進程 & 批量調用
然而，還是不能滿足近100w的私信調用量。所以，增加了數據準備階段。將數據寫成靜態文件，以多個進程的形式，同時處理文件以批量調用粉絲服務介面來發送私信。
在功能上線的第一天晚間，觀察處理文件的進程“卡死”。
- strace PHP 進程信息截圖
- lsof PHP進程信息截圖
從上面兩圖可以確定，PHP進程卡死的原因在於讀取MySQL服務中。進過排查處理後，程式得以進入正常流程。
目前為止，每日的調用量完全可以滿足所需要發送的私信量。
用戶
用戶對簽到提醒的反饋還是非常不錯的，有圖為證：
總結
針對於這種需要長時間運行與調用外部資源的腳本，最重要的就行要進行好完善的異常處理機制。由於PHP腳本的異常處理並非強制的，如果處理不妥到，會導致進程直接終止，排查起來也很困難。
同時，對於相關資源的監控也很重要。比如，當前機器的CPU資源，介面的平均響應時間，DB服務的相應時間等等。以確定每次執行期間相關資源的健康狀態。
文章來源：胡旭博客 => 自從有了她，再也不怕斷簽了：超級話題簽到提醒
轉載請註明出處，違者必究！
