使用2-3法則設計分布式數據訪問層

作者: 衛向軍來源: infoQ 發布時間: 2015-02-11 21:39 閱讀: 5000 次推薦: 1 原文鏈接 [收藏]

　　引言

　　如今移動互聯網行業呈爆發式發展，隨著業務用戶規模和業務邏輯趨向復雜，后端系統的開發和維護變得越來越困難，目前業界涌現出各種各樣的技術文章介紹分布式緩存設計、分布式數據庫設計、負載均衡、HA策略等等，這些都是支撐分布式數據訪問層的基石，不過，本文將從另一個角度探討分布式數據訪問層 (Data Access Layer)的框架設計。

　　本文要介紹的是2-3法則（2個維度，3個原則）在分布式DAL框架設計中的指導作用，兩者共同完成DAL層封裝，主要分為兩點：1）從水平與垂直維度正交分析業務系統設計；2）定義3條必須遵守的設計原則，最重要的是DAL層從水平維度抽象數據訪問策略模型，即個3原則中的第3條。

　　本文最后一節，對分布式數據訪問框架做了探討，提出了兩種實現思路。

　　分布式DAL解決的問題

　　在分布式系統中，每一臺服務器都需要訪問本地緩存、分布式MC緩存、分布式后臺數據庫，對于同一個業務模塊，隨著業務變復雜，需要定義越來越多的數據Model，按照一定的規則存儲在本地緩存、分布式緩存以及后臺數據庫中。

　　目前，業界的數據訪問層定位于應用程序與持久化數據庫之間，比如淘寶的TDDL、IBatis Sharding等，主要完成數據的分庫分表、讀寫分離等，本文的數據存儲涵蓋緩存、數據庫、文件系統，現有的數據庫DAL中間件、Redis客戶端、MC客戶端將作為本文的水平維度的Adaptor，主要解決的問題：

數據訪問在水平數據存儲維度的一致性問題。
快速增加數據Model的能力。
優雅、清晰、模塊化的數據訪問層代碼。

　　兩個維度抽象設計

　　對于上節的問題，下面列舉了水平和垂直維度抽象思考的例子。

　　假設水平維度：

部分熱數據存儲在本地緩存，本文使用EhCache。
部分熱數據存儲在前端緩存，本文使用MC。
全量數據存儲在數據庫緩存，本文使用MySQL。

　　假設垂直維度：

數據模型FileMeta，需要同時存儲在LocalCache、Redis和MySQL中。
數據模型BlockMeta，需要存儲在LocalCache、MC中。
數據模型Context，需要存儲在MC、MySQL中。

　　按照上面的分析，我們畫出系統兩個維度正交設計圖，如下：

　　Composition 而不是Inheritance

　　我們可以想到垂直維度定義N = 3個數據模型接口，水平維度定義N = 3個分層接口，但是水平維度和垂直維度是什么關系呢？

　　在本文的設計中，對問題做了進一步思考，水平維度的接口全部由垂直維度的數據模型接口組合（Composition）而成，完成所有業務只需要定義N + M + 1個接口，而不是N * M + 1個接口，多余的那個是DAL接口，完成數據訪問層封裝工作，第一節例子中的接口定義見下圖：

　　設計原則

　　上節主要介紹了接口設計，這里說一下實現，數據模型類非常簡單，只要MC Client、TDDL、EhCache在不同層完成相應接口實現，最重要的是DAL實現類，需要完成水平各個維度的策略存儲，比如對一個Model，順序寫入MC和MySQL，根據業務實踐經驗，總結出3條設計原則：

每一個數據模型都有CRUD方法，即數據操作的增刪改查，對于MC或者LocalCache來說，增加操作和修改操作可能是一致的，這種情況也必須嚴格定義CRUD方法。
DAL層封裝所有的數據訪問，保證數據的一致性存儲和可靠性，DAL層的實現調用ILocalCacheService、IMCService、IDAOService，根據不同數據模型的存儲策略，分別去調用緩存和數據庫服務，數據模型如果僅存在MySQL或者MC，也需要在DAL層做封裝，這樣雖然對開發效率有一定影響，但是整體開發和維護成本降低很多。
DAL實現抽象出一個DALContext和一個Executor，對于不同的數據模型，配置出不同的DALContext，比如順序存儲在MC和MySQL或者同步寫入MC異步寫入MySQL，DAL也需要負責出錯處理、水平維度的容災切換等。

　　分布式數據訪問框架

　　對于互聯網后端應用來說，最主要的功能就是處理數據，對DAL層的探索與優化是非常有價值的，基于本文提出的2-3法則，感興趣的讀者可以構建一個DAL開源項目，有兩種思路。

　　第一種思路是：