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

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

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

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

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

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

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

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

下面我們來(lái)具體說(shuō)說(shuō)這些存儲(chǔ)系統(tǒng)。

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

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

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

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

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

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

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

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

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

· 分布式鎖

· 消息隊(duì)列

· 服務(wù)端運(yùn)算

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

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

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

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

不太可靠和穩(wěn)定，可能會(huì)丟數(shù)據(jù)，強(qiáng)烈不建議作為核心數(shù)據(jù)存儲(chǔ)，建議作為一個(gè)旁路數(shù)據(jù)庫(kù)用在非關(guān)鍵的業(yè)務(wù)。比如在上圖的架構(gòu)圖中，我們可能會(huì)拿到核心數(shù)據(jù)后再?gòu)钠渌胤饺パa(bǔ)一些數(shù)據(jù)然后進(jìn)行適當(dāng)?shù)募庸?，保存到Mongodb作為一個(gè)監(jiān)控?cái)?shù)據(jù)庫(kù)或者面向后臺(tái)的數(shù)據(jù)庫(kù)來(lái)用（MEAN套件之一，可以想象對(duì)于簡(jiǎn)單的應(yīng)用來(lái)說(shuō)配合腳本語(yǔ)言用起來(lái)多舒服了），掛了也就掛了，沒(méi)掛的話可以分擔(dān)很多MySQL的壓力。

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

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

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

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

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

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

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

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

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

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

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

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

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

· 監(jiān)控圖表

· 按時(shí)間維度聚合

· 查詢的時(shí)間維度可以跨度很長(zhǎng)

· 需要定期歸檔

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

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

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

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

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

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

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

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

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