肖鵬：微博數據庫那些事兒（圖靈訪談）

非商業轉載請註明做譯者、出處，並保留本文的原始連接：http://www.ituring.com.cn/article/211461

肖鵬，微博研發中心技術經理，主要負責微博數據庫（MySQL/Reids/HBase/Memcached）相關的業務保障、性能優化、架構設計，以及周邊的自動化系統建設。經歷了微博數據庫各個階段的架構改造，包括服務保障及SLA體系建設、微博多機房部署、微博平臺化改造等項目。10年互聯網數據庫架構和管理經驗，專一於數據庫的高性能和高科用技術保障方向。

問：您是如何與MySQL結緣，併成爲數據庫方面的專家的？

與MySQL結緣主要也是源於興趣，第一份工做在一家小公司，各個領域的工做都會有接觸，全都作下來發現仍是對數據庫最感興趣，因此就一直從事和數據庫相關的技術工做了。隨着工做年限的增長，我在數據庫方面積累的經驗也逐步增長，愈來愈發現數據庫管理員（DBA）是一個偏實踐的工種，不少理論上的東西在現實中會有各類的變化，好比「反範式」設計等等。因此我建議你們：若是想成爲數據庫方面的專家，必定要挑選好環境，大平臺不少時候會因爲量變引起質變產生不少有挑戰的問題，而解決這些問題是成爲技術專家的必經之路。

問：一路走來，微博的數據規模和業務場景都發生了很大的改變，請問新浪MySQL集羣結構發展到今天都經歷了哪些階段？

微博到今天已經有6年了，很是有幸全程參與了這6年的變化。新浪的MySQL集羣結構主要經歷了3次重大的變化。

第一階段：初創階段

初期微博做爲一個內部創新產品，功能比較簡潔，而數據庫架構也採用1M2S1MB的標準結構，按照讀寫分離設計，主庫承擔寫入，而從庫承擔訪問。若是訪問壓力過大，能夠經過擴容從庫的數量得到scale out的能力。

第二階段：爆發階段

微博上線以後，隨着用戶活躍度的增長，數據庫的壓力也與日俱增。咱們首先經過採購高性能的硬件設備來對單機性能進行scale up，以知足支撐業務的高速發展的需求。而後，經過使用高性能設備爭取來的時間對微博進行總體上的業務垂直拆分，將用戶、關係、博文、轉發、評論等功能模塊分別獨立存儲，並在垂直拆分的基礎上，對一些預期會產生海量數據的業務模塊再次進行了二次拆分。

以博文爲例，博文是微博用戶主要產生的內容，能夠預見會隨着時間維度不斷增大，最終會變得很是巨大。如何在知足業務性能需求的狀況下，儘量使用較少的成本存儲，這是咱們面臨的一個比較有挑戰的問題。

• 首先，咱們將索引同內容進行了拆分，由於索引所需存儲的空間較少，而內容存儲所需空間較大，且對這二者的使用需求也不盡相同。

• 而後，分別對索引和內容採用hash，而後再按照時間維度拆分的方式進行水平拆分，儘可能保障每張表的容量在可控範圍以內，保障查詢的性能指標。

• 最後，業務先經過索引得到實際所需內容id，而後再經過內容庫得到實際的內容，並經過部署memcached來加速整個過程。雖然看上去步驟變多，可是實際效果徹底能夠知足業務需求。

第三階段：沉澱階段

在上一個階段，微博的數據庫經歷了不少的拆分改造，這也就直接形成了規模的成倍增加，而隨着業務經歷了高速增加以後，也開始趨於穩定。在這個階段，咱們開始着重進行自動化的建設。將以前在快速擴張期間積攢下來的經驗轉變爲自動化工具，對外造成標準化和流程化的平臺服務。咱們相繼改造了備份系統、監控系統、AutoDDL系統、MHA系統、巡檢系統、慢查系統、maya中間件系統等。爲了提升業務使用效率和下降溝通成本，相對於內部管理系統而言，咱們從新開發了iDB系統對數據庫平臺的用戶使用。經過iDB系統，用戶能夠便捷地瞭解本身業務數據庫的運行狀態，並能夠直接提交對數據庫的DDL修改需求。DBA僅需點擊審覈經過，便可交由Robot在線上執行，不但提升了工做效率，也提升了安全性和規範性。

問：在過去的2015年，新浪數據庫平臺都作了哪些重大的改進和優化？

數據庫平臺並不只有MySQL，還有Redis、Memcached、HBase等數據庫服務，而在緩存爲王的趨勢下，2015年咱們重點將研發精力投入在Redis上。

Redis中間件

2015年，咱們自研的Redis中間件tribe系統完成了開發和上線。tribe採用有中心節點的proxy架構設計，經過configer server管理集羣節點，並借鑑官方Redis cluster的slot分片設計思路來完成數據存儲。最終實現了路由、分片、自動遷移、fail over等功能，而且預留了操做和監控的API接口，以便同其餘的自動化運維繫統對接。

Databus

因爲咱們先有MySQL後有Redis和HBase等數據庫，因此存在一種場景，就是目前數據已經寫入到MySQL中，可是須要將這些數據同步到其餘數據庫軟件中。爲此咱們開發了Databus，能夠基於MySQL的binlog將數據同步到其餘異構的數據庫中，而且支持自定義業務邏輯。目前已經實現了MySQL到Redis和MySQL到HBase的數據流向，下一步計劃開發Redis到MySQL的數據流向。

問：微博用戶庫設計採用了反範式設計，可是反範式設計也有本身的問題，好比在規模龐大時，數據冗餘多，編碼及維護的困難增長。請問大家是如何解決這些問題的？

反範式設計帶來便利的同時確實也帶來了一些問題，尤爲是在數據規模變大以後，一般來講會有以下幾種解決方案。

• 預拆分，接到需求的時候提早針對於容量進行評估，並按照先垂直後水平進行拆分，若是能夠按照時間維度設計，那就歸入歸檔機制。經過數據庫的庫表拆分，解決容量存儲問題。

• 引入消息隊列，利用隊列的一寫多讀特性或多隊列來知足冗餘數據的多份寫入需求，但僅能保障最終的一致性，中間可能會出現數據延遲。

• 引入接口層，經過不一樣業務模塊的接口將數據進行彙總以後再返回給應用層，下降應用層開發的編碼複雜度。

問：微博平臺當前在使用並維護着多是世界上最大的Redis集羣，在應用Redis的過程當中，大家都產生了哪些具備首創性的解決方案？

微博使用Redis的時間較早，而且一開始量就很大，因而在實際使用過程當中遇到了不少實際的問題，咱們的內部分支版本都是針對這些實際問題進行優化的。比較有特色的有以下三個。

增長基於pos位同步功能

在2.4版本中，Redis的同步一旦出現中斷就會從新將主庫的數據所有傳輸到從庫上，這就會形成瞬時的網絡帶寬峯值，而且對於數據量較大的業務，其從庫恢復的時間較爲緩慢。爲此咱們聯合架構組的同事借鑑MySQL的主從同步複製機制，將Redis的aof改造爲記錄pos位，並讓從庫記錄已經同步的pos位置。這樣，在網絡出現波動的時候，即便重傳也只是一部分數據，並不會影響到業務。

在線熱升級

使用初期，因爲不少新功能的加入，Redis版本不斷升級，每次升級時爲了避免影響業務都須要進行主庫切換，這對於運維帶來了很大的挑戰。因而咱們開發了熱升級機制，經過動態加載libredis.so來實現版本的改變，再也不須要進行主庫切換，極大地提高了運維的效率，也下降了變動帶來的風險。

定製化改造

在使用Redis的後期，因爲微博產品上技術類的需求很是多，因此咱們爲此專門開發了兼容Redis的redisscounter存儲技術類的數據。經過使用array替換hash table極大下降了內存佔用。而在此以後，咱們開發了基於bloom filter的phantom解決判斷類場景需求。

問：在一次分享中您曾經透露新浪數據庫備份系統正計劃結合水位系統實現智能擴容，請問如今實現到哪一步了？

目前這個事情的進展不是很理想，主要是咱們發現MySQL的擴容速度跟不上業務的變化，有些時候擴容完畢以後業務的高峯已通過去了，接下來就須要作縮容，等於作了無用功。因此，目前咱們的思路改成擴縮容cache層。首先實現cache層的自動擴縮容，而後同業務監控系統或者接入層的自動化系統進行聯通，好比，若是計算節點擴容100個node，那麼咱們的cache層就聯動擴容20node，以此來達到業務聯動。

問：將來5年內新浪數據庫還將作出什麼樣的改變？

隨着業務的發展，會遇到愈來愈多的場景，咱們但願能夠引進最適合的數據庫來解決場景問題，好比PostgreSQL、SSDB等。同時，利用MySQL新版本的特性（好比5.7的並行複製、GTID、動態調整BP），不斷優化現有服務的性能和穩定性。

另外，對於現有的NoSQL服務，推動服務化，經過使用proxy將存儲節點進行組織以後對外提供服務。對外下降開發人員的開發複雜度和獲取資源的時間，對內提升單機利用率並解決資源層橫向擴展的瓶頸問題。

同時，嘗試利用各大雲計算的資源，實現cache層的動態擴縮容；充分利用雲計算的彈性資源，解決業務訪問波動的問題。

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

數據庫圈子的變化確實很快，NoSQL還剛剛方興未艾，NewSQL又開始你方唱罷我登場。我我的並不認爲某種數據庫會取代另外一種數據庫，就如同NoSQL剛剛興起的時候不少聲音認爲它會完全取代MySQL，可是從實際狀況看依然仍是互依並存的關係。以我負責的集羣來講，反卻是MySQL更多一些。我我的認爲，每種數據庫都有其最擅長的場景，在特定場景下它就是最佳的數據庫，可是若是脫離了場景則很難說誰優誰劣。

問：可否請您橫向對比一下MySQL、MongoDB以及PostgreSQL？

我我的對MySQL使用得較多，MongoDB和PostgreSQL都有過一些接觸，MySQL做爲LAMP中的一員，老實說對大部分場景都是合適的，尤爲是在併發和數據庫量並無達到一個很大值的時候。可是，在某些場景下MongoDB和PostgreSQL確實更勝一籌。

好比咱們在門戶的新聞發佈系統中使用了MongoDB，其schema less的設計模式和新聞很是貼合，而其sharding功能又解決了容量上的橫向擴張問題，在這個場景下，MySQL並不具有什麼優點。

而在LBS（基於地理位置信息服務）相關的方面，PostgreSQL和PostGIS更具備優點，利用其空間數據索引R-tree和實體類型點、線、線段、方形，以及特定的函數，能夠很方便地實現空間計算需求。

就我我的來講，每種數據庫都有其擅長的場景。若是沒有特殊的架構需求，通常選擇MySQL都不會出問題。若是有特殊的架構需求，那麼就須要根據需求的特色來選擇不一樣的數據庫。

問：對於想要掌握MySQL的同窗，您有哪些學習上的建議？

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

其次，有條件的話，最好找一些大平臺歷練一下，在不少狀況下經驗和能力等同於你解決過的問題的廣度和深度，而環境決定你遇到的問題。

最後，有機會的話多作一些技術分享，不少知識點本身明白和能給別人講明白是兩個徹底不一樣的境界。

---

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