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

這里所說的五件套是指關系型數據庫、索引型數據庫、時序型數據庫、文檔型數據庫和緩存型數據庫。

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

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

同步寫服務負責第一時間把重要的數據落地和落緩存。

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

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

數據聚合服務根據需求從次要數據源進一步讀取數據以時間維度進行聚合，聚合到時間序列數據庫，供監控查詢服務查詢。

下面我們來具體說說這些存儲系統。

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

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

Redis是最常用的分布式緩存解決方案，幾乎在任何互聯網應用中都會用到，特點是：

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

豐富的數據結構是一定要利用的，豐富的數據結構代表了可以依賴豐富的API在服務端做復雜的運算，性能比反序列化取出后運算再序列化存入效率高的多。有的時候甚至可以把這些數據結構和API組合在一起碰撞出絕妙的方案以極高效的方式實現一個高性能的業務邏輯。可以看看《Redis實戰》一書。

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

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

所以Redis的應用也很廣泛：

· 數據緩存

· 分布式鎖

· 消息隊列

· 服務端運算

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

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

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

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

不太可靠和穩定，可能會丟數據，強烈不建議作為核心數據存儲，建議作為一個旁路數據庫用在非關鍵的業務。比如在上圖的架構圖中，我們可能會拿到核心數據后再從其它地方去補一些數據然后進行適當的加工，保存到Mongodb作為一個監控數據庫或者面向后臺的數據庫來用（MEAN套件之一，可以想象對于簡單的應用來說配合腳本語言用起來多舒服了），掛了也就掛了，沒掛的話可以分擔很多MySQL的壓力。

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

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

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

類似于Mongodb的schema-free，無需實現定義表結構。

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

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

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

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

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

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

· 查詢的結果也不僅僅是單表的數據而是比較豐富的數據，查詢數據庫需要查詢多個表多次

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

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

· 監控圖表

· 按時間維度聚合

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

· 需要定期歸檔

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

綜上所述，這里的架構圖只是體現了幾個重要思想：

使用專門的服務來做數據的寫入和讀取，方便進行路由。

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

數據的寫入區分主要數據源的同步寫入和次要數據源的異步寫入，讓主流程更快。

合理利用不同數據源的特性，組合使用發揮所長，避免所短。

數據的加工可以是一個層級的關系，可以由專門業務中間件來進行數據加工。

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

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