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

肖鵬，微博研發中心技術經理，主要負責微博資料庫（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通讀一遍。

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

最後，有機會的話多做一些技術分享，很多知識點自己明白和能給別人講明白是兩個完全不同的境界。

---

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