摘要：同步寫服務(wù)負(fù)責(zé)第一時間把重要的數(shù)據(jù)落地和落緩存。因為或主從復(fù)制導(dǎo)致的一些事故也是層出不窮的。這也是圖中對于的寫入由專門的異步流程進(jìn)行的原因。合理規(guī)劃好的方式，以及想好在后的全套查詢方案。合理利用不同數(shù)據(jù)源的特性，組合使用發(fā)揮所長，避免

這里所說的五件套是指關(guān)系型數(shù)據(jù)庫、索引型數(shù)據(jù)庫、時序型數(shù)據(jù)庫、文檔型數(shù)據(jù)庫和緩存型數(shù)據(jù)庫。

上圖顯示了一套讀寫服務(wù)搭配這五種類型數(shù)據(jù)庫的例子：

這里只是說明了我們可以這么來搭配這些類型的數(shù)據(jù)庫，不是說我們所有的應(yīng)用都需要用到這些類型的數(shù)據(jù)庫。

同步寫服務(wù)負(fù)責(zé)第一時間把重要的數(shù)據(jù)落地和落緩存。

異步寫服務(wù)通過監(jiān)聽MQ來感知數(shù)據(jù)的變化，然后重新讀取最新的數(shù)據(jù)來把數(shù)據(jù)寫入其它次要數(shù)據(jù)源，比如文檔性數(shù)據(jù)庫和索引型數(shù)據(jù)庫，需要的話可以在緩存中回寫一個狀態(tài)。

由一個專門的數(shù)據(jù)查詢服務(wù)來根據(jù)需求做數(shù)據(jù)路由，根據(jù)需求和性能因素，從不同的數(shù)據(jù)源讀取數(shù)據(jù)。

數(shù)據(jù)聚合服務(wù)根據(jù)需求從次要數(shù)據(jù)源進(jìn)一步讀取數(shù)據(jù)以時間維度進(jìn)行聚合，聚合到時間序列數(shù)據(jù)庫，供監(jiān)控查詢服務(wù)查詢。

下面我們來具體說說這些存儲系統(tǒng)。

毫無疑問，強(qiáng)事務(wù)性的數(shù)據(jù)寫入MySQL之類的關(guān)系型數(shù)據(jù)庫是最可靠的，搭配SSD盤的使用，關(guān)系型數(shù)據(jù)庫也很容易達(dá)到萬級的QPS。對于超大數(shù)據(jù)量加上超大并發(fā)的應(yīng)用來說，單表的數(shù)據(jù)量過千萬伴隨著數(shù)萬的QPS很難以單體數(shù)據(jù)庫來支撐，我們需要對數(shù)據(jù)表進(jìn)行Sharding分片處理，把數(shù)據(jù)按照一定的維度切分到比如128個數(shù)據(jù)表，然后分散在8套甚至16套數(shù)據(jù)集群，這樣每一臺MySQL的實例只需要承受1/8或1/16的請求壓力而且數(shù)據(jù)量更小。隨之帶來的問題是，我們需要對應(yīng)用進(jìn)行改造，使之只能按照一定的查詢條件來查詢這個切片后的表，如果不帶條件或帶任意條件的話，我們是無法知道數(shù)據(jù)實際存儲在哪個表哪個實例上的。

這確實是一個比較麻煩的地方，我們的查詢條件可能有十幾個，只能按照一個維度來查詢滿足不了我們的需求。一個折中的方式是我們引入所謂的Index數(shù)據(jù)表，也就是在寫入實際的完整數(shù)據(jù)到Sharding的數(shù)據(jù)表的同時，我們把數(shù)據(jù)表里需要查詢的字段寫入一個專門的沒有經(jīng)過Sharding處理的Index數(shù)據(jù)表，這個數(shù)據(jù)表里存放的幾乎沒有varchar類型的數(shù)據(jù)，全部是各種bigint的各類業(yè)務(wù)ID或是tinyint類型的各種狀態(tài)，以及時間。由于這個表非常親，雖然數(shù)據(jù)條數(shù)多但是表空間幾乎可以在數(shù)據(jù)庫的緩存中容納，性能會高不少。對于實時性要求非常強(qiáng)的基于條件的查詢可以從這個數(shù)據(jù)表來進(jìn)行查詢。而Sharding后的數(shù)據(jù)只能用于按ShardKey來進(jìn)行查詢。

Redis是最常用的分布式緩存解決方案，幾乎在任何互聯(lián)網(wǎng)應(yīng)用中都會用到，特點是：

能持久化數(shù)據(jù)，但是我的觀點是緩存數(shù)據(jù)庫還是僅僅作為緩存的好，要能夠承受丟失數(shù)據(jù)的風(fēng)險，否則可能會死的比較難看。因為RDB或主從復(fù)制導(dǎo)致的一些事故也是層出不窮的。

豐富的數(shù)據(jù)結(jié)構(gòu)是一定要利用的，豐富的數(shù)據(jù)結(jié)構(gòu)代表了可以依賴豐富的API在服務(wù)端做復(fù)雜的運算，性能比反序列化取出后運算再序列化存入效率高的多。有的時候甚至可以把這些數(shù)據(jù)結(jié)構(gòu)和API組合在一起碰撞出絕妙的方案以極高效的方式實現(xiàn)一個高性能的業(yè)務(wù)邏輯?？梢钥纯础禦edis實戰(zhàn)》一書。

超高的性能（當(dāng)然了，配合一些集群方案比如codis就更上一層樓了）足以抵擋任何業(yè)務(wù)請求的直接訪問，很多時候緩存的方案掛是掛在因為各種各樣的原因穿透緩存而不是Redis檔不住。

豐富的集群和高可用方案以及各類各種實用的功能（管道、事務(wù)、Lua腳本），5.0的版本還推出了Stream特性來替代少有人關(guān)注的Disque值得關(guān)注。

所以Redis的應(yīng)用也很廣泛：

· 數(shù)據(jù)緩存

· 分布式鎖

· 消息隊列

· 服務(wù)端運算

在上圖的架構(gòu)中，我們通過同步寫服務(wù)對數(shù)據(jù)庫和緩存進(jìn)行雙寫，目的也就是為了讓緩存中能有新鮮熱數(shù)據(jù)，不管是對內(nèi)還是對外這種單條數(shù)據(jù)的查詢可以直接路由到緩存。

文檔型數(shù)據(jù)庫的代表就是耕耘多年的Mongodb，我在一些非重要業(yè)務(wù)的場景使用過Mongodb幾次，我的評價如下（最近1年多沒有碰過Mongodb，也可能評價有失偏頗）：

超高的寫入性能，非常不錯的讀取性能（和Redis是不能比的，性質(zhì)不同），數(shù)據(jù)量增多后可能會有很厲害的性能衰退，不是Hbase那種無底洞型的存儲，不維護(hù)就往里面一直堆數(shù)據(jù)進(jìn)去最后的性能可能比如MySQL。

因為存的是文檔，所以是弱結(jié)構(gòu)的，存一些事先不能確定的數(shù)據(jù)非常非常合適，而且以后要查的時候可以任何加索引對需要的數(shù)據(jù)進(jìn)行搜索查詢。一個很實用的場景就是作為爬蟲的數(shù)據(jù)源，數(shù)據(jù)變化多端而且不那么重要，而且寫入性能很重要。

不太可靠和穩(wěn)定，可能會丟數(shù)據(jù)，強(qiáng)烈不建議作為核心數(shù)據(jù)存儲，建議作為一個旁路數(shù)據(jù)庫用在非關(guān)鍵的業(yè)務(wù)。比如在上圖的架構(gòu)圖中，我們可能會拿到核心數(shù)據(jù)后再從其它地方去補一些數(shù)據(jù)然后進(jìn)行適當(dāng)?shù)募庸ぃ４娴組ongodb作為一個監(jiān)控數(shù)據(jù)庫或者面向后臺的數(shù)據(jù)庫來用（MEAN套件之一，可以想象對于簡單的應(yīng)用來說配合腳本語言用起來多舒服了），掛了也就掛了，沒掛的話可以分擔(dān)很多MySQL的壓力。

玩法雖然多，什么Sharding、復(fù)制、集群都有，但隨著數(shù)據(jù)量的增多運維可能是一個大坑，很可能遇到集群全軍覆沒無法啟動的情況，數(shù)據(jù)的恢復(fù)耗時很長。內(nèi)存的使用相當(dāng)瘋狂，對硬件的使用總感覺性價比不高。

ElasticSearch作為其代表是最近幾年的黑馬。ELK集群各大互聯(lián)網(wǎng)公司都有使用，只要集群配置得當(dāng)，每秒幾十萬的寫入不是大問題，畢竟徹底的分布式化理論上可以有無限高的寫入能力。ES的特點如下：

非常豐富的查詢API，不僅僅是全文索引查詢，普通的查詢API豐富多樣，組合起來可以在服務(wù)端完成各種業(yè)務(wù)邏輯，基本上SQL+MySQL可以實現(xiàn)的，ES查詢都可以實現(xiàn)，而且還多了更強(qiáng)大的全文搜索。當(dāng)然，查詢的語法稍顯晦澀肯定沒有SQL來的直掛。

類似于Mongodb的schema-free，無需實現(xiàn)定義表結(jié)構(gòu)。

還算強(qiáng)大的寫入和讀取能力，當(dāng)然，索引多的話寫入文檔的效率肯定會降低。這也是圖中對于ES的寫入由專門的異步流程進(jìn)行的原因。

ES天生的分布式配置決定了，在寫入億、十億的數(shù)據(jù)量之后，還能在相當(dāng)可以接受的時間內(nèi)（比如10秒）完成一個多條件復(fù)雜查詢，對于MySQL這個量級下這樣的查詢可能需要10分鐘甚至100分鐘的時間來執(zhí)行，完全不能接受。

ES對嵌套型數(shù)據(jù)的查詢支持不錯，經(jīng)過測試我們傾向于把多標(biāo)關(guān)聯(lián)的數(shù)據(jù)作為一個大的嵌套的JSON拍扁了直接存入ES，比如我們可以把用戶個人唯獨的基本信息+充值訂單+提現(xiàn)訂單+投資訂單，一人一個JSON存進(jìn)去，然后對于嵌套的下層JSON數(shù)據(jù)也是可以方便的利用查詢API進(jìn)行查詢。

因為這些特點，在這個架構(gòu)圖上，我們把ES也作為了查詢服務(wù)的數(shù)據(jù)源，對于滿足下面這些條件的查詢，我們可以走ES：

· 對數(shù)據(jù)延遲不敏感，可以接受一段時間查不到新鮮數(shù)據(jù)

· 查詢特別復(fù)雜，或是全文搜索，不能走Sharding后的RouteKey，Index表也無法滿足需求

· 查詢的結(jié)果也不僅僅是單表的數(shù)據(jù)而是比較豐富的數(shù)據(jù)，查詢數(shù)據(jù)庫需要查詢多個表多次

索引型數(shù)據(jù)庫和文檔型數(shù)據(jù)庫的底層存儲結(jié)構(gòu)是截然不同的，雖然現(xiàn)在有很多人使用ES來完全替代Mongodb，但是個人覺得ES適合存比Mongodb更大的一個數(shù)據(jù)量，分布式不利用起來發(fā)揮不了ES，Mongodb還是適合中型數(shù)據(jù)非Sharding的存儲。

InfluxDb是時序型數(shù)據(jù)庫的代表。對于按照時間段進(jìn)行Group By查詢的話，不管是ES還是MySQL還是Mongodb在API層面當(dāng)然都是支持的，但是查詢效率不堪入目。因此對于諸如下面的需求首當(dāng)其中可以考慮時序型數(shù)據(jù)庫：

· 監(jiān)控圖表

· 按時間維度聚合

· 查詢的時間維度可以跨度很長

· 需要定期歸檔

如果使用傳統(tǒng)方案的話，我們往往會以固定的時間維度來聚合保存數(shù)據(jù)，如果我們要查1小時和1年的維度，都使用5秒的聚合粒度顯然不合適，我們需要在寫入數(shù)據(jù)到時候針對不同的粒度進(jìn)行聚合，需要一定的工作量，使用時間序列數(shù)據(jù)庫可以少一些這樣的煩惱。而且InfluxDb之類的數(shù)據(jù)庫的性能是非常高的，寫入數(shù)據(jù)的性能堪比Redis，單節(jié)點甚至可以承受十萬指標(biāo)的寫入，基本可以滿足大部分應(yīng)用場景的需求。對于一些業(yè)務(wù)指標(biāo)的監(jiān)控，業(yè)務(wù)事件的打點，業(yè)務(wù)數(shù)據(jù)的時間維度聚合，我們完全可以考慮引入專門的時序型數(shù)據(jù)庫。

綜上所述，這里的架構(gòu)圖只是體現(xiàn)了幾個重要思想：

使用專門的服務(wù)來做數(shù)據(jù)的寫入和讀取，方便進(jìn)行路由。

合理規(guī)劃好Sharding的方式，以及想好RDBMS在Sharding后的全套查詢方案。

數(shù)據(jù)的寫入?yún)^(qū)分主要數(shù)據(jù)源的同步寫入和次要數(shù)據(jù)源的異步寫入，讓主流程更快。

合理利用不同數(shù)據(jù)源的特性，組合使用發(fā)揮所長，避免所短。

數(shù)據(jù)的加工可以是一個層級的關(guān)系，可以由專門業(yè)務(wù)中間件來進(jìn)行數(shù)據(jù)加工。

RDBMS以外的數(shù)據(jù)庫如果打算作為主核心存儲引擎的話千萬慎重思考。

采用豐富的數(shù)據(jù)源意味著維護(hù)成本的增多，數(shù)據(jù)不同步的問題在所難免，需要考慮一下我們是否可以接受一定層度的數(shù)據(jù)不一致。