本篇文章給大家分享的是有關(guān)OLTP場(chǎng)景下的數(shù)據(jù)分布式設(shè)計(jì)原則是怎樣的，小編覺得挺實(shí)用的，因此分享給大家學(xué)習(xí)，希望大家閱讀完這篇文章后可以有所收獲，話不多說(shuō)，跟著小編一起來(lái)看看吧。

在宕昌等地區(qū)，都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局，加強(qiáng)發(fā)展的系統(tǒng)性、市場(chǎng)前瞻性、產(chǎn)品創(chuàng)新能力，以專注、極致的服務(wù)理念，為客戶提供成都網(wǎng)站制作、成都網(wǎng)站設(shè)計(jì)、外貿(mào)營(yíng)銷網(wǎng)站建設(shè) 網(wǎng)站設(shè)計(jì)制作定制網(wǎng)站建設(shè),公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),成都品牌網(wǎng)站建設(shè),網(wǎng)絡(luò)營(yíng)銷推廣,外貿(mào)營(yíng)銷網(wǎng)站建設(shè),宕昌網(wǎng)站建設(shè)費(fèi)用合理。

前言

最近幾年做分布式項(xiàng)目，很多工作是關(guān)于OLTP(聯(lián)機(jī)交易系統(tǒng))場(chǎng)景下數(shù)據(jù)分布式架構(gòu)的，疫情期間正好整理下這方面的一些設(shè)計(jì)與實(shí)踐。為避免篇幅太長(zhǎng)，本文分為設(shè)計(jì)篇和技術(shù)篇，設(shè)計(jì)篇主要偏向數(shù)據(jù)拆分的理論與方法，還有一些原則與經(jīng)驗(yàn)。技術(shù)篇?jiǎng)t主要會(huì)介紹分庫(kù)分表中間件的設(shè)計(jì)與使用實(shí)踐，以及如何構(gòu)建一個(gè)完整的分布式數(shù)據(jù)服務(wù)平臺(tái)。

一般來(lái)說(shuō)做分布式架構(gòu)，應(yīng)用層是好做分布式的，因?yàn)橥际菬o(wú)狀態(tài)的(或者通過(guò)將數(shù)據(jù)轉(zhuǎn)移到DB、緩存、MQ等方式來(lái)實(shí)現(xiàn)無(wú)狀態(tài))，只需在流量入口、即在應(yīng)用前面加一個(gè)負(fù)載均衡即可(例如Nginx、HAProxy、F5)，這在大單體架構(gòu)也多已具備。所以一般我們說(shuō)分布式架構(gòu)，一個(gè)重要的部分就是要做數(shù)據(jù)的分布式化。

傳統(tǒng)單體集中式架構(gòu)

數(shù)據(jù)的分布式不像應(yīng)用那么簡(jiǎn)單，因?yàn)楦鞴?jié)點(diǎn)的數(shù)據(jù)可能是不一樣的，需要進(jìn)行路由、解決多副本一致性，甚至多寫沖突等問(wèn)題。雖然實(shí)現(xiàn)方案復(fù)雜，不過(guò)數(shù)據(jù)的分布式本質(zhì)上就兩種樸素思想：復(fù)制和分片。復(fù)制技術(shù)在傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)中也很常見，主要用來(lái)做主備、雙活，例如  MySQL Replication、Oracle DataGuard等。分片在數(shù)據(jù)庫(kù)里也有對(duì)應(yīng)產(chǎn)品。例如 MySQL Fabric、Oracle  Sharding，但與復(fù)制相比，這些數(shù)據(jù)庫(kù)廠商對(duì)應(yīng)的分片方案卻一直沒(méi)有被大眾廣泛接受。

在NewSQL數(shù)據(jù)庫(kù)中往往都內(nèi)置了sharding機(jī)制，而且都基于paxos、raft算法來(lái)保證復(fù)制一致性，關(guān)于分庫(kù)分表與NewSQL方案對(duì)比選型，可參見我之前一篇文章《分庫(kù)分表  vs NewSQL數(shù)據(jù)庫(kù)》。

在OLTP場(chǎng)景下，復(fù)制和分片思想應(yīng)用在傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)上，有兩個(gè)更為人熟知的名字，分庫(kù)分表與讀寫分離。

分庫(kù)分表，就是對(duì)原來(lái)單一數(shù)據(jù)庫(kù)表進(jìn)行拆分，是基于傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)實(shí)現(xiàn)分布式架構(gòu)轉(zhuǎn)型的一個(gè)主要方式，因此首先第一個(gè)問(wèn)題：

為什么拆分?什么時(shí)候需要拆分?

容量、性能、橫向擴(kuò)展、微服務(wù)

單機(jī)數(shù)據(jù)庫(kù)的存儲(chǔ)、CPU、內(nèi)存等資源都存在上限瓶頸，當(dāng)數(shù)據(jù)量、訪問(wèn)量到達(dá)一定量級(jí)后，性能則會(huì)急劇下降，也就是說(shuō)通過(guò)scale  up這種垂直擴(kuò)展的方式是一個(gè)上限的，而且成本是較高的。

如果要實(shí)現(xiàn)scale out橫向擴(kuò)展，就需要把原來(lái)一張表的數(shù)據(jù)拆分到多張物理庫(kù)表中存儲(chǔ)(水平拆分)。

另外如果是微服務(wù)架構(gòu)，拆分后的服務(wù)歸屬不同的系統(tǒng)，對(duì)應(yīng)不同的數(shù)據(jù)庫(kù)，其實(shí)就已經(jīng)進(jìn)行了垂直拆分。

拆分方式有哪些?

1、垂直拆分

垂直拆分一般更加貼近業(yè)務(wù)的拆分方式，在做微服務(wù)時(shí)使用最多的就是這種方式，具體會(huì)根據(jù)DDD(領(lǐng)域驅(qū)動(dòng)設(shè)計(jì))技術(shù)或者業(yè)務(wù)能力進(jìn)行拆分，一般有界上下文確定了，拆分規(guī)則也就比較明確了。

這種方式對(duì)應(yīng)用侵入性較小，往往只需要配置各自獨(dú)立數(shù)據(jù)庫(kù)(可能是物理機(jī)，也可能只是不同的實(shí)列)即可，最多做一個(gè)多數(shù)據(jù)源選擇的數(shù)據(jù)訪問(wèn)層。

另外還有一種垂直拆分的場(chǎng)景是由于冷熱數(shù)據(jù)，同一行數(shù)據(jù)的不同列訪問(wèn)頻率差別很大，或者是有些Text、Blob等大字段影響讀寫效率，這時(shí)也會(huì)將這些列拆分到不同表中。這種方式一般不常見，很多時(shí)候是在做性能優(yōu)化時(shí)會(huì)考慮。

垂直拆分

垂直拆分的優(yōu)點(diǎn)：

• 拆分后業(yè)務(wù)清晰，拆分規(guī)則明確。往往是按照系統(tǒng)或者交易的

• 系統(tǒng)之間整合或擴(kuò)展容易

• 數(shù)據(jù)維護(hù)簡(jiǎn)單、架構(gòu)復(fù)雜度低

垂直拆分的缺點(diǎn)：

• 部分業(yè)務(wù)表無(wú)法join，只能在應(yīng)用層通過(guò)接口方式解決

• 受每種業(yè)務(wù)不同的限制存在單庫(kù)性能瓶頸

• 往往會(huì)產(chǎn)生分布式事務(wù)場(chǎng)景

由于垂直切分是按照業(yè)務(wù)的分類將表分散到不同的庫(kù)，所以有些業(yè)務(wù)表會(huì)過(guò)于龐大，存在單庫(kù)讀寫與存儲(chǔ)瓶頸，這時(shí)就需要水平拆分來(lái)做解決。

2、水平拆分

水平拆分更加技術(shù)化，將一張表的數(shù)據(jù)分布到多張庫(kù)與表中，具體方式可分為：只分庫(kù)、只分表、分庫(kù)又分表。例如order表，只分庫(kù)(ds1.order、ds2.order…dsk.order)，只分表(ds.order_0、ds.order_1…ds.order_n)，分庫(kù)又分表(ds1.order_0、ds2.order_1…dsk.order_n)。

水平拆分

水平拆分的優(yōu)點(diǎn)：

• 如果操作數(shù)據(jù)分布在同一庫(kù)中， 可以支持join、子查詢等復(fù)雜SQL

• 解決了單庫(kù)性能瓶頸，支持橫向擴(kuò)展

• 由于應(yīng)用未拆分，如果有分布式數(shù)據(jù)訪問(wèn)層，則應(yīng)用改造較少

水平拆分的缺點(diǎn)：

• 拆分規(guī)則、分庫(kù)分表數(shù)量需要精心設(shè)計(jì)

• 如果涉及多個(gè)庫(kù)，會(huì)產(chǎn)生分布式事務(wù)場(chǎng)景

• 數(shù)據(jù)擴(kuò)容時(shí)數(shù)據(jù)遷移工作量較大

• 跨庫(kù)join往往需要應(yīng)用實(shí)現(xiàn)，性能較差

• 數(shù)據(jù)合并、聚合、分頁(yè)等無(wú)法由數(shù)據(jù)庫(kù)直接支持

數(shù)據(jù)庫(kù)有分區(qū)表還要分庫(kù)分表嗎?

傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)的分區(qū)表本質(zhì)上還是共享cpu、內(nèi)存，所以仍然面臨著scale  up的問(wèn)題，而且分區(qū)表支持的分區(qū)鍵往往也不夠靈活。但新的一些NewSQL分布式數(shù)據(jù)庫(kù)，如OceanBase的分區(qū)表分散在不同的存儲(chǔ)節(jié)點(diǎn)上，從而避免單機(jī)性能瓶頸問(wèn)題。

拆分具體步驟

1、確定拆分方式

根據(jù)業(yè)務(wù)特性選擇合適的拆分方式，一般結(jié)合使用。

1)垂直拆分

• 場(chǎng)景：字段長(zhǎng)度、訪問(wèn)頻率差別較大字段表、微服務(wù)化

• 注意：需要在同事務(wù)中操作的表盡量不要做拆分

2)水平拆分

• 場(chǎng)景：數(shù)據(jù)量較大，超過(guò)單表、單庫(kù)性能

• 注意：是否有跨庫(kù)事務(wù)，是否有非分片鍵操作表的場(chǎng)景，會(huì)涉及到庫(kù)表掃描交易

2、確定拆分字段

1)垂直拆分表、字段

按照功能模塊進(jìn)行拆分直接按表即可，如果是拆分部分列，則需添加關(guān)聯(lián)列甚至冗余列。

2)水平拆分字段

確保 拆分表都有分片鍵，多為主鍵或唯一索引，這些列中需包含分片信息。如果請(qǐng)求中未包含分片信息，則需要一個(gè)全局的路由表。

3、確定拆分規(guī)則

1)范圍Range

適合按照一定規(guī)律有序遞增的業(yè)務(wù)字段，例如日期、流水ID等，這種方式，例如0-9999->庫(kù)1，10000~19999->庫(kù)2  …;20150101-20161231->庫(kù)1，20170101-20171231->庫(kù)2…。

這種方式天然支持水平擴(kuò)展，方便進(jìn)行冷熱分離、歸檔，按需擴(kuò)容方便，但負(fù)載容易不均衡，如果單庫(kù)壓力大，則也需數(shù)據(jù)遷移。

2)哈希Hash

數(shù)據(jù)分布比較均衡，一般通過(guò)mod庫(kù)/表數(shù)量計(jì)算路由，本質(zhì)上一種預(yù)分配，因此擴(kuò)容時(shí)需要進(jìn)行數(shù)據(jù)遷移，通常有一致性哈希、成倍擴(kuò)容法。

3)應(yīng)用自定義

由應(yīng)用自定義路由規(guī)則，配置有分片ID對(duì)應(yīng)的庫(kù)表序號(hào)，可以通過(guò)路由表、配置文件或其它自定義算法。這種方式靈活度最高，容易實(shí)現(xiàn)動(dòng)態(tài)改變。

在我們項(xiàng)目中是1、2、3方式都有使用。

4、確定拆分?jǐn)?shù)量

1)假設(shè)目標(biāo)數(shù)據(jù)量為T(根據(jù)業(yè)務(wù)發(fā)展需求預(yù)估)

2)單表數(shù)據(jù)量建議P(例如MySQL 為500w)，分表數(shù)量=T/P

3)目前配置典型業(yè)務(wù)場(chǎng)景下，單庫(kù)性能穩(wěn)定前提下對(duì)應(yīng)的數(shù)據(jù)容量上限L

單庫(kù)性能可以根據(jù)cpu(80% 以上)、磁盤IO(磁盤使用率100%  iowait出現(xiàn)并逐步增大)、交易tps穩(wěn)定性(出現(xiàn)tps大幅度波動(dòng))等系統(tǒng)指標(biāo)確定其瓶頸狀態(tài)從而得到容量上限的評(píng)估。

4)分庫(kù)數(shù)量=T/L

庫(kù)表的數(shù)量關(guān)系到未來(lái)擴(kuò)容、以及運(yùn)維需求，不宜太多也不宜太少，以上主要是從容量角度去計(jì)算，實(shí)際場(chǎng)景下還需要結(jié)合硬件成本預(yù)算、數(shù)據(jù)清理歸檔策略等因素綜合考慮。

拆分后怎么擴(kuò)容?

1、垂直擴(kuò)容

垂直拆分后，如果某個(gè)應(yīng)用的數(shù)據(jù)庫(kù)壓力太大，可通過(guò)增加其資源配置(CPU、內(nèi)存、PCIE)進(jìn)行垂直擴(kuò)容。

2、水平擴(kuò)容

水平拆分下可以通過(guò)增加數(shù)據(jù)庫(kù)服務(wù)器進(jìn)行擴(kuò)容。這種方式需要進(jìn)行數(shù)據(jù)遷移，如果一致性哈希則遷移就近節(jié)點(diǎn)數(shù)據(jù)，如果是成倍擴(kuò)容時(shí)則需遷移所有節(jié)點(diǎn)一半數(shù)據(jù)。

一致性哈希模式雖然遷移的數(shù)據(jù)量較小，但容易造成數(shù)據(jù)的冷熱不均，因此我們項(xiàng)目中采用的成倍擴(kuò)容方式，具體方式是提前將表分出來(lái)，例如分成128張表，項(xiàng)目初期將這些表均勻分布在4臺(tái)數(shù)據(jù)庫(kù)服務(wù)器，隨著業(yè)務(wù)增加數(shù)據(jù)量增長(zhǎng)，擴(kuò)容到8臺(tái)數(shù)據(jù)庫(kù)，只需要將原4臺(tái)數(shù)據(jù)庫(kù)各自一半數(shù)量的表遷出到新增的4臺(tái)服務(wù)器，然后修改SQL路由即可。

成倍擴(kuò)容：應(yīng)對(duì)整體數(shù)據(jù)量增長(zhǎng)，擴(kuò)容后物理機(jī)是原有2倍

如果是單臺(tái)數(shù)據(jù)庫(kù)有熱點(diǎn)數(shù)據(jù)壓力，也可以只將該庫(kù)一部分?jǐn)?shù)據(jù)遷移出新擴(kuò)容的庫(kù)。

單庫(kù)擴(kuò)容：應(yīng)對(duì)某個(gè)切片數(shù)據(jù)增長(zhǎng)過(guò)快，擴(kuò)容到獨(dú)立的物理機(jī)

拆分后面臨的問(wèn)題

• 引入分布式事務(wù)的問(wèn)題

• 跨庫(kù)Join的問(wèn)題

• 多庫(kù)合并排序分頁(yè)問(wèn)題

• SQL路由、重寫問(wèn)題

• 多數(shù)據(jù)源管理問(wèn)題

• 多維度拆分后帶來(lái)的數(shù)據(jù)匯總查詢等操作問(wèn)題

解決方式：

• 盡可能避免分布式事務(wù)、跨節(jié)點(diǎn)join、排序場(chǎng)景

• 避免使用數(shù)據(jù)庫(kù)分布式事務(wù)，提供柔性事務(wù)支持(冪等、沖正、可靠性消息、TCC)

• 由應(yīng)用層解決join問(wèn)題

• 提供分布式數(shù)據(jù)訪問(wèn)層

• 匯總庫(kù)、二級(jí)索引庫(kù)、小表廣播

關(guān)于分布式數(shù)據(jù)訪問(wèn)層在技術(shù)篇進(jìn)行詳細(xì)介紹。

讀寫分離

在實(shí)際業(yè)務(wù)場(chǎng)景中，對(duì)數(shù)據(jù)庫(kù)的讀寫頻率是不一樣的。有的是寫多讀少，例如交易流水表;有的是讀寫均衡，例如訂單表;有的則是讀多寫少，如客戶、信息以及配置等信息表。

數(shù)據(jù)分片解決的是單點(diǎn)性能瓶頸和橫向擴(kuò)展能力，適合寫壓力比較大的場(chǎng)景。而讀多寫少的這類場(chǎng)景，如果單庫(kù)容量可以滿足，則可通過(guò)讀寫分離來(lái)解決讀壓力大的問(wèn)題。具體可以把寫操作路由到主庫(kù)，讀操作按照權(quán)重、機(jī)房等分散在主庫(kù)和各個(gè)從庫(kù)。

讀寫分離

讀寫分離模式下需要注意幾點(diǎn)：

1)主從延遲。在從庫(kù)上讀比主庫(kù)數(shù)據(jù)有一定時(shí)延(一般在毫秒級(jí)別，寫壓力大時(shí)可能在秒級(jí)別)，所以選擇這種方式時(shí)業(yè)務(wù)上要允許一定的數(shù)據(jù)時(shí)延，例如一般對(duì)外查詢類交易都使用這種方式。

2)同一事務(wù)中，不能在從庫(kù)讀取數(shù)據(jù)，因?yàn)榭赡苡捎跀?shù)據(jù)延時(shí)讀取到臟數(shù)據(jù)，違背事務(wù)的一致性，所以必須在主庫(kù)讀取。在實(shí)際開發(fā)時(shí)，數(shù)據(jù)訪問(wèn)層可根據(jù)是否關(guān)閉事務(wù)自動(dòng)提交來(lái)自動(dòng)判斷是否必須在主庫(kù)讀。

3)對(duì)于數(shù)據(jù)延遲容忍度很低的查詢交易，可以在開發(fā)時(shí)單獨(dú)再封裝一個(gè)從主庫(kù)查詢的接口，或者在入?yún)⒃黾印笆欠裥枰獜?qiáng)一致”標(biāo)志，交易實(shí)現(xiàn)時(shí)根據(jù)該標(biāo)志選擇從主庫(kù)還是從庫(kù)讀。

在實(shí)際項(xiàng)目中分庫(kù)分表和讀寫分離方式都有場(chǎng)景在用，但注意一般情況下避免使用分庫(kù)分表+讀寫分離這種復(fù)雜方案，因?yàn)榉謳?kù)分表后讀寫壓力也不會(huì)太大了。

原則與經(jīng)驗(yàn)

數(shù)據(jù)分布式是個(gè)系統(tǒng)工程，需要從領(lǐng)域建模、場(chǎng)景劃分、數(shù)據(jù)訪問(wèn)、數(shù)據(jù)遷移擴(kuò)容等多方面綜合考慮，在落地實(shí)現(xiàn)前要從全局做好設(shè)計(jì)，這里簡(jiǎn)單列下我們的一些設(shè)計(jì)原則與經(jīng)驗(yàn)：

1)用簡(jiǎn)單的方案解決問(wèn)題。能不切分盡量不要切分，切莫為了分布式而拆分。讀寫分離能解決問(wèn)題，就不分庫(kù)分表。

2)切分一定要選擇合適切分規(guī)則(能保證90%交易不會(huì)跨分片)， 梳理好所有場(chǎng)景，提前規(guī)劃好再實(shí)施。

3)數(shù)據(jù)訪問(wèn)層設(shè)計(jì)上功能要強(qiáng)大，但一定明確使用場(chǎng)景，切忌無(wú)腦濫用。比如我們項(xiàng)目中數(shù)據(jù)訪問(wèn)中間件雖然支持分布式事務(wù)XA，但一般并不推薦使用;支持DDL，但聯(lián)機(jī)交易時(shí)禁止使用;支持多庫(kù)鏈?zhǔn)绞聞?wù)提交，但默認(rèn)只支持嚴(yán)格單庫(kù)事務(wù)。

4)制定應(yīng)用開發(fā)規(guī)范，明確SQL使用限制與要求，SQL要盡量簡(jiǎn)單。例如我們項(xiàng)目使用MySQL，部署在PC  Server上，單機(jī)性能相比小型機(jī)上DB2、Oracle差很多，因此禁止使用觸發(fā)器、外鍵、join，SQL操作必須攜帶索引與拆分列(數(shù)據(jù)訪問(wèn)層也會(huì)校驗(yàn))，主鍵必須是自增等等。

5)盡量使用柔性事務(wù)解決跨庫(kù)與跨系統(tǒng)事務(wù)問(wèn)題。能用MQ最終一致性就別用Saga、TCC。

以上就是OLTP場(chǎng)景下的數(shù)據(jù)分布式設(shè)計(jì)原則是怎樣的，小編相信有部分知識(shí)點(diǎn)可能是我們?nèi)粘９ぷ鲿?huì)見到或用到的。希望你能通過(guò)這篇文章學(xué)到更多知識(shí)。更多詳情敬請(qǐng)關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。

文章標(biāo)題：OLTP場(chǎng)景下的數(shù)據(jù)分布式設(shè)計(jì)原則是怎樣的
文章分享：http://m.rwnh.cn/article20/jcgjjo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供小程序開發(fā)、面包屑導(dǎo)航、標(biāo)簽優(yōu)化、關(guān)鍵詞優(yōu)化、網(wǎng)站收錄、虛擬主機(jī)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)