建站
咨詢
售后
建站咨詢
新聞中心
在前面的文章中探討了架構優(yōu)化的兩種方案：冷熱分離、查詢分離。
網(wǎng)站建設哪家好，找創(chuàng)新互聯(lián)建站！專注于網(wǎng)頁設計、網(wǎng)站建設、微信開發(fā)、小程序開發(fā)、集團企業(yè)網(wǎng)站建設等服務項目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了金城江免費建站歡迎大家使用！
- 冷熱分離
- 查詢分離
查詢分離其實就是利用了非關系數(shù)據(jù)庫的高性能，但是不足之處也很明顯：當主數(shù)據(jù)量越來越多，寫操作緩慢；這種問題如何破局？可見任何一種優(yōu)化方案都不是最終的銀彈，只有不斷的優(yōu)化演變
這篇文章就來介紹一下解決方案：分庫分表，將圍繞以下幾點介紹：
- 拆分后的存儲選型？
- 分庫分表的實現(xiàn)思路？
- 分庫分表的不足？
拆分后的存儲選型？
在介紹選型之前先來介紹下架構背景，筆者曾經(jīng)做過電商系統(tǒng)的優(yōu)化，該系統(tǒng)中包含的兩個主體：
- 用戶：數(shù)據(jù)量上千萬，每日增長10W+
- 訂單：數(shù)據(jù)量上億，每日百萬級的增長
對于如此量級的數(shù)據(jù)，單庫單表的情況下，無論是IO還是CPU都扛不住，架構上的優(yōu)化是必然。
經(jīng)過了多次探討嘗試，最終選擇了分庫分表。
說到分庫分表首先想到的就是存儲選型，關于持久層的選型主流的無非有如下幾種：
- 關系型數(shù)據(jù)庫：MySQL、Oracle.........
- NoSQL：MongoDB、ES......
- NewSQL：TiDB........
1. 關系型數(shù)據(jù)庫
關系型數(shù)據(jù)庫目前市面上主流無非三種：MySQL、Oracle、SqlServer，筆者更傾向于MySQL，也是很多新型企業(yè)在用的一種數(shù)據(jù)庫，因此本篇文章也將重點圍繞MySQL展開
在任何系統(tǒng)中關系型數(shù)據(jù)庫的地位都是不可或缺的，它的強約束性、事務的控制、SQL語法、鎖....這些功能可謂是久經(jīng)考驗，因此在功能上 MySQL 能滿足我們所有的業(yè)務需求。
2. NoSQL
說到NoSQL，第一個想到就是MongoDB ，它的分片功能從并發(fā)性和數(shù)據(jù)量這兩個角度已經(jīng)能滿足一般大數(shù)據(jù)量的需求，但是仍然需要考慮如下幾點：
- 約束性：MongoDB 不是關系型數(shù)據(jù)庫而是文檔型數(shù)據(jù)庫，它的每一行記錄都是一個結(jié)構靈活可變的 JSON，比如存儲非常重要的訂單數(shù)據(jù)時，我們就不能使用 MongoDB，因為訂單數(shù)據(jù)必須使用強約束的關系型數(shù)據(jù)庫進行存儲。
- 業(yè)務功能考量：事務的控制、SQL語法、鎖以及各種千奇百怪的SQL在已有的架構上都曾久經(jīng)考驗，但是MongoDB在這些功能需要上并不能滿足
- 業(yè)務改造考量：未拆分前使用關系型數(shù)據(jù)庫，使用NoSQL之后對于SQL的改造比較麻煩，項目周期更長
3. NewSQL
NewSQL目前比較主流則是TiDB，該技術比較新，雖然能夠滿足大數(shù)據(jù)量的存儲，但是在選擇上還是需要做些考量：
熟悉程度考量：如果你所在公司架構組對于NewSQL比較數(shù)據(jù)或者已經(jīng)有在使用，則可以選擇
穩(wěn)定性考量：關系型數(shù)據(jù)畢竟是久經(jīng)考驗，在穩(wěn)定性方面肯定是比較好，但是NewSQL的穩(wěn)定性卻無法去考量，建議初期階段可以將一些不太重要的數(shù)據(jù)使用NewSQL存儲
基于MySQL的分庫分表
什么是分表分庫？分表是將一份大的表數(shù)據(jù)拆分存放至多個結(jié)構一樣的拆分表；分庫就是將一個大的數(shù)據(jù)庫拆分成多個結(jié)構一樣的小庫。
前面介紹的三種拆分存儲技術，在我以往的項目中我都沒使用過，而是選擇了基于 MySQL 的分表分庫，主要是有一個重要考量：分表分庫對于第三方依賴較少，業(yè)務邏輯靈活可控，它本身并不需要非常復雜的底層處理，也不需要重新做數(shù)據(jù)庫，只是根據(jù)不同邏輯使用不同 SQL 語句和數(shù)據(jù)源而已。
目前市面上主流的分庫分表分為兩種模式：Proxy模式、Client模式
Proxy模式屬于業(yè)務無侵入型，直接代理數(shù)據(jù)庫，對于開發(fā)者一切都是無感知的，SQL 組合、數(shù)據(jù)庫路由、執(zhí)行結(jié)果合并等功能全部存放在一個代理服務中，比如MyCat、ShardingSphere都對Proxy模式提供了支持
Client模式屬于業(yè)務侵入型，將分庫分表的邏輯放在客戶端，客戶端需要引入一個jar，比如Sharding-JDBC，架構圖如下：
市面上對于分庫分表中間件如下：
兩種模式的優(yōu)缺點也很明顯：
- Proxy模式：資源解耦，業(yè)務無侵入；缺點則是運維成本相對較高
- Client模式：代碼靈活控制，運維成本低；缺點則是語言限制，升級不方便
分庫分表的實現(xiàn)思路
在落實分表分庫解決方案時，我們需要考慮 5 個要點。
1. 分片鍵如何選擇？
針對訂單這個業(yè)務，其中涉及到以下幾個主要的字段：
- user_id：用戶id
- order_id：訂單id
- order_time：下單時間
- store_id：店鋪id
經(jīng)過考量，最終選擇了user_id作為ShardingKey，為什么呢？
選擇user_id作為ShardingKey需要結(jié)合業(yè)務場景，訂單系統(tǒng)中常見的業(yè)務：
- C端用戶需要查詢所有的訂單（user_id）
- 后臺需要根據(jù)城市查詢所有訂單（user_city_id）
- B端商家需要統(tǒng)計自己店鋪的下單量（store_id）
以上三種業(yè)務場景，判斷下優(yōu)先級，C端用戶肯定是需要優(yōu)先滿足，因此使用user_id作為ShardingKey
這樣在查詢時需要將user_id傳遞過來才能定位到指定庫、表
選擇字段作為分片鍵時，我們一般需要考慮三點要求：數(shù)據(jù)盡量均勻分布在不同表或庫、跨庫查詢操作盡可能少、這個字段的值不會變（這點尤為重要）。
2. 分片的策略是什么？
選擇user_id作為ShardingKey之后，需要考慮使用分片策略了，主要分為如下三種
- 范圍分片
假如user_id是自增的數(shù)字，則可以根據(jù)user_id范圍進行分片，每100萬份分為一個庫，每10萬份分為一個表，此時單個庫中將分為10張表，如下表：
- Hash取模
這種方案是根據(jù)Hash值進行分片，比如Hash函數(shù)為：hash(user_id%8)，這里是將user_id對8這個特定值取模，最終分為了8張表；這里一般為了方便后續(xù)擴容，建議選擇2的N次方
- 范圍分片和Hash取模混合
比如先按照范圍對user_id拆分，每100萬份分為一個庫，在對這100萬份數(shù)據(jù)進行Hash取模（hash(user_id%8)）拆分成8個表
當然以上三種方案的優(yōu)缺點也是非常明顯，這里不再贅述了
需要注意的是：在拆分之前，為了避免頻繁的擴容，一定要對未來5年或者10年數(shù)據(jù)增長做個判斷，預留更多的分片
3. 業(yè)務代碼如何修改
業(yè)務代碼的修改這里就不好說了，和自身的業(yè)務是強關聯(lián)。
但是，在這里我想分享一些個人觀點。近年來，分表分庫操作愈發(fā)容易，不過我們需要注意幾個要點。
我們已經(jīng)習慣微服務了，對于特定表的分表分庫，其影響面只在該表所在的服務中，如果是一個單體架構的應用做分表分庫，那真是傷腦筋。
在互聯(lián)網(wǎng)架構中，我們基本不使用外鍵約束。
隨著查詢分離的流行，后臺系統(tǒng)中有很多操作需要跨庫查詢，導致系統(tǒng)性能非常差，這時分表分庫一般會結(jié)合查詢分離一起操作：先將所有數(shù)據(jù)在 ES 索引一份，再使用 ES 在后臺直接查詢數(shù)據(jù)。如果訂單詳情數(shù)據(jù)量很大，還有一個常見做法，即先在 ES 中存儲索引字段（作為查詢條件的字段），再將詳情數(shù)據(jù)存放在 HBase 中（這個方案我們就不展開了）。
4. 歷史數(shù)據(jù)遷移？
歷史數(shù)據(jù)的遷移非常耗時，有時遷移幾天幾夜都很正常。而在互聯(lián)網(wǎng)行業(yè)中，別說幾天幾夜了，就連停機幾分鐘業(yè)務都無法接受，這就要求我們給出一個無縫遷移的解決方案。
還記得講解查詢分離時，我們說過的方案嗎？我們再來回顧下，如下圖所示：
歷史數(shù)據(jù)遷移時，我們就是采用類似的方案進行歷史數(shù)據(jù)遷移，如下圖所示：
此數(shù)據(jù)遷移方案的基本思路：存量數(shù)據(jù)直接遷移，增量數(shù)據(jù)監(jiān)聽 binlog，然后通過 canal 通知遷移程序搬運數(shù)據(jù)，新的數(shù)據(jù)庫擁有全量數(shù)據(jù)，且校驗通過后逐步切換流量。
數(shù)據(jù)遷移解決方案詳細的步驟如下：
- 上線 canal，通過 canal 觸發(fā)增量數(shù)據(jù)的遷移；
- 遷移數(shù)據(jù)腳本測試通過后，將老數(shù)據(jù)遷移到新的分表分庫中；
- 注意遷移增量數(shù)據(jù)與遷移老數(shù)據(jù)的時間差，確保全部數(shù)據(jù)都被遷移過去，無遺漏；
- 第二步、第三步都運行完后，新的分表分庫中已經(jīng)擁有全量數(shù)據(jù)了，這時我們可以運行數(shù)據(jù)驗證的程序，確保所有數(shù)據(jù)都存放在新數(shù)據(jù)庫中；
- 到這步數(shù)據(jù)遷移就算完成了，之后就是新版本代碼上線了，至于是灰度上還是直接上，需要根據(jù)你們的實際情況決定，回滾方案也是一樣。
5. 未來的擴容方案是什么？
隨著業(yè)務的發(fā)展，如果原來的分片設計已經(jīng)無法滿足日益增長的數(shù)據(jù)需求，我們就需要考慮擴容了，擴容方案主要依賴以下兩點。
- 分片策略是否可以讓新表數(shù)據(jù)的遷移源只是 1 個舊表，而不是多個舊表，這就是前面我們建議使用 2 的 N 次方分表的原因；
- 數(shù)據(jù)遷移：我們需要把舊分片的數(shù)據(jù)遷移到新的分片上，這個方案與上面提及的歷史數(shù)據(jù)遷移一樣，我們就不重復啰唆了。
分表分庫的不足
分表分庫的解決方案講完了，以上就是業(yè)界常用的一些做法，不過此方案仍然存在不足之處。
- 增量數(shù)據(jù)遷移：如何保證數(shù)據(jù)的一致性及高可用性
- 短時訂單量大爆發(fā)：分表分庫仍然扛不住時解決方案是什么？
文章標題：業(yè)務單表讀寫緩慢如何優(yōu)化？
當前地址：http://www.5511xx.com/article/dhicdcp.html
