大型網站架構改進歷程：儲存的瓶頸（8）

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

這是一家電商網站的首頁，當我們第一次開啟這個首頁，網站會彈出一個強制性的對話方塊，讓使用者選擇貨物配送的地址，如果是淘寶和京東的話，那麼這個選擇配貨地址的選項是在商品裡，如下圖是淘寶的選擇配送地點：

下圖是京東選擇配貨地點：

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

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

不管網站大與小，一個網站肯定可以分為客戶端、服務端和儲存端，勾連這不同的組成部分是網路，網路是一種通訊設施，距離的遠近會直接影響到網路傳輸的效率問題，如是乎就出現了像CDN這樣的技術，很多大型網際網路公司還會在不同的城市建立機房，這些手段的目的就是在解決距離對網路傳輸效率的影響，但是當這種就近解決問題的方案落到儲存層的時候，問題就來了。上篇裡我說道web服務的水平擴充套件問題，這種水平擴充套件是基於一種無狀態性的原理設計的，但是到了儲存層我們不管怎麼拆分它，它都很難消除狀態的問題，也就是儲存層有狀態性是它的天然屬性。特別是碰到一個競爭性的儲存資源時候，這種狀態性會變得非常頑固，例如商品的庫存問題，如果我們把庫存資料對等的平移到不同地域的資料中心，那麼如何保證不同地方的庫存資訊總是準確的，這就成為了難題。這種問題放在一個小國家不是什麼問題，但是放到地大物博的中國那就很成問題了。所以儲存是這種就近方案的短板了。

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

因為儲存層這種雙核設計缺陷，該企業馬上從事了二代系統的設計和開發，而這個二代系統核心業務就是解決這個儲存層的雙核問題。那到底該怎麼解決了？把雙核變成單核，既然兩個資料中心這麼麻煩，那我們就搞一個資料中心算了，既省錢有沒那麼多麻煩事情，這個肯定不是解決問題的正確思路了，雙核設計的出發點是非常有現實意義和價值的，最後該公司使用了一個新的方案替代雙核，這個方案稱之為主備方案，儲存層任然部署到兩個資料中心，到了業務執行階段，一個資料中心為主，一個資料中心為輔，不過這個主備方案絕不是通常意義的資料備份方案，他其實是吸收了單核和雙核方案的優點，同時儘量避免單核和雙核的缺點，那麼這點上這個主備方案是如何做到的呢？

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

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

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

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

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

本系列講述時候設定了一個很大的前提，那就是儘量保持關聯式資料庫儲存的本性，因此我將很多計算建議遷移到應用層，這個觀點我有很多理由說明它的好處，但是現實中是否是最好的方法，這個就要具體看了，因此我不想去苛求這麼做的合理性，但是邏輯上合理的方案總是會有很多借鑑意義的，這就是我想表達的，至於關於儲存層的計算我傾向於在資料訪問層裡做，因此按照我的思路，最終這個關聯式資料庫儲存層就會變成一個分散式資料庫，資料訪問層當然也是使用分散式系統原理來做，講解分散式系統也是本文章後續想討論，如果我有時間接著寫這個大系列部落格我會在分散式系統這塊繼續講解資料訪問層的設計問題。

好了，文章寫完了，祝大家生活愉快。