在開始本篇主要內容前，我們一起看看下面的幾張截圖，首先是第一張圖，如下圖所示：
這是一家電商網站的首頁，當我們第一次打開這個首頁，網站會彈出一個強制性的對話框，讓用戶選擇貨物配送的地址，如果是淘寶和京東的話，那么這個選擇配貨地址的選項是在商品里，如下圖是淘寶的選擇配送地點：
下圖是京東選擇配貨地點：
那么圖一跟京東和淘寶有什么區別呢？圖一的電商強制用戶選擇地區后，那么我們在查詢這個商品時候會因為地區不同，顯示的查詢結果會不一樣，這個就和網站做國際化有點像，不過網站國際化是切語言和語言相關的靜態資源，但是電商這個地域的選擇是和業務相關的，不同的地域查詢結果是不相同的，這個選擇地域的彈出框很像一個路由器。相比之下，淘寶和京東把商品的配送和商品相關，那么我們在這些網站里查詢商品時候，其實是按照全國查詢的，全國不同的地方查詢同一個條件所獲得到的結果是一致的。從業務角度而言，這說明第一個電商的業務沒有全國鋪開，就算是鋪開了，地域的差異也影響到物流的問題，而淘寶和京東則正是一個全國意義的大型電商網站了。
回到技術的角度，這兩種不同的做法有沒有可能還和技術問題有關了？今天我就來探討下這個問題。
不管網站大與小，一個網站肯定可以分為客戶端、服務端和存儲端，勾連這不同的組成部分是網絡，網絡是一種通訊設施，距離的遠近會直接影響到網絡傳輸的效率問題，如是乎就出現了像CDN這樣的技術，很多大型互聯網公司還會在不同的城市建立機房，這些手段的目的就是在解決距離對網絡傳輸效率的影響，但是當這種就近解決問題的方案落到存儲層的時候，問題就來了。上篇里我說道web服務的水平擴展問題，這種水平擴展是基于一種無狀態性的原理設計的，但是到了存儲層我們不管怎么拆分它，它都很難消除狀態的問題，也就是存儲層有狀態性是它的天然屬性。特別是碰到一個競爭性的存儲資源時候，這種狀態性會變得非常頑固，例如商品的庫存問題，如果我們把庫存數據對等的平移到不同地域的數據中心，那么如何保證不同地方的庫存信息總是準確的，這就成為了難題。這種問題放在一個小國家不是什么問題，但是放到地大物博的中國那就很成問題了。所以存儲是這種就近方案的短板了。
我曾了解到中國一家大型信息企業在設計它們第一代系統時候，就考慮到了這種地域性差異對系統設計的影響，它們的第一代系統在存儲層這塊就設計成了一個雙核系統，什么叫做存儲層的雙核系統了？它們的做法是在北京和上海分別建立兩個數據中心，系統的存儲層分別部署在北京的數據中心和上海的數據中心，兩個數據中心是等價的，那么中國北部的交易就走北京數據中心，中國南部的交易就走上海的數據中心。但是系統上線后，發現這種雙核設計方案成為了整個系統的夢魘了，這個夢魘的最核心的問題就是數據的同步問題，因為該企業是一個全國性業務的企業，因此有大量交易需要南北數據中心同步完數據后才能正常完成，但是想從北京和上海同步數據的效率是異常的低效，我曾經看過一份資料，里面說有機構做了一個測試，當兩個數據中心的距離超過了80公里，那么網絡的延遲性基本是無法忍受的，當然不差錢的企業可以專門鋪設專線來連接兩個數據中心，這種專線的成本高的嚇人，我曾聽人說就在上海，如果鋪專線從浦東到浦西，那么這條專線基本是用人民幣鋪就的，更何況是從北京到上海鋪專線，就算企業不差這些錢延遲性也嚴重影響了企業業務的發展。除了延遲性外，通過網絡大規模傳輸數據，數據的可靠性是很難保證的，也就是網絡傳輸時候經常沒有道理的丟包，這就造成了很多重復性傳輸，使得同步數據的效率更加的低效。
因為存儲層這種雙核設計缺陷，該企業馬上從事了二代系統的設計和開發，而這個二代系統核心業務就是解決這個存儲層的雙核問題。那到底該怎么解決了？把雙核變成單核，既然兩個數據中心這么麻煩，那我們就搞一個數據中心算了，既省錢有沒那么多麻煩事情，這個肯定不是解決問題的正確思路了，雙核設計的出發點是非常有現實意義和價值的，最后該公司使用了一個新的方案替代雙核，這個方案稱之為主備方案，存儲層任然部署到兩個數據中心，到了業務運行階段，一個數據中心為主，一個數據中心為輔，不過這個主備方案絕不是通常意義的數據備份方案，他其實是吸收了單核和雙核方案的優點，同時盡量避免單核和雙核的缺點，那么這點上這個主備方案是如何做到的呢？
首先我們還是要把系統業務交易分下類，系統有些交易對于實時性啊，數據的正確性啊要求非常高，那么這樣的業務場景使用單核存儲系統比較合適，一個業務系統不可能全是這樣的實時性交易，也有一些交易對實時性要求比較差，當然我們還是得要考察下這種交易對于延時容忍度，具體就是一般延時多久用戶是可以接受的，這點非常重要，因為就算是主備方案，那么數據還是會有同步的操作，只不過這個同步的時間粒度上會更粗些，我們可以以系統和業務角度合理設置一個同步時間間隔，如果延時性交易的延時時間超過了這個間隔時間的話，那么這樣的業務場景其實是可以就近處理的，沒有必要將這些請求都發送到主數據中心，這樣可以減輕主數據中心的運行壓力。該企業的二代信息系統還有個要求就是過了每天的零點，前一天的數據必須在兩個數據中心完成同步，換句話說，兩個數據中心數據的差異性最大容忍度是天，為什么要這樣做了？有的朋友看到了一定認為這是為了備份數據，的確這是目的之一，但這個做法還有更大的深意，雙核設計除了解決距離對網絡效率的影響外，還有個重要的目的就是容災，我記得幾年前，有個朋友告訴我他們公司網站掛了6個小時，我當時很奇怪，我就問你們系統難道不是分布式嗎？他說他們線上系統沒有單點，那為什么網站還會整個掛掉了？答案真的讓人不敢相信，因為他們的機房漏雨了，機房的線路短路了，那個朋友告訴我這件事情以后，他們公司又在附近租了個新機房做容災，防止此類事情再發生了。這種情況真的可以稱之為天災了，不過這樣的事情概率很低，可是一旦發生就會非常致命，記得日本爆發九級大地震的時候，我看到一個新網報道，報道里面有好多大型計算機倒掉了，而這個機房的機器的作用幾乎關系到亞洲互聯網系統的命脈，大家都知道每個網站都有自己的域名，域名是一個網站的入口，而日本那個機房放置的服務器就是全球赫赫有名的13臺服務器之一，專門用來解析域名的DNS服務器，如果這些機器掛掉了，可能發生一整個國家都不能正常使用互聯網。但是天災畢竟是局部的，因此全國甚至全球設立不同的數據中心用來容災是很多大型互聯網公司必須走的道路，回到本文的主備方案，為了保證數據中心的容災性，那么我們再設計主備方案同時還要保證主備數據中心可以迅速切換，當一個數據中心出現問題時候可以馬上把輔助的數據中心轉化為主數據中心。為了保證這種切換的可靠性，該企業經常在晚上交易量小的時候，把主備來回切換跑跑。
回到開篇提到的那三張截圖，那個一開始彈出地域選擇框的電商網站，當我們選擇不同的地域時候，查詢同樣的商品最后顯示的商品列表是不同，而京東雖然也有地域選擇，但是我們切換地域后查詢商品后結果基本沒有變化，至于淘寶和天貓壓根就沒有讓我們選擇地域的選項，配送都是在商品這邊進行選擇的。可能淘寶和天貓沒有自營業務，因此天貓很難控制里面商家的地域區別，京東和前面哪家電商網站因為大部分是直營業務，因此配送地址和他們倉儲所在地是有關系的，其實這個做法衍生下的話，地域其實還可以做到數據中心的劃分，例如江滬浙用一個數據中心，中部地區用一個數據中心，那么這種方式就可以幫助我們解決存儲層的就近問題，從這里我們似乎也可以看出B2C和C2C的業務場景的一些區別。
由此我可以做一個總結，首先存儲層做到對等多核的體系基本是不可能的，主備的方案可以解決單核和多核的缺點，同時可以發揚單核和多核的優點，距離的遠近也能產生業務的差異性，我們可以通過這種差異性把數據中心變成分散式，這樣還可以解決數據訪問的就近原則。
美國的互聯網公司規模很大，他們從一開始就是全球化的，那么對于美國的大型互聯網公司將數據中心分散化和本地化就變的非常重要，所以好的存儲層的分布設計方案是完成網站全球布局任務的基礎。但是對于很多中小企業，或者是剛剛創業的公司能在不同地域建立數據中心，或者不差錢但是能快速的建立不同地域的數據中心其實是非常難的事情，那么這個時候我們找一家全球性的云平臺例如亞馬遜的云平臺，或者我們的業務就局限在中國，使用個本土優秀的云平臺也是一種不錯的選擇，云計算的推廣使得創業者的成本越來越低了。
好了，本系列的文章到此為止，本系列都是在講數據庫的問題，我曾經說過任何程序或軟件都是計算和存儲的結合體，本系列著重講到的是存儲，時下很多大型互聯網公司在存儲這塊已經發生了很大的變化，在關系數據庫這塊都已經做到了去商業關系數據庫，而使用開源的關系數據庫，并將這些開源的關系數據進行了大規模的改造，這個做法應該算是互聯網領域關系數據庫發展的前沿了，同時將關系數據庫很難做到的事情用Nosql數據庫來替代也是一種大趨勢。
本系列講述時候設置了一個很大的前提，那就是盡量保持關系數據庫存儲的本性，因此我將很多計算建議遷移到應用層，這個觀點我有很多理由說明它的好處，但是現實中是否是最好的方法，這個就要具體看了，因此我不想去苛求這么做的合理性，但是邏輯上合理的方案總是會有很多借鑒意義的，這就是我想表達的，至于關于存儲層的計算我傾向于在數據訪問層里做，因此按照我的思路，最終這個關系數據庫存儲層就會變成一個分布式數據庫，數據訪問層當然也是使用分布式系統原理來做，講解分布式系統也是本文章后續想討論，如果我有時間接著寫這個大系列博客我會在分布式系統這塊繼續講解數據訪問層的設計問題。
好了，文章寫完了，祝大家生活愉快。
文章列表
留言列表
