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