日韩欧美人妻无码精品白浆,夜夜嗨AV免费入口,国产欧美官网在线看,高校回应聋哑女生因长相完美被质疑

為什么需要分庫分表？是因?yàn)镸ySQL等數(shù)據(jù)庫單庫單表能支撐的系統(tǒng)并發(fā)量和數(shù)據(jù)存儲(chǔ)量存在瓶頸。

中國有超過 10 億的網(wǎng)民，單日交易量超過百萬、千萬單的交易場景越來越多。按照一行數(shù)據(jù) 1K ，每日訂單量 500 萬計(jì)算，一年需要的數(shù)據(jù)存儲(chǔ)為 1700G，行數(shù)1.7億。

顯然此種情況MySQL 單庫單表難以保證查詢寫入性能。一張表一年的數(shù)據(jù)量恐怖如斯，交易場景成百上千張表，年復(fù)一年，所帶來的存儲(chǔ)和并發(fā)量壓力何其巨大呢？業(yè)務(wù)牽引技術(shù)的發(fā)展，分庫分表技術(shù)應(yīng)運(yùn)而生。

目前分庫分表技術(shù)似乎成為行業(yè)標(biāo)準(zhǔn)，站在鄙視鏈上游。不分庫分表的系統(tǒng)似乎都是毫無亮點(diǎn)的垃圾系統(tǒng)，然而真的如此嗎？

接下來我將分享自己在電商交易場景實(shí)際遇到的痛點(diǎn)：

一般情況下通過選擇合適的分片屬性，可以保證業(yè)務(wù)在一個(gè)數(shù)據(jù)庫內(nèi)完成事務(wù)操作。

如用戶領(lǐng)券場景，用戶一次領(lǐng)取 3 張優(yōu)惠券，系統(tǒng)寫入 3 條優(yōu)惠券記錄和一條領(lǐng)券流水，使用 UserId 進(jìn)行分庫分表，可以保證同一個(gè)用戶的 4 條記錄路由到同一數(shù)據(jù)庫，可使用 MySQL 本地事務(wù)即可保證數(shù)據(jù)一致性。

然而**當(dāng)同一個(gè)事務(wù)中多張表的分片屬性不同時(shí)，難以保證這些表在同一個(gè)數(shù)據(jù)庫內(nèi)完成事務(wù)操作，勢必會(huì)出現(xiàn)難以解決的分布式事務(wù)難題**。

如優(yōu)惠券存在庫存，在發(fā)券時(shí)需同時(shí)扣減券庫存，庫存粒度為券模版ID，用戶可同時(shí)領(lǐng)取多個(gè)券模版的券。如何保證庫存扣減、用戶發(fā)券、領(lǐng)取流水等在同一個(gè)數(shù)據(jù)庫內(nèi)完成呢？難以實(shí)現(xiàn)

優(yōu)惠券和領(lǐng)券流水，基于 UserId 拆分?jǐn)?shù)據(jù)庫，但庫存表無用戶屬性，只能使用券模版 ID分庫。然而不同的分片屬性，無法保證在同一個(gè)數(shù)據(jù)庫完成事務(wù)操作，難以保證數(shù)據(jù)強(qiáng)一致性。

因此 當(dāng)同一個(gè)事務(wù)中多張表的分片屬性不同時(shí)，難以保證這些表在同一個(gè)數(shù)據(jù)庫內(nèi)完成事務(wù)操作，勢必會(huì)出現(xiàn)難以解決的分布式事務(wù)難題。即便業(yè)務(wù)側(cè)使用復(fù)雜的業(yè)務(wù)架構(gòu)也難以實(shí)現(xiàn)強(qiáng)一致性，作出妥協(xié)后，可實(shí)現(xiàn)最終一致性。

電商交易場景一般使用 UserId 作為分片屬性，聯(lián)合索引的前綴都是UserId，但這并不絕對，交易場景中存在品牌、門店、司機(jī)、配送等其他維度。

如訂單表使用UserId 作為分片屬性進(jìn)行分庫分表，查詢商家在最近 1 小時(shí)的訂單如何實(shí)現(xiàn)呢？由于使用 UserId 分庫分表，當(dāng)使用商家 ID 查詢時(shí)，需要查詢所有的分庫分表，這顯然不現(xiàn)實(shí)。

業(yè)務(wù)側(cè)有幾種實(shí)現(xiàn)方案，1）使用商家 ID分庫分表，異構(gòu)另一份 MySQL存儲(chǔ) 2）基于 ElasticSearch，異構(gòu)另一種存儲(chǔ)支撐其他維度的檢索場景。

無論哪一種方案都會(huì)導(dǎo)致，數(shù)據(jù)一致性降低，但系統(tǒng)復(fù)雜度增加。

查詢商家最近1 小時(shí)的訂單，業(yè)務(wù)上如此簡單清晰的需求，在分庫分表后，實(shí)現(xiàn)方案竟如此復(fù)雜。此外還要求業(yè)務(wù)在數(shù)據(jù)準(zhǔn)確性上作出妥協(xié)。

正是因?yàn)榉謳旆直砑夹g(shù)的先天不足，所以極大地增加了業(yè)務(wù)系統(tǒng)架構(gòu)的復(fù)雜性。（甚至很多人以架構(gòu)復(fù)雜為榮，錯(cuò)誤的認(rèn)為系統(tǒng)越復(fù)雜越能體現(xiàn)架構(gòu)能力）

此外還有其他更加 tricky的方案，如為了實(shí)現(xiàn)訂單 Id 查詢，在生成的訂單Id中存放UserId后四位（大概意思），用于定位訂單在哪個(gè)分片。

MySQL 主鍵支持自增 ID，但是這一特性在分庫分表后淪為雞肋功能，系統(tǒng)需要分布式方式的 ID 生成器。

如優(yōu)惠券系統(tǒng)在分庫分表后，優(yōu)惠券 ID 需要借助分布式ID生成器生成全局唯一 ID。常見的實(shí)現(xiàn)方式包括 UUID、雪花算法、美團(tuán) Leaf、百度 UidGenerator等。除維護(hù)業(yè)務(wù)系統(tǒng)外，還需要維護(hù)其他純技術(shù)類系統(tǒng)。

毫無疑問，這再次增加架構(gòu)的復(fù)雜性。

除全局主鍵問題，全局唯一鍵也難以實(shí)現(xiàn)。當(dāng)全局唯一鍵的前綴是非分片屬性時(shí)，難以實(shí)現(xiàn)全局唯一鍵。

例如訂單在履約完成后，會(huì)生成一筆履約單。系統(tǒng)明確一筆訂單只能有一筆履約單，因此履約單上的訂單 ID 字段應(yīng)該增加唯一鍵約束。然而履約單在基于 UserID 分庫分表后，OrderId建立的唯一鍵約束只在本表內(nèi)唯一，不能保證在所有的分片內(nèi)實(shí)現(xiàn)全局唯一。

因此 分庫分表后，數(shù)據(jù)庫無法對 OrderId等非分片屬性建立全局的唯一性約束。

除以上具體場景外，分庫分表面臨的難題依然有很多，如擴(kuò)容難問題、存儲(chǔ)成本高、運(yùn)維成本高、高可用難等等問題。

選擇分庫分表后，需要業(yè)務(wù)系統(tǒng)開發(fā)和接入很多輪子，包括

ShardingSphere、mycat等方便客戶端接入分庫分表。如果使用 ShardingSphere需考慮多種語言多套輪子，使用 Mycat代理層方案又會(huì)面臨性能風(fēng)險(xiǎn)。

層出不窮的問題，需要層出不窮的輪子，有些輪子需要自己造，如分庫分表管理工具等。

不禁要問，互聯(lián)網(wǎng)大廠能承受如此復(fù)雜架構(gòu)方案，所有的公司都能承受嗎？導(dǎo)致架構(gòu)如此復(fù)雜的根源是什么呢？分庫分表方案上的先天不足

在系統(tǒng)建設(shè)之初，一個(gè)合格的架構(gòu)師必須考慮到：未來數(shù)據(jù)量龐大后的存儲(chǔ)擴(kuò)容問題。這往往讓人很難抉擇，因?yàn)橐獧?quán)衡當(dāng)下的硬件成本和未來擴(kuò)容成本。

使用分庫分表后，擴(kuò)容非常困難。如8 個(gè)數(shù)據(jù)庫，想繼續(xù)拆分為 16 個(gè)數(shù)據(jù)庫，一定會(huì)對業(yè)務(wù)造成影響，停機(jī)遷移是難以避免的問題，需要極多的運(yùn)維工具保障擴(kuò)容過程的安全性和快速性，做到對業(yè)務(wù)影響程度最低。因此擴(kuò)容成本和風(fēng)險(xiǎn)都極高。

如果在系統(tǒng)建設(shè)初期就拆分為 16 個(gè)庫，又會(huì)面臨硬件和運(yùn)維成本過高的問題。如果每一個(gè)業(yè)務(wù)在系統(tǒng)建設(shè)初期都如此鋪張浪費(fèi)，那么公司的硬件成本將極高。

僅一個(gè)業(yè)務(wù)團(tuán)隊(duì)就16 個(gè)數(shù)據(jù)庫，公司那么多業(yè)務(wù)將會(huì)有多么龐大規(guī)模的數(shù)據(jù)庫實(shí)例。有 DBA 曾分享經(jīng)歷，他一天新部署了120 套 mysql實(shí)例，可想而知，DBA 們面臨了多么龐大的運(yùn)維壓力。

研發(fā)視角和 DBA視角不同，結(jié)論不同。業(yè)務(wù)研發(fā)更多考慮容量不足和并發(fā)度不足風(fēng)險(xiǎn)，會(huì)傾向于設(shè)置較大的分庫分表規(guī)模，而 DBA 會(huì)考慮運(yùn)維成本、硬件成本，希望數(shù)據(jù)庫規(guī)模在可控范圍內(nèi)。兩者站在不同的視角，各有理由，這是一個(gè)矛盾。

我相信大多數(shù)業(yè)務(wù)研發(fā)不清楚，自家公司MySQL單庫單實(shí)例的最高并發(fā)度，最高容量，在設(shè)置分片規(guī)模時(shí)往往是拍腦袋決定。只要研發(fā)定的分片方案不離譜，往往 DBA也就接受了。

這些決策中，往往還摻雜歷史問題。如團(tuán)隊(duì)已經(jīng)有了 10 個(gè)庫，無論業(yè)務(wù)規(guī)模如何，新表默認(rèn)拆分10 個(gè)庫，而不會(huì)考慮是否真的需要 10 個(gè)庫。

分庫分表技術(shù)把數(shù)據(jù)庫解決不了的問題推到業(yè)務(wù)側(cè)，“脅迫” 業(yè)務(wù)側(cè)使用復(fù)雜方案參與解決，要求業(yè)務(wù)側(cè)在數(shù)據(jù)一致性上作出妥協(xié)。

為什么單庫單表存在系統(tǒng)瓶頸，就選擇分庫分表呢？有其他更好的方案嗎？分布式數(shù)據(jù)庫。

如阿里的 OceanBase基于兩階段提交協(xié)議解決了分布式事務(wù)問題，提供了比肩本地事務(wù)的強(qiáng)一致性，此外還提供以下能力解決了分庫分表技術(shù)難以解決的問題 1、2、3、4。相比分庫分表，業(yè)務(wù)側(cè)使用分布式數(shù)據(jù)庫的門檻更低。

OceanBase 在性能、擴(kuò)容能力、運(yùn)維和硬件成本上，相比分庫分表有更優(yōu)的表現(xiàn)

單機(jī)數(shù)據(jù)庫能支撐的并發(fā)量和存儲(chǔ)量的天花板很低，分庫分表和分布式數(shù)據(jù)庫是解決此類問題的兩種方案。分庫分表通過分庫分表中間件及一系列輪子整合了獨(dú)立的數(shù)據(jù)庫實(shí)例，可解決并發(fā)量和存儲(chǔ)量的難題，但是犧牲了一致性，增加了使用門檻。而分布式數(shù)據(jù)庫則直面困難，使用分布式集群架構(gòu)在解決并發(fā)量和存儲(chǔ)量挑戰(zhàn)的同時(shí)，也提供了類比單機(jī)數(shù)據(jù)庫的使用門檻和強(qiáng)一致性事務(wù)能力。

就像 ElaticSearch 替代 Lucene ，RedisCluster 替代單機(jī)Redis一樣，低門檻、強(qiáng)一致性、支持高并發(fā)大數(shù)據(jù)量存儲(chǔ)的分布式數(shù)據(jù)庫一定是數(shù)據(jù)庫的主流發(fā)展方向。

分庫分表更像是開源數(shù)據(jù)庫技術(shù)落后互聯(lián)網(wǎng)業(yè)務(wù)發(fā)展時(shí)，不得已的臨時(shí)過渡方案。