1. 程式人生 > 其它 >分庫分表中介軟體原理

分庫分表中介軟體原理

背景

分庫分表這個詞相信很多人都不陌生,在網際網路公司資料到達一定規模的時候,多數都會對資料進行分庫分表,或者也有人叫分片,英文翻譯為Sharding;更加準確來說我們常常關心的是水平分片,即單個業務的某些表到達一定規模後,即使建立索引也無法從根本上帶來很大的效能提升,這時我們會考慮把單表拆分,以MySQL為例,B+樹索引的深度會隨著記錄的增多而逐漸加深,根據索引查詢的開銷也會越來越大,而單表拆分成多個表之後,B+樹深度降低,每個單表獨立查詢的速度也會加快,如果同時還分庫的話,並且在不同的例項上,大量的查詢壓力也會分擔到不同的機器上,這對單個數據庫機器減壓也帶來好處。

分庫分表的技術方案總體上來講分為兩大類:應用層依賴類中介軟體、中間層代理類中介軟體。

應用層依賴類中介軟體

這類分庫分表中介軟體的特點就是和應用強耦合,需要應用顯示依賴相應的jar包(以Java為例),比如知名的TDDL、噹噹開源的sharding-jdbc、蘑菇街的TSharding、攜程開源的Ctrip-DAL、支付寶開源但比較低調的zdal等。

此類中介軟體的基本思路就是重新實現JDBC的API,通過重新實現DataSource、PrepareStatement等操作資料庫的介面,讓應用層在基本(注意:這裡用了基本)不改變業務程式碼的情況下透明地實現分庫分表的能力。中介軟體給上層應用提供熟悉的JDBC API,內部通過sql解析、sql重寫、sql路由等一系列的準備工作獲取真正可執行的sql,然後底層再按照傳統的方法(比如資料庫連線池)獲取物理連線來執行sql,最後把資料結果合併處理成ResultSet返回給應用層。

此類中介軟體的優點很明顯,就是無需額外部署,只要和應用繫結一起釋出即可,但是缺點也很明顯,就是不能跨語言,比如Java寫的sharding-jdbc顯然不能用在C#專案中,所以攜程的dal也要重新寫一套C#的客戶端。

中間層代理類中介軟體

這類分庫分表中介軟體的核心原理是在應用和資料庫的連線之間搭起一個代理層,上層應用以標準的MySQL協議來連線代理層,然後代理層負責轉發請求到底層的MySQL物理例項,這種方式對應用只有一個要求,就是隻要用MySQL協議來通訊即可,所以用MySQL Workbench這種純的客戶端都可以直接連線你的分散式資料庫,自然也天然支援所有的程式語言。比較有代表性的產品有開創性質的

Amoeba、阿里開源的Cobar、社群發展比較好的Mycat等。

在技術實現上除了和應用層依賴類中介軟體基本相似外,代理類的分庫分表產品必須實現標準的MySQL協議,某種意義上講資料庫代理層轉發的就是MySQL協議請求,就像Nginx轉發的是Http協議請求。

上述無論哪種型別的產品,除了實現分庫分表這一主要功能外,都會額外實現一些其他很有實用價值的功能,比如讀寫分離、負載均衡等。