數(shù)據(jù)訪問層開發(fā)實(shí)踐

1、數(shù)據(jù)訪問層開發(fā)實(shí)踐許超前手機(jī)之家2010年04月03日mEiwpw!1黑SLim/-.I11，丄it*II11mEiwpw!1黑SLim/-.I11，丄it*II11目錄前言關(guān)于數(shù)據(jù)訪問層(DataAccessLayer)關(guān)于DalDal的產(chǎn)生Dal的發(fā)展Dal21.xDal22.xDal的未來5）關(guān)于我們6)Q&AmEiwpw!1黑SLim/-.I11，丄it*II11關(guān)于數(shù)據(jù)訪問層引用維基百科:ADataAccessLayer(DAL)isalayerofacomputerprogramwhichprovidessimplifiedaccesstodatastoredinpersisten

2、tstorageofsomekind,suchasanentity-relationaldatabase.Thisdataaccesslayerisusedinturnbyotherprogrammodulestoaccessandmanipulatethedatawithinthedatastorewithouthavingtodealwiththecomplexitiesinherentinthisaccess.關(guān)于數(shù)據(jù)訪問層（續(xù)）應(yīng)用程序DataAccessLayer文件APIDBDAL在系統(tǒng)中的位置1IMobi/e手機(jī)之贏關(guān)于Dal-軟件定位mEiwpw!1黑SLim/-.I11，丄i

3、t*II11關(guān)于Dal-軟件定位mEiwpw!1黑SLim/-.I11，丄it*II11關(guān)于Dal-概覽mEiwpw!1黑SLim/-.I11，丄it*II11Dal是手機(jī)之家開發(fā)的數(shù)據(jù)訪問層軟件的產(chǎn)品名。Dall0、Dal21.x、Dal22.x及Dal2x則是該軟件的不同版本系列的一個引用。Dal是手機(jī)之家研發(fā)團(tuán)隊近幾年在開發(fā)和運(yùn)營上的經(jīng)驗的總結(jié)以及智慧的結(jié)晶。開發(fā)Dal的目的是為了解決在構(gòu)建大中型網(wǎng)站時遇到的和數(shù)據(jù)訪問有關(guān)的諸多問題，如怎樣使得分表透明化，怎樣使得緩存存取清除自動化，怎樣才能更好地防止服務(wù)單點(diǎn)故障等等。Dall0是一個具有里程碑意義的版本，但在很多方面仍然欠考慮。Dal2

4、1.x是一個經(jīng)過精心設(shè)計、認(rèn)真編寫，具有較高可用性的分布式數(shù)據(jù)訪問層，是綜合數(shù)據(jù)代理(如MySQLProxy)、名值對緩存(如Memcached)、集群等等思想而構(gòu)建的一個軟件系統(tǒng)。Dal22.x是目前的最新系列，引入了很多新特性：如分布式事務(wù)，支持?jǐn)?shù)據(jù)庫主從等等。1）不但具備了memcached和mysqlproxy的優(yōu)點(diǎn)，還避免了兩者的缺點(diǎn)。2）Dal作為一個中間件，應(yīng)保持語言中立、數(shù)據(jù)庫中立。3）讓系統(tǒng)在數(shù)據(jù)訪問層上具備分布式計算能力。4）不造ORM輪子，只是發(fā)明訪問數(shù)據(jù)的接口。關(guān)于Dal-核心概念mEiwpw!1黑SLim/-.I11，丄it*II11關(guān)于Dal-核心概念mEiwpw!

5、1黑SLim/-.I11，丄it*II111）透明分片透明，緩存透明，主從透明。2）虛庫（邏輯庫）和實(shí)庫（物理庫）虛庫：不是一個真正存在的庫。也叫邏輯庫。實(shí)庫：是真實(shí)存在的庫。也叫物理庫。3）虛表（邏輯表）和實(shí)表（物理表）虛表：不是一個真正存在的表。也叫邏輯表。實(shí)表：是真實(shí)存在的表。也叫物理表。4）分片（分表）分片可以分布在同一個庫中，也可以在多個庫中。也叫分表。5）映射虛庫T實(shí)庫;虛表T實(shí)表；應(yīng)用列名T數(shù)據(jù)庫列名;6）條目緩存和查詢緩存7）輔助索引8）分片情況：不分片、分片無輔助索引、分片有輔助索引9）面向庫的開發(fā)方式這是指，Dal自動從數(shù)據(jù)庫獲得需要的信息，而不是由應(yīng)用開發(fā)人員在配置文件里

6、顯示配置。開發(fā)人員要配的只是分表的規(guī)則、連接池的使用、緩存的使用等。只在應(yīng)用層需要和數(shù)據(jù)庫不一樣的信息時（如字段名），才在配置文件里顯式寫出。列名IDPIDIMobile手機(jī)之家mEiwpw!1黑SLim/-.I11，丄it*II11mEiwpw!1黑SLim/-.I11，丄it*II11關(guān)于Dal-設(shè)計指導(dǎo)思想Dal總體上設(shè)計成(Core+Plugins)的形式。Core負(fù)責(zé)一些不可插件化(或難以插件化)的組件，Plugins則是那些可插化的組件。我們定的是機(jī)制，提供的是策略；機(jī)制是軟件目標(biāo)和宗旨的體現(xiàn)，一般是不能輕易改變的，而策略則應(yīng)當(dāng)是能比較簡單地進(jìn)行切換的。那么，Core即機(jī)制，Plu

7、gins即策略。mEiwpw!1黑SLim/-.I11，丄it*Ii11Dal的產(chǎn)生Dal的產(chǎn)生-多數(shù)現(xiàn)有系統(tǒng)的經(jīng)典問題1）由于webserver可以直接訪問dbserver，在高峰階段，并發(fā)量比較大，導(dǎo)致dbserver經(jīng)常down掉。2）添加緩存代碼以降低數(shù)據(jù)庫訪問壓力，但由于開發(fā)人員自己控制緩存使得：a）緩存訪問邏輯混雜在系統(tǒng)的各個角落，造成代碼維護(hù)成本上升。b）開發(fā)人員根據(jù)自己的喜好來控制緩存的KEY和VALUE，造成緩存混亂。c）開發(fā)人員既要負(fù)責(zé)業(yè)務(wù)邏輯的編寫，還要負(fù)責(zé)緩存管理，造成編程復(fù)雜度提高、開發(fā)效率低下。Dal的產(chǎn)生-多數(shù)現(xiàn)有系統(tǒng)的經(jīng)典問題（續(xù)）3）在分表的情況下，程序員需要

8、考慮和編寫大量繁雜的和分表有關(guān)的代碼:a）需要根據(jù)規(guī)則計算出數(shù)據(jù)的存取目標(biāo)是在哪個分表當(dāng)中。b）如果取回的數(shù)據(jù)分布在不同的分表中，需要合并結(jié)果。c）由于大表切分后變成了多個小的分表，對于有排序要求的查找,需要通過建立并查找輔助索引來解決。d）如果一套分表有多個輔助索引，需要尋找最優(yōu)輔助索引。DaI的產(chǎn)生-Dall.O應(yīng)需而生DaI的產(chǎn)生-Dall.O應(yīng)需而生MySQLiMobWe手機(jī)之；EDal的產(chǎn)生-Dall.O的典型用法（續(xù)）Dal的產(chǎn)生-Dall.O的典型用法（續(xù)）Dal的產(chǎn)生-Dall.0的典型用法接口采用APIInvocation+CallChain的方式，所有的方法名取自SQL關(guān)鍵

9、字，方便記憶。1)增：DataAccessor:insert()-table(imobile.postdb_post)-data(array(post_id=1,.)-dup()-execute();刪：DataAccessor:delete()-table(imobile.post.db_post)-where(post_id,IN,array(1,2,3)-limit(3)-execute();TFl改：DataAccessor:update()-table(imobile.postdb_post)-data(array(level=0)-where(user_id,limit(10)-e

10、xecute();查：DataAccessor:select()-table(imobile.post.db_post)-columns(post_id)-where(array(threadd=1,forumd=2)-getAll();Dal的產(chǎn)生-Dall.0的成效Dal的產(chǎn)生-Dall.0的成效4啊勒4啊勒Dall.0使得數(shù)據(jù)庫的QPS從兒千降到兒百，緩存命中率穩(wěn)定在60%80%之間。Dall.0還標(biāo)準(zhǔn)化了調(diào)用接口，簡化了編程，使程序員在業(yè)務(wù)邏輯層面不再關(guān)心緩存與分表問題，極大地提高了生產(chǎn)力。訃Dal的產(chǎn)生-Dall.0的問題訃Dal的產(chǎn)生-Dall.0的問題BLW期妙加A.；但是，Da

11、ll.O仍然有很多不足:Dal1.0直接和數(shù)據(jù)庫打交道。如果操作的數(shù)據(jù)分布在不同的分表中，為了提高性能，需要并行處理。但是PHP不好做到。為了保證索引和分表數(shù)據(jù)的一致性，需要引入事務(wù)。但是Dall.0沒有。Dal1.0直接針對MySQL編碼，萬一將來需要采用其它的數(shù)據(jù)庫，怎么辦？MyCached和Memcached在不同的進(jìn)程，很多情況下需要兩次請求才能組合出完整的數(shù)據(jù)。如果需要支持其它的語言，怎么辦？要彌補(bǔ)這些不足，必須從根本上進(jìn)行重新設(shè)計。如果說Dal1.0是為易用性而設(shè)計，那么Dal2x就是為性能、可用性等等而設(shè)計。4IMobiJe手機(jī)之康mEiwpw!1黑SLim/-.I11，丄it*

12、Ii11手機(jī)之康Dal的發(fā)展Dal的發(fā)展-Dal21.x大圖怠WS,.Dal的發(fā)展-DalServer21.x大圖DALPDal的發(fā)展-Dal21.x在手機(jī)之家系統(tǒng)中的位置MySQL應(yīng)用I讀寫數(shù)據(jù)寫消息Dal2.1.x讀寫數(shù)據(jù)M3每分鐘調(diào)一次發(fā)送更新任務(wù)消息隊列服務(wù)搜索更新！客戶端丿搜索索引服務(wù)L回調(diào)應(yīng)用程序、內(nèi)置消息隊列Mobile手機(jī)之紊|Dal的發(fā)展-Dal2.1.x/Dall.O性能簡單對比|Dal的發(fā)展-Dal2.1.x/Dall.O性能簡單對比.*3喚琴.*3喚琴測試方法：每次涉及1個記錄，循環(huán)10000次，每次涉及的記錄都不相同。Dal21.xinsert:8.215306997

13、2992s,8.2881560325623s,8.2909779548645sdelete:8.928288936615s,8.4321990013123s,8.039489030838supdate:8.9594140052795s,7.6687839031219s,7.580326795578sselect:7.9645628929138s,3.0665209293365s,3.0304710865021sDal1.0insert:42.473783969879s,43.072340011597s,42.900885105133sdelete:25.484493017197s,25.382

14、812976837s,25.41899895668supdate:74.74593091011s,74.557103872299s,74.246424913406sselect:14.060505151749s,9.7374119758606s,6.5931770801544s.*3喚琴IDal的發(fā)展-Dal2.1.x/Dal1.0對比結(jié)果分析在增、刪、改、查四類查詢當(dāng)中，Dal21x都比Dall0有了很大的提升。原因在于：減少了一次socket請求、采用了異步消息處理機(jī)制、弓I入連接池及優(yōu)化了算法等等。Dal的發(fā)展-Dal21.x/Memcached簡單性能對比測試方法Dal21.xMemc

15、ached1.4.2每次獲取1個，循環(huán)10000次，每次獲取的記錄都不相冋10.839928150177s（全部不命中的情況）3.0760769844055s3.1021270751953s3.0667681694031s1.9119760990143s1.8506801128387s1.8564429283142s1.8201019763947s每次獲取10000個，執(zhí)行1次，所有的記錄都不相同。0.64966702461243s0.55020594596863s0.52798008918762s0.57868385314941s0.28920984268188s0.288759946823

16、12s0.28748893737793s0.27671718597412sDaI的發(fā)展-Dal2.1.x/Memcached對比結(jié)果分析從時間消耗的數(shù)量級來看，DaI21.x和Memcachedl42屬于同一個級別；從時間消耗的絕對值來看，DaI21x還是有一定的差距。那么這1/31/2的時間消耗都花在哪了？主要是在協(xié)議解析及查詢分析上。|Dal的發(fā)展-Dal2.1.x的問題|Dal的發(fā)展-Dal2.1.x的問題|Da啲發(fā)展-Dal2.1.x的成效.*3喚琴以下是手機(jī)之家某個時刻4組Dal服務(wù)的緩存命中率統(tǒng)計快照：1)entryCacheHits=1999443615(96.53%)entry

17、CacheMisses=71820652(3.47%)2)entryCacheHits=728834651(82.44%)entryCacheMisses=155230407(17.56%)3)entryCacheHits=717269426(93.35%)entryCacheMisses=51101159(6.65%)4)entryCacheHits=217927450(74.06%)entryCacheMisses=76326220(25.94%)其中，2)組服務(wù)命中率低的原因是：上面跑的是論壇，全動態(tài)的，更新頻繁;4)組服務(wù)命中率低的原因是：應(yīng)用層又做了緩存了，到Da啲冷請求變多了。1）

18、Dal21.x采用的是內(nèi)置緩存，而且存放的數(shù)據(jù)結(jié)構(gòu)也不好（大量的Map及字符串），在緩存數(shù)據(jù)量大的情況下，JVM不堪重負(fù)，將進(jìn)行頻繁的GC。在高峰情況下，甚至?xí)霈F(xiàn)全GC，這時客戶端connectiontimeout就頻繁出現(xiàn)了2）不支持分布式事務(wù)。這使得在分片分布在多個庫的情況下，數(shù)據(jù)的完整性得不到保證。而跨查詢事務(wù)問題更是得不到解決。3）不能簡單的支持?jǐn)?shù)據(jù)庫主從。4）緩存不能簡單地進(jìn)行外置。5）不好在高峰時段進(jìn)行配置Reload。6）不管分不分片，都得寫一大堆配置。7）內(nèi)置消息隊列占用太多內(nèi)存。8）不能把dal作為嵌入式包來使用。Dal的發(fā)展-Dal22.x大圖Dal的發(fā)展-Dal22.x大圖數(shù)據(jù)庫集群Cach#dDB#aCache#brDB#b1緩存集群DB#dDB#dIDa啲發(fā)展-Dal2.2.x重要變更IDa啲發(fā)展-Dal2.2.x重要變更1）自動生成條目（實(shí)體）類，用于緩存數(shù)據(jù)庫記錄。數(shù)據(jù)已經(jīng)有了類型，同時有望緩解JVMGC問題。2）支持分布