3.4 小結

分表分庫的解決方案就講完了，這也是業界常用的做法。這個方案實現以后，項目組對它做了一些壓力測試，1億訂單量的情況下，基本上也能做到20毫秒之內響應。

后來，隨著業務的發展，在分表分庫系統上線的11個月后，日訂單量達到了100萬。事實證明，在大數據時代，提前考慮大數據量的到來是必要的。

不過系統在營銷高峰期還是出了問題：宕機1小時。但問題不在訂單數據庫這邊，而是出現在一個商品API服務的緩存上。訂單數據庫和商品API服務分別由訂單組和商品組負責。

回到這個方案，它在訂單讀寫層面基本是足夠的，至少保證了數據庫不會宕機，不會因為訂單量大系統就撐不住。

不過該方案還有一些不足之處。

1）復雜查詢慢：很多查詢需要跨訂單數據庫進行，然后再組合結果集，這樣的查詢比較慢。業界的普遍做法是前面提到的查詢分離。第2章講了單獨使用Elasticsearch做查詢分離的方案，這里分表分庫的二期項目也進行了查詢分離，只是查詢數據存到了Elasticsearch和HBase中。Elasticsearch存放訂單ID、用來查詢關鍵字的字段以及查詢頁面列表里用到的字段，HBase存放訂單的全量數據。Elasticsearch先根據用戶的查詢組合返回查詢結果到查詢頁面。用戶點擊特定的訂單，就能根據訂單ID去HBase獲取訂單的全量數據。

2）增量數據遷移的高可用性和一致性：如果是自己編寫遷移的代碼，那就參考前面冷熱分離和查詢分離的遷移邏輯；也可以使用開源工具，這個方案在后面數據同步的場景中會單獨展開。

3）短時訂單量大爆發：分表分庫可以解決數據量大的問題，但是如果瞬時流量非常大，數據庫撐不住怎么辦？這一問題會在后面的緩存和秒殺架構等場景中專門展開。

至此，數據持久化層的所有場景就介紹完了。之后將進入緩存層場景實戰。