概述
京東的商品評論目前已達到數十億條，每天提供的服務調用也有數十億次，而這些數據每年還在成倍增長，而數據存儲是其中最重要的部分之一，接下來就介紹下京東評論系統的數據存儲是如何設計的。
整體數據存儲包括基礎數據存儲、文本存儲、數據索引、數據緩存幾個部分。
基礎數據存儲
基礎數據存儲使用 MySQL，因用戶評論爲文本信息，通常包含文字、字符等，佔用的存儲空間比較大，爲此 MySQL 作爲基礎數據庫只存儲非文本的評論基礎信息，包括評論狀態、用戶、時間等基礎數據，以及圖片、標籤、點贊等附加數據。而不同的數據又可選擇不同的庫表拆分方案，參考如下：
- 評論基礎數據按用戶 ID 進行拆庫並拆表；
- 圖片及標籤處於同一數據庫下，根據商品編號分別進行拆表；
- 其它的擴展信息數據，因數據量不大、訪問量不高，處理於同一庫下且不做分表即可。
因人而異、因系統而異，根據不同的數據場景選擇不同存儲方案，有效利用資源的同時還能解決數據存儲問題，爲高性能、高可用服務打下堅實基礎。
文本存儲
文本存儲使用了 mongodb、hbase，選擇 nosql 而非 mysql，一是減輕了 mysql 存儲壓力，釋放 msyql，龐大的存儲也有了可靠的保障；二是 nosql 的高性能讀寫大大提升了系統的吞吐量並降低了延遲。存儲的升級過程嘗試了 cassandra、mongodb 等分佈式的 nosql 存儲，cassandra 適用於寫多讀少的情況，而 mongodb 也是基於分佈式文件存儲的數據庫，介於關係型數據庫與非關係型數據庫之間，同時也是內存級數據庫，mongo 寫性能不及 cassandra，但讀寫分離情況下讀性能相當不錯，因此從應用場景上我們選擇了 mongodb。mongodb 確實不錯，也支持了系統穩定運行了好幾年。
但從今後的數據增長、業務擴增、應用擴展等多方面考慮，hbase 纔是最好的選擇，它的存儲能力、可靠性、可擴展性都是毋庸置疑的。選擇了 hbase，只需要根據評論 ID 構建 Rowkey，然後將評論文本信息進行存儲，查詢時只需要根據 ID 便能快速讀取評論的文本內容，當然也可將評論的其它字段信息進行冗餘存儲，這樣根據評論 ID 讀取評論信息後不用再從 mysql 進行讀取，減少數據操作，提升查詢性能。
數據索引
京東的評論是以用戶和商品兩個維度進行劃分的。對於用戶而言，用戶需要發表評論、上傳曬圖、查看自己的評論等，因此 mysql 數據庫中只要根據用戶 ID 對評論數據進行拆庫拆表進行存儲，便能解決用戶數據讀寫問題。而對於商品而言，前臺需要將統計商品的評論數並將所有評論展示出來，後臺需根據評論的全字段進行檢索同時還帶模糊查詢，而評論數據是按 userId 進行庫表拆分的，現在要按商品去獲取評論，顯然當前的拆分庫是無法實現的。起初考慮過根據商品編號再進行拆庫拆表，但經過多層分析後發現行不通，因爲再按商品編號進行拆分，得再多加一倍機器，硬件成本非常高，同時要保持用戶及商品兩維度的分庫數據高度一致，不僅增加了系統維護成本及業務複雜度，同時也無法解決評論的數據統計、列表篩選、模糊查詢等問題，爲此引入了全文檢索框架solr（前臺）/elasticsearch（後臺）進行數據索引。
數據索引其實就是將評論數據構建成索引存儲於索引服務中，便於進行評論數據的模糊查詢、條件篩選及切面統計等，以彌補以上數據存儲無法完成的功能。京東評論系統爲此使用了 solr/elasticsearch 搜索服務，它們都是基於 Lucene 的全文檢索框架，也是分佈式的搜索框架( solr4.0 後增加了solr cloud 以支持分佈式)，支持數據分片、切面統計、高亮顯示、分詞檢索等功能，利用搜索框架能有效解決前臺評論數據統計、列表篩選問題，也能支持後臺系統中的關鍵詞顯示、多字段檢索及模糊查詢，可謂是一舉多得。
搜索在構建索引時，屬性字段可分爲存儲字段與索引字段，存儲字段在創建索引後會將內容存儲於索引文檔中，同時也會佔用相應的索引空間，查詢後可返回原始內容，而索引字段創建索引後不佔用索引空間也無法返回原始內容，只能用於查詢，因此對於較長的內容建議不進行存儲索引。
評論搜索在構建索引時，主鍵評論 ID 的索引方式設置爲存儲，其它字段設置爲索引，這樣不僅減少索引文件的存儲空間，也大大提升了索引的構建效率與查詢性能。當然，在使用搜索框架時，業務數據量比較小的也可選擇將所有字段進行存儲，這樣在搜索中查詢出結果後將不需要從數據庫上查詢其它信息，也減輕了數據庫的壓力。
爲了更好地應對前後臺不同的業務場景，搜索集羣被劃分爲前臺搜索集羣和後臺搜索集羣。
前臺搜索集羣根據商品編號進行索引數據分片，用於解決評論前臺的評論數統計、評論列表篩選功能。評論數統計，如果使用常規數據庫進行統計時，需要進行 sql 上的 group 分組統計，如果只有單個分組統計性能上還能接受，但京東的評論數統計則需要對 1 到 5 分的評論分別進行統計，分組增加的同時隨着統計量的增加數據庫的壓力也會增加，因此在 mysql 上通過 group 方式進行統計是行不通的。而使用solr 的切面統計，只需要一次查詢便能輕鬆地統計出商品每個分級的評論數，而且查詢性能也是毫秒級的。切面統計用法如下：
評論列表，只需根據條件從搜索中查詢出評論 ID 集合，再根據評論 ID 到 mysql、Hbase 中查詢出評論的其它字段信息，經過數據組裝後便可返回前臺進行展示。
後臺搜索集羣 評論後臺系統需要對評論進行查詢，其中包括關鍵詞高亮顯示、全字段檢索、模糊查詢等，爲此 solr/elasticsearch 都是個很好的選擇，目前使用 elasticsearch。
數據緩存
面對數十億的數據請求，直接擊穿到 mysql、搜索服務上都是無法承受的，所以需要對評論數據進行緩存，在此選擇了高性能緩存 redis，根據不同的業務數據進行集羣劃分，同時採用多機房主從方式部署解決單點問題，這樣只需要對不同的緩存集羣進行相應的水平擴展便能快速提升數據吞吐能力，也有效地保證了服務的高性能、高可用。
當然，緩存設計時還有很多細節可以進行巧妙處理的，如：
- 當用戶新發表一條評論，要實現前臺實時展示，可以將新增的評論數向首屏列表緩存中追加最新的評論信息；
- 評論數是讀多寫少，這樣就可以將評論數持久化到 redis 當中，只有當數據進行更新時通過異步的方式去將緩存刷新即可；評論數展示可通過 nginx+lua 的方式提供服務，服務請求無需回源到應用上，不僅提升服務性能，也能減輕應用系統的壓力；
- 對於評論列表，通常訪問的都是第一屏的數據，也就是第一頁的數據，可以將第一頁的數據緩存到 redis當中，有數據更新時再通過異步程序去更新；
- 對於秒殺類的商品，評論數據可以結合本地緩存提前進行預熱，這樣當秒殺流量瞬間湧入的時候也不會對緩存集羣造成壓力；通過減短 key 長度、去掉多餘屬性、壓縮文本等方式節省內存空間，提高內存使用率。
數據容災與高可用
引入了這麼多的存儲方案就是爲了解決大數據量存儲問題及實現數據服務的高可用，同時合理的部署設計與相應的容災處理也必須要有的。以上數據存儲基本都使用多機房主從方式部署，各機房內部實現主從結構進行數據同步。如圖：
MySQL 集羣數據庫拆庫後需要對各分庫進行多機房主從部署，系統應用進行讀寫分離並根據機房進行就近調用，當主機房數據庫出現故障後將故障機房的數據操作都切換到其它機房，待故障排除後再進行數據同步與流量切換。
使用主從機房部署的方式，所有數據更新操作都要在主庫上進行，而當主機房故障是需要通過數據庫主從關係的重建、應用重新配置與發佈等一系列操作後才能解決流量切換，過程較爲複雜且影響面較大，所以這是個單點問題，爲此實現數據服務多中心將是我們下一個目標。
多中心根據特定規則將用戶分別路由到不同機房進行數據讀寫，各機房間通過數據總線進行數據同步，當某一機房出現故障，只需要一鍵操作便能快速地將故障機房的用戶流量全部路由到其它機房，實現了數據的多寫多活，也進一步實現了服務的高可用。數據多中心如下：
hbase 集羣目前使用的是京東的公有集羣，實現了雙機房主備部署，主集羣出現故障後自動將流量切換到備用集羣，而當 hbase 整個集羣故障時還可對其進行降級，同步只寫入緩存及備用存儲 mongo，待集羣恢復後再由後臺異步任務將數據回寫到 hbase 當中。
搜索集羣根據商品編號進行索引數據分片多機房主從部署，並保證至少 3個從節點並部署於多個機房當中，當主節點出現故障後從這些從節點選取其中一個作爲新的主提供服務。集羣主節點只提供異步任務進行索引更新操作，從節點根據應用機房部署情況提供索引查詢服務。
Redis 緩存集羣主從部署仍是標配，主節點只提供數據的更新操作，從節點提供前臺緩存讀服務，實現緩存數據的讀寫分離，提升了緩存服務的處理能力。當主節點出現故障，選取就近機房的一個從節點作爲新主節點提供寫服務，並將主從關係進行重新構建。任何一從節點出現故障都可通過內部的配置中心進行一鍵切換，將故障節點的流量切換到其它的從節點上。
總結
整體數據架構並沒有什麼高大上的設計，而且整體數據架構方案也是爲了解決實際痛點和業務問題而演進過來的。數據存儲方案上沒有最好的，只有最適合的，因此得根據不同的時期、不同的業務場景去選擇合適的設計纔是最關鍵的，大家有什麼好的方案和建議可以相互討論與借鑑，系統的穩定、高性能、高可用纔是王道。