馮大輝，是前支付寶網絡中國科技有限公司的DBA?，F在丁香園( http://DXY.cn )網站出任CTO。

在工作之余，也比較關注Web2.0的一些發展情況，會在BLOG上寫一些架構相關的文章，和大家分享，BLOG的地址是 http://www.dbanotes.net/

作為一名資深的DBA，大輝卻在自己的BLOG上邊寫了不少關于網站架構這方面的一些文章，能不能談談DBA跟網站架構這方面的關系呢？

好多朋友和我開玩笑，說我做一個DBA，卻總去寫一些架構相關的東西，“是不是這個廚子不看菜譜，看兵法了？”其實二者之間我覺得是有些關系的。因為像數據庫的維護，甚至于設計、架構相關的工作，做到一定程度上覺得自己還是要向前再走幾步，也就是說一定要把我們架構相關的一些事情融合進來，但是作為一個 DBA沒必要一定要像我們的相關架構師這樣，去做一些編碼之類的實際工作。但是一些和DB結合的比較緊密的東西是一定要關注一下的，這也是我在BLOG上寫了不少與架構相關文章的一個主要原因。

一般來說要提升網站的性能，瓶頸主要都有那些，如果要解決這些瓶頸，又都存在哪些最佳實踐呢？

在以前，可能很大的一個瓶頸，我覺得還是在數據庫上，最后會落在實際的IO上面。但是現在隨著一些Web2.0技術的出現，當前我覺得一個網站真正能否應付大流量、高并發，主要的問題還在于Cache的相關使用上，這點十分重要。

一個要經受住大規模、高并發、訪問量考驗的成功Web2.0網站在設計的架構中要注意哪些東西呢？

這個我想在前期的規劃中肯定是需要做一些預防性的措施，比如說選擇適合的技術架構啊，這個絕對是在第一步應該必須要考慮的事情。另外還有一些像包括在產品設計上也會有很多需要注意的地方，現在我們的很多Web2.0網站，包括國內的這些新興的一些Web2.0網站，在產品設計上，我認為多多少少存在一些過度設計的現象。但這些設計不經意之間可能會對后臺帶來災難性的影響，那么這對開發人員、架構師，甚至維護人員都帶來很大的壓力。
另一方面呢，我想參考當前業界上一些已經相對比較成熟的技術，還是很關鍵的。我們做一個網站就好比造汽車一樣，不一定非要造得像奔馳這樣頂級豪華的，我們只需造一輛能跑起來，跑得很好的汽車，這可能就已經達到成功的一半了。

那剛才在網站性能和調優這方面，你剛才也提到了，緩存的作用是非常重要的，那么他到底處于怎么樣一個重要的地位呢？如何對緩存進行優化從而提升性能？

就我以前的相關經驗，在Oracle的一些實踐上，一方面是在高并發的設計上會有一些注意的事項。另外一個就是能否充分利用Oracle自己的內存，最后實質上看其是能否充分利用自己的Cache機制。在Web2.0網站，可能很少有使用Oracle這樣的場景。但在MySQL上，一方面MySQL自己的 Cache機制應該說還做得不錯，再一個就是，絕大多數網站都會考慮使用，像Memcached 這樣的外部組件進來，然后在這個地方，其實我們最后考量的是命中率，衡量命中率的高低，這是大家必須要注意的地方。
命中丟失實際上最后壓到我們的數據庫上，數據庫的命中再丟失有可能會壓到最下面的磁盤上。磁盤一定要能支撐住我們當前的最低需求，舉個最簡單的例子，我們的應為：memcached，可能前面的命中率是80%，那么有20%會壓到后面的DB上，這個DB的命中率有可能達到95%，剩下的5%，加上前面那個 20%，最后我們把所有的乘起來，這個比例會打到最后端的硬盤上，我們硬盤的整體響應能力又是有限的…我們可以去做RAID，甚至可以出現單塊硬盤這樣的情況。那么硬盤承載能力是有限的，我們把它反上去乘，一點點的乘，乘到前面去，就能計算出我們當前的系統能承載Cache的瓶頸。在設計的時候，一定要考慮到這樣的情況，否則當壓力確實突然增加到我們不能承受的時候，臨時做一些擴展的手段，可能就會比較麻煩。

你剛才說到Cache命中率，那對于一個比較成功的這種網站，它Cache命中率一般會在多少呢？

拿Oracle來說，我覺得它本身的命中率做到90%多，甚至是99.99這樣的情況，在MySQL的環境下可能做不到這樣， Memcached一般，據我所知，可能70%、80%已經不錯了，但是命中率只是一個表面的現象，我們還要看實際真正的外部應用到底是怎樣，有的可能不同的Web應用類型，他所能承載的訪問頻率也不大一樣，所以并沒有固定的比例，只能是憑一些經驗，但總體來說肯定是命中率越高，會越好一些。

在Web2.0的時代，海量數據對于越來越多的開發者來說，已經不再是一個遙不可及的話題了，可能隨便哪一個訪問量很大的Web2.0網站都有可能擁有令人咂舌的數據量，那么對于這種網站，除了對數據庫存儲進行優化，除了緩存，然后還有那些策略？

我覺得可能主要是在存儲方面會有一些大的挑戰，比如存儲的可靠性。像以前我們就曾經遇到過這樣的BSP服務商，對客戶的數據居然沒有備份，導致了很多用戶損失了一段時間之內的數據，這樣總體來說對網站的聲譽、對用戶的資源都是很糟糕的。
隨著我們現在互聯網的飛速發展，數據總體來說是趨于膨脹性的，在這個過程中，我們如何把數據有效的存儲，并且有效的獲取，便是個比較復雜的問題，像一方面我們前面說了太多Web2.0相關的話題。還有一個是像，比如說我所在的公司支付寶，當然我們也面臨著這樣的大數據量、海量數據的挑戰，當前我們的一個策略，也是沿襲公司這SOA戰略化思想，就是數據庫相關的，對后臺的相關數據進行一定的SOA化處理，然后另外一個比較重要的策略就是數據生命周期的管理，我們對這樣的，在數據生命已經達到這樣的周期之后，就相關的數據做一些歸檔化的處理，進行二級存儲或者分級存儲。那么話說回來，對一些Web2.0網站，我覺得也可以運用這樣的思想機制，對用戶已經不大可能訪問或者訪問頻率比較小的（數據），采用分級存儲，或者說額外做一些訪問策略的制訂，應該也是有必要的。

我們也聽說過另外一種分片數據庫機制，那么請你談談分片這種策略是怎么樣一種策略？

分片總的來說，它不是一種比較新的技術，我們現在像MySQL在 5 點幾之后，有了分區功能。其實在這之前，MySQL是沒有分區能力的。當時如果需要處理一些比較大的數據量。比方說要對數據隨著時間進行歷史化處理，那么就會比較麻煩，人們可能是因地制宜，就產生Sharding這樣技術策略。嚴格來說，數據分片呢，其實在我們以前也有一些相關的實踐，在其他的數據庫上，我們也會有一些歷史策略，只是當時這個名詞沒有完全定義下來。據我所知，這個詞是從大型專線游戲中發展出來的，大部分用戶會集中在某個區域。那么這一部分集中在某個區域的用戶，會把他們放在特定的服務器上。不同區域之間的用戶之間的關聯度可能不大，這個場景和我們現在的數據庫分片策略其實是非常非常相似的，我們當前如果對數據庫做一些分片，也會采用這樣的基本思想，比如說根據不同的用戶ID范圍，或者說不同的地區，如果建的是商務網站，可能根據產品的類型，我們會把不同的數據扔到不同的DB上，這些不同DB之間的關聯度是很小的。然后我們在不同DB之間，可能相對來說會有一個分裝層，在這個封裝層之外，對這個應用程序用戶來說，就像是透明的，那么就達到了我們數據庫上高度擴展化的目標。謝謝。

那分片這種策略有什么利弊嗎？

分片首先他的好處還是很容易看到的，起碼我們的DB能達到不依賴于某個單點，而這樣能做到平滑的擴展，就像大家常說的Scale Out橫向擴展機制。它的弊端也是比較明顯，對于事務高速處理這樣的網站，它有它的自己的缺點，事實上我們好多朋友也應該知道，一個事務如果跨數據庫，這樣對設計者，對編碼人員來說，還是比較棘手。那么如果一個事務如果跨兩個甚至多個DB，Sharding復雜度就會很高。Sharding在業界的應用場景基本上也就是這種讀應用比較重的情況，而且對事務的安全性要求不高，這樣的場景會非常適合。

目前在許多網站的架構設計中有絕大多數的項目在持久化方面就是采用數據關系映射（ORM）的方式。大家對于這種高負載的大規模網站應用來說，你覺得存在哪些應用呢？

首先一點呢，我想拿我們支付寶來說，ORM是大家覺得用得非常好的，但在一個相對比較大的開發環境，對開發團隊來說，它的弊端可能就不大容易看出來。因為我們用得是ORM，就很容易把中間DB這層完全隔離出來。然后把這一層的處理交給專門的DB職員——我們這邊還有專門的開發DBA，由他們來專門對這層進行集中的監控管理，甚至做一些規劃類的工作。這樣呢，開發工程師還有架構師這邊，實際上他們可以集中精力在其他方面做更多的投入，一個比較大的團隊我覺得像ORM這些還是很容易能看到好處的。
在另一方面，我們看一下它的弊端，因為像一些Web，回頭我們說一些，Web中小網站，他可能相對人手也比較少，大家 用得工具呢，可能像PHP、 ROR這些東西，也是在開發上，上手又比較容易的。那么這個時候，事實上一個潛在的問題是，當代碼規模到一定程度，如果沒有去做一些OR映射，那么可能會給網站帶來一些潛在的比如說代碼管理上的問題，這一點只是我的個人看法，實際上大家在具體的應用場景可能會有各自頭疼的問題，我在這方面不是專家，也僅供大家參考。

那你所做的支付寶，其實是企業級別的應用，在企業級別應用所采用的這種架構策略和，一般Web 2.0所采用的這種架構策略會有什么異同？

事實上一個從很明顯的一個特點說，支付寶其實業務是非常復雜的，這和我們很多的Web2.0公司不大一樣，Web2.0它可能從一個點切入進去。在這一點上，我覺得做得比較透。支付寶呢，它可能有點像我們以前做的一些通用軟件，他要考慮不同的行業、不同的用戶、還有像買賣之間，與這么多銀行之間的關系等等，這個復雜度還是很大的。
這實際上就從一定程度上決定了我們和Web2.0公司截然不同的應用解決方案，像當前我們在支付寶，在一年之前，甚至兩年之前就已經考慮，把我們的整個網站SOA化、組件化。在這個過程中，也考慮了一些像Web2.0中的技術元素，但總體的思路呢，還是說向SOA化，向面向服務這方面大步的跨進，然后就從 SOA這一點，事實上很多Web2.0公司，他們未必能完全的實現，完全的做到這樣的面向服務化，我覺得這可能是兩者截然不同的一個表面特點。
另外，像支付寶也在嘗試做一些，對外部客戶、服務提供一些接口，甚至完全開放的一個平臺，這一點又和我們當前這些像FaceBook，或者是說，像美國的MySpace這樣的社交區、SNS網絡了有一些共通之處。

那目前在Web2.0網站這個領域里面，網站的架構主要有哪些趨勢，下邊還將有怎么樣一個走向呢？

其實作為一個技術人員，每當要談到趨勢，肯定要給大家笑。從中長期來看，國內的一些Web2.0服務逐漸又涌現出來了，那么隨著這樣的業務發展，我相信會有更多的商業化元素加進來。像以前是好多Web2.0公司是完全使用開源的技術，那么隨著規模的興起，一些以前提供開源技術的組織或個人他們會嘗試進行一些商業化的運作，商業化并不是個壞事情，一方面給我們提供更好的服務。另一方面，他們得到了足夠的商業支持，反過來之后他們又會對整體的開源開發環境、發展環境起到很好的促進，我相信在未來的兩到三年之內，會有一部分的商業公司涌到Web2.0的發展生態圈里面。然后從技術方面來講，像前面幾個月 MySQL被Sun收購了。那么起碼是在Web.2.0這樣的軟件鏈條中的一個重要環節，有些人可能會感覺，出了一些問題。但現在像在數據庫這一層呢，也不排除像PostgresSQL這些其他的數據庫，他們趁這個機會被商業公司所擁抱，他們也會做出一些更大規模的應用場景出來。在數據庫這方面可能會限制大家，幾家開源數據庫形成一個僵局，Sun在……這個有些扯遠了，還是繞回來。像現在很多的Web2.0公司，他們對Web服務器這方面也會采用一些比較新的，像Nginx我覺得在，起碼在接下來的一段時間內會吸引絕大多數公司長期的去使用它、去擁抱它，甚至為它開發一些更激動人心的新特性。

那最后作為一個由DBA成長為DB Architect（應為：Architect），同樣都是A，但這個A已經有一個變化，那么你對后來者有哪些建議呢？

建議談不上，跟大家談談自己在這個過程中的一些轉變。首先從DBA，因為DBA做一些實際相關的維護工作，從這個過程轉到架構師這邊，是相對從這比較 “實”的崗位到，轉到現在看起來相對好像稍稍“虛”了一些，但是在這個虛的過程中，又相當于我們且退一步，然后就能看得更遠一些，能看到整個軟件架構的網站發展，甚至是公司戰略上的一些事情，這對個人成長是有好處的，我希望大家如果有這個意愿也可以稍微嘗試一下，因為DBA只是我們整個軟件開發行業中的一個環節，那么在這個環節前面和后面，其實都有很多可以做的事情，其實每個人都不是不可替代的，那我們是否可以嘗試一下是否能夠去替代別人呢？謝謝大家。

(原文： http://www.infoq.com/cn/interviews/fengdahui-database-architecture )

與馮大輝談數據庫架構(InfoQ)