京東的商品評論目前已達到數十億條，每天提供的服務調用也有數十億次，而這些數據每年還在成倍增長，而數據存儲是其中最重要的部分之一，接下來就介紹下京東評論系統的數據存儲是如何設計的。
整體數據存儲包括基礎數據存儲、文本存儲、數據索引、數據緩存幾個部分。
基礎數據存儲
基礎數據存儲使用MySQL，因用戶評論為文本信息，通常包含文字、字符等，占用的存儲空間比較大，為此MySQL作為基礎數據庫只存儲非文本的評論基礎信息，包括評論狀態、用戶、時間等基礎數據，以及圖片、標簽、點贊等附加數據。而不同的數據又可選擇不同的庫表拆分方案，參考如下：
-
評論基礎數據按用戶ID進行拆庫並拆表；
-
圖片及標簽處於同一數據庫下，根據商品編號分別進行拆表；
-
其它的擴展信息數據，因數據量不大、訪問量不高，處理於同一庫下且不做分表即可。
因人而異、因系統而異，根據不同的數據場景選擇不同存儲方案，有效利用資源的同時還能解決數據存儲問題，為高性能、高可用服務打下堅實基礎。
文本存儲
文本存儲使用了MongoDB、HBase，選擇NoSQL而非MySQL，一是減輕了MySQL存儲壓力，釋放MySQL，龐大的存儲也有了可靠的保障；二是NoSQL的高性能讀寫大大提升了系統的吞吐量並降低了延遲。
存儲的升級過程嘗試了Cassandra、MongoDB等分布式的NoSQL存儲，Cassandra適用於寫多讀少的情況，而 MongoDB也是基於分布式文件存儲的數據庫，介於關系型數據庫與非關系型數據庫之間，同時也是內存級數據庫，Mong寫性能不及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。
未來也計划將前台搜索集群切換為Elasticsearch。
數據緩存
面對數十億的數據請求，直接擊穿到MySQL、搜索服務上都是無法承受的，所以需要對評論數據進行緩存，在此選擇了高性能緩存Redis，根據不同的業務數據進行集群划分，同時采用多機房主從方式部署解決單點問題，這樣只需要對不同的緩存集群進行相應的水平擴展便能快速提升數據吞吐能力，也有效地保證了服務的高性能、高可用。
當然，緩存設計時還有很多細節可以進行巧妙處理的，如：
-
當用戶新發表一條評論，要實現前台實時展示，可以將新增的評論數向首屏列表緩存中追加最新的評論信息；
-
評論數是讀多寫少，這樣就可以將評論數持久化到Redis當中，只有當數據進行更新時通過異步的方式去將緩存刷新即可；評論數展示可通過nginx+lua的方式提供服務，服務請求無需回源到應用上，不僅提升服務性能，也能減輕應用系統的壓力；
-
對於評論列表，通常訪問的都是第一屏的數據，也就是第一頁的數據，可以將第一頁的數據緩存到Redis當中，有數據更新時再通過異步程序去更新；
-
對於秒殺類的商品，評論數據可以結合本地緩存提前進行預熱，這樣當秒殺流量瞬間涌入的時候也不會對緩存集群造成壓力；通過減短key長度、去掉多余屬性、壓縮文本等方式節省內存空間，提高內存使用率。
數據容災與高可用
引入了這么多的存儲方案就是為了解決大數據量存儲問題及實現數據服務的高可用，同時合理的部署設計與相應的容災處理也必須要有的。以上數據存儲基本都使用多機房主從方式部署，各機房內部實現主從結構進行數據同步。如圖：
MySQL集群數據庫拆庫后需要對各分庫進行多機房主從部署，系統應用進行讀寫分離並根據機房進行就近調用，當主機房數據庫出現故障后將故障機房的數據操作都切換到其它機房，待故障排除后再進行數據同步與流量切換。
使用主從機房部署的方式所有數據更新操作都要在主庫上進行，而當主機房故障是需要通過數據庫主從關系的重建、應用重新配置與發布等一系列操作后才能解決流量切換，過程較為復雜且影響面較大，所以這是個單點問題，為此實現數據服務多中心將是我們下一個目標。
多中心根據特定規則將用戶分別路由到不同機房進行數據讀寫，各機房間通過數據總線進行數據同步，當某一機房出現故障，只需要一鍵操作便能快速地將故障機房的用戶流量全部路由到其它機房，實現了數據的多寫多活，也進一步實現了服務的高可用。數據多中心如下：
HBase集群目前使用的是京東的公有集群，實現了雙機房主備部署，主集群出現故障后自動將流量切換到備用集群，而當HBase整個集群故障時還可對其進行降級，同步只寫入緩存及備用存儲Mongo，待集群恢復后再由后台異步任務將數據回寫到HBase當中。
搜索集群根據商品編號進行索引數據分片多機房主從部署，並保證至少3個從節點並部署於多個機房當中，當主節點出現故障后從這些從節點選取其中一個作為新的主提供服務。集群主節點只提供異步任務進行索引更新操作，從節點根據應用機房部署情況提供索引查詢服務。
Redis緩存集群主從部署仍是標配，主節點只提供數據的更新操作，從節點提供前台緩存讀服務，實現緩存數據的讀寫分離，提升了緩存服務的處理能力。當主節點出現故障，選取就近機房的一個從節點作為新主節點提供寫服務，並將主從關系進行重新構建。任何一從節點出現故障都可通過內部的配置中心進行一鍵切換，將故障節點的流量切換到其它的從節點上。
總結
整體數據架構並沒有什么高大上的設計，而且整體數據架構方案也是為了解決實際痛點和業務問題而演進過來的。數據存儲方案上沒有最好的，只有最適合的，因此得根據不同的時期、不同的業務場景去選擇合適的設計才是最關鍵的，大家有什么好的方案和建議可以相互討論與借鑒，系統的穩定、高性能、高可用才是王道。
作者介紹 韋仕
-
京東商城交易平台評價社區負責人，2010年加入京東，先后參與了用戶、商品、評論等系統的架構升級工作。