【51CTO綜合報(bào)道】在WEB開(kāi)發(fā)中，數(shù)據(jù)庫(kù)的數(shù)據(jù)讀寫(xiě)和傳輸一向是瓶頸，在此基礎(chǔ)上的解決方案基本都是數(shù)據(jù)庫(kù)連接層的設(shè)計(jì)，一個(gè)公司數(shù)據(jù)庫(kù)連接層的強(qiáng)弱與否可以標(biāo)識(shí)這個(gè)公司的全局規(guī)劃的“工藝水平”到達(dá)一個(gè)什么程度了。下面的內(nèi)容來(lái)自明查暗訪(fǎng)，決無(wú)侵犯之意，旨在提供給需要統(tǒng)一規(guī)劃整體架構(gòu)的架構(gòu)師一個(gè)幫助。
1.人人網(wǎng)
參考：http://ugc.renren.com/2009/12/28/renren-ice-problem/
關(guān)鍵詞：ice中間層，統(tǒng)一配置數(shù)據(jù)源，開(kāi)發(fā)者不關(guān)心分庫(kù)分表
與很多大型的網(wǎng)站一樣，人人網(wǎng)的系統(tǒng)全部是由開(kāi)源軟件構(gòu)建的。使用Nginx做前端接入，resin做容器，Memcached做通用 cache，MySQL做數(shù)據(jù)庫(kù)，使用Linux操作系統(tǒng)。
除了上述的部分外，人人網(wǎng)還有一個(gè)與眾不同的中間層。中間層以服務(wù)的形式存在，位于MySQL和resin中間，提供高并發(fā)低成本的數(shù)據(jù)訪(fǎng)問(wèn)層。
51CTO曾對(duì)人人網(wǎng)的技術(shù)高級(jí)總監(jiān)黃晶進(jìn)行過(guò)專(zhuān)訪(fǎng)，詳情請(qǐng)看《專(zhuān)訪(fǎng)人人網(wǎng)黃晶：SNS網(wǎng)站后臺(tái)架構(gòu)探秘》和《51CTO專(zhuān)訪(fǎng)人人網(wǎng)黃晶：WEB開(kāi)發(fā)需要隨需應(yīng)變》。
在專(zhuān)訪(fǎng)中，黃晶先生曾提到“我們的數(shù)據(jù)庫(kù)用到了部分自身緩存機(jī)制，比如盡可能利用innodb的pool和MySQL的Query Cache。在中間用到Memcached，以及基于ICE通訊框架由我們自己編寫(xiě)的包含業(yè)務(wù)邏輯處理能力的緩存服務(wù)，在我們自行開(kāi)發(fā)的分布式KV系統(tǒng)中也會(huì)充分利用內(nèi)存Cache加速。”
2.百度
參考：http://wenku.baidu.com/view/9daa2b8102d276a200292e9c.html
關(guān)鍵詞：dbproxy，服務(wù)器都是flash卡，DBA與開(kāi)發(fā)者都不關(guān)心分褲分表（半自動(dòng)）
百度的dbproxy利器，將MySQL的管理半自動(dòng)化，HA等功能一應(yīng)俱全，再加上SSD等硬件支持，性能相當(dāng)不一般。dbproxy的作用是合理地分配數(shù)據(jù)庫(kù)請(qǐng)求給所有的DB Server, 使得在請(qǐng)求的數(shù)量等于或者小于所有DB Server的計(jì)算能力總和時(shí), 服務(wù)能夠正常運(yùn)行。
第一種方式的dbproxy: Web Server上的數(shù)據(jù)庫(kù)客戶(hù)端(如PHP腳本)擁有選擇DB Server的智能。
這種方式實(shí)現(xiàn)簡(jiǎn)單, 完全用Web腳本實(shí)現(xiàn), 腳本自己判斷應(yīng)該連接其中的一臺(tái)或者幾臺(tái)DB Server, 請(qǐng)決定把SQL請(qǐng)求發(fā)給誰(shuí). 這種方式因?yàn)樾阅軉?wèn)題, 所以應(yīng)用不是很廣。
第二種方式的dbproxy: SQL代理進(jìn)程
類(lèi)似HTTP代理服務(wù)器, 這種方式的dbproxy獨(dú)立運(yùn)行, 所以客戶(hù)端請(qǐng)求將不再直接和DB Server連接, 而是通過(guò)它中轉(zhuǎn)。這樣的dbproxy, 首先要擁有解析協(xié)議(也即SQL)的能力, 這也帶來(lái)一個(gè)特點(diǎn), dbproxy可以與后端的MySQL連接, 但卻接收前端(如PHP腳本)發(fā)來(lái)的Oracle數(shù)據(jù)庫(kù)的SQL請(qǐng)求。
當(dāng)然, dbproxy的主要功能還是在SQL分發(fā)方面. 另外, 還可以在dbproxy上面做與業(yè)務(wù)更接近的緩存, 相比數(shù)據(jù)庫(kù)的底層緩存很多時(shí)候更有效。
3.盛大-技術(shù)保障中心
參考：網(wǎng)友
關(guān)鍵詞：無(wú)中間件，每個(gè)系統(tǒng)一個(gè)數(shù)據(jù)庫(kù)，開(kāi)發(fā)者嚴(yán)重關(guān)心分庫(kù)分表
4.新浪
參考：網(wǎng)友
關(guān)鍵詞：無(wú)中間件 分表要開(kāi)發(fā)者自己做
5.金山
參考：網(wǎng)友
關(guān)鍵詞：無(wú)中間件 分表要開(kāi)發(fā)者自己做
6.騰訊
參考：騰訊大講堂45-解剖TTC
關(guān)鍵詞：Tencent Table Cache
TTC是提供高速數(shù)據(jù)訪(fǎng)問(wèn)服務(wù)的通用cache server。特點(diǎn)是采用epoll和異步狀態(tài)機(jī)模式提高并發(fā)能力。TTC看上去是一個(gè)數(shù)據(jù)庫(kù)緩沖層，由于資料有限，只能如此分析。
7.淘寶、支付寶
參考：http://wenku.baidu.com/view/f36d620c844769eae009edba.html
關(guān)鍵詞：JBoss作為中間件，有數(shù)據(jù)路由層，數(shù)據(jù)庫(kù)Oracle 與 MySQL
在網(wǎng)絡(luò)上許多文檔里都有提到阿里內(nèi)部是有一數(shù)據(jù)路由層的，另外JBoss的使用也使得他們輕便不少（可惜當(dāng)年哥在淘寶時(shí)只搞的是搜索，不使用DB）
目前淘寶和支付寶使用的Oracle數(shù)據(jù)庫(kù)為Oracle 11g。借助Oracle 11g新增的PL/SQL 相關(guān)的某些新特性如網(wǎng)絡(luò)日志分析工具，為客戶(hù)和內(nèi)部技術(shù)人員帶來(lái)了更加快速簡(jiǎn)便的全新體驗(yàn);利用Oracle Advanced Compression技術(shù)，不僅節(jié)省大量存儲(chǔ)空間，而且提升了查詢(xún)性能。
延伸閱讀
豆瓣網(wǎng)：BeansDB與NoSQL的應(yīng)用與發(fā)展
51CTO采訪(fǎng)過(guò)豆瓣網(wǎng)首席架構(gòu)師洪強(qiáng)寧先生，在專(zhuān)訪(fǎng)中我們專(zhuān)門(mén)探討了關(guān)于BeansDB在豆瓣的應(yīng)用問(wèn)題。
BeansDB主要由Server端和Client端兩個(gè)部分組成。Server端用C編寫(xiě)，使用Memcached的通訊協(xié)議，任何支持Memcached的Client端都可以與BeansDB的Server端同步來(lái)獲取和存儲(chǔ)數(shù)據(jù)。在Client端方面的主要差別是分布式的邏輯實(shí)現(xiàn)方面。目前，BeansDB的Client端主要是豆瓣自己用Python語(yǔ)言的實(shí)現(xiàn)。Client端的運(yùn)作方式是寫(xiě)數(shù)據(jù)時(shí)寫(xiě)入多份，讀的時(shí)候只讀一份，用其他任何語(yǔ)言實(shí)現(xiàn)也和簡(jiǎn)單。
BeansDB開(kāi)放在Google Code上，在采訪(fǎng)中，洪強(qiáng)寧先生談到，豆瓣開(kāi)放BeansDB，希望能看到其他語(yǔ)言的Client端實(shí)現(xiàn)，讓這個(gè)BeansDB的使用更加方便，能讓更多人用到這個(gè)產(chǎn)品。
目前，BeansDB在豆瓣主要部署了兩個(gè)集群：一個(gè)集群用于存儲(chǔ)數(shù)據(jù)庫(kù)中的大文本數(shù)據(jù)，比如日記、帖子一類(lèi)；另外一個(gè)豆瓣FS集群，主要用于存儲(chǔ)媒體文件，比如用戶(hù)上傳的圖片、豆瓣電臺(tái)上的音樂(lè)等。
