摘要：開篇金幣積分商城下稱商城是眾多內(nèi)的一個產(chǎn)品，隨著使用的用戶越來越多，商城對于用戶留存的提升，扮演著重要的角色做為提高用戶黏性的核心產(chǎn)品，在擁有很好用戶體驗的同時，也必須存在著一個高效穩(wěn)定的系統(tǒng)。分析上述兩點，得到結(jié)論按用戶進行分庫分表。

金幣（積分）商城（下稱“商城”）是眾多App內(nèi)的一個產(chǎn)品，隨著App使用的用戶越來越多，商城對于用戶留存的提升，扮演著重要的角色；做為提高用戶黏性的核心產(chǎn)品，在擁有很好用戶體驗的同時，也必須存在著一個高效、穩(wěn)定的系統(tǒng)。

商城，是一個基于虛擬貨幣（下稱“金幣”）進行運營的產(chǎn)品，也就意味著，我們需要給用戶發(fā)放金幣，用于用戶兌換各種獎品。我們需要詳細記錄用戶金幣的收支情況，并提供給用戶查詢。在redis、memcache盛行的時代，構(gòu)建一個幾十萬QPS的只讀系統(tǒng)并不復雜，需要做到：無狀態(tài)服務+多級緩存，并且能夠進行水平擴展，應該就差不多了。而商城需要記錄每秒十萬的用戶行為，需要的是每秒數(shù)十萬（這里翻倍了）的數(shù)據(jù)讀寫（insert&update)操作，這種量級是無法在單實例數(shù)據(jù)上完成的，那么該如何分庫分表。

Tip 1 . 在做設計時，首先要明確3個事情

業(yè)務場景，不要空談設計，場景是什么
目標，系統(tǒng)需要做到的目標是什么
分析上述兩點，得到什么結(jié)論

那么，對于用戶行為數(shù)據(jù)的場景是：1.用戶A查詢自己的所有金幣記錄（不能查別人的），2.查看商城內(nèi)金幣數(shù)量分布情況。對于第二個場景可以直接通過大數(shù)據(jù)進行統(tǒng)計分析（不進行詳細解讀）。對于第一個場景，系統(tǒng)需要做到的目標是：用戶A只進行一次查詢，就可以得到所有數(shù)據(jù)（不考慮分頁場景）。分析上述兩點，得到結(jié)論：按用戶id進行分庫分表。（分析過程有些磨嘰了，哈哈，忍著）
原則明確后，能夠開始進行分庫分表嗎？不能。需要進一步確認，如何分？分多少？擴容成本？對于數(shù)據(jù)庫擴容，我們選擇以2的N次冪進行擴容，這種方式的好處是，進行擴容時，只需要將數(shù)據(jù)copy一份就可以，上層應用增加數(shù)據(jù)庫節(jié)點，無需考慮數(shù)據(jù)遷移問題（可靠性高），不好的地方是，會產(chǎn)生臟數(shù)據(jù)，這個問題并沒太多影響，按照擴容后規(guī)則，刪除即可。對于分表，我們將金幣記錄在每個庫中拆成5份。

Tip 2 .為什么要進行分庫分表

服務器資源（cpu、磁盤、內(nèi)存、IO）遇到瓶頸
數(shù)據(jù)量變大，數(shù)據(jù)操作（crud）開銷變大

部署圖如下：

數(shù)據(jù)編號=uid%4，表編號=uid%5

算法流程圖如下：

目前業(yè)內(nèi)對分庫實現(xiàn)方案有兩種

客戶端分庫分表，在客戶端完成分庫分表操作，直接鏈接數(shù)據(jù)庫。

中間件（例如：cobar），客戶端鏈接中間件，由中間件完成分庫分表操作。

這兩種方案各有利弊，客戶端分庫分表由于直連數(shù)據(jù)庫，所以性能比使用中間件要高。而使用中間件，能夠很好的將分庫分表操作與客戶端隔離，數(shù)據(jù)調(diào)整對上層透明，便于統(tǒng)一管理。

為什么要關(guān)注id生成策略？全局唯一，全局有序，業(yè)務隔離，不容易被猜到等等，這些都不是關(guān)鍵。重點討論下，如何讓看似無意義的id，對系統(tǒng)后續(xù)擴展帶來意義。

Java領(lǐng)域著名的唯一id應該算是uuid了，不過uuid太長，而且包含字母，不適合做為訂單id。通過調(diào)研，我們借鑒了Twitter的Snowflake算法來實現(xiàn)，算法思想是在64位長整型數(shù)字中，存儲node編號，并且有序，同時支持并發(fā)。

為了便于訂單數(shù)據(jù)后期擴展，我們有必要在訂單id生成時，就將其做好分庫分表準備（雖然目前訂單量不多）

其中serverid，占2位，最大支持2^2臺服務器（0-3），dbid占6位，最大支持2^6個數(shù)據(jù)庫，其他以此類推。

訂單數(shù)據(jù)除了用戶維度查詢外，還有通過商品維度來查詢的場景，例如：按照商品，進行訂單發(fā)貨。為了解決這個問題，我們對應的策略是，將訂單數(shù)據(jù)進行冗余，并按照商品維度進行存儲。方案雖然簡單，但是保持兩個訂單庫數(shù)據(jù)的一致性是一件很麻煩的事情。

顯然單機數(shù)據(jù)庫事務是無法解決的（數(shù)據(jù)不在同一個數(shù)據(jù)庫中），所以要保證數(shù)據(jù)一致性，需要引入強一致性的分布式事務，這個方案先不談實現(xiàn)成本問題，就憑其超低的效率，這是我們無法接收的。所以引入異步數(shù)據(jù)同步，來實現(xiàn)數(shù)據(jù)的最終一致性。當然，異步同步數(shù)據(jù)也會帶來數(shù)據(jù)不一致（消息總線丟消息，嘿嘿），所以我們又引入了實時監(jiān)控服務，實時計算數(shù)據(jù)差異，并進行一致性同步。

流程圖如下：

Tip 3 . 類似這種存在多個緯度的數(shù)據(jù)存儲問題，都可以采用這種方案來解決

這是個經(jīng)典的議題了，我們在這個方案上，并無創(chuàng)新，用幾張圖來簡單說明下。

如何讓商城在大流量下存活？這是一個類似搶購或者秒殺場景如何應對的問題，對于這個問題在@沈劍 的《秒殺系統(tǒng)優(yōu)化思路》中已經(jīng)寫的很清晰了，那么，我再補充一下。

中心思路路仍然是”逐層消耗流量“，應用層面對大流量情況下，很有可能自身難保，還沒來得及攔截流量，自身就已經(jīng)OOM了。那么該如何優(yōu)化這個方案？見下圖：

在ngx層進行優(yōu)化，有兩個方案：

達到應用層最大處理能力時，Hold住流量，讓請求排隊，逐步施放流量到應用層。

達到應用層最大處理能力時，拋棄多余流量。

我們采用的第二個方案。視頻課程

==【完】==