基于 Docker 的 RDS，我們是這樣做的

一、傳統DB的瓶頸及問題

1.1、傳統數據庫的創建主要分以下幾步：

1. 業務方&用戶和DBA申請，并附上業務量和需要的資源等信息

2. DBA根據需求，選擇相應的物理資源，并安裝數據庫

3. DBA交付數據庫，并提供數據庫連接信息如：IP、端口等

4. 業務方&用戶初始化數據庫，導入業務數據，然后找DBA建立訪問指定庫或者表的讀寫、只讀等權限的連接賬號

如下圖：

可以看出幾乎每一步都需要DBA的參與，在業務量小的情況下，并沒有什么問題。但是當業務增量越來越大，每天有幾十個甚至上百個數據庫申請時，DBA的負擔就會很大，而且影響業務上線速度。

1.2、數據庫為什么要平臺化

DBA每天都會遇到各個業務線的種種需求，每個業務線都會認為自己的需求重要，總會催DBA盡快完成。而DBA也是人，需要時間一個個的去完成這些需求。而這些需求其實90%以上都是重復性操作，很需要一個平臺來把這些90%的重復任務用邏輯代碼來實現，讓用戶或者DBA只需要點一點按鈕就可以完成。

二、RDS發展

隨著IaaS、PaaS平臺的流行，數據庫也從傳統數據庫服務逐漸轉向了云平臺數據庫服務化，在私有云+公有云模式下，越來越多新技術力量革新產生了更多優質化的服務。RDS做為典型的在線數據庫云服務，具有資源彈性伸縮，穩定性，易用性等特點。多重安全防護措施和完善的性能監控體系，并提供專業的數據庫備份、恢復及優化方案，使企業用戶能更加專注于應用開發和業務發展。為企業帶來了成本核算上的收益，降低綜合成本（硬件成本+管理成本）。

• 易用性

通過web方式管理數據庫，能夠短時間進行數據庫的快速部署，將完整的數據庫方案提供給用戶的同時，解決繁雜的數據庫維護成本，使得業務線能更高效的解決費時費力的重復性維護管理工作。

• 靈活性

RDS服務與用戶自身搭建的數據庫使用方式相同，對外IP+端口方式提供鏈接，能夠與云服務內ECS、SLB、GCE等服務結合提供更好的服務。

• 水平擴展能力

RDS應對業務量大規模變化時，節點內能夠快速進行硬件資源調整，節點間集群內也能快速的進行容量伸縮。有效的解決設備利用率偏低的問題，在不影響業務情況下進行動態遷移。

• 高可用性

RDS服務對外提供不同架構的可用性保障，在主業數據務節點失去響應能力的時候，能有相應的其他集群節點或從節點進行業務快速切換，防止因單點造成的業務損失。

• 云化

RDS服務是在原有傳統關系型數據庫服務發展的基礎上，結合目前主流的云計算虛擬化等技術，將數據庫管理實現成一鍵式、自動化、 資源池、在線集中管理等方式，減少很多繁雜管理操作，同時能夠快速更加便捷的操作和使用數據庫。

三、樂視RDS

3.1、誕生

3.1.1、為什么會有樂視RDS

在日常管理傳統數據庫的時候我們遇到了很多問題，比如：

• 樂視這幾年快速發展的同時，業務對數據庫的需求量也是越來越大，最開始的時候業務庫還是人工或者人工+腳本的方式創建。業務緊急上線，數據庫的搭建時間就是個瓶頸。

• 由于安全原因或者權限問題，用戶需要緊急修改數據庫賬號密碼，但由于聯系不到DBA，不能及時修改，可能造成數據泄露、丟失。

• 用戶想知道當前的數據庫狀態或者一些性能指標，而此時DBA在忙著處理線上問題，不能及時提供等等。

我們就開始思考，是不是需要作出一套樂視RDS，在業務方或者用戶需要數據庫資源的時候，只要登錄平臺輕輕一點數據庫創建按鈕，即刻使用。我們只提供基礎的數據庫服務平臺，并負責其穩定性和可靠性。而用戶有自己數據庫大部分管理權限，讓用戶對數據庫的操作脫離DBA，并且了解自己數據庫的實時狀態。這樣既減輕了DBA的壓力，又帶來了更高的效率。

最終樂視RDS的雛形就建立了起來，樂視RDS基于docker虛擬化可以限制硬件層（CPU、內存、磁盤io）等資源，將同屬于一個物理集群之間資源進行隔離。有效控制資源環境穩定性并提高資源利用率。

從2014年開始我們就嘗試使用Docker容器技術，把容器作為RDS數據庫集群各個節點運行的基礎環境，這在國內可以說是比較早使用此種架構的互聯網公司。

3.1.2、為什么會選用Docker技術

我們使用Docker主要的原因有：

• 開源程序，可定制開發

• 快速部署

• 靈活

• 豐富可定制的鏡像資源

• 資源隔離

• 輕量，滿足數據庫運行環境即可，不會占用多余的系統資源

3.1.3、優勢何在

對應云端的數據庫來說，其實用戶最想看到的就是，在申請完數據庫后，立刻就能使用，并自主管理，而樂視RDS完全可以滿足：

• 快速

• 穩定

• 可控

• SSD的加入，IO不再是數據庫瓶頸

• 無需熱備，所有節點都在激活狀態，都為多主結構

• 應用可以從集群中任意節點進行讀寫

• 讀寫可水平擴展

• 可線上動態添加、刪除數據節點

• 擴展，縮減數據節點對客戶端透明

3.1.4、遇到的問題

在樂視RDS這幾年的發展過程中，其實遇到了很多的困難和問題，下面大概說幾點：

• 數據庫的版本和架構選型

根據云平臺的特性，我們最終選擇了基于Percona Xtradb Cluster的數據庫集群架構，并對其進行了一系列優化，使其在容器環境下更穩定的運行，我們內部命名為Mcluster。

• 數據庫賬號權限的管控

對數據庫賬號的管控很重要，我們嚴格控制數據庫賬號的權限，使之只能在指定的權限下，干相應的事。

• 數據庫物理資源隔離限制

因為我們的數據庫基于Docker技術，所以物理資源的隔離變得尤其重要，其中也遇到了很多問題。現在我們已經可以隔離包括CPU、內存、磁盤IO等物理資源

• 使用入門

能更好的把用戶了解并熟練使用樂視RDS這其實是很難的一件事，因為內部用戶的觀念里還是認為數據庫要DBA管理，不關他們什么事。

我們經常和用戶進行交流，收集他們初次使用樂視RDS中遇到的各種問題，并完善我們的幫助中心和Web頁面使用向導。

• 備份恢復

數據庫備份重要性不言而喻，在硬件損壞、數據丟失、誤刪除等等的很多災難性的時刻，如果做了充分的備份都可以保證數據的全量恢復，最大限度的挽救丟失的數據。

由于數據庫集群的特性，數據是冗余三份或者更多的，備份功能我們也是經過了幾個版本的迭代，正常業務每天都會有備份，在部分重要業務上可以開啟實時備份功能。

• 全局數據庫性能狀態掌控

隨著數據庫的總量越來越大，對所有數據庫性能的掌控變得尤其重要，為了實時了解數據庫運行狀態，我們定制了一系列的指標來完成此目的。

• 預警維度制定

預警維度的制定這個環節是我們最頭痛的，由于前期定制的告警維度過于敏感，導致告警量很大，對于相關運維人員來說是個噩夢。

最終經過多次討論，修改了很多不必要的預警維度，使現在的樂視RDS預警精確性大大提高。

經歷了上面的種種問題和阻礙，樂視RDS終于橫空出世。

3.2、發展和現有規模

3.2.1、樂視RDS主要發展大事記如下

樂視RDS現在主要還是給樂視集團內部各個子生態提供數據庫服務，線上已經為900+的業務線提供數據庫服務，3000+的容器規模，樂視RDS在集團內部數據庫使用率已經達到60%以上。

3.2.2、RDS主要架構發展歷史

RDS架構1.x：單實例多Database+LVS（ 起步 ）

RDS架構2.x：PXC+Docker+Gbalancer （ 發展 ）

RDS架構3.x：(PXC or PostgreSql or MariaDB or otherDB)+Docker+Gbalancer（ 多元化 ）

• 1.x主要是 起步 階段，我們選擇在每個物理機上安裝單實例庫，并在上面創建多個database，通過LVS進行負載，但使用中發現這種架構并不適合云平臺的理念。

• 2.x主要是 發展 階段，我們選擇了PXC（Perconal Xtradb Cluster）數據庫集群，運行在Docker上，并使用Gbalancer做數據庫代理。

• 3.x主要是 多元化 階段，經過前面兩階段大的架構演變，我們最終的目的是把平臺當成插槽（既提供各種通用的接口）。不限于MySQL，任何數據庫都可以插到平臺上，進行創建、管理等一些列操作，為用戶提供穩定、快捷、易維護的數據庫服務。如下圖：

3.2.3、樂視RDS為各個子生態提供數據庫服務

樂視RDS現在已經為樂視各個子生態提供穩定、高效的數據庫服務，并根據業務方使用中反饋的各種需求和問題，完善著樂視RDS。

3.3、樂視RDS整體構架圖

樂視RDS整體架構主要分為以下幾大部分：

1） Database層為具體的數據庫業務，和MySQL選擇存儲引擎一樣，Database層也秉承著可插拔特性。既可以是MySQL，也可以是PostgreSQL等任何數據庫（我們現在使用的為MySQL）

2）    Matrix層負責前端數據庫創建、管理、監控、維護和相關資源調度

3）    Data Analysis層主要負責數據庫日志的分析還有用戶行為分析

4）    BeeHive層負責組件服務的調度管理

3.4、樂視RDS基本使用示意圖

• 業務用戶：可以通過Matrix云平臺對數據庫，進行創建、擴容縮絨、權限配置、性能查看、用戶資源管理等等的一系列操作。

• DBA&平臺管理員：有更高的權限管理所有數據庫集群，并可以根據收集過來的日志分析數據庫性能、用戶行為等等。

• 業務服務器：會通過本地安裝的Gbalancer中間件，來訪問相應的數據庫。

• ES集群：會收集Mcluster日志數據、容器里的相關日志，以供進行業務分析。

• 物理資源池：根據Mcluster的配置需求，在物理資源池里獲取相應的資源，而且當物理資源不足的時候，可以動態的添加物理服務器到物理資源池里，來擴充整個物理資源池。

3.5、彈性伸縮

樂視RDS的彈性伸縮是基于 “大資源池的概念” ，所有物理服務器資源在整體看來其實一個大資源池，數據庫可以在這個池子里自由的擴容、縮容、遷移。

3.5.1、彈性伸縮的主要特點

擴容&縮容

樂視RDS可以隨著業務的瞬時增長，在業務高峰時自動擴容（包括節點數量、CPU、內存、IOPS等），當度過業務高峰后，在閑時自動縮容，在保證業務穩定的同時最大限度的節省硬件資源。

平滑遷移

隨著業務量的的線性增長一定階段后，出現物理資源瓶頸，樂視RDS能在可以實現不停業務或者說用戶無感知的情況下，平滑的遷移數據庫到更高配的物理服務器上，同時保證業務的不間斷性。

3.5.2、使用場景介紹

1）    三節點的數據庫集群已經不能滿足用戶大量并發查詢的需求，需要彈性添加數據庫節點

2）    由于物理服務器損壞，需要把物理服務器上的數據庫放到健康的服務器上

3）    單個業務量增長巨大，之前使用的數據庫集群所在的物理機資源（比如：CPU、內存、磁盤IO等）已經不能滿足業務的要求，此時樂視RDS可以實現不停業務或者說用戶無感知的情況下，平滑的遷移數據庫到更高配的物理服務器上。

3.6、數據庫預警

數據庫預警對于提供平臺服務的我們來說，其實是很重要的一塊，如何保證數據庫出問題的時候，第一時間通知相關責任人解決故障，這是我們提供更好服務的關鍵。

目前主要使用云平臺的RDS預警功能模塊進行數據庫預警：

3.6.1、普通級別告警

數據庫集群未出現明顯異常，也沒有對業務造成影響，但已經超過了平臺預設的最低穩定指標，比如：數據庫讀寫超時、集群節點間同步數據延遲等等。通過短息、微信、郵件的方式通知相關責任人，提前分析原因，并進行相應的處理措施。保證在未出現問題之前，就已經及時發現并把問題解決。

3.6.2、嚴重級別告警

數據庫集群已經出現了明顯異常，而且對業務操作了一定的影響，比如：嚴重超時、數據庫節點或整個集群故障等。通過電話、短息、微信、郵件所有通知途徑，告知相關責任人，及時上線解決問題，盡可能的減少因為數據庫問題對業務造成的損失。

3.7、數據庫監控

監控系統在云平臺RDS服務中處于舉足輕重的地位，監控系統的好壞直接決定了，RDS服務出現問題之前預測性能瓶頸，是RDS服務提供穩定服務的有利保障。

監控系統我們已經完全實現平臺化收集并查看，監控指標包括容器的各類性能指標、數據庫各種性能指標、數據庫集群各個節點間同步狀態的監控等等。

下面大概介紹一下：

3.7.1、容器的性能監控

因為我們是基于容器運行數據庫服務，所以容器的性能監控至關重要。通過安裝在各個物理集群里的agent程序，收集相關數據到Matrix平臺，收集的信息包括所有數據庫容器的CPU、內存、磁盤IO、網絡等等的使用情況，DBA會通過平臺多種維度的展現，來及時發現出現性能瓶頸數據庫容器，并優化相關數據庫服務。

下面為Matrix平臺展現的，某個物理集群中，讀寫消耗Top3的容器相關指標曲線圖：

3.7.2、數據庫性能監控

包括數據集群的TPS、QPS、Innodb相關資源使用情況監控等等。下面為平臺的部分截圖：

1)    數據庫基本運行指標

2）數據庫集群實際read行數情況統計

3.7.3、集群數據同步監控

根據數據庫集群同步參數，來收集集群各個節點間的同步狀態。下面為平臺的部分截圖：

3.8、Gbalancer數據庫中間件

為了保證數據庫的高可用性，雖然基于Percona Xtradb Cluster的Mcluster數據庫集群架構可以接受多節點寫，但是在我們的實際使用中發現其在大量并發寫的情況下，會出現各種問題。

而在2014年的時候，大多數中間件不能滿足我們的需求，最終我們決定自己開發一款符合我們要求的數據庫集群中間件。

我們開發了一款內部命名為Gbalancer的數據庫中間件產品，Gbalancer的主要特點是輕便、高效、部署簡單，并且充分利用了Mcluster數據庫集群特性。

通過和業務代碼的配合，其可以實現數據庫級別的高可用、負載、讀寫分離等功能。

Gbalancer的幾種主要運行模式有：

1）    輪詢訪問模式：把數據請求輪詢轉發到后端Mcluster數據庫集群的所有節點

2）    單節點訪問模式：把數據請求只轉發到數據庫集群中的一個節點上，只有當前數據庫節點有問題的時候，才會切換到另外一個數據庫節點上

3）    隧道模式：通過和數據庫節點建立持久隧道連接，所有數據連接都通過隧道來訪問數據庫（適用于短連接）

不同模式有各自的特點和業務使用場景。

在實際線上應用中，通過在本地業務服務器上安裝Gbalancer，根據需求配置Gbalancer連接數據庫的模式，并和業務代碼相結合，最終可以實現數據庫級別的高可用、負載、讀寫分離等功能。如下圖：

注：Gbalancer目前已經開源，項目地址為 https://github.com/zhgwenming/gbalancer

3.9、日志收集和分析

由于RDS數據庫集群的數量激增，我們最頭痛的就是數據庫集群批量報錯、單個業務線出現大量的低效的SQL語句等問題的及時發現和后期的分析工作，這些問題雖然短時間內也許不會造成致命問題。但如果不及時發現問題進行處理，后期很可能是致命性的。

目前通過ES，我們把所有日志進行統一的存儲、管理和分析。其中對于數據庫來說，最主要的日志還是錯誤日志和慢查詢日志。

我們把收集過來的MySQL（錯誤、慢查詢）日志、容器日志按各個關鍵指標和維度進行劃分，在Matrix云平臺上以圖表的形式展現出來，可以宏觀的查看所有的日志信息，這樣保證了：

1）    出現數據庫集群報錯的時候我們能捕獲報錯并查看其規模、分類和具體信息

2）    如果批量出現大量慢SQL時，我們也能按照時間、數量、來源IP等一些列維度，來發現有問題的SQL語句，并對相關業務方提供優化建議

3）    數據庫容器報錯后，能捕獲并及時發現問題、解決問題，還可以供后期分析問題原因，防范再次出現

如下圖：

3.10、踩過的坑

1）    在線修改大表，會對整個集群造成影響

2）    多節點寫，產生大量死鎖

3）    大批量DML，整個集群pause

4）    導致數據庫集群間不同步的場景

5）    集群級別從庫壞了后的自動切換

6）    創建表為MyISAM引擎后的數據恢復步驟

四、展望

樂視RDS發展到現在，已經逐漸趨于成熟，但還有很多功能需要完善，在今年我們會繼續發力樂視RDS。使其在功能和穩定性方面更上一層樓，并在不久的將來和大家見面。

• VSDL（Virtual SQL Data Layer）構建

• 全球化分布式數據庫

Q&A

Q1：你們的RDS有用Zabbix進行集中監控管理嗎

A1：我們監控中有zabbix進行監控，zabbix通過調用我們自行開發的接口監控數據庫狀態，進行數據庫容器集群事實監控。

Q2：請問運維標準化怎么定義的，怎么實施的

A2：運維標準化的范疇還是挺大的，比如服務器標準化，IDC標準化，網絡標準化，架構設計標準化，容器標準化等等。就不一一列舉了，我們通過規范與宣講，起到了一定的效果，但是隨著樂視集團與云公司的發展，已經趕不上變化，只有平臺化，將各種標準系統化管控起來，才能將我們的標準與想法一一實現。這也是現在業界的一個普遍共識。

Q3：運維自動化用的什么平臺

A3：運維自動化我們使用的是自主開發的Matrix管理平臺

Q4：怎么快速擴容，快速部署

A4：依賴于Docker的先天特性，我們通過部署在物理機上的beehive程序，來快速部署容器。而容器里的mcluster-manager來進行數據庫集群的擴容。

Q5：發布系統怎么做的

A5：目前我們發布系統是自行研發的系統，根據集群容器級別進行升級，以python +saltstack方式實現快速容器集群組件升級。

Q6：filebeat在使用過程中是否遇到發送重復數據，或者說超時重發導致日志大量重復，是否遇到過？怎么解決的

A6：我們使用filebeat中，并未發現發送重復數據，超時的話會有，我們通過date插件來把時間鎖定在實際的日志記錄時間。

Q7：集群日志會不會出現時間差異

A7：如果不用date插件的話，會出現。我們現在用date插件來獲取日志實際的記錄時間，并錄入ES集群，可以避免日志記錄時間和ES存儲時間的差異。

Q8：后端存儲用的是什么 是開源的分布式存儲嗎

A8:目前我們根據不同的業務線有不同的存儲方案，一般RDS這邊采用的存儲相對比較傳統，SAS、SSD，備份盤采用Gluster分布式系統。

Q9：請問你們對不對log做解析，把字符串解析成對應的參數值。如果是用logstash做，是否遇到解析速率的瓶頸，如何優化的

A9：我們會對log進行解析的，只會截取取關鍵數據指標錄入ES集群。logstash我們也有在使用，通過把數據放到MQ里，然后用多個logstash解析MQ里的日志數據，加快解析速度。

Q10：關于Gbalancer中第三種方式隧道，這個主要解決的什么問題？是基于什么應用場景產生的？比另外兩種的優勢在哪

A10：主要解決短連接過多消耗數據庫資源，通過和數據庫節點建立持久隧道連接，所有數據連接都通過隧道來訪問數據庫，進而減小對數據庫服務器資源的消耗。另外兩種輪詢和單節點訪問，是不會建立持久連接（除非所用的編程程序支持）

Q11：能否將踩過坑中的解決方案例如多節點寫產生死鎖問題解決方案介紹下

A11：我們通過在業務端安裝gbalancer，用端口區分，分別使用gbalancer輪詢和單節點模式。然后在業務代碼里把讀和寫用不同的gbalancer代理端口來訪問數據庫。

Q12：你們使用docker是如何進行編排的

A12：matrix+beehive，matrix是編排器，beehive是容器管理系統。請

Q13：在寫入數據之后進行集群間同步的時候，是最終一致性還是實時一致性？設計時時如何考慮的

A13：Mcluster底層采用的是開源Percona Xtradb Cluster 進行封裝，PXC集群數據為強一致性，架構設計之初考慮到互聯網應用讀寫比例，讀較為大的情景。PXC多節點數據一致性的同時，多節點讀也帶來讀性能的提高。

Q14：您好老師，請教一下，當數據庫鏈接突然斷掉，數據需要回滾的時候，這個時候集群是如何做的

A14：PXC集群特點，在每一次數據庫會話連接時候，保證多節點一致性，數據庫會話提交都需要在多節點進行驗證，驗證通過后才會提交執行。這里所提到的當數據庫會話連接突然斷掉的場景，應該屬于應用于數據庫連接沒有進行commit確認操作，會進行回滾。

Q15：請教下您這邊，剛才講到了數據庫集群的擴容，請問下擴容之后，新的庫是否要全量復制所有數據？還是增量保存

A15：擴容是會讀取共享磁盤上備份數據，在擴容節點進行恢復，然后選擇壓力最小的作為donor，進行增量恢復。根據場景不同也有可能做SST全量復制，進行動態擴容。

 

 

 

來自：http://mp.weixin.qq.com/s?__biz=MzA4Nzg5Nzc5OA==&mid=2651662244&idx=1&sn=df48003cfa9bb339702cda63a88249f6&scene=0