上篇裏我講到某些網站在高併發下會報出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，今天內容就講到這裏了，有這兩篇文章我們可以理出一個解決大型網站數據瓶頸的一個脈絡了，具體如下：
單庫數據庫-->數據庫讀寫分離-->緩存技術-->搜索技術-->數據的垂直拆分-->數據的水平拆分
以上的每個技術細節在具體實現中可能存在很大的不同，但是問題的緣由大致是一致的，我們理清這個脈絡就是想告訴大家我們如果碰到這樣的問題應該按何種思路進行思考和設計解決方案，好了，今天就寫到這裏了，晚安。