分布式(distributed)資料訪問層(data access layer),簡稱dal,是利用mysql proxy、memcached、集群等技術優點而構建的乙個架構系統。主要目的是為了解決在高併發、大資料流操作遇到的和資料訪問有關的諸多問題,例如怎麼進行切庫分表,怎樣能更好地防止服務單點故障等等。
是由手機之家一位資深的開發者和架構師許超前最先提出的。(和我名字很像似呀,^^^^)
(以下內容引用自網路)
2023年,手機之家的使用者已經接近1000萬、pv也到了500萬以上,正處於中小型**向大型**的過渡時期。那時候,我們明顯感覺到我們在技術上已經遇上了瓶頸,乙個是系統負載過高,經常要擔心我們的資料庫是不是又掛了,進而造成整個系統的癱瘓。第二個是5年積累下來的**也已經非常難以維護,因為分層模糊,結果到處充滿著資料庫訪問邏輯、到處充滿著快取讀寫邏輯,再加上表的設計不合理,造成無法簡單地進行水平伸縮。總之我們的系統已經到了不得不進行改造的地步了。這裡是指水平可伸縮。事實上,這點更應該是整個系統要考慮的目標了,而非dal,dal要考慮的是怎麼更好地支援。舉例說,我們可以乙個庫乙個服務,甚至可以是乙個表乙個服務,庫、表拆分後,dal應能路由查詢、合併結果,而不是讓應用程式去操心這些事。後來,老高(手機之家創始人高春輝)組了乙個研發團隊,旨在從根本上解決上述提到的問題。在此後一年的時間裡,我們走了很多彎路,經歷了很多痛苦,不過,也正是在這段時間裡產生了dal的雛形,經過若干次改進變成了後來的dal1.0。dal的產生完全是形勢使然。 dal1.0上線後資料庫的qps明顯下降從幾千降到幾百。事實證明,我們找到了一條行得通的路子。所以才有dal的後續版本的開發,才有今天的dal2.x版本的產生……
對於根據id來取進行的查詢,在快取命中的情況下,應該達到和memcached不相上下的讀取速度。在快取不命中的情況下,則應該充分利用分庫分表和平行計算的優勢,最大化地提高查詢的效率。對於修改型查詢,掛在上面的***,不應該影響效能。
需要設計一套簡單好用的api便於應用程式的開發。api必須是自完備的應用開發者不需要太費力就能記住的。應用開發人員不再關心分庫分表問題,不再關心快取問題,特別是快取清除問題。甚至不再關心後端的資料庫是mysql,還是oracle,或者是其它。
像連線池元件、快取元件、查詢分析元件、訊息佇列元件、通訊協議等等不應該寫死,應設計成可方便定製的。還應該提供足夠的鉤子用於擴充套件。只有這樣,dal 的架構才是靈活的、擁抱變化的。簡單說,我們定的是機制,提供的是策略,機制是軟體目標和宗旨的體現,一般是不能輕易改變的,而策略則應當是能比較簡單地進行切換的。
**根據自己的業務特點開發了tddl(taobao distributed data layer)框架,主要解決了分庫分表對應用的透明化以及異構資料庫之間的資料複製,它是乙個基於集中式配置的 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).可分析的日誌列印,日誌流控,動態變更
tddl必須要依賴diamond配置中心(diamond是**內部使用的乙個管理持久配置的系統,目前**內部絕大多數系統的配置,由diamond來進行統一管理,同時diamond也已開源)。
tddl原始碼:
cobar client是乙個輕量級分布式資料訪問層(dal)基於ibatis(已更名為mybatis)和spring框架實現。
主要特性:
(1).可以支援垂直和水平資料切分資料庫集群的訪問。
(2).支援雙機熱備的ha解決方案, 應用方可以根據情況選用資料庫特定的ha解決方案(比如oracle的rac),或者選用cobarclient提供的ha解決方案。
(3).小資料量的資料集計(aggregation), 暫時只支援簡單的資料合併。
(4).資料庫本地事務的支援, 目前採用best efforts 1pc模式的事務管理。
(5).資料訪問操作相關sql的記錄, 分析等.(可以採用國際站現有ark解決方案,但cobarclient提供擴充套件的切入介面)。
分布式 資料訪問層
所有的業務資料都放在乙個資料庫中來管理 資料庫減壓是思路有三個 資料庫拆分可以水平拆分或者垂直拆分 垂直拆分是把乙個資料庫中不同業務單元的資料分到不同的資料庫裡 帶來的影響 水平拆分是根據一定的規則把同一業務單元的資料拆分到多個資料庫中 帶來的影響 1.了解分布式事務 分布式事務是指事務的參與者,支...
分布式資料訪問層DDAL
首先,資料庫切分有兩種 水平切分 垂直切分。水平切分就是橫向擴庫或擴表,利用db路由或者table路由查詢查詢。google有個hibernateshards,這裡沒什麼可說。阿里還有自己的ddal框架amoeba。垂直切分就是把不同的業務放到不同庫中,業務切分 系統解耦 分布式事務。複雜的業務涉及...
Tddl分布式資料訪問層
tddl taobao distribute data layer 是整個 資料庫體系裡面具有非常重要的乙個中介軟體產品,在公司內部具有廣泛的使用。tddl整個產品包括對應用透明的分庫分表層 和 具有眾多特性的動態資料來源,本次先開源動態資料來源,下期開源分庫分表層。動態資料來源的主要特性有 1.資...