1、前言

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

2、項目簡介

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

3、面臨的問題

3.1 數(shù)據(jù)越來越多

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

3.1.1 技術選型

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

1.基于JDBC進行代理：該方案不需要運維等人員的介入，技術內(nèi)部即可進行開發(fā)優(yōu)化。

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

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

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

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

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

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

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

3.1.2 數(shù)據(jù)遷移流程

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

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

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

具體流程如圖：

3.2 查詢越來越復雜

3.2.1 初期方案

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

3.2.2 臨時改進方案

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

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

3.2.3 接入ElasticSearch中間件

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

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

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

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

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

3.3 請求量越來越大

3.3.1 讀寫分離

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

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

Object getByInfoFromMater(Long id);

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

優(yōu)點：服務方無感知
缺點：可能對性能造成影響

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

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

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

4、總結

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

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