非商業(yè)轉(zhuǎn)載請(qǐng)注明作譯者、出處，并保留本文的原始鏈接：http://www.ituring.com.cn/article/211461

肖鵬，微博研發(fā)中心技術(shù)經(jīng)理，主要負(fù)責(zé)微博數(shù)據(jù)庫(kù)（MySQL/Reids/HBase/Memcached）相關(guān)的業(yè)務(wù)保障、性能優(yōu)化、架構(gòu)設(shè)計(jì)，以及周邊的自動(dòng)化系統(tǒng)建設(shè)。經(jīng)歷了微博數(shù)據(jù)庫(kù)各個(gè)階段的架構(gòu)改造，包括服務(wù)保障及SLA體系建設(shè)、微博多機(jī)房部署、微博平臺(tái)化改造等項(xiàng)目。10年互聯(lián)網(wǎng)數(shù)據(jù)庫(kù)架構(gòu)和管理經(jīng)驗(yàn)，專注于數(shù)據(jù)庫(kù)的高性能和高科用技術(shù)保障方向。

問：您是如何與MySQL結(jié)緣，并成為數(shù)據(jù)庫(kù)方面的專家的？

與MySQL結(jié)緣主要也是源于興趣，第一份工作在一家小公司，各個(gè)領(lǐng)域的工作都會(huì)有接觸，全都做下來發(fā)現(xiàn)還是對(duì)數(shù)據(jù)庫(kù)最感興趣，所以就一直從事和數(shù)據(jù)庫(kù)相關(guān)的技術(shù)工作了。隨著工作年限的增加，我在數(shù)據(jù)庫(kù)方面積累的經(jīng)驗(yàn)也逐步增加，越來越發(fā)現(xiàn)數(shù)據(jù)庫(kù)管理員（DBA）是一個(gè)偏實(shí)踐的工種，很多理論上的東西在現(xiàn)實(shí)中會(huì)有各種的變化，比如「反范式」設(shè)計(jì)等等。所以我建議大家：如果想成為數(shù)據(jù)庫(kù)方面的專家，一定要挑選好環(huán)境，大平臺(tái)很多時(shí)候會(huì)由于量變引發(fā)質(zhì)變產(chǎn)生很多有挑戰(zhàn)的問題，而解決這些問題是成為技術(shù)專家的必經(jīng)之路。

問：一路走來，微博的數(shù)據(jù)規(guī)模和業(yè)務(wù)場(chǎng)景都發(fā)生了很大的改變，請(qǐng)問新浪MySQL集群結(jié)構(gòu)發(fā)展到今天都經(jīng)歷了哪些階段？

微博到今天已經(jīng)有6年了，非常有幸全程參與了這6年的變化。新浪的MySQL集群結(jié)構(gòu)主要經(jīng)歷了3次重大的變化。

第一階段：初創(chuàng)階段

初期微博作為一個(gè)內(nèi)部創(chuàng)新產(chǎn)品，功能比較簡(jiǎn)潔，而數(shù)據(jù)庫(kù)架構(gòu)也采用1M2S1MB的標(biāo)準(zhǔn)結(jié)構(gòu)，按照讀寫分離設(shè)計(jì)，主庫(kù)承擔(dān)寫入，而從庫(kù)承擔(dān)訪問。如果訪問壓力過大，可以通過擴(kuò)容從庫(kù)的數(shù)量獲得scale out的能力。

第二階段：爆發(fā)階段

微博上線之后，隨著用戶活躍度的增加，數(shù)據(jù)庫(kù)的壓力也與日俱增。我們首先通過采購(gòu)高性能的硬件設(shè)備來對(duì)單機(jī)性能進(jìn)行scale up，以滿足支撐業(yè)務(wù)的高速發(fā)展的需求。然后，通過使用高性能設(shè)備爭(zhēng)取來的時(shí)間對(duì)微博進(jìn)行整體上的業(yè)務(wù)垂直拆分，將用戶、關(guān)系、博文、轉(zhuǎn)發(fā)、評(píng)論等功能模塊分別獨(dú)立存儲(chǔ)，并在垂直拆分的基礎(chǔ)上，對(duì)一些預(yù)期會(huì)產(chǎn)生海量數(shù)據(jù)的業(yè)務(wù)模塊再次進(jìn)行了二次拆分。

以博文為例，博文是微博用戶主要產(chǎn)生的內(nèi)容，可以預(yù)見會(huì)隨著時(shí)間維度不斷增大，最終會(huì)變得非常巨大。如何在滿足業(yè)務(wù)性能需求的情況下，盡可能使用較少的成本存儲(chǔ)，這是我們面臨的一個(gè)比較有挑戰(zhàn)的問題。

• 首先，我們將索引同內(nèi)容進(jìn)行了拆分，因?yàn)樗饕璐鎯?chǔ)的空間較少，而內(nèi)容存儲(chǔ)所需空間較大，且對(duì)這兩者的使用需求也不盡相同。

• 然后，分別對(duì)索引和內(nèi)容采用hash，然后再按照時(shí)間維度拆分的方式進(jìn)行水平拆分，盡量保障每張表的容量在可控范圍之內(nèi)，保障查詢的性能指標(biāo)。

• 最后，業(yè)務(wù)先通過索引獲得實(shí)際所需內(nèi)容id，然后再通過內(nèi)容庫(kù)獲得實(shí)際的內(nèi)容，并通過部署memcached來加速整個(gè)過程。雖然看上去步驟變多，但是實(shí)際效果完全可以滿足業(yè)務(wù)需求。

第三階段：沉淀階段

在上一個(gè)階段，微博的數(shù)據(jù)庫(kù)經(jīng)歷了很多的拆分改造，這也就直接造成了規(guī)模的成倍增長(zhǎng)，而隨著業(yè)務(wù)經(jīng)歷了高速增長(zhǎng)之后，也開始趨于穩(wěn)定。在這個(gè)階段，我們開始著重進(jìn)行自動(dòng)化的建設(shè)。將之前在快速擴(kuò)張期間積攢下來的經(jīng)驗(yàn)轉(zhuǎn)變?yōu)樽詣?dòng)化工具，對(duì)外形成標(biāo)準(zhǔn)化和流程化的平臺(tái)服務(wù)。我們相繼改造了備份系統(tǒng)、監(jiān)控系統(tǒng)、AutoDDL系統(tǒng)、MHA系統(tǒng)、巡檢系統(tǒng)、慢查系統(tǒng)、maya中間件系統(tǒng)等。為了提高業(yè)務(wù)使用效率和降低溝通成本，相對(duì)于內(nèi)部管理系統(tǒng)而言，我們重新開發(fā)了iDB系統(tǒng)對(duì)數(shù)據(jù)庫(kù)平臺(tái)的用戶使用。通過iDB系統(tǒng)，用戶可以便捷地了解自己業(yè)務(wù)數(shù)據(jù)庫(kù)的運(yùn)行狀態(tài)，并可以直接提交對(duì)數(shù)據(jù)庫(kù)的DDL修改需求。DBA僅需點(diǎn)擊審核通過，即可交由Robot在線上執(zhí)行，不但提高了工作效率，也提高了安全性和規(guī)范性。

問：在過去的2015年，新浪數(shù)據(jù)庫(kù)平臺(tái)都做了哪些重大的改進(jìn)和優(yōu)化？

數(shù)據(jù)庫(kù)平臺(tái)并不僅有MySQL，還有Redis、Memcached、HBase等數(shù)據(jù)庫(kù)服務(wù)，而在緩存為王的趨勢(shì)下，2015年我們重點(diǎn)將研發(fā)精力投入在Redis上。

Redis中間件

2015年，我們自研的Redis中間件tribe系統(tǒng)完成了開發(fā)和上線。tribe采用有中心節(jié)點(diǎn)的proxy架構(gòu)設(shè)計(jì)，通過configer server管理集群節(jié)點(diǎn)，并借鑒官方Redis cluster的slot分片設(shè)計(jì)思路來完成數(shù)據(jù)存儲(chǔ)。最終實(shí)現(xiàn)了路由、分片、自動(dòng)遷移、fail over等功能，并且預(yù)留了操作和監(jiān)控的API接口，以便同其他的自動(dòng)化運(yùn)維系統(tǒng)對(duì)接。

Databus

由于我們先有MySQL后有Redis和HBase等數(shù)據(jù)庫(kù)，所以存在一種場(chǎng)景，就是目前數(shù)據(jù)已經(jīng)寫入到MySQL中，但是需要將這些數(shù)據(jù)同步到其他數(shù)據(jù)庫(kù)軟件中。為此我們開發(fā)了Databus，可以基于MySQL的binlog將數(shù)據(jù)同步到其他異構(gòu)的數(shù)據(jù)庫(kù)中，并且支持自定義業(yè)務(wù)邏輯。目前已經(jīng)實(shí)現(xiàn)了MySQL到Redis和MySQL到HBase的數(shù)據(jù)流向，下一步計(jì)劃開發(fā)Redis到MySQL的數(shù)據(jù)流向。

問：微博用戶庫(kù)設(shè)計(jì)采用了反范式設(shè)計(jì)，但是反范式設(shè)計(jì)也有自己的問題，比如在規(guī)模龐大時(shí)，數(shù)據(jù)冗余多，編碼及維護(hù)的困難增加。請(qǐng)問你們是如何解決這些問題的？

反范式設(shè)計(jì)帶來便利的同時(shí)確實(shí)也帶來了一些問題，尤其是在數(shù)據(jù)規(guī)模變大之后，通常來說會(huì)有如下幾種解決方案。

• 預(yù)拆分，接到需求的時(shí)候提前針對(duì)于容量進(jìn)行評(píng)估，并按照先垂直后水平進(jìn)行拆分，如果可以按照時(shí)間維度設(shè)計(jì)，那就納入歸檔機(jī)制。通過數(shù)據(jù)庫(kù)的庫(kù)表拆分，解決容量存儲(chǔ)問題。

• 引入消息隊(duì)列，利用隊(duì)列的一寫多讀特性或多隊(duì)列來滿足冗余數(shù)據(jù)的多份寫入需求，但僅能保障最終的一致性，中間可能會(huì)出現(xiàn)數(shù)據(jù)延遲。

• 引入接口層，通過不同業(yè)務(wù)模塊的接口將數(shù)據(jù)進(jìn)行匯總之后再返回給應(yīng)用層，降低應(yīng)用層開發(fā)的編碼復(fù)雜度。

問：微博平臺(tái)當(dāng)前在使用并維護(hù)著可能是世界上最大的Redis集群，在應(yīng)用Redis的過程中，你們都產(chǎn)生了哪些具有獨(dú)創(chuàng)性的解決方案？

微博使用Redis的時(shí)間較早，并且一開始量就很大，于是在實(shí)際使用過程中遇到了很多實(shí)際的問題，我們的內(nèi)部分支版本都是針對(duì)這些實(shí)際問題進(jìn)行優(yōu)化的。比較有特點(diǎn)的有如下三個(gè)。

增加基于pos位同步功能

在2.4版本中，Redis的同步一旦出現(xiàn)中斷就會(huì)重新將主庫(kù)的數(shù)據(jù)全部傳輸?shù)綇膸?kù)上，這就會(huì)造成瞬時(shí)的網(wǎng)絡(luò)帶寬峰值，并且對(duì)于數(shù)據(jù)量較大的業(yè)務(wù)，其從庫(kù)恢復(fù)的時(shí)間較為緩慢。為此我們聯(lián)合架構(gòu)組的同事借鑒MySQL的主從同步復(fù)制機(jī)制，將Redis的aof改造為記錄pos位，并讓從庫(kù)記錄已經(jīng)同步的pos位置。這樣，在網(wǎng)絡(luò)出現(xiàn)波動(dòng)的時(shí)候，即使重傳也只是一部分?jǐn)?shù)據(jù)，并不會(huì)影響到業(yè)務(wù)。

在線熱升級(jí)

使用初期，由于很多新功能的加入，Redis版本不斷升級(jí)，每次升級(jí)時(shí)為了不影響業(yè)務(wù)都需要進(jìn)行主庫(kù)切換，這對(duì)于運(yùn)維帶來了很大的挑戰(zhàn)。于是我們開發(fā)了熱升級(jí)機(jī)制，通過動(dòng)態(tài)加載libredis.so來實(shí)現(xiàn)版本的改變，不再需要進(jìn)行主庫(kù)切換，極大地提升了運(yùn)維的效率，也降低了變更帶來的風(fēng)險(xiǎn)。

定制化改造

在使用Redis的后期，由于微博產(chǎn)品上技術(shù)類的需求非常多，所以我們?yōu)榇藢ｉT開發(fā)了兼容Redis的redisscounter存儲(chǔ)技術(shù)類的數(shù)據(jù)。通過使用array替換hash table極大降低了內(nèi)存占用。而在此之后，我們開發(fā)了基于bloom filter的phantom解決判斷類場(chǎng)景需求。

問：在一次分享中您曾經(jīng)透露新浪數(shù)據(jù)庫(kù)備份系統(tǒng)正計(jì)劃結(jié)合水位系統(tǒng)實(shí)現(xiàn)智能擴(kuò)容，請(qǐng)問現(xiàn)在實(shí)現(xiàn)到哪一步了？

目前這個(gè)事情的進(jìn)展不是很理想，主要是我們發(fā)現(xiàn)MySQL的擴(kuò)容速度跟不上業(yè)務(wù)的變化，有些時(shí)候擴(kuò)容完畢之后業(yè)務(wù)的高峰已經(jīng)過去了，接下來就需要做縮容，等于做了無(wú)用功。所以，目前我們的思路改為擴(kuò)縮容cache層。首先實(shí)現(xiàn)cache層的自動(dòng)擴(kuò)縮容，然后同業(yè)務(wù)監(jiān)控系統(tǒng)或者接入層的自動(dòng)化系統(tǒng)進(jìn)行聯(lián)通，比如，如果計(jì)算節(jié)點(diǎn)擴(kuò)容100個(gè)node，那么我們的cache層就聯(lián)動(dòng)擴(kuò)容20node，以此來達(dá)到業(yè)務(wù)聯(lián)動(dòng)。

問：未來5年內(nèi)新浪數(shù)據(jù)庫(kù)還將做出什么樣的改變？

隨著業(yè)務(wù)的發(fā)展，會(huì)遇到越來越多的場(chǎng)景，我們希望可以引進(jìn)最適合的數(shù)據(jù)庫(kù)來解決場(chǎng)景問題，比如PostgreSQL、SSDB等。同時(shí)，利用MySQL新版本的特性（比如5.7的并行復(fù)制、GTID、動(dòng)態(tài)調(diào)整BP），不斷優(yōu)化現(xiàn)有服務(wù)的性能和穩(wěn)定性。

另外，對(duì)于現(xiàn)有的NoSQL服務(wù)，推進(jìn)服務(wù)化，通過使用proxy將存儲(chǔ)節(jié)點(diǎn)進(jìn)行組織之后對(duì)外提供服務(wù)。對(duì)外降低開發(fā)人員的開發(fā)復(fù)雜度和獲取資源的時(shí)間，對(duì)內(nèi)提高單機(jī)利用率并解決資源層橫向擴(kuò)展的瓶頸問題。

同時(shí)，嘗試?yán)酶鞔笤朴?jì)算的資源，實(shí)現(xiàn)cache層的動(dòng)態(tài)擴(kuò)縮容；充分利用云計(jì)算的彈性資源，解決業(yè)務(wù)訪問波動(dòng)的問題。

問：您如何看待新興的NewSQL？

數(shù)據(jù)庫(kù)圈子的變化確實(shí)很快，NoSQL還剛剛方興未艾，NewSQL又開始你方唱罷我登場(chǎng)。我個(gè)人并不認(rèn)為某種數(shù)據(jù)庫(kù)會(huì)取代另一種數(shù)據(jù)庫(kù)，就如同NoSQL剛剛興起的時(shí)候很多聲音認(rèn)為它會(huì)徹底取代MySQL，但是從實(shí)際情況看依然還是互依并存的關(guān)系。以我負(fù)責(zé)的集群來說，反倒是MySQL更多一些。我個(gè)人認(rèn)為，每種數(shù)據(jù)庫(kù)都有其最擅長(zhǎng)的場(chǎng)景，在特定場(chǎng)景下它就是最佳的數(shù)據(jù)庫(kù)，但是如果脫離了場(chǎng)景則很難說誰(shuí)優(yōu)誰(shuí)劣。

問：能否請(qǐng)您橫向?qū)Ρ纫幌翸ySQL、MongoDB以及PostgreSQL？

我個(gè)人對(duì)MySQL使用得較多，MongoDB和PostgreSQL都有過一些接觸，MySQL作為L(zhǎng)AMP中的一員，老實(shí)說對(duì)大部分場(chǎng)景都是合適的，尤其是在并發(fā)和數(shù)據(jù)庫(kù)量并沒有達(dá)到一個(gè)很大值的時(shí)候。但是，在某些場(chǎng)景下MongoDB和PostgreSQL確實(shí)更勝一籌。

比如我們?cè)陂T戶的新聞發(fā)布系統(tǒng)中使用了MongoDB，其schema less的設(shè)計(jì)模式和新聞非常貼合，而其sharding功能又解決了容量上的橫向擴(kuò)張問題，在這個(gè)場(chǎng)景下，MySQL并不具備什么優(yōu)勢(shì)。

而在LBS（基于地理位置信息服務(wù)）相關(guān)的方面，PostgreSQL和PostGIS更具有優(yōu)勢(shì)，利用其空間數(shù)據(jù)索引R-tree和實(shí)體類型點(diǎn)、線、線段、方形，以及特定的函數(shù)，可以很方便地實(shí)現(xiàn)空間計(jì)算需求。

就我個(gè)人來說，每種數(shù)據(jù)庫(kù)都有其擅長(zhǎng)的場(chǎng)景。如果沒有特殊的架構(gòu)需求，一般選擇MySQL都不會(huì)出問題。如果有特殊的架構(gòu)需求，那么就需要根據(jù)需求的特點(diǎn)來選擇不同的數(shù)據(jù)庫(kù)。

問：對(duì)于想要掌握MySQL的同學(xué)，您有哪些學(xué)習(xí)上的建議？

首先，多讀書，至少將High Performance MySQL通讀一遍。

其次，有條件的話，最好找一些大平臺(tái)歷練一下，在很多情況下經(jīng)驗(yàn)和能力等同于你解決過的問題的廣度和深度，而環(huán)境決定你遇到的問題。

最后，有機(jī)會(huì)的話多做一些技術(shù)分享，很多知識(shí)點(diǎn)自己明白和能給別人講明白是兩個(gè)完全不同的境界。

---

更多精彩，加入圖靈訪談微信！

總結(jié)

以上是生活随笔為你收集整理的肖鹏：微博数据库那些事儿（图灵访谈）的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

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