【轉】關於大型網站技術演進的思考（八）--存儲的瓶頸終篇（8）

　　在開始本篇主要內容前，咱們一塊兒看看下面的幾張截圖，首先是第一張圖，以下圖所示：

　　這是一家電商網站的首頁，當咱們第一次打開這個首頁，網站會彈出一個強制性的對話框，讓用戶選擇貨物配送的地址，若是是淘寶和京東的話，那麼這個選擇配貨地址的選項是在商品裏，以下圖是淘寶的選擇配送地點：

那麼圖一跟京東和淘寶有什麼區別呢？圖一的電商強制用戶選擇地區後，那麼咱們在查詢這個商品時候會由於地區不一樣，顯示的查詢結果會不同，這個就和網站作國際化有點像，不過網站國際化是切語言和語言相關的靜態資源，可是電商這個地域的選擇是和業務相關的，不一樣的地域查詢結果是不相同的，這個選擇地域的彈出框很像一個路由器。相比之下，淘寶和京東把商品的配送和商品相關，那麼咱們在這些網站裏查詢商品時候，實際上是按照全國查詢的，全國不一樣的地方查詢同一個條件所得到到的結果是一致的。從業務角度而言，這說明第一個電商的業務沒有全國鋪開，就算是鋪開了，地域的差別也影響到物流的問題，而淘寶和京東則正是一個全國意義的大型電商網站了。

　　回到技術的角度，這兩種不一樣的作法有沒有可能還和技術問題有關了？今天我就來探討下這個問題。

　　無論網站大與小，一個網站確定能夠分爲客戶端、服務端和存儲端，勾連這不一樣的組成部分是網絡，網絡是一種通信設施，距離的遠近會直接影響到網絡傳輸的效率問題，如是乎就出現了像CDN這樣的技術，不少大型互聯網公司還會在不一樣的城市創建機房，這些手段的目的就是在解決距離對網絡傳輸效率的影響，可是當這種就近解決問題的方案落到存儲層的時候，問題就來了。上篇裏我說道web服務的水平擴展問題，這種水平擴展是基於一種無狀態性的原理設計的，可是到了存儲層咱們無論怎麼拆分它，它都很難消除狀態的問題，也就是存儲層有狀態性是它的自然屬性。特別是碰到一個競爭性的存儲資源時候，這種狀態性會變得很是頑固，例如商品的庫存問題，若是咱們把庫存數據對等的平移到不一樣地域的數據中心，那麼如何保證不一樣地方的庫存信息老是準確的，這就成爲了難題。這種問題放在一個小國家不是什麼問題，可是放到地大物博的中國那就很成問題了。因此存儲是這種就近方案的短板了。

　　我曾瞭解到中國一家大型信息企業在設計它們第一代系統時候，就考慮到了這種地域性差別對系統設計的影響，它們的第一代系統在存儲層這塊就設計成了一個雙核系統，什麼叫作存儲層的雙核系統了？它們的作法是在北京和上海分別創建兩個數據中心，系統的存儲層分別部署在北京的數據中心和上海的數據中心，兩個數據中心是等價的，那麼中國北部的交易就走北京數據中心，中國南部的交易就走上海的數據中心。可是系統上線後，發現這種雙核設計方案成爲了整個系統的夢魘了，這個夢魘的最核心的問題就是數據的同步問題，由於該企業是一個全國性業務的企業，所以有大量交易須要南北數據中心同步完數據後才能正常完成，可是想從北京和上海同步數據的效率是異常的低效，我曾經看過一份資料，裏面說有機構作了一個測試，當兩個數據中心的距離超過了80千米，那麼網絡的延遲性基本是沒法忍受的，固然不差錢的企業能夠專門鋪設專線來鏈接兩個數據中心，這種專線的成本高的嚇人，我曾聽人說就在上海，若是鋪專線從浦東到浦西，那麼這條專線基本是用人民幣鋪就的，更況且是從北京到上海鋪專線，就算企業不差這些錢延遲性也嚴重影響了企業業務的發展。除了延遲性外，經過網絡大規模傳輸數據，數據的可靠性是很難保證的，也就是網絡傳輸時候常常沒有道理的丟包，這就形成了不少重複性傳輸，使得同步數據的效率更加的低效。

　　由於存儲層這種雙核設計缺陷，該企業立刻從事了二代系統的設計和開發，而這個二代系統核心業務就是解決這個存儲層的雙核問題。那到底該怎麼解決了？把雙核變成單核，既然兩個數據中心這麼麻煩，那咱們就搞一個數據中心算了，既省錢有沒那麼多麻煩事情，這個確定不是解決問題的正確思路了，雙核設計的出發點是很是有現實意義和價值的，最後該公司使用了一個新的方案替代雙核，這個方案稱之爲主備方案，存儲層任然部署到兩個數據中心，到了業務運行階段，一個數據中心爲主，一個數據中心爲輔，不過這個主備方案毫不是一般意義的數據備份方案，他實際上是吸取了單核和雙核方案的優勢，同時儘可能避免單核和雙核的缺點，那麼這點上這個主備方案是如何作到的呢？

　　首先咱們仍是要把系統業務交易分下類，系統有些交易對於實時性啊，數據的正確性啊要求很是高，那麼這樣的業務場景使用單核存儲系統比較合適，一個業務系統不可能全是這樣的實時性交易，也有一些交易對實時性要求比較差，固然咱們仍是得要考察下這種交易對於延時容忍度，具體就是通常延時多久用戶是能夠接受的，這點很是重要，由於就算是主備方案，那麼數據仍是會有同步的操做，只不過這個同步的時間粒度上會更粗些，咱們能夠以系統和業務角度合理設置一個同步時間間隔，若是延時性交易的延時時間超過了這個間隔時間的話，那麼這樣的業務場景實際上是能夠就近處理的，沒有必要將這些請求都發送到主數據中心，這樣能夠減輕主數據中心的運行壓力。該企業的二代信息系統還有個要求就是過了天天的零點，前一天的數據必須在兩個數據中心完成同步，換句話說，兩個數據中心數據的差別性最大容忍度是天，爲何要這樣作了？有的朋友看到了必定認爲這是爲了備份數據，的確這是目的之一，但這個作法還有更大的深意，雙核設計除了解決距離對網絡效率的影響外，還有個重要的目的就是容災，我記得幾年前，有個朋友告訴我他們公司網站掛了6個小時，我當時很奇怪，我就問大家系統難道不是分佈式嗎？他說他們線上系統沒有單點，那爲何網站還會整個掛掉了？答案真的讓人不敢相信，由於他們的機房漏雨了，機房的線路短路了，那個朋友告訴我這件事情之後，他們公司又在附近租了個新機房作容災，防止此類事情再發生了。這種狀況真的能夠稱之爲天災了，不過這樣的事情機率很低，但是一旦發生就會很是致命，記得日本爆發九級大地震的時候，我看到一個新網報道，報道里面有好多大型計算機倒掉了，而這個機房的機器的做用幾乎關係到亞洲互聯網系統的命脈，你們都知道每一個網站都有本身的域名，域名是一個網站的入口，而日本那個機房放置的服務器就是全球赫赫有名的13臺服務器之一，專門用來解析域名的DNS服務器，若是這些機器掛掉了，可能發生一整個國家都不能正常使用互聯網。可是天災畢竟是局部的，所以全國甚至全球設立不一樣的數據中心用來容災是不少大型互聯網公司必須走的道路，回到本文的主備方案，爲了保證數據中心的容災性，那麼咱們再設計主備方案同時還要保證主備數據中心能夠迅速切換，當一個數據中心出現問題時候能夠立刻把輔助的數據中心轉化爲主數據中心。爲了保證這種切換的可靠性，該企業常常在晚上交易量小的時候，把主備來回切換跑跑。

　　回到開篇提到的那三張截圖，那個一開始彈出地域選擇框的電商網站，當咱們選擇不一樣的地域時候，查詢一樣的商品最後顯示的商品列表是不一樣，而京東雖然也有地域選擇，可是咱們切換地域後查詢商品後結果基本沒有變化，至於淘寶和天貓壓根就沒有讓咱們選擇地域的選項，配送都是在商品這邊進行選擇的。可能淘寶和天貓沒有自營業務，所以天貓很難控制裏面商家的地域區別，京東和前面哪家電商網站由於大部分是直營業務，所以配送地址和他們倉儲所在地是有關係的，其實這個作法衍生下的話，地域其實還能夠作到數據中心的劃分，例如江滬浙用一個數據中心，中部地區用一個數據中心，那麼這種方式就能夠幫助咱們解決存儲層的就近問題，從這裏咱們彷佛也能夠看出B2C和C2C的業務場景的一些區別。

　　由此我能夠作一個總結，首先存儲層作到對等多核的體系基本是不可能的，主備的方案能夠解決單核和多核的缺點，同時能夠發揚單核和多核的優勢，距離的遠近也能產生業務的差別性，咱們能夠經過這種差別性把數據中心變成分散式，這樣還能夠解決數據訪問的就近原則。

　　美國的互聯網公司規模很大，他們從一開始就是全球化的，那麼對於美國的大型互聯網公司將數據中心分散化和本地化就變的很是重要，因此好的存儲層的分佈設計方案是完成網站全球佈局任務的基礎。可是對於不少中小企業，或者是剛剛創業的公司能在不一樣地域創建數據中心，或者不差錢可是能快速的創建不一樣地域的數據中心實際上是很是難的事情，那麼這個時候咱們找一家全球性的雲平臺例如亞馬遜的雲平臺，或者咱們的業務就侷限在中國，使用個本土優秀的雲平臺也是一種不錯的選擇，雲計算的推廣使得創業者的成本愈來愈低了。

　　好了，本系列的文章到此爲止，本系列都是在講數據庫的問題，我曾經說過任何程序或軟件都是計算和存儲的結合體，本系列着重講到的是存儲，時下不少大型互聯網公司在存儲這塊已經發生了很大的變化，在關係數據庫這塊都已經作到了去商業關係數據庫，而使用開源的關係數據庫，並將這些開源的關係數據進行了大規模的改造，這個作法應該算是互聯網領域關係數據庫發展的前沿了，同時將關係數據庫很難作到的事情用Nosql數據庫來替代也是一種大趨勢。

　　本系列講述時候設置了一個很大的前提，那就是儘可能保持關係數據庫存儲的本性，所以我將不少計算建議遷移到應用層，這個觀點我有不少理由說明它的好處，可是現實中是不是最好的方法，這個就要具體看了，所以我不想去苛求這麼作的合理性，可是邏輯上合理的方案老是會有不少借鑑意義的，這就是我想表達的，至於關於存儲層的計算我傾向於在數據訪問層裏作，所以按照個人思路，最終這個關係數據庫存儲層就會變成一個分佈式數據庫，數據訪問層固然也是使用分佈式系統原理來作，講解分佈式系統也是本文章後續想討論，若是我有時間接着寫這個大系列博客我會在分佈式系統這塊繼續講解數據訪問層的設計問題。

　　好了，文章寫完了，祝你們生活愉快。

 

原文連接： http://www.cnblogs.com/sharpxiajun/p/4280337.html