支付寶數據庫架構師馮大輝：談數據庫架構

概要
在上個月阿里巴巴舉辦的網俠大會上，InfoQ中文站有幸與著名的DBA馮大輝在一起，談了談網站/數據庫架構、數據庫性能調優、數據關係映射以及DBA個人職業發展等方面的話題。

個人簡介
馮大輝，就職於阿里巴巴集團旗下支付寶（中國）網絡科技有限公司（Alipay.com），擔任數據庫架構師，負責支付寶數據庫架構規劃、解決方案等相關工作。2007 年國內首批 Oracle ACE. 網上 ID 爲“Fenng”，業餘時間關注 Web 2.0 網站架構技術。
個人Blog：http://www.dbanotes.net

InfoQ中文站的讀者們，大家好，今天我們有幸請到馮大輝先生參加我們的這個採訪，大輝你好，請跟大家介紹一下你是誰，在做些什麼？

大家好，我叫馮大輝，是支付寶網絡中國科技有限公司的DBA。現在主要是負責支付寶相關的數據庫架構的工作，在工作之餘，我也比較關注Web2.0的一些發展情況，會在BLOG上寫一些架構相關的文章，和大家分享，BLOG的地址是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只是我們整個軟件開發行業中的一個環節，那麼在這個環節前面和後面，其實都有很多可以做的事情，其實每個人都不是不可替代的，那我們是否可以嘗試一下是否能夠去替代別人呢？謝謝大家。