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

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

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

Tip 1 . 在做設(shè)計(jì)時(shí)，首先要明確3個(gè)事情

業(yè)務(wù)場景，不要空談設(shè)計(jì)，場景是什么
目標(biāo)，系統(tǒng)需要做到的目標(biāo)是什么
分析上述兩點(diǎn)，得到什么結(jié)論

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

Tip 2 .為什么要進(jìn)行分庫分表

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

部署圖如下：

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

算法流程圖如下：

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

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

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

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

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

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

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

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

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

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

流程圖如下：

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

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

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

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

在ngx層進(jìn)行優(yōu)化，有兩個(gè)方案：

達(dá)到應(yīng)用層最大處理能力時(shí)，Hold住流量，讓請求排隊(duì)，逐步施放流量到應(yīng)用層。

達(dá)到應(yīng)用層最大處理能力時(shí)，拋棄多余流量。

我們采用的第二個(gè)方案。視頻課程

==【完】==