RDS平台介紹

本文整理自美團點評技術沙龍第10期：資料庫技術架構與實踐。

美團點評技術沙龍由美團點評技術團隊主辦，每期沙龍邀請美團點評及其它互聯網公司的技術專家分享來自一線的實踐經驗，覆蓋各主要技術領域。

本次沙龍主要圍繞資料庫相關的主題，內容包括美團資料庫自動化運維繫統構建、點評側MySQL自動化服務平台RDS、美團資料庫中間件、和小米高級DBA帶來的Redis Cluster的大規模運維實踐。

今天我就給大家講一下我們這邊做的資料庫運維的自動化平台，他是怎麼樣子的。首先我會給大家簡單介紹一下我們做平台的背景，以及平台的一些技術架構，以及針對我們DBA和開發的需求的全套解決方案。

首先是背景，我們為什麼要做RDS，在做RDS之前其實我們也有一套自己的自動化系統，可是我們有了這套自動化系統我們發現有了之後我們DBA還是很忙，每天忙於工單處理，大表DDL，集群搭建，擴容，數據遷移等等。這些東西不能說沒有價值，但是對於DBA來說，每一次的重複操作，都會讓這個價值指數級下降，並且不能帶來成長。所以我們對這些需求做了一個簡單的分析。

首先第一個，工單審核，大表DDL，數據許可權，都是與數據相關的需求，我們看另一部分，集群擴容，數據遷移，故障轉移是與資料庫相關的。所以我們這邊有一個理念我們一定要讓數據相關的全部讓他們自助化，讓開發去做，而不是讓我們DBA去做，而跟DBA相關的全部讓他自動化。這就是我們現在的理念。

接下來我們面臨一個問題就是改造原系統還是重建一個。老系統很符合一個傳統運維繫統的「特點」：運維開發自己搭伺服器，自己上線，自己維護。這會帶來一系列問題，比如自己維護的成本很高，還有就是因為這一套與線上業務應用完全不同，所以無法享用業務成熟的組件以及各種自動化服務。所以我們改變了以前的思路，我們以前自己搭的系統全部廢掉，全部用線上的系統，我們從整個系統維護搭建以及我們使用的組件全是線上一模一樣的一套，甚至包括我們資料庫這些東西，全部託管到我們DBA來，還有對伺服器這塊交給業務運維他們去管，他們更專業，管得肯定也更好。還有就是原來系統面向DBA的，就是我讓你DBA工作稍微不再繁瑣，自動化工具，你去點一下做完了，現在我們的理念是面向開發，什麼叫面向開發呢？就是我們希望開發與我們DBA的整個交互，靠這個系統來交互，你不要老找我說這說那，你就跟我系統打交道好了，有什麼錯我們系統會告訴你，告訴你怎麼去做，讓DBA完全從我們整個平台的日常需求裡面脫離出來，這就是我們整個的設計理念。

因為我們說了，我們要跟線上業務一樣，所以我們前面有了一層slb，做均衡負載的。然後是RDS主體部分，主要由RDS主程序和、動態配置管理中心Lion，數據遷移工具Puma和數據訪問層中間件zebra組成，其中zebra中間件是一個基於jdbc的資料庫動態鏈接池。

資料庫則是MHA+MySQL的架構。最後有一個輕量級的jobCenter，主要用於執行系統級的命令。

最後是一個Job Center，因為我們DBA需要跟資源打交道，會去做一些資源維護，你需要操作系統級別的許可權，我們要實現他，其實我們當時有三種方案，第一個我們在自己的管理伺服器之上搭一個服務提供API，你來調度，但這就回到我們以前的老路上，你需要去維護這服務，成本很高。第二個就是我們在我們自己的機器上，去裝這些腳本，或者給他一些操作系統級命令他自己去執行，這裡面又有一個問題，這樣裝了之後，我們自己的伺服器和線上應用伺服器就不一樣，當他不一樣之後你就無法讓業務運維進行統一化管理了，所以我們也拋棄了。我們就選了第三種方案，把我們的命令寫在這個MySQL裡面，我們專門的管理機去取這個命令去執行，而且這層特別薄，薄到幾乎無需維護，這樣就跟線上業務一模一樣，而且還可以進行水平擴展，所以整個系統下來全部可以水平擴展。

然後我們還有一個無狀態任務流中心：

這個主要分為process和task。每個process由多個task組成，每個task可以分成多個並發的子task，每個子task我們都會盡量做成冪等。

整個流程由start開始，並由流程中心的doNext控制，最後的每個任務進入到一個任務隊列中，最後jobcenter會取出任務，並fork出新進程具體執行相關任務，並進行回調。為了支持jobcenter的分散式擴展，我們用mysql的任務隊列做了一個很輕量級的互斥鎖來達到多任務中心的互斥功能。主要是我們給每個task一個初始狀態UNDO，然後task center拿到任務後會回去update這個任務，並將UNDO作為條件，然後得到MySQL的匹配行數返回值，如果為1則執行，否則放棄，給其它task center執行。

RDS系統實現了DBA的一鍵集群搭建，擴容/縮容，備份還原，流量控制，動態遷庫/拆庫，以及單表拆分等功能。我們主要來看看動態數據遷移。

動態遷庫/拆庫在可靠性和自動化程度相較之前都有了一個很大的提升。而動態遷庫/拆庫主要分為四個步驟：1.種子數據的遷移；2.增量數據遷移；3.賬號許可權遷移；4.數據源切換。而增量數據遷移和數據源切換是關鍵點。其中增量數據遷移我們支持中間機（搭建MySQL中間機，通過配置過濾規則進行數據同步）和puma兩種方式，因為各有優缺點（前者快但繁瑣且只能有一個源，而後者雖然稍慢，但是支持多源同目標）。

在切換數據源時，我們採用：校驗許可權→鎖表→校驗數據一致性→切換動態數據源→kill被阻塞query→renametable...→resetslave這樣一個流程來保證整個流程的安全可靠。其中對於鎖表，我們必須在一個事務中進行lock tables，數據一致性校驗我們採用官方的checksum演算法來check每張表的最後1000條數據（1000是我們的一個經驗值），然後針對遷移過程中被阻塞的sql，我們採用直接kill的方式來讓業務報錯重試，以避免數據的不一致。

而對於單表的自動分庫分表，我們採用：配置分表規則→根據規則dump數據→配置增量同步任務→業務開啟雙寫→關閉老表寫入這樣幾步來實現單表的動態拆分。

針對開發人員，我們提供了一個SqlEditor的模塊來支持。這個模塊集查詢，修改、許可權配置和數據模糊於一身。它相對於以前的臨時許可權方案主要有這樣幾個優點：

1.統一的系統級訪問賬號

2.從向資料庫申請許可權變成向系統申請許可權

3.從根源上規範了用戶的訪問行為(默認訪問運營庫，主庫查詢嚴格控制，返回結果1w行，60秒kill)

4.審計、安全控制更加方便(讀寫許可權分離，column級別的密級設置以及數據模糊)

作者簡介

柯任，美團點評開發DBA。主要負責點評側自動化平台的搭建以及Mongodb的維護工作。