思維導(dǎo)圖

前言

在很多時(shí)候，我們都可以在各種框架應(yīng)用中看到ZooKeeper的身影，比如Kafka中間件，Dubbo框架，Hadoop等等。為什么到處都看到ZooKeeper？

一、

前些年，互聯(lián)網(wǎng)行業(yè)里對(duì)架構(gòu)師這個(gè)崗位的標(biāo)準(zhǔn)還不是很清晰。所以，很多架構(gòu)師的工作往往就是一些技術(shù)被公司認(rèn)可的資深工程師負(fù)責(zé)。

彼時(shí)，正巧我也是這類人員之一，故也得到了一個(gè)從零開始架設(shè)一套廣告投放平臺(tái)的機(jī)會(huì)。

我很喜歡鉆研技術(shù)，對(duì)這種機(jī)會(huì)自然很看重。

那時(shí)候，架構(gòu)并無(wú)如今這么復(fù)雜，一開始就是前面搞幾個(gè) Web 應(yīng)用，后面共享個(gè)數(shù)據(jù)庫(kù)。大致像這樣：

當(dāng)然，上面的架構(gòu)其實(shí)做了很多簡(jiǎn)化，省略了很多細(xì)節(jié)。比如，為了提高性能做的緩存，為了提高吞吐做的負(fù)載均衡統(tǒng)統(tǒng)沒有在上圖給出。因?yàn)檫@些和本章話題無(wú)關(guān)，暫時(shí)咱們就忽略這些東西，只看核心部分。

這套架構(gòu)初期運(yùn)行還是沒什么問(wèn)題的，再加上一些緩存機(jī)制，初期一些性能問(wèn)題都通過(guò)調(diào)整緩存提升緩存的碰撞率應(yīng)付了過(guò)去。

可是，隨著廣告投放量的增大，廣告的訪問(wèn)量也在暴漲。這些暴漲的訪問(wèn)量引發(fā)了性能問(wèn)題。當(dāng)時(shí)，由于前端有負(fù)載均衡，應(yīng)用層倒是沒出現(xiàn)什么問(wèn)題……

問(wèn)題出在后面的數(shù)據(jù)庫(kù)上

二、

這套架構(gòu)數(shù)據(jù)庫(kù)用的是 MySQL，本身也只有一臺(tái)主庫(kù)在對(duì)外服務(wù)，另外一臺(tái)備庫(kù)采用了 MySQL 自己的全同步機(jī)制做實(shí)時(shí)備份。

當(dāng)廣告訪問(wèn)量暴漲的時(shí)候，因?yàn)闃I(yè)務(wù)需要，很多數(shù)據(jù)需要在數(shù)據(jù)庫(kù)中做實(shí)時(shí)插入，這就導(dǎo)致了大量的磁盤 IO 產(chǎn)生。這些大量的磁盤 IO 造成了數(shù)據(jù)庫(kù)本身性能的急劇下降。

悲催的是，整套廣告平臺(tái)的所有功能又都是共享一個(gè)數(shù)據(jù)庫(kù)的，所以隨著數(shù)據(jù)庫(kù)本身的性能下降，平臺(tái)的所有功能都受到了影響。

由于問(wèn)題主要在于大量廣告流量的寫入，所以，靠讀寫分離的方案去緩解問(wèn)題這條路就走不通了。

只好先升級(jí)硬件了。在經(jīng)過(guò)了幾輪硬件升級(jí)和數(shù)據(jù)庫(kù)調(diào)優(yōu)之后，單數(shù)據(jù)庫(kù)再也無(wú)法支撐不斷上漲的流量了。沒辦法，要考慮搞數(shù)據(jù)庫(kù)切分了。

那時(shí)候，我個(gè)人是很恐懼?jǐn)?shù)據(jù)庫(kù)切分的。

原因不僅僅在于需要在應(yīng)用層多寫很多復(fù)雜的邏輯，其根本原因是當(dāng)時(shí)流行的 2PC（兩階段提交）方案，這個(gè)方案本身能保證在數(shù)據(jù)庫(kù)切分的情況下，原來(lái)的事務(wù)依然保留著自身的 ACID 性質(zhì)。即:

Atomicity（原子性），不管事務(wù)里執(zhí)行多少命令，對(duì)外它們都是一體的，要么都執(zhí)行，要么都不執(zhí)行。

Consistency（一致性），正因?yàn)槭聞?wù)里要么做要么都不做，所以數(shù)據(jù)庫(kù)的狀態(tài)變化只能由事務(wù)變更后，才會(huì)叫一致性狀態(tài)。

Isolation（隔離性），事務(wù)里做的事兒事務(wù)外面誰(shuí)也看不到，就跟個(gè)盒子把數(shù)據(jù)罩起來(lái)一樣，到底中間怎么變化的，事務(wù)外面的觀察不到。

Durability（持久性），事務(wù)確認(rèn)成功了，那這狀態(tài)就永久不變了。

但也正因?yàn)檫@ 4 個(gè)特性，2PC 才讓我顧慮重重。

顧慮1：首先，數(shù)據(jù)庫(kù)拆分了，那么根據(jù)事務(wù)的原子性，事務(wù)自身必須是一體的，那么事務(wù)涉及到的不同的數(shù)據(jù)庫(kù)就必須都訪問(wèn)一遍，而這本身就意味著很高的通信成本。

再加上，為了保持一致性，事務(wù)失敗后，還必須恢復(fù)各個(gè)數(shù)據(jù)庫(kù)原來(lái)的狀態(tài)，這就必須讓已經(jīng)成功執(zhí)行過(guò)本地事務(wù)的數(shù)據(jù)庫(kù)全部回滾。

而稍微懂點(diǎn)數(shù)據(jù)庫(kù)的人都知道，這個(gè)成本有多大。

更可怕的是，本身事務(wù)的隔離性還可能加上鎖。一旦一個(gè)熱點(diǎn)數(shù)據(jù)區(qū)域被大量訪問(wèn)，最差情況就可能出現(xiàn)串行訪問(wèn)。而這對(duì)此套平臺(tái)，包括我自己都將是個(gè)悲劇。

顧慮2：數(shù)據(jù)庫(kù)的拆分會(huì)造成整個(gè)平臺(tái)的可用性下降。

假設(shè)我現(xiàn)在有一臺(tái)數(shù)據(jù)庫(kù)，它的可用性是 99.9%。如果因?yàn)榉謳?kù)，數(shù)據(jù)庫(kù)從一臺(tái)變成兩臺(tái)，那么平臺(tái)的可用性就會(huì)變成：

平臺(tái)的可用性 = 99.9% * 99.9% = 99.8%

從 99.9% 變成了 99.8%，這意味著可用性下降了 0.1%，每個(gè)月的不可用時(shí)間會(huì)增加 43 分鐘之多。

一邊是硬件升級(jí)已經(jīng)到頂，單機(jī)數(shù)據(jù)庫(kù)也優(yōu)化到了極限，再不做數(shù)據(jù)庫(kù)拆分，平臺(tái)可能隨時(shí)癱瘓。一邊是沒有好的策略，可能拆分?jǐn)?shù)據(jù)庫(kù)后，每個(gè)月都有宕機(jī)的風(fēng)險(xiǎn)，同時(shí)性能也可能會(huì)出現(xiàn)劇烈的下降。

我被逼入了死角。

三、

這種痛苦的糾結(jié)折磨了我大概一周，直到我看到了 CAP 定理。當(dāng) CAP 定理說(shuō)分布式系統(tǒng)在分區(qū)容錯(cuò)的時(shí)候，只能一致性和可用性二選一時(shí)，我高興的蹦了起來(lái)。

原來(lái)，可用性和一致性是不能兼得的。

為何我會(huì)那么高興？因?yàn)楸莆胰胨澜堑目刹粌H是技術(shù)上的問(wèn)題了，我還承受著來(lái)自于業(yè)務(wù)方和領(lǐng)導(dǎo)的壓力。每天一上班，我就需要面對(duì)業(yè)務(wù)各方的抱怨，以及領(lǐng)導(dǎo)一輪又一輪的催促。

有了 CAP 定理的支持，我知道我最終是要面臨選擇的。既然在這個(gè)世界上做分布式架構(gòu)的所有人都要面臨選擇，那我又怎么可能獨(dú)善其身呢？

在對(duì)單機(jī)數(shù)據(jù)庫(kù)引發(fā)的各種問(wèn)題做了一次徹底的各種歸因以后，我下了決心：

一定要搞定拆分?jǐn)?shù)據(jù)庫(kù)并給出良好方案。

只是，2PC 這個(gè)攔路虎，它成為了我的大敵。通過(guò) CAP 定理，我非常肯定，只要我選了 2PC 方案，可用性就一定會(huì)出現(xiàn)嚴(yán)重的問(wèn)題，這個(gè)方案也肯定不可能拿出來(lái)丟人現(xiàn)眼的。

我唯一的方向就是去犧牲一些一致性，往可用性方向走。可是，怎么走呢？

也許是老天眷顧，也許是大家都承受著和我一樣夜不能寐的壓力，很快，BASE 理論在國(guó)內(nèi)傳開了。

BASE 理論讓我知道了，這個(gè)世上能排到前幾名的技術(shù)大公司也一樣會(huì)出問(wèn)題，也一樣會(huì)對(duì)這些問(wèn)題進(jìn)行妥協(xié)。而且 BASE 理論的思想讓我的思路一下子就打開了，苦思而不得的問(wèn)題開始有了頭緒。

我要開始著手制定技術(shù)方案了。

四、

BASE 思想中的 BA（Basically Available）基本可用，是鼓勵(lì)通過(guò)預(yù)先的架構(gòu)設(shè)計(jì)或者前期規(guī)劃，盡量在分布式的系統(tǒng)中，把以前可能影響全平臺(tái)的嚴(yán)重問(wèn)題，變成只會(huì)影響平臺(tái)中的一部分?jǐn)?shù)據(jù)或者功能的非嚴(yán)重問(wèn)題。

有了這個(gè)思想之后，我就對(duì)廣告平臺(tái)中的很多重要的數(shù)據(jù)表進(jìn)行了拆分，并將這些表的數(shù)據(jù)分散到了不同的數(shù)據(jù)庫(kù)中。

比如，有個(gè)廣告流量詳情表，每當(dāng)用戶點(diǎn)擊廣告或者廣告展示出來(lái)的時(shí)候，為了保證不丟失，這些數(shù)據(jù)都是實(shí)時(shí)插入到這個(gè)表里的。

我對(duì)這張表是怎么切分的呢？

當(dāng)有人點(diǎn)擊廣告了，他的點(diǎn)擊記錄會(huì)被傳到我的應(yīng)用層，然后我會(huì)在應(yīng)用層根據(jù)廣告 ID 做哈希，再根據(jù)哈希結(jié)果的不同，分別存到不同的數(shù)據(jù)庫(kù)中去。

假如這三個(gè)數(shù)據(jù)庫(kù)中的一個(gè)出現(xiàn)了問(wèn)題，則只會(huì)有三分之一的數(shù)據(jù)受到影響。這就實(shí)現(xiàn)了 BASE 理論中的 BA——基本可用了。基本可用其實(shí)也真的就是表達(dá)的這么一回事：

通過(guò)一些架構(gòu)設(shè)計(jì)，即使平臺(tái)中某部分組件出現(xiàn)了問(wèn)題，也不會(huì)導(dǎo)致整個(gè)平臺(tái)不可用。

好了，既然采取了數(shù)據(jù)庫(kù)拆分的策略，又根據(jù) BASE 理論中的 BA 思想拆分了一些重要的表，那么，到了現(xiàn)在，可能也無(wú)從后悔，只能繼續(xù)沿著 BASE 這條路，一條路走到黑了。

五、

接下來(lái)，需要著手解決性能問(wèn)題了。2PC 方案……算了……它瘋狂的一致性性格會(huì)要了我的狗命的。

那么極端點(diǎn)，我們不搞事務(wù)可不可以呢？

還用前面說(shuō)的那套廣告平臺(tái)舉例。

當(dāng)時(shí)，從業(yè)務(wù)上，要求廣告的訪問(wèn)數(shù)據(jù)都要保證及時(shí)入庫(kù)不能丟，因?yàn)閬G了就可能造成計(jì)費(fèi)的損失，而這些損失全是錢。所以，每當(dāng)用戶點(diǎn)擊廣告或者廣告展示出來(lái)的時(shí)候，為了保證不丟失，這些數(shù)據(jù)都是實(shí)時(shí)入庫(kù)的。

又根據(jù)業(yè)務(wù)需求，當(dāng)廣告流量入庫(kù)時(shí)，還需要往廣告預(yù)算表和媒體流水表里同時(shí)根據(jù)這筆流量進(jìn)行記賬，以供后續(xù)財(cái)務(wù)計(jì)算。

如果完全不考慮事務(wù)，則拆分庫(kù)后，操作可能會(huì)是這個(gè)樣子。

這三個(gè)操作可能會(huì)并行發(fā)往不同的數(shù)據(jù)庫(kù)執(zhí)行。由于三個(gè)操作之間沒有事務(wù)的約束，所以，一個(gè)操作出問(wèn)題了，另外的操作并不會(huì)受到影響。

而這卻也引發(fā)了另外一個(gè)問(wèn)題，數(shù)據(jù)狀態(tài)不一致。

如果在上面的業(yè)務(wù)中，插入廣告流量表的操作失敗了，但其余兩張表插入成功了，業(yè)務(wù)就會(huì)面臨一個(gè)很尷尬的情況：他們算出的財(cái)務(wù)報(bào)表沒有依據(jù)。財(cái)務(wù)流水中找不到產(chǎn)生了這筆流水的依據(jù)。

而這種不一致的狀態(tài)由于已經(jīng)被持久化到了數(shù)據(jù)庫(kù)中，就會(huì)導(dǎo)致這種不一致的狀態(tài)永久存在了數(shù)據(jù)庫(kù)中。這業(yè)務(wù)能接受嗎？但凡有點(diǎn)職業(yè)精神的程序員能接受嗎？

給大家分享下我的復(fù)習(xí)的面試資料

這些面試全部出自大廠面試真題和面試合集當(dāng)中，小編已經(jīng)為大家整理完畢（PDF版）

資料獲取方式：戳這里前往我的騰訊文檔免費(fèi)下載

• 第一部分：Java基礎(chǔ)-中級(jí)-高級(jí)

• 第二部分：開源框架（SSM：Spring+SpringMVC+MyBatis）

• 第三部分：性能調(diào)優(yōu)（JVM+MySQL+Tomcat）

• 第四部分：分布式（限流：ZK+Nginx；緩存：Redis+MongoDB+Memcached；通訊：MQ+kafka）

• 第五部分：微服務(wù)（SpringBoot+SpringCloud+Dubbo）

• 第六部分：其他：并發(fā)編程+設(shè)計(jì)模式+數(shù)據(jù)結(jié)構(gòu)與算法+網(wǎng)絡(luò)

進(jìn)階學(xué)習(xí)筆記pdf

都已整理好，需免費(fèi)下載點(diǎn)擊這里即可

• Java架構(gòu)進(jìn)階之架構(gòu)筑基篇（Java基礎(chǔ)+并發(fā)編程+JVM+MySQL+Tomcat+網(wǎng)絡(luò)+數(shù)據(jù)結(jié)構(gòu)與算法）

• Java架構(gòu)進(jìn)階之開源框架篇（設(shè)計(jì)模式+Spring+SpringMVC+MyBatis）

• Java架構(gòu)進(jìn)階之分布式架構(gòu)篇 （限流（ZK/Nginx）+緩存（Redis/MongoDB/Memcached）+通訊（MQ/kafka））

• Java架構(gòu)進(jìn)階之微服務(wù)架構(gòu)篇（RPC+SpringBoot+SpringCloud+Dubbo+K8s）

647883)]

[外鏈圖片轉(zhuǎn)存中…(img-YgbLqlyf-1622454647884)]

• Java架構(gòu)進(jìn)階之微服務(wù)架構(gòu)篇（RPC+SpringBoot+SpringCloud+Dubbo+K8s）

[外鏈圖片轉(zhuǎn)存中…(img-zhclYh1U-1622454647885)]

[外鏈圖片轉(zhuǎn)存中…(img-P3ZBq2h0-1622454647886)]

總結(jié)

以上是生活随笔為你收集整理的美团java研发岗二面：java静态方法存储在哪个区的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。