閱讀592 返回首頁    go 技術社區[雲棲]

映客直播技術實戰：直播平台的數據庫架構演變

摘要：8月24日，阿裏雲數據庫技術峰會到來，本次技術峰會邀請到了阿裏集團和阿裏雲數據庫老司機們，為大家分享了一線數據庫實踐經驗和技術幹貨。在本次峰會上，特邀嘉賓映客直播架構師王振濤分享了映客直播作為創業公司從0至日活千萬的數據庫架構變遷，數據庫在直播中的經典應用場景，數據庫存儲的優化思路，以及如何構建一個高可用數據庫架構。

以下內容根據演講嘉賓現場視頻以及PPT整理而成。

本次分享的內容將主要圍繞以下四個部分：
一、映客直播發展曆程
二、直播遇上雲數據庫
三、風口上的數據庫架構變遷
四、直播典型應用場景分析

一、映客直播發展曆程
d7c4a6e8e1b0fd3245f5590f04aa7af75c336b38
映客直播是2015年5月份成立的一家公司，在移動直播領域，映客算是比較早成立的公司了。如上圖中所展示的就是映客APP上的一些頁麵，左圖展示的是映客APP中的熱門內容，這裏是某一個反串演員主播正在進行直播，並且此時有5萬多觀眾正在觀看；右圖則是映客直播的發現頻道，發現頻道裏麵主要會在熱門時段對於平台內的優質內容進行展示推送。在映客APP中會有很多類似於前麵提到的這些頁麵，包括了遊戲直播、健身直播以及小視頻等等。作為一個剛剛成立兩年的公司而言，映客直播的發展速度還是非常迅速的，從2015年5月映客成立之初，剛剛發布APP時的DAU隻有200，到當年10月份的時候DAU就已經達到了10萬+，再到12月份短短兩個月的時間，映客直播的DAU就已經突破了100萬，而在2016年中下旬的時候，DAU峰值就已經達到了千萬級別。以上就是映客直播大致的整體發展曆程。

二、直播遇上雲數據庫
業務起步：映客APP發布
接下來為大家介紹映客直播從開始到現在的架構發展演變過程。當映客APP剛發布的時候，整個後台其實隻有三個人負責，兩個開發和一個運維，這時的架構如下圖所示。起初的架構其實是非常簡單的，後台是由8台虛擬機搭建而成的，其中的6台虛擬機做了服務，而剩下的2台做了存儲，存儲這部分則是使用了自己搭建的MySQL和Redis。在這個起步階段，對於後台係統要求最高的一點就是當出現了產品想法就需要盡快地實現，這樣的架構非常適合在業務起步階段的需求條件下實現一個直播APP，當時第一版本的開發工作隻花費了2周的時間。
d5c5d7b7c8c0c28b1d7f50e189d45dec0089b9c6

業務發展：規模化
而隨著映客直播業務量的提升，從2015年的5月份到10月份，映客的DAU達到了10萬+，到12月份的時候就已經達到了100萬+，此時的業務發展已經達到了規模化的階段，這個階段的整體服務端的架構設計如下圖所示。此時的架構也是分為了接入層、業務層、基礎層以及數據層，但是此時的架構與第一版的架構相比，其整體的框架已經基本成型了，這一版的架構實現了一些業務拆分、數據拆分以及模塊化複用，此時服務的底層仍舊是依賴於Redis和MySQL數據庫的。這個階段最為顯著的變化就是引入了雲，也就是說此時的服務已經上雲了。
3040a164b3a2e2386c62ed28d1166fa5be60f350

對於映客的服務上雲，當時的考慮主要基於以下幾點：
  1. DDoS，因為雲主機本身是可以防止DDoS攻擊的，這樣就可以將代理層全部都部署到雲上。
  2. 直播存在一個天然的屬性就是有很多的明星活動以及其他大V的活動，因為這些活動所造成的瞬時壓力是非常大的，如果使用自建機房就需要為這些可能僅僅持續幾個小時的活動而囤積很多台服務器，需要購買很多預留資源。而使用在雲之後，雲主機本身是按照使用量進行收費的，這樣可以將很多核心業務都部署到雲上，在出現瞬時活動需要進行擴容的時候就可以直接進行擴容，當活動結束之後就可以釋放這些多餘的資源，通過這樣的彈性伸縮可以極大地降低直播平台的運營成本。
  3. 雲主機以及雲數據庫等這些雲資源使用的都采用的是集群模式的部署，而其集群模式往往也是對於用戶透明的，這樣就可以理解成雲本身幫助我們實現了一層高可用。
  4. 平滑可伸縮，比如現在的數據庫的配置或者性能不能滿足需求了，就可以使用雲上的這些資源進行平滑地擴容，並且雲上的擴容對於服務是沒有任何影響的，而且包括SLB負載均衡器這些對於雲的用戶而言都是比較友好的。

綜合以上四點的考慮，映客直播在業務規模化的階段就使用了雲服務。
f3c76394a787086a65a62b853265f89fe32e1dcc

而使用雲服務之後首先需要麵對的一個問題就是：整體遷移。對於整體遷移而言，雲服務本身也提供了一些工具可以實現對於存儲進行實時地同步以及在最後進行切換，對於雲服務本身可以實現隔離以及製作鏡像之後就可以打包發布到雲上去。映客直播當時的業務量也不是太大，所以整體而言遷移上雲的過程還是比較順利的。但是任何事情可能都不隻會有好的一麵，當使用了雲服務之後同時也會遇到一些問題，映客在上雲的過程中也遇到了一些不可控的因素，也就是“水土不服”。比如當時的雲服務的MySQL連接數是有上限為2000的限製的，而映客當時采用的很多服務框架都是屬於多進程的框架，這樣就非常容易造成連接數不夠用的情況；並且當時外網帶寬限製是200M，很容易就跑滿了，而且內網帶寬也是一樣的情況；另外，在使用雲主機的時候也會出現一些資源搶占或者宕機的情況。綜上所述，在上雲之後有好的一麵，也存在著不是特別舒服的一麵。在這個過程中，映客不再僅僅是一個雲服務的用戶了，也演變成為雲服務的產品經理或者QA，映客與阿裏雲也是從開始的接觸、了解到後來的“相愛相殺”，並且一起來推進雲服務的優化，一直到雙方都達到比較好的狀態。

業務爆發：千萬日活
其實雲服務本身是作為基礎設施的，它可以為我們提供高質量的運維。但是當業務的日活、流量還在爆發性增長的時候，單單依靠雲服務這種基礎設施的能力還是不夠的，所以映客的服務框架也在不斷地迭代中。如下圖所示的架構框架是在映客上雲之後，進行了一次比較大的改造之後的框架，這個框架就已經實現了一些分層，主要分為了用戶層、應用層以及數據層，並且在雲服務基礎設施上實現了很多服務化的重構、存儲的優化等的一些技術中間件，做了方方麵麵的工作來保障當業務爆發達到千萬日活的時候，服務還依舊能夠支撐住，這樣的框架本身的穩定性也還是比較不錯的。近期，映客在做的一件事情就是在目前體量已經非常大的情況下，如何去保證資源的獨占和安全，目前也正在基於雲服務設施進行VPC的部署，而且這項工作目前推進得也還不錯。
d8becb5f925fcb985db8e364524c7e33ecbeb76b

雲上架構
其實大家可以看到，映客的整體架構是構建在雲服務基礎設施之上的。目前映客已經達到今天千萬日活這樣的體量還在使用雲服務其實主要基於以下幾個方麵的考慮：首先，我們認為在現階段，雲服務的發展已經相對比較成熟了，並且也是比較安全的，雲服務在內部可以保障一些高可用的支撐；另外，用戶使用的所有服務基本上都是集群化的，並且是支持平滑伸縮的，這些對於有活動運營需求的直播平台而言都是非常有價值的；並且雲服務的用戶也不需要預留太多資源來支撐可伸縮的容量；除此之外，如果使用自建機房，那麼運維團隊需要足夠了解每一個環節，需要能夠支撐從硬件設施到監控以及上線等各個方麵，這對於一個快速迭代的公司的運維團隊而言則是非常困難的，而使用雲服務則可以保障基礎設施的高質量運維。以上這些就是映客直播到目前千萬日活的體量依舊選擇在雲上架構未來的很重要的原因。
e7cf1f2777f25de40c95527937824cedf8319f34
其實很多服務以及係統到最後歸結起來都是數據，所以雲服務的重中之重或者基礎的基礎就是雲數據庫，這也是映客的架構中一直在不斷地迭代和優化的技術層麵。雲數據庫作為基礎，也經曆了從單機時代到集群時代，再到分布式框架的發展演變。
6da443a2e9888dee5a734e49d3d71afd536cbfc8

三、風口上的數據庫架構變遷
接下來為大家分享映客從0到千萬日活過程中數據庫架構變遷的曆程。談到數據庫，無論是像Oracle、MySQL這樣的關係型數據庫，還是像MongoDB這樣的NoSQL的數據庫，大家想到的第一點就是數據庫的性能。而數據庫主機的性能主要和以下的這幾個方麵相關：CPU、存儲、索引、IO、鎖、內存以及內部的線程模型等，這些都是確保數據庫設計本身性能非常關鍵的方麵。
f48a6e5cc74e0e3a987586c37dc55e5678637e72
在另一個層麵，當數據庫實現了集群化或者分布式之後，可能會麵臨著另外的一個問題，也就是所謂的CAP理論。CAP理論就是當想要在一致性、可用性以及分區可容忍性這三個方麵進行權衡時，需要結合具體的業務場景，針對於具體不同的業務場景需要有選擇地舍棄一些東西來保障核心的訴求。
4b4e6bd83a797f59d3809321486aa6d8631895ff
在映客的數據庫設計演變的過程中，大致經曆了如下這樣的變化：用戶量從千級到了億級，日活從百級到了千萬級，大V粉絲從百級到了千萬級，送禮峰值的QPS從十級到了萬級，關係數據從千級到了千億級。大家可能會產生疑問，為什麼關係數據一下子從千級到了千億級。其實直播本身存在一些社交屬性，比如當用戶喜歡一個主播的時候就可能去關注他，每一條關注就可能產生兩條記錄，所以當用戶量已經達到億級的時候，關係數據的量就會是非常大並且也非常重要的。所以在這樣的過程中，千億級別關係數據的存儲所麵對的挑戰還是非常大的。另外，直播本身也存在大V屬性，很多大主播可能具有千萬量級的粉絲，那麼在大V每開一次直播的時候，千萬粉絲都需要收到這個大V的開播提醒。而對於千萬粉絲而言，他們的關注列表中都要出現這個大V正在直播的關注信息。同樣的，在大V關閉直播時，關注列表中的直播信息就需要立即消失，這些對於實時性、高並發、大容量的要求是非常高的。除此之外，非常重要的一點就是映客直播本身是支持送禮的，而且映客還獨創性地支持了禮物連送，也就是比如我喜歡一個主播，可能送的禮物的價值是一毛錢，但是可以進行連續送禮，可以連續送幾萬次，雖然這對於用戶的體驗而言是非常爽的，但是對於服務器而言則會造成非常大的壓力，所以萬級QPS的送禮的金融數據的壓力也是映客之前所麵臨的很大的挑戰。
d073d1baf4b325d508c513c962cc8ce5b009aa8c
在這個過程中就涉及到基礎數據和雲數據庫之間的碰撞。一方麵，基礎數據在爆發性地增長；另外一方麵，雲數據庫需要能夠支撐數據的指數級增長的量級。

在數據庫架構演變過程中，無論是MySQL、Redis還是MongoDB這些數據庫層麵的服務都經曆如下圖所示的變化，從單主機的模式到後來獨立主機，到後來的主從讀寫分離，再後來根據用戶、房間、資料等維度進行垂直拆分，而在維度已經很大比如像關係數據已經到達千億量級的時候還進行了水平拆分。
25c95d71612e9fdf6115d7879e5f03a4b83e1d49

關鍵技術點-數據遷移工具
在數據庫架構演變過程中涉及到一些技術點，在這裏可以與大家分享一下。在數據遷移工具這部分在數據庫架構演變過程一直都扮演者極為重要的角色。對於同構數據的遷移而言，其實有比較成熟的方案，同構數據遷移相當於上圖中的從單主機一直到垂直拆分這部分，這部分由於所涉及到數據表的結構以及數據的拆分策略都沒有什麼變化，所以這部分工作直接依賴雲數據庫的遷移工具，就可以實現數據的平滑遷移，並且業務上基本是無感知的。這部分適用的場景就是服務器級別、實例級別的擴容或者讀寫分離以及業務的垂直拆分等。但是當體量已經足夠大到需要做很多水平層麵的拆分的時候，很多現有的成熟的工具就已經不太適用了。這個過程中，映客直播的技術團隊就基於binlog等日誌層麵的東西開發了自己的一套異構數據遷移中間件，這個中間件比較適用於異構數據庫或者是做分庫分表的遷移。因為在分庫分表的過程中要想做到業務的盡量的無感知還是比較困難的，特別是在一開始是單庫單表，需要分成1000張表，在分完成1000張表之後是很難再回退過去的，這個成本是非常大的。如果在這個過程中異構數據遷移組件做的足夠好，就可以將風險降到很低。
85bd618429601f3628d00a4382dfc72fb48a4d8d
對於異構數據的遷移方麵可以為大家分享一個比較成熟的方案，比如需要從單庫單表的數據維度遷移到32個庫，每個庫32個分表這樣一千多張表的數據維度，此時可以首先把分庫分表的一千多張表的數據維度當做之前單庫單表的邏輯存庫，而這個邏輯存庫在一開始是通過基礎組件binlog觸發保證數據的實時同步的，其延時基本上可以達到秒級。如果是這樣就可以先將服務中一些讀的操作遷移過去，因為對於讀操作而言，即使出現問題進行回滾也是沒有任何代價的。等讀操作遷移完成，並且通過驗證比對沒有問題之後，再將比較少的寫的操作遷移過去，這樣就能夠從整體上降低很多的風險。

關鍵技術點-分庫分表中間件
第二個關鍵技術點就涉及到訪問分庫分表數據的問題。在實現這部分時，我們也調研了很多業界的方案。目前業界比較成熟的方案主要有兩種，分別是基於Client的和基於Proxy的，映客技術團隊對於這兩種方案在不同的時期也都實現過，但是總的宗旨是實現分庫分表的透明化。首先，對於業務而言，不需要關心SQL到底執行到哪一個庫表上，也不需要關心分庫分表的策略是什麼。第二個就是數據庫本身配置的統一管理，這部分就是對於線上數據的統一切換以及配置都是非常有用的。第三個就是需要提供統一的監控。第四點，既然使用了這個分庫分表中間件，就相當於所有的業務都是依賴於這個中間件的，其高可用設計就是非常關鍵的。另外，分庫分表中間件的設計本身是一個集群模式，所以需要做好中間件和數據庫中間鏈接的管理，通過一些連接池的模型將鏈接更好的管理起來。包括後麵的負載均衡以及更好的擴展能力等都是在實現分庫分表中間件時需要考慮的。
d324069ad28c7cf41d6bef9ee960d7adf1575330
結合以上的技術關鍵點，映客的技術團隊實現了兩種分庫分表中間件，在最開始技術棧還比較單一的時候，實現了基於Client的分庫分表中間件——Mdriver Client，基於其分庫分表的lab庫可以實現將之前提到的大部分技術點都在內部集成。對於用戶而言，可能隻需要關心初始化這個Client，然後正常地寫SQL，最終的結果可以直接匯聚好並返回回來，包括中間的路由策略都是由Client本身通過統一配置中心來實現的。這個過程中更多的會涉及到對於多語言的支持，相對而言其優點是當中間件掛掉或者宕機了所造成的災難性後果的情況會少一些。除此之前，在最近由於考慮到對於整個公司層麵而言，可能不止有一兩種語言棧，而且不是所有的業務都需要使用Client來實現，這時候就應該提供更加友好的分庫分表中間件，所以後來映客技術團隊調研了Atlas Proxy這種形式，也在內部開發了一個支持分庫分表的Atlas Proxy版本。

關鍵技術點-分布式事務
第三個關鍵技術點就是分布式事務，在之前可能所有的業務在一個數據庫上通過一個本地事務就可以解決問題。而現在已經按照水平拆分和垂直拆分之後分成了很多個庫表以及很多個維度的模塊，這時候就涉及到了數據一致性的管理。而在這一方麵，從業務層麵來說業務可能處理的比較多的有兩種分布式事務，第一類就是預占資源型，預占資源型就是比如是A要給B送禮或者A給B轉賬的時候，對於A而言需要扣錢，這部分是需要預先將錢扣掉的，然後再給B加上，這個過程對於A而言就是預占資源型。預占資源型有什麼特點呢？其實就是如果想要給B加錢，那麼就一定需要確保A的錢已經被扣掉了，而且這個操作如果在最終沒有成功，那麼對於A而言是非常容易回滾的。相當於預占資源型的分布式事務的要求是實時的、同步的、並且能夠保證可回滾。這一部分現在業界使用的比較多的模型就是基於補償的，也就是tcc的分布式事務框架，這種框架模型也是電商以及金融相關的業務中使用的比較多的。
a8fd81fc27b0b00522c732ab8b81f705b9a6833b
而第二類分布式事務則是給予資源型的，還是用剛才轉賬的例子，如果A給B轉賬，使用給予資源型事務，如果事務失敗了，但是B已經把錢轉走了，這時候想要回滾其實是無法實現的。所以對於給予資源型的分布式事務而言，要麼先不要給B把錢加上，也就是通過凍結資源的方式實現，要麼就是通過一些異步必達的方式保證一定成功。而給予資源型事務的特點是其實時性要求不像預占資源型事務那麼強，往往可以允許一定的延遲，比如A給B轉賬，B的錢晚到一會是沒有太大影響的。所以給予資源型事務的特點就決定了其比較適合實現一些異步操作，並且保證其成功。

以上這些就是在實現了數據庫架構演變之後，映客技術團隊在分布式事務這部分所麵臨的問題以及所做的事情。

四、直播典型應用場景分析
任何脫離了實際應用場景的架構都很難說它是一個好的架構，所以還是需要去分析架構的應用場景，根據其應用場景來分析究竟應該選擇什麼樣的架構模型。接下來就與大家分享在直播這個應用場景之下，與數據庫相關的技術點以及如何進行數據庫架構的設計和迭代。

下圖中展現的是一個直播大V，直播大V的特點就是其粉絲會非常多，下圖中的大V有156萬粉絲，而最多的粉絲量可能會達到千萬級別。而粉絲量比較多所帶來的問題就是無論是推送量還是關注度，還是在直播間中的活躍度都會非常高。而且本身而言，大V的直播也會比較頻繁。此時對於平台考驗最大的就是關係係統，所以關係係統必須能夠支撐高並發、大容量，並且對於關係係統的實時性以及一致性的要求也是比較高的。如果A關注了B，而到最後沒有關注成功或者並沒有收到B直播的推送信息，那麼這就是一個故障。所以這對於關係係統的壓力是非常大的，因為任意用戶之間都可以建立相互的關係本身就是笛卡爾積的形式。
487f883c1b23df5a0c8a2ad551aff786a06217d6
所以映客技術團隊也對於關係係統，特別是關係數據庫進行了一些優化。對於關係數據庫的優化主要分為了幾個層麵，首先是讀寫分析，也就是關係數據庫這部分的寫和讀是分離開來的；另外還實現了寫的異步化，寫這部分的每個關係的觸發所涉及到的寫的操作會非常多，這時候就應該確保關鍵路徑的寫操作成功之後，其他的都通過寫異步化的形式來做；當千億級的數據爆發之後，數據量已經突破了數據庫單實例的限製，這時候就必須要做很多分庫分表等數據拆分方麵的工作；另外在關係係統這部分還存在一個特點，就是消息推送需要涉及到關係，兩人聊天也需要涉及到關係，而且每一種需要關係的場景都是不一樣的，所以需要做很多異構數據的處理工作。

通過下圖大家可以看到，在關係係統的主關係服務上有很多異步化的優化。首先，要想實現這些優化需要確保關係服務本身以及關係數據本身是收攏的，有統一的入口。在這之後就可以統一地把控這個入口，然後確保關鍵路徑寫成功，其他非關鍵路徑都可以通過消息隊列分發出去，並組建一些異構的數據源或者不同類型的需要做很多Cache優化、異構數據構建等的工作。
2fbeedc16c439b394b073a324a1274af0cfb7f5a
從上圖中大家可以看到，如果主播有一千萬粉絲，那麼每次主播開播的時候，就需要將這一千萬粉絲都查詢到並進行推送，那麼這對於係統所造成的壓力將會是非常大的。所以在這個過程中通過Redis，通過一些數據拆分保證即使主播有一千萬粉絲也可以實現秒級推送。有一些場景比如在關注直播裏麵，假如主播有一千萬粉絲，如果每次開播推送消息時都對於這一千萬粉絲的數據進行寫操作，這將會對關係數據庫造成非常大的壓力，其實可以通過關注列表去反查有所有正在觀看直播的觀眾進行推送，這樣就可以通過推拉結合的方式將這些對於係統性能影響非常大的點通過異構的方式解決掉。

下圖展現的也是映客平台的一個大主播，在日榜中，這個主播一天收獲到了四千多萬的映票，而一個映票相當於一毛錢。每個用戶可以一個小禮物、一個映票地去送，並且可以連送。這樣就會造成這一個問題，因為這四千多萬的映票在一天之內，甚至在一個小時或者半個小時內都送給這個主播，勢必會對於數據庫造成很大的壓力，如果主播的數據在數據庫中僅為一條數據，那麼會涉及到很多次更新操作。所以基於這樣送禮的高並發場景，映客也做了很多層麵的優化，首先支撐送禮這個場景的金融屬性中的強一致性，雖然一個映票隻有一毛錢，禮物的價值雖小但是仍舊是一個金融屬性，如果這一毛錢沒有到主播賬戶上，這將會成為一個金融故障，其影響將會是非常大的。而且粉絲無論在什麼時候送給主播一個映票，都需要看到主播的映票數量是在實時地增長的，如果在短時間內主播的映票數沒有增長，用戶可能就來投訴了，所以在這個場景下對於實時性的要求也是非常高的。除了需要保證金融數據的強一致性以及實時性的前提，還需要保證在多個粉絲同時向主播送禮時的高並發特性，這對於金幣係統的壓力也是非常大的。
03edddd1138ba7f8fe9f3ae328fba724fdafba52

映客直播金幣係統
映客的金幣係統在初始時的架構如下圖所示，也是依賴於RDS的MySQL集群，一開始是單主機的，後來進行了獨立實例的優化，在這之後還進行了讀寫的分離，實現了讀寫分離之後其實業務包括送禮、支付和體現還是可以直接操作數據庫的。這個時候即便是金幣數據庫能夠支撐的量再大，穩定性再高，當遇到剛才提到的主播一天收到四千萬映票的情況時，數據庫所產生的延遲也是無法接受的。
21dc81687ef4cbdf4035f7ab754d6c824d41a148
於是映客技術團隊對於金幣係統也做了2.0版本的優化，與之前提到的關係服務類似，對於任何的數據層麵的優化的前提就是首先需要進行入口的收攏，也就是讓金幣係統負責所有的與金幣數據相關的操作。當入口收攏之後就可以去進行多方麵的優化，而第一個層麵就是做分庫分表的工作，第二個層麵則是對於主播收禮的過程進行異步的優化。為什麼要實現這兩個層麵呢？可能分庫分表並不能解決一個主播一天收到四千多萬次映票的壓力，而它解決的其實是另一個問題，就是將整體的並發吞吐量提升上去。可能最後觀眾送出的禮物都會匯聚到這一個主播上來，但是對於觀眾而言，每個用戶都是單獨的個體，對於他們而言，其操作並不會特別快，而且觀眾都是離散地分布在不同的數據庫上的，這時候就可以通過分庫分表的將數據進行拆分從而將觀眾這一側的壓力降到最低。另一個層麵，可以通過異步的優化，如果在主播這一側的收禮比較多，就可以通過異步串行的處理甚至是合並性的處理來保證係統的壓力處於可控範圍之內。而這兩層優化的前提還是入口必須收攏，這就是映客對於金幣係統優化的考量。
32e6d8b7945b1910bdf5dd5d769286c8e02ba5d2

送禮邏輯解析
這裏為大家分享一個業務中比較核心的送禮邏輯。之前也提到送禮操作和收禮操作需要分為兩塊，並且每個部分需要采用不同的策略，一種是分庫分表的策略，另外一種是使用異步化的策略來解決。
a9c6d18a08cab1f4a70be30f60bd0df23797fcd8
剛才提到的分布式事務中包括了預占資源型事務和給予資源型事務。而送禮恰恰是預占資源型事務，這就必須保障送禮有一個比較好的實時性並且能夠進行同步操作。因為送禮所涉及的是同步操作，需要具有實時性，並且送禮時觀眾端的比較離散的操作，通過分庫分表就能很容易地保證其有一個整體吞吐量的提升。這裏的同步操作並不是簡單的更新操作，一旦更新操作失敗了，就很難實現容錯處理。這裏就涉及到會對於每個操作本身進行本地事務的日誌記錄，如果失敗了或者造成一些冪等性的問題時就有據可查了。另外在收禮端，這裏相當於分布式事務中給予資源的操作，既然是給予資源，並且本身還可以容忍一定的延遲性，就可以在扣費成功之後將這個事務投入到一個消息隊列中，通過消息隊列來異步地處理收禮操作，並且可以對於大小主播進行通道的隔離，這樣就很好地滿足了收禮方的需求。總體而言，這樣的邏輯設計保障了送禮和收禮雙方的穩定性、高並發以及實時性。

總結
其實，數據庫本身而言是一個基礎設施。那麼作為基礎設施，我們主要可以依賴數據庫的穩定性以及基本的性能。而雲為數據庫提供了專家級的運維，這一點也是比較好的方麵。但是雲數據庫也不是萬能的，在前麵提到的場景中的很多情況下必須在架構層麵以及具體的業務場景層麵進行具體的架構梳理和優化。在數據庫架構方麵，我們一直都在路上，並且將會一直努力前行。
10da1a2ab250908f11b8c1e8cf11a8dfffa6e332

最後更新：2017-09-02 01:33:51

  上一篇：go  少時誦詩書所所所所所所所所所所所所
  下一篇：go  如何避免數據庫“勒索事件”和“從刪庫到跑路”的尷尬