如何運營億級QPS的Redis系統

我們在運營redis的過程中，遇到各種各樣的問題總結如下：

環境：網路、tcp引數設定的問題；

設計：做持久化時，頁表複製造成的卡頓；

開發者：慢查詢，連線風暴，缺流控等；

終端使用者：比如電商的秒殺活動，訪問陡增導致處理能力到極限。

總的來說，是服務執行過程中，資源的需求與供給不匹配。

在應對這些運營難題過程中，我們陸續地翻越三座大山：

元資訊的混亂導致一些運維故障在日常運營中經常碰到？最基本的四類元資訊是集群、裝置、例項和配置。我們解決這類問題的時候定3條原則。

首先對所有元資訊進行梳理，提取各種元資訊的公共特徵，分類建模，然後抽象出模板物件的屬性與方法，定義資料結構，最後設定資料同步與消費的方式，對外提供api介面。這樣一套基本的db-cmdb子系統就建成了。也就是資料庫層統一元資訊管理系統。

設計思路上，採用通用框架，可以管理不同資料庫型別的資訊，也為後面的運維自動化奠定基礎。

系統提供服務之初，整體運維規模還不大，很多運維工作可以通過手工解決。在客戶量爆發後，1~2個dba是無法通過手工解決萬台裝置運營？更無法面對億級qps效能衝擊？

為了應對規模化的運營，我們打造「作業平台」的系統，來承載我們的運維邏輯。

首先將指令碼編輯作為工具，託管在平台上。這種工具的原則是原子操作，只有失敗與成功兩種狀態。工具串起來成為流程，每個工具可以被多個流程復用，這樣大部分運維操作，包括上下架機器，redis的遷移，擴縮容都可以通過流程來實施。同時各類操作均通過視覺化來展示，簡單明瞭。

手工觸發的運維流程，只能算是半自動化。我們該如何把整體的運營工作打造成全自動化呢？

自動化排程系統：對於按事件和時間排程系統異常時觸發的告警，第一是按時間排程，比如每週三下午3點重啟乙個服務，通過時間來觸發。第二是按事件排程，我們把每一種告警，都作為一種事件，註冊到排程系統中。排程系統捕獲到事件後，可以呼叫作業平台的任務或者流程去完成一些工作，這就形成乙個運維的閉環。

決策系統：在處理乙個事情之前，我們還需要獲取各種資訊，如何根據資訊做決策？乙個決策系統，先發起決策請求，過程中可能會涉及到一些決策樹，或者ai決策等，根據決策的結果，再確定調哪些作業流程，或者是否調作業流程。

總結：技術支援業務，技術推動業務，技術引領業務。

雲時代下，dba應該對自身能力提出更高更全面的要求。我們不但要保證系統高效穩定，協助好使用者，還要在產品打造方向、架構設計的細節上，元件的原始碼，社群的跟進甚至是引領，我們都需要有自己的積累與影響力。

我們既是運維，也是開發，也是產品。這也是雲時代下，服務化、do合一的乙個趨勢！