作者 |  十眠

我們從應用的視角出發(fā)整理抽象了我們在訪問、使用數(shù)據(jù)庫時場景的一些穩(wěn)定性治理、性能優(yōu)化、提效等方面的實戰(zhàn)經(jīng)驗，對于每一個后端應用來說，數(shù)據(jù)庫無疑是重中之重，我們希望通過我們的數(shù)據(jù)庫治理能力，可以幫助到大家更好地使用數(shù)據(jù)庫服務。

MSE 數(shù)據(jù)庫治理完整解決方案

本文將詳細介紹 MSE 數(shù)據(jù)庫治理的熱點功能，動態(tài)讀寫分離的設計與實現(xiàn)。

1.讀寫分離的概述

數(shù)據(jù)庫動態(tài)讀寫分離的常見場景：

• 一個大客戶的請求過來，查詢數(shù)據(jù)庫返回上萬條幾百 M 的數(shù)據(jù)，數(shù)據(jù)庫的 CPU 直接打滿。
• 微服務應用的某些業(yè)務并不是那么重要，卻存在大量查詢數(shù)據(jù)庫的邏輯，影響數(shù)據(jù)庫實例穩(wěn)定性，從而導致整體服務質(zhì)量的下降。
• 在業(yè)務處理過程中，如果對數(shù)據(jù)庫的讀操作遠多于寫操作，那么在做系統(tǒng)性能優(yōu)化時就可以考慮引入讀寫分離的方案，一方面只讀庫可以承擔主庫的壓力，另一方面能夠有效的避免由數(shù)據(jù)更新導致的鎖等待，提升微服務應用的性能。
• 隨著業(yè)務的增長，我們在一定時機下需要對數(shù)據(jù)庫實例進行擴容。根據(jù)經(jīng)驗大多數(shù)應用的讀寫比都在 5:1 以上，有些場景甚至大量的高于 10:1，在對數(shù)據(jù)庫有少量寫請求，但有大量讀請求的應用場景下，單個實例可能無法承受讀取壓力，甚至對業(yè)務產(chǎn)生影響。

可以了解到的是數(shù)據(jù)庫讀寫分離方案可以滿足阿里云上大多數(shù)公司的穩(wěn)定性治理、性能提升以及數(shù)據(jù)庫擴容的需求。

如果了解讀寫分離實現(xiàn)的同學一定會關注以下這些問題：

• MSE 是如何解決讀寫分離對業(yè)務的侵入性？如何做到業(yè)務無需改動一行代碼，即可具備讀寫分離能力。
• MSE 如何做到精細化動態(tài)的讀寫分離控制？即使我們不知道這個業(yè)務接口真實的 SQL 是什么，但我們已經(jīng)可以控制這個接口的讀 SQL 訪問只讀實例。
• MSE 是如何解決讀寫分離帶來的一致性問題？對于一致性敏感的業(yè)務，如何實現(xiàn)一致性的保障，滿足業(yè)務在不同場景下對一致性級別的要求。

2.MSE 讀寫分離技術揭秘

讀寫分離也就是將數(shù)據(jù)庫拆分為主庫和從庫，即主庫負責處理事務性的增刪改操作，從庫負責處理查詢操作的數(shù)據(jù)庫架構(gòu)。單單看讀寫分離的概念，第一感覺就是對業(yè)務的侵入性一定不小，那么 MSE 是如何做到無侵入的呢？

（1）無侵入性：無需修改一行代碼

MSE 數(shù)據(jù)庫治理能力通過 JavaAgent 技術，動態(tài)增加用戶的數(shù)據(jù)源，注入動態(tài)讀寫分離能力，支持運行時動態(tài)將弱讀請求路由至只讀實例。

MSE 在數(shù)據(jù)源層面實現(xiàn)了抽象，其中 DynamicConnection、DynamicStatement 會根據(jù)具體規(guī)則從而實現(xiàn) Master/Slaver 的切換，做到根據(jù) SQL 的讀寫類型、事務的狀態(tài)以及用戶的業(yè)務規(guī)則來做 SQL 的路由，將符合條件的讀 SQL 請求轉(zhuǎn)發(fā)至 RDS 只讀實例中。

（2）精細化路由：按照請求條件、接口、SQL 多層次多條件

很多時候我們通過編寫 DAO 訪問數(shù)據(jù)庫，那么在一些復雜應用的場景下，我們很可能只知道 DAO 接口，在一些復雜場景下我們只知道微服務的接口，內(nèi)部甚至搞不清楚到底調(diào)用的哪個 DAO 接口、SQL 語句，甚至如果是運維角色參與設計，我們很可能不知道哪個微服務接口導致的讀請求導致數(shù)據(jù)庫抖動，我們只知道入口應用的某個 uid。那么我們?nèi)绾巫龅綄I(yè)務接口內(nèi)的讀請求路由至只讀實例呢？

MSE 數(shù)據(jù)庫治理提供了應用層面完整的 callStack 信息，可以讓我們站在應用的視角上清晰地看到哪些接口內(nèi)部執(zhí)行了哪些 SQL。

MSE 通過鏈路傳遞技術，支持在入口微服務、微服務接口、DAO 層面標記弱讀請求的標記，支持標記的當前線程內(nèi)的 SQL 調(diào)用、當前微服務內(nèi)的 SQL 調(diào)用、符合流量條件的請求鏈路級別的所有 SQL 調(diào)用等多個層面的弱讀標記傳遞，最終傳遞給讀寫分離組件的路由引擎進行  SQL 的路由依據(jù)的判斷。

（3）強一致性模式：指定接口、事務

當數(shù)據(jù)庫負載很高時，例如對大表執(zhí)行 DDL（如加字段）操作或大批量插入數(shù)據(jù)的時候，延遲會非常嚴重，從而導致無法從只讀實例中讀取最新數(shù)據(jù)。MSE 提供了一些策略解決如上問題，某些接口或者某些業(yè)務對一致性比較非常高，我們可以通過規(guī)則配置告訴 MSE 在特定場景下，某些讀接口標記為強讀請求。MSE 內(nèi)部會通過一些機制保證讀寫分離的強一致性效果。

（4）白屏化能力：通過 AccessLog 實時感知讀寫分離情況

有讀寫分離能力，那么我們?nèi)绾沃雷x寫分離的執(zhí)行情況，到底哪些應用，哪些請求被分離至了只讀實例？MSE 白屏化能力提供了一套完整的 AccessLog。

• 讀請求路由至只讀實例

• 讀請求路由至主實例

3.總結(jié)

MSE 從應用的視角出發(fā)，結(jié)合微服務治理通用的技術，MSE 推出的是完整的數(shù)據(jù)庫治理解決方案，從 SQL 洞察、SQL 流控降級與容錯、連接池治理到數(shù)據(jù)庫灰度、動態(tài)讀寫分離。我們希望通過數(shù)據(jù)庫治理能力可以幫助用戶的微服務可以更好地使用數(shù)據(jù)庫，降低數(shù)據(jù)庫使用的成本，提升數(shù)據(jù)庫訪問的穩(wěn)定性。

MSE 的數(shù)據(jù)庫治理能力也需要更多更加深入的客戶場景與落地實踐，如果您對 MSE 的數(shù)據(jù)庫治理能力感興趣，歡迎聯(lián)系我們，只有經(jīng)過客戶打磨的產(chǎn)品才會愈發(fā)歷久彌新。

在建設數(shù)據(jù)庫治理能力的同時，我們也通過 OpenSergo 在與社區(qū)共同建設數(shù)據(jù)庫治理的標準。