流控資料庫

A. 阿里雲 MSE 支持 Go 語言流量防護

隨著 Go 語言和雲原生技術的普及，Go 語言在微服務場景中的應用愈發廣泛，對微服務治理和流量控制的需求也日益增長。在 Go 語言中，盡管社區提供了 go.uber.org/ratelimit 等限流庫，但這些庫存在局限性：僅支持 Go 語言，且功能上缺乏多語言兼容和動態配置，無法滿足完善的限流降級需求。

阿里雲微服務引擎（MSE）結合了業界先進的 Sentinel 技術，為 Go 語言和 Java 應用提供了全面的微服務治理能力。本文將詳細講解如何在 Go 語言微服務中利用 MSE 的限流降級功能。

限流降級在微服務中是通過三個步驟實現的：首先，設定目標介面（Target），如訂單創建介面，限制其每秒請求量（Strategy）為1000次；當達到限流閾值後，返回異常（FallbackAction）以防止系統過載。

為了在 Go 語言應用中接入 MSE 的限流降級，首先在啟動應用時，添加 MSE SDK 的初始化命令。在雲原生部署中，推薦通過環境變數管理配置，以方便在不同環境間切換。MSE-Go-SDK 推薦使用特定的環境變數來連接 MSE。

接入後，可以在 MSE 控制台的「應用列表」頁面查看已接入的應用。接下來，要定義資源（Target），MSE 支持使用 Sentinel 的資源定義，只需將業務邏輯包裹在 Sentinel 定義的代碼塊內。對於使用微服務框架如 Dubbo-go、Gin 或 gRPC 的開發者，可以利用相應的適配器自動注冊資源到 MSE。

配置限流降級規則時，可以設置流控、隔離、熔斷和熱點規則。在應用詳情頁面，可以查看資源概覽、代碼中的資源注冊以及規則設置的效果，如流量拒絕率、並發控制等。MSE 還在持續發展，計劃支持 OpenSergo 標准，以實現不同語言微服務的統一治理，並探索流量治理、資料庫治理等更多功能，為開發者提供全面的微服務治理解決方案。

如果您對 MSE 專業版或雲原生網關感興趣，可以享受折扣優惠。獲取更多信息和下載鏈接，請參考相關鏈接。

B. 為什麼要用 Tair 來服務低延時場景 - 從購物車升級說起

低延時服務是內存資料庫Tair的核心能力，使其在高吞吐、大連接數、熱點請求、異常流量、復雜計算邏輯、彈性伸縮等真實場景中保持穩定性能的關鍵。今年雙十一期間，Tair作為購物車升級的核心產品，展示了大淘寶技術團隊不斷自我審視、追求更好的選擇的精神。

體驗提升通常意味著降低服務降級、提高數據實時性、減少調用鏈路的延遲。這需要從客戶端到資料庫組件的每一個環節提供最強的產品能力。在資料庫層，挑戰在於在訪問量激增的同時，保持延時穩定和成本控制。Tair具備內存/SCM混合存儲、水平擴展分區無鎖和sql引擎等技術，這些技術在支撐雙十一活動的過程中逐步完善，持續優化服務端性能。

存儲引擎性能是低延時的基礎，涉及並發、事務處理、快照等功能。Tair採用內存/SCM作為主要存儲介質，提供單次訪問延時在ns級別的性能。介質成本考量包括硬體選擇和數據結構設計，如採用SCM降低存儲成本，並通過透明壓縮減少空間佔用。索引方面，Tair使用多種數據結構如HashTable、SkipList、RBTree等，針對不同場景優化性能。

為應對高並發挑戰，Tair採用RCU無鎖引擎提升內存引擎性能，通過SQL場景下的多線程處理實現線性擴展，同時支持Serializable事務隔離，增強並發處理能力。在水平擴展方面，Tair支持數據分散到不同分區，提供穩定的低延遲服務。此外，針對連接數限制，Tair通過優化多線程IO能力、解耦IO線程和worker線程、實現輕量化連接等技術手段提高系統處理能力。

在異常場景處理方面，Tair通過熱點策略、流控機制、執行流程優化等手段，確保系統在面對突發異常流量或特定請求時的穩定運行。熱點處理採用智能路由和數據分散策略，減少單點壓力。流控機制幫助系統識別並限制異常流量，保證正常服務不受影響。執行流程優化包括存儲過程使用和Pipeline執行模型，減少解析和編譯開銷，提升執行效率。

隨著Tair功能的擴展，從基礎的KV存儲到支持復雜數據結構和SQL查詢，Tair已經成為提供低延時、高並發、數據安全的內存資料庫解決方案。在購物車升級、銷量統計、判店場景等雙十一關鍵業務中，Tair展示了其強大的性能和靈活性。同時，Tair在技術創新和產品力上持續發展，包括發表頂會論文、獨立產品上線、提供豐富數據處理能力等，為客戶提供更廣泛的價值。

綜上所述，Tair通過核心的低延時服務，結合多維度的技術優化和場景適應能力，為雙十一等關鍵業務場景提供了穩定、高效的數據處理支持，體現了其在低延時場景中的重要價值。

C. mysql中間件有哪些

mysql-proxy是官方提供的mysql中間件產品可以實現負載平衡，讀寫分離，failover等，但其不支持大數據量的分庫分表且性能較差。下面介紹幾款能代替其的mysql開源中間件產品，Atlas，cobar，tddl，讓我們看看它們各自有些什麼優點和新特性吧。
Atlas
Atlas是由 Qihoo 360, Web平台部基礎架構團隊開發維護的一個基於MySQL協議的數據中間層項目。它是在mysql-proxy 0.8.2版本的基礎上，對其進行了優化，增加了一些新的功能特性。360內部使用Atlas運行的mysql業務，每天承載的讀寫請求數達幾十億條。
Altas架構：
Atlas是一個位於應用程序與MySQL之間，它實現了MySQL的客戶端與服務端協議，作為服務端與應用程序通訊，同時作為客戶端與MySQL通訊。它對應用程序屏蔽了DB的細節，同時為了降低MySQL負擔，它還維護了連接池。

以下是一個可以參考的整體架構，LVS前端做負載均衡，兩個Altas做HA,防止單點故障。

Altas的一些新特性：
1.主庫宕機不影響讀
主庫宕機，Atlas自動將宕機的主庫摘除，寫操作會失敗，讀操作不受影響。從庫宕機，Atlas自動將宕機的從庫摘除，對應用沒有影響。在mysql官方的proxy中主庫宕機，從庫亦不可用。
2.通過管理介面，簡化管理工作，DB的上下線對應用完全透明，同時可以手動上下線。

3.自己實現讀寫分離
（1）為了解決讀寫分離存在寫完馬上就想讀而這時可能存在主從同步延遲的情況，Altas中可以在SQL語句前增加 /*master*/ 就可以將讀請求強制發往主庫。
主庫可設置多項，用逗號分隔，從庫可設置多項和權重，達到負載均衡。

4.自己實現分表
（1）需帶有分表欄位。
（2）支持SELECT、INSERT、UPDATE、DELETE、REPLACE語句。
（3）支持多個子表查詢結果的合並和排序。

這里不得不吐槽Atlas的分表功能，不能實現分布式分表，所有的子表必須在同一台DB的同一個database里且所有的子表必須事先建好，Atlas沒有自動建表的功能。
5.之前官方主要功能邏輯由使用lua腳本編寫，效率低，Atlas用C改寫，QPS提高，latency降低。
6.安全方面的提升
（1）通過配置文件中的pwds參數進行連接Atlas的用戶的許可權控制。
（2）通過client-ips參數對有許可權連接Atlas的ip進行過濾。
（3）日誌中記錄所有通過Altas處理的SQL語句，包括客戶端IP、實際執行該語句的DB、執行成功與否、執行所耗費的時間 ，如下面例子。
圖4

7.平滑重啟
通過配置文件中設置lvs-ips參數實現平滑重啟功能，否則重啟Altas的瞬間那些SQL請求都會失敗。該參數前面掛接的lvs的物理網卡的ip，注意不是虛ip。平滑重啟的條件是至少有兩台配置相同的Atlas且掛在lvs之後。
source：https://github.com/Qihoo360/Atlas
alibaba.cobar
Cobar是阿里巴巴（B2B）部門開發的一種關系型數據的分布式處理系統，它可以在分布式的環境下看上去像傳統資料庫一樣為您提供海量數據服務。那麼具體說說我們為什麼要用它，或說cobar--能幹什麼？以下是我們業務運行中會存在的一些問題：
1.隨著業務的進行資料庫的數據量和訪問量的劇增，需要對數據進行水平拆分來降低單庫的壓力，而且需要高效且相對透明的來屏蔽掉水平拆分的細節。
2.為提高訪問的可用性，數據源需要備份。
3.數據源可用性的檢測和failover。
4.前台的高並發造成後台資料庫連接數過多，降低了性能，怎麼解決。
針對以上問題就有了cobar施展自己的空間了，cobar中間件以proxy的形式位於前台應用和實際資料庫之間，對前台的開放的介面是mysql通信協議。將前台SQL語句變更並按照數據分布規則轉發到合適的後台數據分庫，再合並返回結果，模擬單庫下的資料庫行為。

Cobar應用舉例
應用架構：

應用介紹：
1.通過Cobar提供一個名為test的資料庫，其中包含t1,t2兩張表。後台有3個MySQL實例(ip:port)為其提供服務，分別為：A,B,C。
2.期望t1表的數據放置在實例A中，t2表的數據水平拆成四份並在實例B和C中各自放兩份。t2表的數據要具備HA功能，即B或者C實例其中一個出現故障，不影響使用且可提供完整的數據服務。
cabar優點總結：
1.數據和訪問從集中式改變為分布：
（1）Cobar支持將一張表水平拆分成多份分別放入不同的庫來實現表的水平拆分
（2）Cobar也支持將不同的表放入不同的庫
（3） 多數情況下，用戶會將以上兩種方式混合使用
注意！：Cobar不支持將一張表，例如test表拆分成test_1,test_2, test_3.....放在同一個庫中，必須將拆分後的表分別放入不同的庫來實現分布式。
2.解決連接數過大的問題。
3.對業務代碼侵入性少。
4.提供數據節點的failover,HA：
(1)Cobar的主備切換有兩種觸發方式，一種是用戶手動觸發，一種是Cobar的心跳語句檢測到異常後自動觸發。那麼，當心跳檢測到主機異常，切換到備機，如果主機恢復了，需要用戶手動切回主機工作，Cobar不會在主機恢復時自動切換回主機，除非備機的心跳也返回異常。
(2)Cobar只檢查MySQL主備異常，不關心主備之間的數據同步，因此用戶需要在使用Cobar之前在MySQL主備上配置雙向同步。
cobar缺點：
開源版本中資料庫只支持mysql，並且不支持讀寫分離。
source：http://code.alibabatech.com/wiki/display/cobar/Home
TDDL
淘寶根據自己的業務特點開發了TDDL（Taobao Distributed Data Layer 外號:頭都大了 ©_Ob）框架，主要解決了分庫分表對應用的透明化以及異構資料庫之間的數據復制，它是一個基於集中式配置的 jdbc datasource實現，具有主備，讀寫分離，動態資料庫配置等功能。
TDDL所處的位置（tddl通用數據訪問層，部署在客戶端的jar包，用於將用戶的SQL路由到指定的資料庫中）：

淘寶很早就對數據進行過分庫的處理， 上層系統連接多個資料庫，中間有一個叫做DBRoute的路由來對數據進行統一訪問。DBRoute對數據進行多庫的操作、數據的整合，讓上層系統像操作一個資料庫一樣操作多個庫。但是隨著數據量的增長，對於庫表的分法有了更高的要求，例如，你的商品數據到了百億級別的時候，任何一個庫都無法存放了，於是分成2個、4個、8個、16個、32個……直到1024個、2048個。好，分成這么多，數據能夠存放了，那怎麼查詢它？這時候，數據查詢的中間件就要能夠承擔這個重任了，它對上層來說，必須像查詢一個資料庫一樣來查詢數據，還要像查詢一個資料庫一樣快（每條查詢在幾毫秒內完成），TDDL就承擔了這樣一個工作。在外面有些系統也用DAL（數據訪問層） 這個概念來命名這個中間件。
下圖展示了一個簡單的分庫分表數據查詢策略：

主要優點：
1.資料庫主備和動態切換
2.帶權重的讀寫分離
3.單線程讀重試
4.集中式數據源信息管理和動態變更
5.剝離的穩定jboss數據源
6.支持mysql和oracle資料庫
7.基於jdbc規范，很容易擴展支持實現jdbc規范的數據源
8.無server,client-jar形式存在，應用直連資料庫
9.讀寫次數,並發度流程式控制制，動態變更
10.可分析的日誌列印,日誌流控，動態變更