打造基於大併發通訊技術及大數據技術的O2O系統

本文來自於個推CTO葉新江在2015Qcon的分享整理。

截止2015年6月，個推SDK累計接入總用戶數達50億 (其中海外近5億)，接入應用超過35萬，開發者人數近20萬，覆蓋獨立終端超過8億（其中海外超過1億），日均活躍用戶近6億，日分發消息20億條。

這麼龐大的數據，是如何作到的呢？2011年公司作的是小規模IM產品，發展思路偏向於拿來主義，和不少開發者同樣會選擇MySQL來做爲網站數據庫。到了2011年，從新設計了系統架構，選擇了更爲開源的大併發通訊系統；直至去年，多地協同、流式處理的理念應運而生，造成了大分佈及大數據的處理系統。從單點的數據庫到點與點的通信，再到網絡結構系統，不只須要克服思惟上的侷限，更須要挑戰服務器的極限。
例如：延遲和吞吐量，用戶多了以後如何在保證延遲可接受的狀況下達到想要的吞吐？關於這點你們能夠回想下Java虛擬機的垃圾回收算法。

如下是開發大併發通訊系統的相關經驗：

1.內部服務調用方式
關於調用方式，異步非侵入式是首選。無需等待返回值的函數調用絕對擁有最高的收益，輔以非侵入調用就能最大程度上減小對目標程序的佔用。

2.JVM及線程調優
個推選擇CMS（Concurrent Mark-Sweep）做爲GC（Garbage Collection)，默認了92%的回收觸發條件。另外要注意的是Linux下的性能調優，如MAT的使用，利用 top-p-H 來查看CPU佔用狀況，利用jstack,jmap命令定位問題所在等。

3.TCP 闌尾
TCP是全雙工的，所以關閉鏈接必需要在兩個方向上分別進行，反覆的通道開啓和關閉很容易帶來問題。起初TW(Time Wait)就是爲了克服不穩定的網絡帶來的丟包等問題，現在隨着網絡技術的發展，TW已經成了雞肋。另外，雖說TW狀態的鏈接既能夠被回收（Recycle）又能夠被重用（Reuse），但沒有人願意冒這雙重風險。在兩者選其一時，能在時間戳上知足接入規律的Reuse有着明顯的優點。

4．健壯保障
須要重點關注：關鍵詞，如流控、維穩、異常隔離、分降級、斷續處理等。就流控而言，有可能出現SDK發送數據存在邏輯問題而致使浪涌現象的狀況。

5.分佈式事務
如何在分佈式狀況下實現將100元錢從A轉到B？傳統思惟是按照A.C.I.D原則進行操做。A.C.I.D指數據庫事務正確執行的四個基本要素。包含：原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation）和持久性（Durability）。這裏我詳細討論下另外一種替代方案——B.A.S.E，Basic Availability：基本可用；Soft-state ：軟狀態/柔性事務，能夠理解爲」無鏈接」的, 而 「Hard state」 是」面向鏈接」的；Eventual consistency：最終一致性，最終整個系統（時間和系統的要求有關）看到的數據是一致的。在B.A.S.E中，強調可用性的同時，引入了最終一致性這個概念，不像A.C.I.D，並不須要每一個事務都是一致的，只須要整個系統通過必定時間後最終達到是一致的。首先肯定考慮因素，即用什麼方式來分割交易事務，資源方面有哪些要求，如何保證冪等性。

接下來是具體實現方式，流程以下：

1.設置業務交易記錄表 T, 並創建一套和 T 相同存儲的隊列 Q
2.記錄交易到 T, 同時放入隊列 Q, 兩個動做一個事務
3.A設置一個已處理交易記錄表TA
4.監測 Q, 若是有給 A 的交易請求，則
開始事務
查看 TA 中是否有處理過此交易
If沒有處理過 then
更新 A 記錄
把處理痕跡寫入 TA
end if
結束事務
If 上面的事務處理成功 then
Q出列
end if
1. B也按上述方式處理

---

使用分佈式事務有助於簡化應用開發，使用消息隊列明顯須要更多的工做量，二者各有優劣。
總結：對於時間緊迫或者對性能要求不高的系統，應採用分佈式事務加快開發效率，對於時間需求不是很緊，對性能要求很高的系統，應考慮使用消息隊列方案。對於原使用分佈式事務，且系統已趨於穩定，性能要求高的系統，則可使用消息隊列方案進行重構來優化性能。

6.關於前瞻和成本
舉個簡單的例子——數據分區。實施前肯定須要的資源，事先規劃和分割，看到資源的限制後安排後期數據搬遷，最後利用redis內存分配佔用。

最後談一點咱們理解的O2O下的推送。咱們的核心爲5W，即在合適的時間（When）、合適的地點（Where）、合適的場景（Which）把合適的內容（What）推送給合適的人（Who）。好比中午12點，用戶來到了到中關村附近，平常比較喜歡粵菜，天然但願收到有關粵菜館的一些優惠信息或者位置信息。在推送依據上，個推依賴於用戶畫像，而且根據場景進行高效的信息推送。