1、前言

我們在大部分開發場景下，對持久層的建設基于單庫單表其實就可以實現當前的產品需求。但是隨著業務發展越來越久，數據量、請求量也在不斷的增加，只是單庫單表可能不足以支撐系統的穩定運行，本文主要給大家分享一下筆者在項目實際迭代過程中對持久層穩定性的建設過程。

2、項目簡介

簡單來講就是用戶在一些活動場景下獲取優惠券信息，領取并綁定到關系表里，后續用戶去售賣一些商品的時候可以從領取的優惠券列表里選擇一個合適的優惠券來使用。

3、面臨的問題

3.1 數據越來越多

項目初期，單表完全可以hold住系統的穩定運行，但是由于優惠券的發放門檻特別低，導致優惠券的數量隨著業務的發展激增，用戶領券的關系表數量也越來越多，為了避免以后單表數據量過大帶來的不必要的麻煩，我們對綁定關系表進行分表處理。

3.1.1 技術選型

目前市面上對于分庫分表的方案大體分為三類：

1.基于JDBC進行代理：該方案不需要運維等人員的介入，技術內部即可進行開發優化。

2.基于數據庫進行代理：該方案需要DBA或者運維的介入，維護起來不方便。

3.TiDB數據庫：支持無限的水平擴展，具備強一致性和高可用性，編碼層面的使用跟MYSQL無異。

最終選型
以上三種方案，筆者這邊最終選擇了基于JDBC進行代理，因為這種方案可以純內部進行消化，不需要外部部門介入，對于開發成本、時間周期來講都是比較容易彈性調整的，后續有改造也不需要外部介入。

至于框架的選擇選擇了ShardingJDBC，原因以下幾點：
1.社區活躍，遇到問題可以快速收到反饋。
2.框架經過多年演進，已經是很穩定且成熟的產品。
3.公司內部應用廣泛，可以協助共建。

分庫分表如何設計？
分庫分表擴容涉及到重新hash分片的問題，極其麻煩，所以最好一步到位，短期內不進行擴容操作。
我們基于數據當前的增長速度，簡單計算下未來十年可能帶來的數據量，計算出8庫8表即可滿足該場景。
查詢場景都是基于用戶維度，所以拿uid作為分片鍵即可。

增長速度遠超預期怎么辦？
即使增長速度遠超預期也不打算進行擴容操作，因為成本過高。優惠券過期時間很短，用戶在優惠券過期一定時間后就可以考慮將優惠券進行歸檔操作，這樣即可保證數據量穩定在我們預期之內。

為什么不用TiDB?
由于筆者對TiDB了解不深，考慮到遇到問題不易快速定位、解決，且該表對于業務流程至關重要，所以暫不考慮使用TiDB來存儲。

3.1.2 數據遷移流程

遷移流程大體如下：
1 延遲雙寫
我們先插入或修改舊表數據，成功之后再去寫入或修改新表，然后發送一個延遲消息，消息觸達之后進行新老數據核對，如果數據存在異常則進行修正，令其保持一致。

2 數據清洗
設置一個時間節點，將該時間點前的主鍵id全部跑出來，然后在腳本任務里，實時去查詢該主鍵id對應的最新數據，寫入到新表中。

3 異步糾錯
遷移后的一定時間內，查詢的時候對新老數據進行校驗，如有不一致數據進行異步修復。

具體流程如圖：

3.2 查詢越來越復雜

3.2.1 初期方案

優惠券由于查詢條件比較復雜（涉及到數組查詢、模糊查詢），且隨著業務發展不斷追加新的查詢條件，導致不太適合每個查詢條件作為單獨的字段存儲，故而放到了一個json里統一維護，但是這種存儲方式查詢的時候就無法直接利用mysql進行過濾。
例如：小明想查詢一個條件為：iPhone13非全新機、價格滿1000元可用、以舊換新場景下、郵寄售賣可用的優惠券。
最初數據量不多的時候直接把配置表全部拿出來機型進行內存過濾，拿著滿足條件的配置id去綁定關系表里進行查找。

3.2.2 臨時改進方案

隨著產品不斷創建優惠券進行精細化投放，熱門機型都會有對應的優惠券，庫里的券大概有幾百條。這樣每次都要從庫里全量拉出幾百條進行處理的話顯然99.9%的數據都是不必要的，因為用戶只需要一張券，所以考慮成本最小的臨時改進方案就是將優惠券放到內存中進行緩存，通過內存過濾減少每個請求過來造成的不必要的額外查詢，降低gc頻率。
這里借鑒了一些中間件同步緩存數據的方案，進行推拉結合的方式，一方面實時廣播推送保證時效性，另一方面定時去拉數據來進行兜底處理。

但是本方案也不是長久之計，隨著券的不斷創建，內存中過濾的id可能會命中的特別多，這樣查詢的時候性能也會很糟糕，所以在時間充裕的時候考慮介入其他更適合的中間件，雖然成本高，但是能從根本上是解決問題。

3.2.3 接入ElasticSearch中間件

通過調研發現公司內部比較適合的查詢中間件只有ElasticSearch，市面上也可能有其他適合的中間件，但還需要考慮額外的搭建、運維維護的成本，使用ElasticSearch就足夠解決該問題。
這里實際接入流程不做多贅述，有興趣的可以參考相關的文章。

不過使用ElasticSearch也有一個缺點，就是數據寫入到查詢存在一定的延遲，并且我們這邊有的場景還對時效性要求很高，例如：系統在請求的開始階段給用戶發一張券，用戶拿到后還會再去獲取最優券，這張券直接查可能會獲取不到。
原來的兼容方案是寫入成功后業務內部把id帶到上下文在內存中進行過濾，這樣需要兼容的地方很多，且每個場景都要單獨處理。

那我是如何解決的？
我這邊通過Redis+ElasticSearch 聯動查詢來保證時效性，在寫入成功之后將配置id同步保存到Redis的zset結構中，設置個10s的過期時間。

當有查詢過來的時候，同時查詢ElasticSearch與redis中的數據，然后合并過濾獲取出最合適的券。

一些性能優化手段：
1.查詢只返回需要的字段信息。
2.定義索引的時候使用合適的字段。
3.限制數據總量，根據實際場景做數據歸檔。
4.減少索引范圍，強制根據uid進行分片路由。

3.3 請求量越來越大

3.3.1 讀寫分離

隨著業務qps越來越高，每逢大促寫入、查詢的流量都會激增，所以經常收到關于主庫流量太高的數據庫告警，為了應對各種帶來的尖刺流量，保證主庫的穩定，進行了讀寫分離，減緩主庫寫入的壓力。

主從延遲怎么解決？
有一種最簡單粗暴的方案，單獨提供主庫的查詢接口，但是這種對于調用方改造成本極大， 況且提供了主庫接口之后可能很多人都不會去再使用從庫了，從而無法達到讀寫分離的效果。

Object getByInfoFromMater(Long id);

理想中的方案
我這邊調研了下是否有中間件能幫我實現主從選取的能力，即在主從同步成功之后才進行從庫的讀取，否則都是讀取主庫。

優點：服務方無感知
缺點：可能對性能造成影響

不過沒找到這種中間件，所以我這邊針對于這種方案用redis做了個一個簡化版：

通過定義注解來控制是否執行該組件：
設置了寫入注解的方法：內部全部使用主庫進行讀操作，保證一致性，且設置2s左右過期時間的TAG。
設置讀注解的方法：內部判斷TAG是否存在，存在則走主庫，否則從庫。

這種方案也會帶來負面影響：
帶有注解的方法都要查詢一次redis，耗時會增高， 且如果2s內主從同步失敗，還是會存在查詢不一致的情況，當然考慮實際場景，這種概率微乎其微，我們業務是可以接受的。

4、總結

在從0到1做一個項目的時候，沒必要過度設計，應該快速上線，保證系統正常運行即可。項目初期可以先遇到問題再去解決問題，但是項目具備一定的流量之后，需要提前發現項目痛點并規劃如何解決，否則等到真正遇到問題，再去解決可能已經來不及了，留給我們解決的時間已經不多了。

以上都是筆者在實際工作中的總結、歸納，各位如果有更好的方案或是不同的見解，歡迎評論區留言，共同討論、進步。