在此次活動中，來自麥包包技術保障部總監簡朝陽發表了《MySQL的B2C電商系統前端數據層架構》演講，在此次演講中，他帶來了三方面的技術分享，一個是基于MySQL常見一些高可用可擴展架構分析；另一方面是基于日志解析對現在一些數據庫常見架構方面一些擴展，包括一些可靠性或者高可用性以及一些問題解決方面的內容；再有就是基于用戶行為分析系統的一個數據層的構建。 

麥包包技術保障部總監簡朝陽

以下是簡朝陽的演講實錄：

大家好，我是來自麥包包技術保障部的簡朝陽，今天我分享的主題是基于MySQL的B2C電商系統前端數據層架構。我之前在互聯網企業工作，也是與電子商務相關。之前我自己寫過一本MySQL方面的書，可能有些同學看過。

今天主題主要有三個方面，一個是基于MySQL常見一些高可用可擴展架構分析；還有是基于日志解析對現在一些數據庫常見架構方面一些擴展，包括一些可靠性或者高可用性，包括一些問題解決方面的內容；最后就是基于用戶行為分析這樣一個系統的一個數據層的構建。

基于MySQL常見一些高可用可擴展架構分析

常見架構在高可用方面有硬件高可用和數據高可用，因為是數據庫、數據層這塊，硬件給我們支持數據，數據怎么保護它，怎么讓它保護我們的業務正常運行，這兩塊是重要的。冗余基本上無外乎增加一些備份、備用設備，再一個存儲設備的備份，電源的雙電源等等這方面的內容，可能這個應該不需要太多的深入討論，因為這個是比較熟悉的。熟悉高可用可能是我們更關注或者說對大家更有用。數據高可用通過兩種方式，一個是共享方式解決，同一份數據被多個主機掛載，這是一個共享的方式。還有就是冗余，多種數據的方式。比如我們通過自己實現或者是第三方實現的數據的程序，這里是數據同步方面的東西，數據多重拷貝來進行多方面訪問。這個數據出現問題了，還有其他的數據來保證業務持續下去。

看看共享方面，這是我畫的一個架構圖，共享的話底層我們的Storages而是一份數據或者是有可能是幾份數據，通過中間的交換設備，比如說我們的同構網絡，SaaS，通過這樣的協議來交換主機。主機可能是一兩個節點或者是多個節點承接這個數據，數據做任何變化的時候都是被前端這些節點同時操作，通過底層協議相關的關系來達到我們這個數據的高可用。比如我前端這個節點，數據庫或者說我其他的存儲設備主機節點出現問題，我數據只要在，我馬上可以啟用備用節點使用這個數據，不會有任何中斷。這是目前比較常見的數據共享這種方式，這是我們今天所要討論的MySQL。

MySQL的高可用架構是大家比較了解的數據復制的方式，也是目前在整個業界使用MySQL最多的一種保證它的高可用、擴展的一個方式。MySQL數據庫的復制跟其他的數據庫有點不一樣，他是基于邏輯復制，不是獨立一個個數據庫拷貝，他是從日志里面解析出來，而不是說我主節點有什么數據塊的變化再復制到背景里面去。所以MySQL在這個過程中沒有主機的限制和協議的限制，這給我們MySQL的利用過程中帶來很大的靈活性。

我這里畫了一個基本常用的架構圖，是雙的主節點相互護持，還有三個備節點，可能還有多個節點。我的兩個寫入節點已經是高可用了，一個節點出現問題，另外一個節點馬上可以啟用。我們可以通過第三方，比如說類似開源的HA管理人員管理我們的數據庫、網絡、資源，這里面一個節點任何一個方面，比如網絡、數據庫出現問題之后，他馬上可以通過浮動IP切換，使用另外一個節點提供服務，很好的保證了我們前端寫入節點高可用。項目使用，如果使用共享存儲或者說共享設備的方式，存在的一個問題就是你的存儲數據在提供服務的時候，你只是被一個點去鎖住，一旦要切換，你首先遇到一個問題就是必須在主機端要解這個鎖，釋放這個資源。然后再加鎖，再使用這個資源，這個過程很長，如果遇到任何問題就會卡住，HA切換就會遇到問題。但是這種非共享被復制的方式高可用就不會遇到這個問題。因為他的數據是不會加這個鎖，數據可以隨便寫的。所以這共享設備的HA切換，一般消耗的切換時間都需要比通過冗余方式來切換時間要長，你出現故障要切換的時候，碰到冗余的方式就是幾秒鐘一切換就完了。但是如果你使用共享設備，如果你底層一些存儲量比較大，可能要花比較多的時間才會切換完。幾秒鐘和幾分鐘對我們的客戶來說是有很大的差距的，所以在高可用這一塊，可能再通過冗余方式遠遠好于通過共享的方式。當然冗余方式也會有副作用，比如說管理性，設備利用率方面可能會沒有我們共享方式高。但是所帶來的價值就是他的操作更靈活，他的可用性更高。他對設備的要求也會更低一些。

當我這樣一個架構遇到異常的時候，他如何來改動我們的可能性，首先我們的一個節點出現問題以后，本來我們前面有三個節點，當出現問題之后，看這個箭頭，可以把出現問題的節點斷掉，剩下好的節點，他們兩個資源之間沒有一個鎖或者是一個資源等待的關系，一旦出現問題他可以非常迅速反映，馬上把這個節點棄用，而用其他的節點。所以當我們復制節點出現問題的時候，很容易切換，無論是自己實現這樣管理的作業層還是通過其他的軟件判斷，檢查也好都可以做到這個切換。

如果我們的寫入節點有問題怎么辦？我們看看當我們的A出現問題，會出現什么狀況？比如我們太多寫A這個節點，當這個節點出現問題的時候，我們所有的業務都可以正常運轉，所有客戶訪問不涉及寫入是沒有任何異常的。只有在需要寫入操作的時候才需要設計這個異常所做出的判斷，這個還有B節點，還可以提供服務。可以通過一些腳本、商業軟件都可以，主要一些開源軟件已經很成熟了，幫助我們管理這些浮動的資源，通過這樣浮動IP去判斷我們數據庫或者是其他的網絡是否是通的，數據庫資源是否正常。這時候如果我們馬上切換到B節點，整個鏈路沒有任何問題，不需要做任何數據庫層的切換，只需要IP切換一下，這個過程也是非常短的。

但是可能有些同學會想到，如果我的B節點出現問題怎么辦，我們來看一看。正常我們的數據可能寫入了A節點，通過B節點復制到后面的三個點。這種情況下B節點做了兩個事情，一個是A節點的高可用保證，一個冗余。同時他還做了一個復制的蹤跡，兩層的復制。這個時候如果B節點出現問題，之前A節點的復制實際上是會中斷的。這個中斷它的影響其實并不是特別大，因為在這個中斷之后對我們業務正常訪問讀取的話，他的影響只是說我后面讀取出來的數據是有一點延遲。我的頁面能夠讓用戶看到和不能讓用戶看到是很大差異，不管數據有沒有延遲，如果只是一點故障，整個系統不可見了，讓用戶看到我們的數據有點延遲，這兩種概念是很大差異的。所以這種情況下，對故障的恢復時間也是有很大一個緩沖余地。這種情況下，我們所需要做的就是后面的所有節點從Marste（音）切換到A這個節點，這個時候我們一旦把他的Marste節點從B切換到A之后，之前延遲的數據馬上可以恢復趕上去。這個時候如果B節點起來之后，只要數據沒有損壞，不是存儲數據硬件損壞的話，把硬件更換之后不用做任何操作，不用搭建復制頁面，他會自動把數據復制過去。這種情況下，他的影響也是比較小的。一般情況下B節點沒有提供任何服務，負載很低，他出現問題的可能性遠低于其他的節點，壓力大的時候比壓力小的時候更會出現問題，大家也會有親身經歷。這是我介紹了一下目前比較常規的一些高可用方面的一些架構。

基于日志解析的準實時同步對架構進行擴展

我們看看我們常規的擴展方向，擴展的話無非兩方面，一種是向上擴展，還有一種是向外擴展，向上擴展什么意思呢？就是我們主機或者說里面某些部件升級或者是主機型號升級，或者說我增加一點內存，增加一點硬盤的方式。同樣在節點數量方面也增加，只是把這個節點的處理能力增加了。向外擴展是在節點數上面的擴展，就相當于我們常說的儲存擴展。他無論是水平拆分還是縱向拆分，增加這個節點數的方式。或者是按模塊按功能做一些拆分或者是把同樣相關的數據做拆分。前期的話這種縱向擴展維護性方面或者是擴展成本方面比較小，但是達到一定程度之后垂直擴展無法滿足要求。我們為了做縱向擴展，從PC機升級到小型機，這個時候小型機非常的昂貴，你一旦上了小型機的船，很難從上面下來，現在小型機廠商也不多，很容易被一個廠商綁架，成本會飛快的飆升。然后向外擴展還有就是復制，這也是向外擴展的一個方式。再一個通過Cache/Search擴展。也是一個擴展的方式。

第一步要做一個縱向擴展，按照模塊或者是表把它拆開，然后當一個還不夠的時候，某一個模塊都沒辦法通過，我們不得不考慮這種水平擴展，做水平的拆分。這里舉的例子，比如我們一些用戶信息，用戶信息訪問。或者是根據產品的ID的方式，水平分拆就是怎么樣選擇分拆線，這個選擇很多時候讓我們后面的應用如何去開發會影響很大。一個不太好的分拆線會不知道怎么去應用，因為拆開之后就很難合并，把這些數據拿到一起合并升級其實成本也很高。很多時候我們遇到就是如何選擇這個分拆線。我先做了垂直拆分，不滿足要求每個地區進行水平拆分。這是我們常見做擴展的方案。也是目前很多電商或者說很多互聯網企業在使用的。我們后面是想在常規方案基礎上再加入我們的B2C電子商務企業特點，來應對特點來做一些加工擴展和改進。

我們B2C網站的特點我這里列舉了幾個，不一定完全囊括。我們產品數量的基數并不大，一個企業所賣的東西不像一個平臺那么多。而且每一個產品的數據其實變更，產品并行之后它需要變更的內容很少，SKU數量基數不會太大，一般不會超過千萬級別。另外一個就是雖然我的SKU的量不多，但是每一個SKU被訪問到的次數很大，我的基數少，但是訪問量高，我的次數平均被訪問是很大的。而且網上購物什么的，大家可能平時都在上班，我購物的時候是很集中的，不像有些網站，新聞網站上班可以看看，波峰和波谷時間差異不是特別大。電子商務和購物在平時來看很多網站對我們B2C來說可能是高峰，下班這個時間可能就是高峰或者是很晚的時候還是高峰。

另外我們的數據少，但是他訪問多，數據比起來少，整體來說這差異很大。另外一個，我們是針對和消費者做很多分析服務，包括我們后面還有很多供應鏈管理、倉儲相關，前端系統和后端倉儲、物流相關信息交互很多。不像傳統互聯網企業，你所做的是信息，沒有后端傳統，這些數據交互，所以這種情況下，以后交互很少，會在這個信息上面去瀏覽，不會有傳統的東西在里面。他這里面有很大的差異，交互很多。

針對這個特點，我們要做什么時期呢？可以把我們寫入集中化，寫入的量并不是想象那么大，不像平臺企業那樣有那么多寫入。大部分的寫入是自己在寫入，內部系統在寫入。用戶的交易性內容可能會寫入比較多，但是我們寫入會比較少，這時候的寫入會做集中化管理，他不會有太大瓶頸，至少在一定范圍內可用。但是我們讀就不一樣，雖然訪問用戶很多，任何人在下班買東西之前不會看完第一眼就下單，他會不斷看，所以瀏覽次數會很多，讀取就會受影響。所以這種讀取一定要擴展。而且讀取的擴展比別的是方便的，如果我們擴展寫入的話里面涉及邏輯，所以數據交互，你讀取的時候可以按照模塊、各方面MySQL的數據進行拆分，可以減少很多寫入的放大。

我們的交易和產品兩個分離，交易寫入量非常多，需要很長的一致性，它的優化模型不一樣，我們的產品分離。為什么要分離？因為產品大部分都是讀，而且他的讀的量很集中，這樣我們可以利用他的MySQL的日志，開放性寫的特點，自己做復制。利用MySQL的開放性是怎么樣擴展這個系統。很多朋友會問我為什么自己去做開發或者是做復制，或者是利用現成的方案。我們的讀在擴展的時候如果你只是做簡單復制的方式，你寫的每一個點都要復制到讀上面。這種復制過程中寫入放大是很可怕的。這種冗余或者復制方案只可能解決你讀的問題。自己的用戶只寫了一個點，但是復制到其他點的時候每次只做寫入，而且是單線層的寫入，當你遇到大篇寫入的時候會容易出現延時。雖然他另外一個事物比這個大事物早很長時間完成了，但是他一定要完成之前這個事物，才可能往后面做。我們就可以利用MySQL這種比較開放的復制協議來做一些簡單開發。自己來復制我們數據，我只把我需要這個數據復制到相應節點，而不是所有的節點。MySQL基于對數據庫的過濾數據，整個數據傳輸還是一樣的。

我們要減少和后端的一些交互節點，減少交互節點是為什么呢？因為我們各種數據交互以及交互的點或者是交互方式越簡單，他遇到的問題越少。你這個交互成為一個網狀的時候，不知道去管理維護了。

這了發了一個寫入集中簡單的示意圖，我們在一個點寫入，通過日志解析，數據復制，再通過我們自己對日志協議的理解，加入一些方式，可以很大程度緩解數據，讓延時更少，讓復制更靈活。通過這樣一種方式去做復制。比如說這里SQU可能分為多個庫，這種促銷相關信息又分到一個地方去，各種訂單也分到一個地方去，還有很多其他的類似的東西。

產品和交易庫分離，比如把交易分到一邊，產品分到一邊，包括擴展方式也有很大差異。交易相關數據，他的一致性要求高，需要事物支持，你一旦涉及到錢這個東西之后，你做了一半結果失敗了，客戶肯定不愿意了。或者說里面有異常，錢沒收回來，你自己肯定也不愿意。這里面一定要出現一個強一致性的。然后交易的量是很大，是一個幾何基數方式。交易寫入量也很大，不斷有相關數據進去出來，所以寫入量很大。所以在交易方式，我們一般采用什么方式擴展呢？更多使用是向上擴展。我們增強交易主機的處理能力，增強IO設備的IO能力。你會面臨當失敗之后如何去往下走的問題，包括你后面補償也好，這個出現問題后面的會很復雜。為了減少這種，減少節點，就使用獨立節點，把這個獨立節點能力加強，這種方式無論是維護性還有系統開發方面都會有很大的優勢。本身由于這一塊你交易是直接你的公司能力相關的。你說他擴展的時候在成本可控的情況下愿意投入這筆錢，畢竟他是這塊的核心，而且他涉及的點并不是特別多。所以他擴展也是比較容易解決的。我們產品相關就有另外一個特點，一致性要求沒有那么高，操作有時候是單條記錄，但個點。數據本身要求也沒有那么苛刻，他不需要這種強制性保護，最終一致性就OK，很符合我們分布式做法的。因為他量小，他的基數小，而且他的數據持續性要求不像我們的交易數據那么大，交易數據用戶一直操作，不能等他一會刷新之后才可以看到下一步操作，產品不一樣。你自己內部一些產品部門或者一些管理部門做一些產品分析之后，他不需要立刻讓用戶看到，用戶延時一塊看到實際上影響不大。你這種基于時間點促銷，實際上這種活動相關的數據，你是可以提前做一些準備的，不可能我讓我的產品人員就等著，我12點要促銷，我12點就點這個促銷，插入什么東西，肯定要預設的，所以擴展方式也不一樣。還有變化小，可以用Cache去解決。再看看我們把后端加進來，后端倉儲和物流的交互，不管他可能是直接通過數據庫或者是應用交互的時候都在減少中間的交互節點。不要讓他去為了節省一點點讀取，為寫入節點增加一些資源，雖然消耗了節點資源，但是整個復雜性會降低很多。

第三個節點，這里說的是分析推薦系統。我的一個電子商務的企業，我這里說的是必要性。為什么我們需要這樣一個系統，首先我們需要根據我們一些訪問的數據或者是日志數據，你需要提升用戶體驗，拿到這些用戶分析結果，你平時自己去看自己的網站覺得很好，但是換一個角度，用戶角度他是用你這個系統的時候他可能看到是另外一個東西，他更多看到是不好的方面，你更多看到是好的方面，掩蓋這些有問題的地方。左翼我們通過這種分析推薦的系統或者是日志的分析系統可以降低這種出現問題之后的難度，提高用戶的使用體驗。在這個過程中也是提升整體品牌形象的一個很好的方式。

還有一方面，我自己寫的是提升銷量，這可能是寫的比較直接的，我們為什么可以認為能提升銷量呢。每個公司不可能每樣產品一樣的銷售情況，有一些是滯銷，有一些是熱銷產品。我們最可能的就是滯銷品，出現的原因也很多？有的是產品本身有問題，用戶用了覺得不習慣、不大好，不愿意買。還有一種情況，我這個產品，用戶根本就是看到的機會比較少，我這里說的曝光率。當這個產品的曝光率沒有達到一定量的時候或者是比別人多少的時候，他成了滯銷品啟示是很自然的事情。我們的系統不一定知道哪個產品的曝光率不夠，一定要讓我們分析用戶的點擊行為，分析每個產品的曝光率量，然后提高這種因為曝光而成為只品產品的銷量，直接提升我們的整體銷量。

然后還有一點，我們可以根據用戶的一些使用習慣，可以分析用戶一些興趣點，分析他所喜歡的這些產品到底是什么樣的，什么類型的，是什么價位的。這些數據對我們來說都是很有用的，這樣我們在查找這個商品或者說他在選商品的時候，我們可以大大縮短他選商品的時間，讓他一旦進入我們系統之后，可以找到自己想要什么系統，想要什么樣的產品因為我們可以推薦，我們根據他以往一些購買經歷，以往一些點擊行為的數據進行分析，可以分析出他對那些產品感興趣，我們增強加大這些產品在他面前的曝光率，做到每個用戶進來現實的個性化，還可以增加他們購買得欲望，也是提升我們銷量很好的事情。還有其他我這里沒有一一列舉。

我們這個分析系統好處很多，實際上他也面臨很多問題，怎么樣實現這個分析系統，怎么樣做好這個推薦過程。比如說我們第一個來講，我基礎數據怎么收集，我到底該收集哪些數據，這個問題也是一個難點。最初的時候不知道該收集哪個數據。剛開始隨便收集數據，然后慢慢分析，我收集的這個數據量很大，如何過濾沒有用的，這也是一個問題。因為你收集很多數據進來，發現你占用空間大，量大，難度大。還有數據范圍廣，包括自己的產品的屬性、歸類也是你關系的，這時候可能會影響你在收集的應用，通過PS或者是在應用里面嵌入代碼劃點等方式，都有可能對我們的系統造成影響。這時候如何降低我們的收集數據的應用對我們原本應用影響也是一個難點，這是一個技術難點。搜集結果也分析，這時候可能存在兩方面難點，一個就是結構數據量大，通過傳統的關系數據庫你很難去處理。你沒有很好的常規的日志分析工具去分析，常規日志分析工具就是常規的功能，我們需要遠不止這些，我們需要自己設計、定制一些功能，所以沒有一個合適的商業軟件去滿足。這兩方面是一個技術的問題，還有就是我們如何制定這個模型，分析的模型，這可能更多是一個數據和商業方面的問題。

我們分析，可能我搭建大型的分布式系統去做，也能解決這個積蓄問題。怎么樣把數據分析結果反饋到前端網站，怎么樣讓用戶在網上點，瀏覽網站的時候提示數據反饋回去，這也是一個問題。你不可能讓前端程序直接訪問后端的集群，這個分析也會做到實時性。

構建基于用戶訪問行為的實時推薦分析系統數據層

針對這里幾個技術難點，我后面做簡單的介紹。因為前面兩個純技術方面的東西和商業方面都有關系，后面這個點基本上就是純技術方面的東西。看看后面的內容，我們這個分析推薦系統如何組建，如何搭建他。這里設計了一個方案，大家可以看一下。關系型結構化方式將用戶行為記錄在MySQL數據庫中。我通過Blacphole存儲引擎作為行為記錄的基礎表引擎。再把這個數據中轉到MySQL它的一個開源倉儲解決方案，Infobright。這個過程中我們是利用了實時的解析Binlog方式，將這個數據轉發到Infobright里面。這個做的好處就是標準的SQL接口對數據進行訪問。無論是前端寫數據還是后面分析數據，都可以對SQL接口，降低我們對程序開發成本。為什么會選擇這種Blacphole的存儲引擎呢，他只是記錄日志，真正數據沒有記錄下來，只是作為一個中轉。因為Blackhole作為倉儲引擎他的并發量是有限的。雖然他不像很多其他的系統，可是他的并發量會受到很大的限制，他可以由一定的并發，但是不可能做到其他的系統一樣提供那樣的并發。所以可以降低很多他在并發方面的開銷，真正專注于他擅長一點，做分析。

前端用一個MySQL數據庫接管這些數據，也是有統一的接口。當他不寫數據的時候，他不需要保證這個數據的非常可靠的特性，用我們的日志數據，你丟個幾條沒有問題，他不像我們的交易數據，他是可以丟的。所以他日志不需要每次都同步到磁盤，這時候基本上數據都還在我們內粗里面，所以性能影響很小。所以我簡單做這樣一個架構。

我們看后面一些，我畫了一個圖，我中間這里畫了一個是用戶數據集群，做了相關分離，每個都是多個節點的數據庫，我們的應用陳旭會通過一些各種類型的GS或者是其他的嵌入式的包，把日志寫到Blacphole存儲引擎，通過日志同步工具，這種分析引擎實時跟應用程序交互，我們把分析結構以異步方式嵌入到前面的應用程序，Web頁面程序。這樣對我們前端應用影響很小，而且這個分析結構一直在變化。雖然可能每一次展示分析結構，并不是他上一次點擊完的分析結構，而是一直跟著他的點擊流做分析和變化。

這就是我做的簡單的一個架構圖，可能沒有深入的去分析每一個點。這里我之所以說這樣一個架構，我在這里把他列出來，文件節點要統一，可能會出現一些延時等等。擴展能力很強，但是他的并發節點很弱，一個節點他占用80-90%，他的系統能力可能就榨干了整個硬件設備的能力。

這個軟件我后面可以介紹他大概的結構情況，MySQL的Infobright是基于存儲解決方案的引擎，他有非常好的架構在里面，在下面的知識網格，他在數據進去的時候不斷統計你這些數據，運算他的一些分析，每一個狀態一些柱狀圖還有信息。我們常規的數據都是基于行的，但是這個有非常強的壓縮能力，他的壓縮是比較大的。他還可以支持MySQL原先的運行，Infobright存儲引擎，有開源版也有別的版的，大家可以研究一下。