關于大型網(wǎng)站技術演進的思考2--存儲的瓶頸2

Patagonia

　　
上篇里我講到某些網(wǎng)站在高并發(fā)下會報出503錯誤，503錯誤的含義是指網(wǎng)站服務端暫時無法提供服務的含義，503還表達了網(wǎng)站服務端現(xiàn)在有問題但是以后可能會提供正常的服務，對http協(xié)議熟悉的人都知道，5開頭的響應碼表達了服務端出現(xiàn)了問題，在我們開發(fā)測試時候最為常見的是500錯誤，500代表的含義是服務端程序出現(xiàn)了錯誤導致網(wǎng)站無法正常提供服務，500通常是服務端異常和錯誤所致，如果生產(chǎn)系統(tǒng)里發(fā)現(xiàn)了500錯誤，那么只能說明網(wǎng)站存在邏輯性的錯誤，這往往是系統(tǒng)上線前的測試做的不到位所致�；氐�503錯誤，我上文解釋為拒絕訪問，其實更加準確的回答應該是服務不可用，那么為什么我會說503錯誤在高并發(fā)的情況下90%的原因是數(shù)據(jù)庫所致呢？上文我做出了詳細的解釋，但是今天我回味了一下，發(fā)現(xiàn)那個解釋還不是太突出重點，問題的重點是在高并發(fā)的情況整個網(wǎng)站系統(tǒng)首先暴露出問題的是數(shù)據(jù)庫，如果我們把整個網(wǎng)站系統(tǒng)比作一個盛水的木桶，那么木桶最短的那個板就是數(shù)據(jù)庫了，一般而言網(wǎng)站的服務應用出問題都會是解決存儲問題之后才會出現(xiàn)。
       數(shù)據(jù)庫出現(xiàn)了瓶頸并不是程序存在邏輯性錯誤，數(shù)據(jù)庫瓶頸的表現(xiàn)就是數(shù)據(jù)庫因為承受了太多的訪問后，數(shù)據(jù)庫無法迅速的做出響應，嚴重時候數(shù)據(jù)庫會拒絕進一步操作死鎖在哪里不能做出任何反應。數(shù)據(jù)庫猶如一把巨型的大鎖，很多人爭搶這個鎖時候會導致這個大鎖完全被鎖死，最終請求的處理就停留在這個大鎖上最終導致網(wǎng)站提示出503錯誤，503錯誤最終會傳遞到所有的客戶端上，最終的現(xiàn)象就是全站不可用了。
       上文里我講到session共享的一個方案是將session數(shù)據(jù)存儲在外部一個獨立的緩存服務器里，我開始說用一臺服務器做緩存服務器，后面提到如果覺得一臺服務器做緩存不安全，那么采用分布式緩存服務器例如memcached，那么這里就有一個問題了，為了保證web服務的可用性，我們會把web服務分開部署到不同的服務器上，這些服務器都是對等關系，其中一臺服務器不能正常提供服務不會影響到整個網(wǎng)站的穩(wěn)定性，那么我們采取memcached集群是不是可以達到同樣的效果了？即緩存服務器集群中一臺服務器掛掉，不會影響到用戶對網(wǎng)站的使用了？問題的答案是令人失望了，假如我們使用兩臺服務器做緩存服務器來存儲session信息，那么如果其中一臺服務器掛掉了，那么網(wǎng)站將會有一半的用戶將不能正常使用網(wǎng)站，原因是他們的session信息丟失了，網(wǎng)站無法正常的跟蹤用戶的會話狀態(tài)。我之所以提到這個問題是想告訴大家以memcached為代表的分布式緩存和我們傳統(tǒng)理解的分布式系統(tǒng)是有區(qū)別的，傳統(tǒng)的分布式系統(tǒng)都會包含一個容災維護系統(tǒng)穩(wěn)定性的功能，但實際的分布式技術是多種多樣的，例如memcached的分布式技術并不是為了解決容災維護系統(tǒng)穩(wěn)定性的模式設計，換個說法就是memcached集群的設計是沒有過分考慮冗余的問題，而只有適當?shù)娜哂嗖拍鼙ＷC系統(tǒng)的健壯性問題。分布式技術的實現(xiàn)是千差萬別的，每個優(yōu)秀的分布式系統(tǒng)都有自身獨有的特點。
       全面的講述memcached技術并非本文的主題，而且這個主題也不是一兩句話能說清楚的，這里我簡單的介紹下memcached實現(xiàn)的原理，當網(wǎng)站使用緩存集群時候，緩存數(shù)據(jù)是通過一定的算法將緩存數(shù)據(jù)盡量均勻分不到不同服務器上，如果用戶A的緩存在服務器A上，那么服務器B上是沒有該用戶的緩存數(shù)據(jù)，早期的memcache數(shù)據(jù)分布式的算法是根據(jù)緩存數(shù)據(jù)的key即鍵值計算出一個hash值，這個hash值再除以緩存服務器的個數(shù)，得到的余數(shù)會對應某一臺服務器，例如1對應服務器A，2對應服務器B，那么余數(shù)是1的key值緩存就會存儲在服務器A上，這樣的算法會導致某一臺服務器掛掉，那么網(wǎng)站損失的緩存數(shù)據(jù)的占比就會比較高，為了解決這個問題，memcached引入了一致性hash算法。關于一致性hash網(wǎng)上有很多資料，這里我就貼出一個鏈接，本文就不做過多論述了。鏈接地址如下：
http://blog.csdn.net/kongqz/article/details/6695417
      一致性hash可以服務器宕機時候這臺服務器對整個緩存數(shù)據(jù)的影響最小。
      上文里我講到了讀寫分離的設計方案，而讀寫分離方案主要是應用于網(wǎng)站讀寫比例嚴重失衡的網(wǎng)站，而互聯(lián)網(wǎng)上絕大部分網(wǎng)站都是讀操作的比例遠遠大于寫操作，這是網(wǎng)站的主流，如果一個網(wǎng)站讀寫比例比較均衡，那么這個網(wǎng)站一般都是提供專業(yè)服務的網(wǎng)站，這種網(wǎng)站對于個人而言是一個提供生活便利的工具，它們和企業(yè)軟件類似。大部分關注大型網(wǎng)站架構技術關心的重點應該是那種對于讀寫比例失衡的網(wǎng)站，因為它們做起來更加有挑戰(zhàn)性。
      將數(shù)據(jù)庫進行讀寫分離是網(wǎng)站解決存儲瓶頸的第一步，為什么說是第一步呢？因為讀寫分離從業(yè)務角度而言它是一種粗粒度的數(shù)據(jù)拆分，因此它所包含的業(yè)務復雜度比較低，容易操作和被掌控，從技術而言，實現(xiàn)手段也相對簡單，因此讀寫分離是一種低成本解決存儲瓶頸的一種手段，這種方案是一種改良方案而不是革命性的的方案，不管是從難度，還是影響范圍或者是經(jīng)濟成本角度考慮都是很容易讓相關方接受的。
      那么我們僅僅將數(shù)據(jù)庫做讀寫分離為何能產(chǎn)生好的效率了？回答這個問題我們首先要了解下硬盤的機制，硬盤的物理機制就有一個大圓盤飛速旋轉，然后有個磁頭不斷掃描這個大圓盤，這樣的物理機制就會導致硬盤數(shù)據(jù)的順序操作比隨機操作效率更高，這點對于硬盤的讀和寫還算公平，但是寫操作在高并發(fā)情況下會有點復雜，寫操作有個特性就是我們要保證寫操作的準確性，但是高并發(fā)下可能會出現(xiàn)多個用戶同時修改某一條數(shù)據(jù)，為了保證數(shù)據(jù)能被準確的修改，那么我們通常要把并行的操作轉變?yōu)榇�行操�?/strong>，這個時候就會出現(xiàn)一個鎖機制，鎖機制的實現(xiàn)是很復雜的，它會消耗很多系統(tǒng)性能，如果寫操作摻雜了讀操作情況就更復雜，效率會更加低效，相對于寫操作讀操作就單純多了，如果我們的數(shù)據(jù)只有讀操作，那么讀的性能也就是硬盤順序讀能力和隨機讀能力的體現(xiàn)，即使摻雜了并發(fā)也不會對其有很大的影響，因此如果把讀操作和寫操作分離，效率自然會得到很大提升。
      既然讀寫分離可以提升存儲系統(tǒng)的效率，那么為什么我們又要引入緩存系統(tǒng)和搜索技術了？緩存將數(shù)據(jù)存在內存中，內存效率是硬盤的幾萬倍，這樣的好處不言而喻，而選擇搜索技術的背后的原理就不同了，數(shù)據(jù)庫存儲的數(shù)據(jù)稱之為結構化數(shù)據(jù)，結構化數(shù)據(jù)的限制很多，當結構化數(shù)據(jù)遇到了千變萬化的隨機訪問時候，其效率會變得異常低效，但是如果一個網(wǎng)站不能提供靈活、高效的隨機訪問能力，那么這個網(wǎng)站就會變得單板沒有活力，例如我們在淘寶里查找我們想要的商品，但是時常我們并不清楚自己到底想買啥，如果是在實體店里店員會引導我們的消費，但是網(wǎng)站又如何引導我們的消費，那么我們必須要賦予網(wǎng)站通過人們簡單意向隨機找到各種不同的商品，這個對于數(shù)據(jù)庫就是一個like操作的，但是數(shù)據(jù)里數(shù)據(jù)量達到了一定規(guī)模以后like的低效是無法讓人忍受的，這時候搜索技術在隨機訪問的能力正好可以彌補數(shù)據(jù)庫這塊的不足。
     業(yè)務再接著的增長下去，數(shù)據(jù)量也會隨之越來越大了，這樣發(fā)展下去總有一天主庫也會產(chǎn)生瓶頸了，那么接下來我們又該如何解決主庫的瓶頸了？方法很簡單就是我們要拆分主庫的數(shù)據(jù)了，那么我該以什么維度拆分數(shù)據(jù)了？一個數(shù)據(jù)庫里有很多張表，不同的表都針對不同的業(yè)務，網(wǎng)站的不同業(yè)務所帶來的數(shù)據(jù)量也不是不同的，這個時候系統(tǒng)的短板就是那些數(shù)據(jù)量最大的表，所以我們要把那些會讓數(shù)據(jù)庫產(chǎn)生瓶頸的表拆出來，例如電商系統(tǒng)里商品表和交易表往往數(shù)據(jù)量非常大，那么我們可以把這兩種表建立在單獨的兩個數(shù)據(jù)庫里，這樣就拆分了數(shù)據(jù)庫的壓力，這種做法叫做數(shù)據(jù)垂直拆分，不過垂直拆分會給原有的數(shù)據(jù)庫查詢，特別是有事務的相關操作產(chǎn)生影響，這些問題我們必須要進行改造，關于這個問題，我將在下篇里進行討論。
     當我們的系統(tǒng)做完了讀寫分離，數(shù)據(jù)垂直拆分后，我們的網(wǎng)站還在迅猛發(fā)展，最終一定又會達到新的數(shù)據(jù)庫瓶頸，當然這些瓶頸首先還是出現(xiàn)在那些數(shù)據(jù)量大的表里，這些表數(shù)據(jù)的處理已經(jīng)超出了單臺服務器的能力，這個時候我們就得對這個單庫單表的數(shù)據(jù)進行更進一步的拆分，也就是將一張表分布到兩臺不同的數(shù)據(jù)庫里，這個做法就是叫做數(shù)據(jù)的水平拆分了。
     Ok，今天內容就講到這里了，有這兩篇文章我們可以理出一個解決大型網(wǎng)站數(shù)據(jù)瓶頸的一個脈絡了，具體如下：
     單庫數(shù)據(jù)庫-->數(shù)據(jù)庫讀寫分離-->緩存技術-->搜索技術-->數(shù)據(jù)的垂直拆分-->數(shù)據(jù)的水平拆分
     以上的每個技術細節(jié)在具體實現(xiàn)中可能存在很大的不同，但是問題的緣由大致是一致的，我們理清這個脈絡就是想告訴大家我們如果碰到這樣的問題應該按何種思路進行思考和設計解決方案，好了，今天就寫到這里了，晚安。
轉自
http://www.cnblogs.com/sharpxiajun/p/4240419.html
                       
                               
                    
                               
                       
                       
                       
                                時間:2015-02-02 21:22來源:博客園 作者:夏天的森林責任編輯:zhangkai

本文來自ChinaUnix新聞頻道，如果查看原文請點：http://news.chinaunix.net/opensource/2015/0203/3234094.shtml