<b>摘要：</b>8月24日，阿裡雲資料庫技術峰會到來，本次技術峰會邀請到了阿裡集團和阿裡雲資料庫老司機們，為大家分享了一線資料庫實踐經驗和技術幹貨。在本次峰會上，特邀嘉賓映客直播架構師王振濤分享了映客直播作為創業公司從0至日活千萬的資料庫架構變遷，資料庫在直播中的經典應用場景，資料庫存儲的優化思路，以及如何建構一個高可用資料庫架構。
<b>以下内容根據演講嘉賓現場視訊以及ppt整理而成。</b>
本次分享的内容将主要圍繞以下四個部分：
一、映客直播發展曆程
二、直播遇上雲資料庫
三、風口上的資料庫架構變遷
四、直播典型應用場景分析
<b></b>
映客直播是2015年5月份成立的一家公司，在移動直播領域，映客算是比較早成立的公司了。如上圖中所展示的就是映客app上的一些頁面，左圖展示的是映客app中的熱門内容，這裡是某一個反串演員主播正在進行直播，并且此時有5萬多觀衆正在觀看；右圖則是映客直播的發現頻道，發現頻道裡面主要會在熱門時段對于平台内的優質内容進行展示推送。在映客app中會有很多類似于前面提到的這些頁面，包括了遊戲直播、健身直播以及小視訊等等。作為一個剛剛成立兩年的公司而言，映客直播的發展速度還是非常迅速的，從2015年5月映客成立之初，剛剛釋出app時的dau隻有200，到當年10月份的時候dau就已經達到了10萬+，再到12月份短短兩個月的時間，映客直播的dau就已經突破了100萬，而在2016年中下旬的時候，dau峰值就已經達到了千萬級别。以上就是映客直播大緻的整體發展曆程。
<b>二、直播遇上雲資料庫</b>
<b>業務起步：映客app釋出</b>
接下來為大家介紹映客直播從開始到現在的架構發展演變過程。當映客app剛釋出的時候，整個背景其實隻有三個人負責，兩個開發和一個運維，這時的架構如下圖所示。起初的架構其實是非常簡單的，背景是由8台虛拟機搭建而成的，其中的6台虛拟機做了服務，而剩下的2台做了存儲，存儲這部分則是使用了自己搭建的mysql和redis。在這個起步階段，對于背景系統要求最高的一點就是當出現了産品想法就需要盡快地實作，這樣的架構非常适合在業務起步階段的需求條件下實作一個直播app，當時第一版本的開發工作隻花費了2周的時間。
業務發展：規模化
而随着映客直播業務量的提升，從2015年的5月份到10月份，映客的dau達到了10萬+，到12月份的時候就已經達到了100萬+，此時的業務發展已經達到了規模化的階段，這個階段的整體服務端的架構設計如下圖所示。此時的架構也是分為了接入層、業務層、基礎層以及資料層，但是此時的架構與第一版的架構相比，其整體的架構已經基本成型了，這一版的架構實作了一些業務拆分、資料拆分以及子產品化複用，此時服務的底層仍舊是依賴于redis和mysql資料庫的。這個階段最為顯著的變化就是引入了雲，也就是說此時的服務已經上雲了。
對于映客的服務上雲，當時的考慮主要基于以下幾點：
ddos，因為雲主機本身是可以防止ddos攻擊的，這樣就可以将代理層全部都部署到雲上。
直播存在一個天然的屬性就是有很多的明星活動以及其他大v的活動，因為這些活動所造成的瞬時壓力是非常大的，如果使用自建機房就需要為這些可能僅僅持續幾個小時的活動而囤積很多台伺服器，需要購買很多預留資源。而使用在雲之後，雲主機本身是按照使用量進行收費的，這樣可以将很多核心業務都部署到雲上，在出現瞬時活動需要進行擴容的時候就可以直接進行擴容，當活動結束之後就可以釋放這些多餘的資源，通過這樣的彈性伸縮可以極大地降低直播平台的營運成本。
雲主機以及雲資料庫等這些雲資源使用的都采用的是叢集模式的部署，而其叢集模式往往也是對于使用者透明的，這樣就可以了解成雲本身幫助我們實作了一層高可用。
平滑可伸縮，比如現在的資料庫的配置或者性能不能滿足需求了，就可以使用雲上的這些資源進行平滑地擴容，并且雲上的擴容對于服務是沒有任何影響的，而且包括slb負載均衡器這些對于雲的使用者而言都是比較友好的。
綜合以上四點的考慮，映客直播在業務規模化的階段就使用了雲服務。
而使用雲服務之後首先需要面對的一個問題就是：整體遷移。對于整體遷移而言，雲服務本身也提供了一些工具可以實作對于存儲進行實時地同步以及在最後進行切換，對于雲服務本身可以實作隔離以及制作鏡像之後就可以打包釋出到雲上去。映客直播當時的業務量也不是太大，是以整體而言遷移上雲的過程還是比較順利的。但是任何事情可能都不隻會有好的一面，當使用了雲服務之後同時也會遇到一些問題，映客在上雲的過程中也遇到了一些不可控的因素，也就是“水土不服”。比如當時的雲服務的mysql連接配接數是有上限為2000的限制的，而映客當時采用的很多服務架構都是屬于多程序的架構，這樣就非常容易造成連接配接數不夠用的情況；并且當時外網帶寬限制是200m，很容易就跑滿了，而且内網帶寬也是一樣的情況；另外，在使用雲主機的時候也會出現一些資源搶占或者當機的情況。綜上所述，在上雲之後有好的一面，也存在着不是特别舒服的一面。在這個過程中，映客不再僅僅是一個雲服務的使用者了，也演變成為雲服務的産品經理或者qa，映客與阿裡雲也是從開始的接觸、了解到後來的“相愛相殺”，并且一起來推進雲服務的優化，一直到雙方都達到比較好的狀态。
<b>業務爆發：千萬日活</b>
其實雲服務本身是作為基礎設施的，它可以為我們提供高品質的運維。但是當業務的日活、流量還在爆發性增長的時候，單單依靠雲服務這種基礎設施的能力還是不夠的，是以映客的服務架構也在不斷地疊代中。如下圖所示的架構架構是在映客上雲之後，進行了一次比較大的改造之後的架構，這個架構就已經實作了一些分層，主要分為了使用者層、應用層以及資料層，并且在雲服務基礎設施上實作了很多服務化的重構、存儲的優化等的一些技術中間件，做了方方面面的工作來保障當業務爆發達到千萬日活的時候，服務還依舊能夠支撐住，這樣的架構本身的穩定性也還是比較不錯的。近期，映客在做的一件事情就是在目前體量已經非常大的情況下，如何去保證資源的獨占和安全，目前也正在基于雲服務設施進行vpc的部署，而且這項工作目前推進得也還不錯。
<b>雲上架構</b>
其實大家可以看到，映客的整體架構是建構在雲服務基礎設施之上的。目前映客已經達到今天千萬日活這樣的體量還在使用雲服務其實主要基于以下幾個方面的考慮：首先，我們認為在現階段，雲服務的發展已經相對比較成熟了，并且也是比較安全的，雲服務在内部可以保障一些高可用的支撐；另外，使用者使用的所有服務基本上都是叢集化的，并且是支援平滑伸縮的，這些對于有活動營運需求的直播平台而言都是非常有價值的；并且雲服務的使用者也不需要預留太多資源來支撐可伸縮的容量；除此之外，如果使用自建機房，那麼運維團隊需要足夠了解每一個環節，需要能夠支撐從硬體設施到監控以及上線等各個方面，這對于一個快速疊代的公司的運維團隊而言則是非常困難的，而使用雲服務則可以保障基礎設施的高品質運維。以上這些就是映客直播到目前千萬日活的體量依舊選擇在雲上架構未來的很重要的原因。
其實很多服務以及系統到最後歸結起來都是資料，是以雲服務的重中之重或者基礎的基礎就是雲資料庫，這也是映客的架構中一直在不斷地疊代和優化的技術層面。雲資料庫作為基礎，也經曆了從單機時代到叢集時代，再到分布式架構的發展演變。
<b>三、風口上的資料庫架構變遷</b>
接下來為大家分享映客從0到千萬日活過程中資料庫架構變遷的曆程。談到資料庫，無論是像oracle、mysql這樣的關系型資料庫，還是像mongodb這樣的nosql的資料庫，大家想到的第一點就是資料庫的性能。而資料庫主機的性能主要和以下的這幾個方面相關：cpu、存儲、索引、io、鎖、記憶體以及内部的線程模型等，這些都是確定資料庫設計本身性能非常關鍵的方面。
在另一個層面，當資料庫實作了叢集化或者分布式之後，可能會面臨着另外的一個問題，也就是所謂的cap理論。cap理論就是當想要在一緻性、可用性以及分區可容忍性這三個方面進行權衡時，需要結合具體的業務場景，針對于具體不同的業務場景需要有選擇地舍棄一些東西來保障核心的訴求。
在映客的資料庫設計演變的過程中，大緻經曆了如下這樣的變化：使用者量從千級到了億級，日活從百級到了千萬級，大v粉絲從百級到了千萬級，送禮峰值的qps從十級到了萬級，關系資料從千級到了千億級。大家可能會産生疑問，為什麼關系資料一下子從千級到了千億級。其實直播本身存在一些社交屬性，比如當使用者喜歡一個主播的時候就可能去關注他，每一條關注就可能産生兩條記錄，是以當使用者量已經達到億級的時候，關系資料的量就會是非常大并且也非常重要的。是以在這樣的過程中，千億級别關系資料的存儲所面對的挑戰還是非常大的。另外，直播本身也存在大v屬性，很多大主播可能具有千萬量級的粉絲，那麼在大v每開一次直播的時候，千萬粉絲都需要收到這個大v的開播提醒。而對于千萬粉絲而言，他們的關注清單中都要出現這個大v正在直播的關注資訊。同樣的，在大v關閉直播時，關注清單中的直播資訊就需要立即消失，這些對于實時性、高并發、大容量的要求是非常高的。除此之外，非常重要的一點就是映客直播本身是支援送禮的，而且映客還獨創性地支援了禮物連送，也就是比如我喜歡一個主播，可能送的禮物的價值是一毛錢，但是可以進行連續送禮，可以連續送幾萬次，雖然這對于使用者的體驗而言是非常爽的，但是對于伺服器而言則會造成非常大的壓力，是以萬級qps的送禮的金融資料的壓力也是映客之前所面臨的很大的挑戰。
在這個過程中就涉及到基礎資料和雲資料庫之間的碰撞。一方面，基礎資料在爆發性地增長；另外一方面，雲資料庫需要能夠支撐資料的指數級增長的量級。
在資料庫架構演變過程中，無論是mysql、redis還是mongodb這些資料庫層面的服務都經曆如下圖所示的變化，從單主機的模式到後來獨立主機，到後來的主從讀寫分離，再後來根據使用者、房間、資料等次元進行垂直拆分，而在次元已經很大比如像關系資料已經到達千億量級的時候還進行了水準拆分。
<b>關鍵技術點-資料遷移工具</b>
在資料庫架構演變過程中涉及到一些技術點，在這裡可以與大家分享一下。在資料遷移工具這部分在資料庫架構演變過程一直都扮演者極為重要的角色。對于同構資料的遷移而言，其實有比較成熟的方案，同構資料遷移相當于上圖中的從單主機一直到垂直拆分這部分，這部分由于所涉及到資料表的結構以及資料的拆分政策都沒有什麼變化，是以這部分工作直接依賴雲資料庫的遷移工具，就可以實作資料的平滑遷移，并且業務上基本是無感覺的。這部分适用的場景就是伺服器級别、執行個體級别的擴容或者讀寫分離以及業務的垂直拆分等。但是當體量已經足夠大到需要做很多水準層面的拆分的時候，很多現有的成熟的工具就已經不太适用了。這個過程中，映客直播的技術團隊就基于binlog等日志層面的東西開發了自己的一套異構資料遷移中間件，這個中間件比較适用于異構資料庫或者是做分庫分表的遷移。因為在分庫分表的過程中要想做到業務的盡量的無感覺還是比較困難的，特别是在一開始是單庫單表，需要分成1000張表，在分完成1000張表之後是很難再回退過去的，這個成本是非常大的。如果在這個過程中異構資料遷移元件做的足夠好，就可以将風險降到很低。
對于異構資料的遷移方面可以為大家分享一個比較成熟的方案，比如需要從單庫單表的資料次元遷移到32個庫，每個庫32個分表這樣一千多張表的資料次元，此時可以首先把分庫分表的一千多張表的資料次元當做之前單庫單表的邏輯存庫，而這個邏輯存庫在一開始是通過基礎元件binlog觸發保證資料的實時同步的，其延時基本上可以達到秒級。如果是這樣就可以先将服務中一些讀的操作遷移過去，因為對于讀操作而言，即使出現問題進行復原也是沒有任何代價的。等讀操作遷移完成，并且通過驗證比對沒有問題之後，再将比較少的寫的操作遷移過去，這樣就能夠從整體上降低很多的風險。
<b>關鍵技術點-分庫分表中間件</b>
第二個關鍵技術點就涉及到通路分庫分表資料的問題。在實作這部分時，我們也調研了很多業界的方案。目前業界比較成熟的方案主要有兩種，分别是基于client的和基于proxy的，映客技術團隊對于這兩種方案在不同的時期也都實作過，但是總的宗旨是實作分庫分表的透明化。首先，對于業務而言，不需要關心sql到底執行到哪一個庫表上，也不需要關心分庫分表的政策是什麼。第二個就是資料庫本身配置的統一管理，這部分就是對于線上資料的統一切換以及配置都是非常有用的。第三個就是需要提供統一的監控。第四點，既然使用了這個分庫分表中間件，就相當于所有的業務都是依賴于這個中間件的，其高可用設計就是非常關鍵的。另外，分庫分表中間件的設計本身是一個叢集模式，是以需要做好中間件和資料庫中間連結的管理，通過一些連接配接池的模型将連結更好的管理起來。包括後面的負載均衡以及更好的擴充能力等都是在實作分庫分表中間件時需要考慮的。
結合以上的技術關鍵點，映客的技術團隊實作了兩種分庫分表中間件，在最開始技術棧還比較單一的時候，實作了基于client的分庫分表中間件——mdriver client，基于其分庫分表的lab庫可以實作将之前提到的大部分技術點都在内部內建。對于使用者而言，可能隻需要關心初始化這個client，然後正常地寫sql，最終的結果可以直接彙聚好并傳回回來，包括中間的路由政策都是由client本身通過統一配置中心來實作的。這個過程中更多的會涉及到對于多語言的支援，相對而言其優點是當中間件挂掉或者當機了所造成的災難性後果的情況會少一些。除此之前，在最近由于考慮到對于整個公司層面而言，可能不止有一兩種語言棧，而且不是所有的業務都需要使用client來實作，這時候就應該提供更加友好的分庫分表中間件，是以後來映客技術團隊調研了atlas proxy這種形式，也在内部開發了一個支援分庫分表的atlas proxy版本。
<b>關鍵技術點-分布式事務</b>
第三個關鍵技術點就是分布式事務，在之前可能所有的業務在一個資料庫上通過一個本地事務就可以解決問題。而現在已經按照水準拆分和垂直拆分之後分成了很多個庫表以及很多個次元的子產品，這時候就涉及到了資料一緻性的管理。而在這一方面，從業務層面來說業務可能處理的比較多的有兩種分布式事務，第一類就是預占資源型，預占資源型就是比如是a要給b送禮或者a給b轉賬的時候，對于a而言需要扣錢，這部分是需要預先将錢扣掉的，然後再給b加上，這個過程對于a而言就是預占資源型。預占資源型有什麼特點呢？其實就是如果想要給b加錢，那麼就一定需要確定a的錢已經被扣掉了，而且這個操作如果在最終沒有成功，那麼對于a而言是非常容易復原的。相當于預占資源型的分布式事務的要求是實時的、同步的、并且能夠保證可復原。這一部分現在業界使用的比較多的模型就是基于補償的，也就是tcc的分布式事務架構，這種架構模型也是電商以及金融相關的業務中使用的比較多的。
而第二類分布式事務則是給予資源型的，還是用剛才轉賬的例子，如果a給b轉賬，使用給予資源型事務，如果事務失敗了，但是b已經把錢轉走了，這時候想要復原其實是無法實作的。是以對于給予資源型的分布式事務而言，要麼先不要給b把錢加上，也就是通過當機資源的方式實作，要麼就是通過一些異步必達的方式保證一定成功。而給予資源型事務的特點是其實時性要求不像預占資源型事務那麼強，往往可以允許一定的延遲，比如a給b轉賬，b的錢晚到一會是沒有太大影響的。是以給予資源型事務的特點就決定了其比較适合實作一些異步操作，并且保證其成功。
以上這些就是在實作了資料庫架構演變之後，映客技術團隊在分布式事務這部分所面臨的問題以及所做的事情。
任何脫離了實際應用場景的架構都很難說它是一個好的架構，是以還是需要去分析架構的應用場景，根據其應用場景來分析究竟應該選擇什麼樣的架構模型。接下來就與大家分享在直播這個應用場景之下，與資料庫相關的技術點以及如何進行資料庫架構的設計和疊代。
下圖中展現的是一個直播大v，直播大v的特點就是其粉絲會非常多，下圖中的大v有156萬粉絲，而最多的粉絲量可能會達到千萬級别。而粉絲量比較多所帶來的問題就是無論是推送量還是關注度，還是在直播間中的活躍度都會非常高。而且本身而言，大v的直播也會比較頻繁。此時對于平台考驗最大的就是關系系統，是以關系系統必須能夠支撐高并發、大容量，并且對于關系系統的實時性以及一緻性的要求也是比較高的。如果a關注了b，而到最後沒有關注成功或者并沒有收到b直播的推送資訊，那麼這就是一個故障。是以這對于關系系統的壓力是非常大的，因為任意使用者之間都可以建立互相的關系本身就是笛卡爾積的形式。
是以映客技術團隊也對于關系系統，特别是關系資料庫進行了一些優化。對于關系資料庫的優化主要分為了幾個層面，首先是讀寫分析，也就是關系資料庫這部分的寫和讀是分離開來的；另外還實作了寫的異步化，寫這部分的每個關系的觸發所涉及到的寫的操作會非常多，這時候就應該確定關鍵路徑的寫操作成功之後，其他的都通過寫異步化的形式來做；當千億級的資料爆發之後，資料量已經突破了資料庫單執行個體的限制，這時候就必須要做很多分庫分表等資料拆分方面的工作；另外在關系系統這部分還存在一個特點，就是消息推送需要涉及到關系，兩人聊天也需要涉及到關系，而且每一種需要關系的場景都是不一樣的，是以需要做很多異構資料的處理工作。
通過下圖大家可以看到，在關系系統的主關系服務上有很多異步化的優化。首先，要想實作這些優化需要確定關系服務本身以及關系資料本身是收攏的，有統一的入口。在這之後就可以統一地把控這個入口，然後確定關鍵路徑寫成功，其他非關鍵路徑都可以通過消息隊列分發出去，并組建一些異構的資料源或者不同類型的需要做很多cache優化、異構資料建構等的工作。
從上圖中大家可以看到，如果主播有一千萬粉絲，那麼每次主播開播的時候，就需要将這一千萬粉絲都查詢到并進行推送，那麼這對于系統所造成的壓力将會是非常大的。是以在這個過程中通過redis，通過一些資料拆分保證即使主播有一千萬粉絲也可以實作秒級推送。有一些場景比如在關注直播裡面，假如主播有一千萬粉絲，如果每次開播推送消息時都對于這一千萬粉絲的資料進行寫操作，這将會對關系資料庫造成非常大的壓力，其實可以通過關注清單去反查有所有正在觀看直播的觀衆進行推送，這樣就可以通過推拉結合的方式将這些對于系統性能影響非常大的點通過異構的方式解決掉。
下圖展現的也是映客平台的一個大主播，在日榜中，這個主播一天收獲到了四千多萬的映票，而一個映票相當于一毛錢。每個使用者可以一個小禮物、一個映票地去送，并且可以連送。這樣就會造成這一個問題，因為這四千多萬的映票在一天之内，甚至在一個小時或者半個小時内都送給這個主播，勢必會對于資料庫造成很大的壓力，如果主播的資料在資料庫中僅為一條資料，那麼會涉及到很多次更新操作。是以基于這樣送禮的高并發場景，映客也做了很多層面的優化，首先支撐送禮這個場景的金融屬性中的強一緻性，雖然一個映票隻有一毛錢，禮物的價值雖小但是仍舊是一個金融屬性，如果這一毛錢沒有到主播賬戶上，這将會成為一個金融故障，其影響将會是非常大的。而且粉絲無論在什麼時候送給主播一個映票，都需要看到主播的映票數量是在實時地增長的，如果在短時間内主播的映票數沒有增長，使用者可能就來投訴了，是以在這個場景下對于實時性的要求也是非常高的。除了需要保證金融資料的強一緻性以及實時性的前提，還需要保證在多個粉絲同時向主播送禮時的高并發特性，這對于金币系統的壓力也是非常大的。
<b>映客直播金币系統</b>
映客的金币系統在初始時的架構如下圖所示，也是依賴于rds的mysql叢集，一開始是單主機的，後來進行了獨立執行個體的優化，在這之後還進行了讀寫的分離，實作了讀寫分離之後其實業務包括送禮、支付和展現還是可以直接操作資料庫的。這個時候即便是金币資料庫能夠支撐的量再大，穩定性再高，當遇到剛才提到的主播一天收到四千萬映票的情況時，資料庫所産生的延遲也是無法接受的。
于是映客技術團隊對于金币系統也做了2.0版本的優化，與之前提到的關系服務類似，對于任何的資料層面的優化的前提就是首先需要進行入口的收攏，也就是讓金币系統負責所有的與金币資料相關的操作。當入口收攏之後就可以去進行多方面的優化，而第一個層面就是做分庫分表的工作，第二個層面則是對于主播收禮的過程進行異步的優化。為什麼要實作這兩個層面呢？可能分庫分表并不能解決一個主播一天收到四千多萬次映票的壓力，而它解決的其實是另一個問題，就是将整體的并發吞吐量提升上去。可能最後觀衆送出的禮物都會彙聚到這一個主播上來，但是對于觀衆而言，每個使用者都是單獨的個體，對于他們而言，其操作并不會特别快，而且觀衆都是離散地分布在不同的資料庫上的，這時候就可以通過分庫分表的将資料進行拆分進而将觀衆這一側的壓力降到最低。另一個層面，可以通過異步的優化，如果在主播這一側的收禮比較多，就可以通過異步串行的處理甚至是合并性的處理來保證系統的壓力處于可控範圍之内。而這兩層優化的前提還是入口必須收攏，這就是映客對于金币系統優化的考量。
<b>送禮邏輯解析</b>
這裡為大家分享一個業務中比較核心的送禮邏輯。之前也提到送禮操作和收禮操作需要分為兩塊，并且每個部分需要采用不同的政策，一種是分庫分表的政策，另外一種是使用異步化的政策來解決。
剛才提到的分布式事務中包括了預占資源型事務和給予資源型事務。而送禮恰恰是預占資源型事務，這就必須保障送禮有一個比較好的實時性并且能夠進行同步操作。因為送禮所涉及的是同步操作，需要具有實時性，并且送禮時觀衆端的比較離散的操作，通過分庫分表就能很容易地保證其有一個整體吞吐量的提升。這裡的同步操作并不是簡單的更新操作，一旦更新操作失敗了，就很難實作容錯處理。這裡就涉及到會對于每個操作本身進行本地事務的日志記錄，如果失敗了或者造成一些幂等性的問題時就有據可查了。另外在收禮端，這裡相當于分布式事務中給予資源的操作，既然是給予資源，并且本身還可以容忍一定的延遲性，就可以在扣費成功之後将這個事務投入到一個消息隊列中，通過消息隊列來異步地處理收禮操作，并且可以對于大小主播進行通道的隔離，這樣就很好地滿足了收禮方的需求。總體而言，這樣的邏輯設計保障了送禮和收禮雙方的穩定性、高并發以及實時性。
<b>總結</b>
其實，資料庫本身而言是一個基礎設施。那麼作為基礎設施，我們主要可以依賴資料庫的穩定性以及基本的性能。而雲為資料庫提供了專家級的運維，這一點也是比較好的方面。但是雲資料庫也不是萬能的，在前面提到的場景中的很多情況下必須在架構層面以及具體的業務場景層面進行具體的架構梳理和優化。在資料庫架構方面，我們一直都在路上，并且将會一直努力前行。