愛奇藝基礎(chǔ)數(shù)據(jù)平臺(tái)演進(jìn)
[導(dǎo)讀]愛奇藝基礎(chǔ)數(shù)據(jù)平臺(tái)主要是為了統(tǒng)一公司內(nèi)部的基礎(chǔ)數(shù)據(jù)交換規(guī)范，解決不同團(tuán)隊(duì)之間ID不統(tǒng)一問題（各團(tuán)隊(duì)都有自己獨(dú)立的ID）、數(shù)據(jù)定義不統(tǒng)一、數(shù)據(jù)更新不及時(shí)等問題。隨著公司業(yè)務(wù)發(fā)展，除了視頻基礎(chǔ)數(shù)據(jù)，還逐步對(duì)接了UGC視頻、全網(wǎng)影視資料、資源位、直播、游戲、文學(xué)、電商等公司大部分業(yè)務(wù)方...
愛奇藝基礎(chǔ)數(shù)據(jù)平臺(tái)主要是為了統(tǒng)一公司內(nèi)部的基礎(chǔ)數(shù)據(jù)交換規(guī)范，解決不同團(tuán)隊(duì)之間ID不統(tǒng)一問題（各團(tuán)隊(duì)都有自己獨(dú)立的ID）、數(shù)據(jù)定義不統(tǒng)一、數(shù)據(jù)更新不及時(shí)等問題。
隨著公司業(yè)務(wù)發(fā)展，除了視頻基礎(chǔ)數(shù)據(jù)，還逐步對(duì)接了 UGC 視頻、全網(wǎng)影視資料、資源位、直播、游戲、文學(xué)、電商等公司大部分業(yè)務(wù)方的基礎(chǔ)數(shù)據(jù)，支持海量業(yè)務(wù)數(shù)據(jù)的存儲(chǔ)、分發(fā)、在線查詢、離線分析等服務(wù)。?目前已有近百張數(shù)據(jù)表，總數(shù)據(jù)量數(shù)十億，數(shù)據(jù)日增長(zhǎng)百萬級(jí)，日消息量千萬級(jí)，覆蓋公司幾十個(gè)業(yè)務(wù)團(tuán)隊(duì)。
本文將從愛奇藝數(shù)據(jù)平臺(tái)在實(shí)際業(yè)務(wù)中解決HBase高可用、消息服務(wù)高可用以及平臺(tái)整體服務(wù)水平擴(kuò)展能力等方面，敘述愛奇藝的探索和實(shí)踐。
01
愛奇藝基礎(chǔ)數(shù)據(jù)平臺(tái)主要提供以下能力：
02
03
首先需要通過統(tǒng)一管理平臺(tái)，定義好表及其的字段類型結(jié)構(gòu)，隨后會(huì)發(fā)布基于Protobuf的數(shù)據(jù)定義包，通過這個(gè)包來使用分發(fā)平臺(tái)中存儲(chǔ)的數(shù)據(jù)。
生產(chǎn)業(yè)務(wù)通過ID服務(wù)、寫入服務(wù)將數(shù)據(jù)寫入平臺(tái)，平臺(tái)會(huì)先將數(shù)據(jù)入庫HBase，后會(huì)發(fā)送一個(gè)更新通知消息，下游業(yè)務(wù)通過訂閱消息獲取到具體變更的ID及字段信息，再通過讀取服務(wù)獲取該ID的最新數(shù)據(jù)。
平臺(tái)內(nèi)部也基于消息將本次變動(dòng)的內(nèi)容記錄于HBase，方便業(yè)務(wù)排查定位問題，尤其是數(shù)據(jù)結(jié)果不對(duì)時(shí)，業(yè)務(wù)可以很快通過這個(gè)變更記錄查詢到是哪個(gè)業(yè)務(wù)在什么時(shí)間具體IP地址改動(dòng)的數(shù)據(jù)，在實(shí)際工作場(chǎng)景中使用頻率較高。
對(duì)于消息合并服務(wù)主要是對(duì)寫入觸發(fā)的消息進(jìn)行相同ID寫入的合并，減少發(fā)出的消息量，降低下游訂閱業(yè)務(wù)的處理壓力。我們針對(duì)消息區(qū)分了優(yōu)先級(jí)，不同的優(yōu)先級(jí)有不同的合并窗口時(shí)間，例如：直播等業(yè)務(wù)對(duì)時(shí)效性相對(duì)敏感，消息合并則窗口期更短。
04
ID服務(wù)使用2個(gè)MySQL集群，其中一個(gè)MySQL示例只生成單數(shù)ID，另外一個(gè)MySQL生成雙數(shù)ID，這樣可以做到其中一個(gè)MySQL不可用時(shí)，另外一個(gè)MySQL可以正常提供服務(wù)。
4.2? 消息分發(fā)
平臺(tái)本身存儲(chǔ)了很多不同業(yè)務(wù)的數(shù)據(jù)表（例如：視頻、直播、圖書等），業(yè)務(wù)可以根據(jù)自己的業(yè)務(wù)需要可以訂閱單個(gè)或多個(gè)不同的業(yè)務(wù)表消息并做一定規(guī)則的過濾，而這種場(chǎng)景屬于比較普遍的，所以由平臺(tái)本身實(shí)現(xiàn)比較合理，不用每個(gè)業(yè)務(wù)都做一遍?；谶@種背景下我們最初使用了ActiveMQ的VirtualTopic做了大類的區(qū)分，但一段時(shí)間后我們發(fā)現(xiàn)這種方式并不夠靈活，無法控制的更精細(xì)。為此我們自研了一個(gè)ActiveMQ插件來滿足相對(duì)精細(xì)的消息分發(fā)控制，整體結(jié)構(gòu)如下圖：
通過管理平臺(tái)我們將規(guī)則通過一個(gè)特殊的Topic推送到插件，插件本身會(huì)監(jiān)聽這個(gè)Topic消息，將規(guī)則保存在內(nèi)存中并持久化，插件會(huì)在每一條消息發(fā)送之前對(duì)消息進(jìn)行一個(gè)路由，根據(jù)訂閱規(guī)則匹配發(fā)送到1個(gè)或多個(gè)隊(duì)列中，原理類似AOP機(jī)制。
05
由于本身平臺(tái)業(yè)務(wù)場(chǎng)景決定，一次寫入對(duì)應(yīng)N次讀取，所以在極端場(chǎng)景下，線上偶爾發(fā)生過HBase某個(gè)RegionServer宕機(jī)的情況，進(jìn)而造成大量的超時(shí)情況。
目前我們的主要解決的思路就是加緩存，讀多寫少就是緩存的主要場(chǎng)景。在數(shù)據(jù)庫選型上，我們?cè)赗edis、CouchBase、MongoDB上進(jìn)行了調(diào)研，最終選擇了MongoDB，主要的原因是Redis和CouchBase在容量上不滿足業(yè)務(wù)需求。在我們對(duì)MongoDB的壓測(cè)中，性能方面也在可接受范圍內(nèi)。
緩存方案如下：
寫入服務(wù)每次請(qǐng)求都會(huì)生成一個(gè)唯一的SessionID，我們將這個(gè)ID作為數(shù)據(jù)的版本號(hào)，緩存是否失效使用這個(gè)版本號(hào)來判斷。每次寫入時(shí)更新緩存以及讀取時(shí)緩存失效時(shí)更新緩存都為異步，主要是為了降低延時(shí)，以及避免緩存更新失敗導(dǎo)致寫入失敗。
為了保證緩存和HBase的一致性，每次請(qǐng)求都要讀取HBase中存儲(chǔ)的版本號(hào)，這也對(duì)HBase造成了較大的壓力，為了解決這個(gè)問題，我們將HBase中SessionId設(shè)為單獨(dú)列族，并設(shè)置IN_MEMORY => ‘true’來優(yōu)化。? ? ??
5.2? HBase可用性
由于全部數(shù)據(jù)都存儲(chǔ)在HBase，所以提升HBase本身的可用性就尤為重要，目前單集群內(nèi)的單節(jié)點(diǎn)故障，HBase本身的機(jī)制是可以保證的。但是如果整個(gè)集群故障或者集群所在機(jī)房出現(xiàn)了故障，如何能保證服務(wù)可用？
經(jīng)過調(diào)研目前開源版本HBase還沒有相對(duì)完善的跨機(jī)房部署方案，例如單個(gè)機(jī)房故障情況下不影響服務(wù)正常使用。
我們?cè)诮Y(jié)合服務(wù)特性的情況下設(shè)計(jì)的HBase同城主備高可用方案，如下：
Mongo作為寫入緩存，保存WAL（WriteAhead Log）Mongo三機(jī)房部署，高可用。
Synchronizer服務(wù)將WAL寫入主HBase，異步服務(wù)。
主HBase與備用HBase建立數(shù)據(jù)同步。
寫入流程：Write服務(wù)只寫入Mongo，由Synchronizer同步服務(wù)將數(shù)據(jù)同步到主HBase。
讀取流程：同時(shí)讀取Mongo和HBase，將WAL最新數(shù)據(jù)與HBase數(shù)據(jù)合并得到最新數(shù)據(jù)返回，讀取服務(wù)使用Hystrix進(jìn)行熔斷，如果主HBase宕了，Mongo中數(shù)據(jù)與備用HBase集群仍然可以合并出最新數(shù)據(jù)返回。
Mongo中WAL設(shè)置TTL，時(shí)間大于主庫到從庫的同步延遲。
目前該方案已經(jīng)在生產(chǎn)環(huán)境經(jīng)歷了2次故障，并且故障對(duì)讀寫無影響，上下游業(yè)務(wù)無感知。
5.3? ActiveMQ碰到的問題
對(duì)于第一個(gè)問題我們的處理這種問題的方式也比較簡(jiǎn)單粗暴，通過之前開發(fā)的插件對(duì)每一個(gè)隊(duì)列進(jìn)行閾值控制，超過一定閾值則不再繼續(xù)發(fā)送消息并通知業(yè)務(wù)及時(shí)消費(fèi)消息，這對(duì)業(yè)務(wù)本身是有一定影響的，對(duì)業(yè)務(wù)不友好，治標(biāo)不治本。
在經(jīng)歷了較多次線上問題后，我們決定考慮其他消息中間件，在調(diào)研了市面上主流的消息中間件后我們將Kafka和RocketMQ作為備選，在選型的時(shí)候我們主要考慮幾個(gè)因素，可用性、可靠性、水平擴(kuò)展能力，在這3項(xiàng)中兩個(gè)中間件都滿足需求。
還有一個(gè)需要考慮的因素就是消息過濾或分發(fā)，因?yàn)榇媪筷?duì)列都有訂閱規(guī)則，考慮業(yè)務(wù)遷移成本問題，這個(gè)訂閱規(guī)則實(shí)現(xiàn)還是由平臺(tái)實(shí)現(xiàn)，對(duì)比發(fā)現(xiàn)RocketMQ支持在服務(wù)器端過濾，這個(gè)特點(diǎn)吸引了我們，在經(jīng)過功能驗(yàn)證后，該功能滿足需求，最終選型RocketMQ。
部署方案如下：
單集群同城3機(jī)房部署，主從部署在不同機(jī)房，保證單節(jié)點(diǎn)宕機(jī)、單機(jī)房不可用消息發(fā)送和消息消費(fèi)不受影響，并且消息消費(fèi)的時(shí)效性也不受影響。
我們還開發(fā)了基于RocketMQ客戶端的SDK，過濾規(guī)則都存儲(chǔ)在配置服務(wù)，由SDK負(fù)責(zé)將訂閱規(guī)則推送到FilterServer，業(yè)務(wù)可以更簡(jiǎn)單的遷移到RocketMQ，消息過濾在集群端，所以效率更高，可以減少不必要的消息投遞到客戶端。上線后，徹底解決了之前ActiveMQ的問題。
5.4? 擴(kuò)展讀能力
隨著業(yè)務(wù)的不斷發(fā)展，對(duì)接的業(yè)務(wù)會(huì)越來越多，現(xiàn)有讀寫邏輯相對(duì)復(fù)雜，讀取能力并不能完全達(dá)到水平擴(kuò)展的能力。為了可以更好支撐未來的業(yè)務(wù)發(fā)展，需要進(jìn)一步提升讀取能力，使服務(wù)讀取能力完全做到水平擴(kuò)展。在數(shù)據(jù)庫層面，通常有讀寫分離，也就是正常的讀請(qǐng)求操作主庫，其余純讀取的請(qǐng)求使用從庫來解決這種問題，但是由于業(yè)務(wù)場(chǎng)景限制，很多業(yè)務(wù)都是通過訂閱以及獲取最新數(shù)據(jù)的方式來同步平臺(tái)數(shù)據(jù)經(jīng)過一定的業(yè)務(wù)處理、抽取、加工成最終業(yè)務(wù)想要的數(shù)據(jù)，所以單純將所有用戶的讀取請(qǐng)求都轉(zhuǎn)為讀從庫顯然并不合適，而且這些請(qǐng)求中還有一部分讀請(qǐng)求是寫入業(yè)務(wù)的先讀后寫，但是這種方案也給了我們啟發(fā)。
由于平臺(tái)業(yè)務(wù)較復(fù)雜，無法單純?cè)跀?shù)據(jù)庫層面做讀寫分離，所以就新增一個(gè)業(yè)務(wù)層面的從庫，通過業(yè)務(wù)服務(wù)同步主庫數(shù)據(jù)，這樣下游業(yè)務(wù)可以通過從庫同步或者單純讀取數(shù)據(jù)，而且從庫可以增加多個(gè)。
服務(wù)方案如下：
新服務(wù)SlaveRead（從庫）可通過消息 讀取的方式從主庫同步最新數(shù)據(jù)，更新后發(fā)出消息，提供給下游服務(wù)使用，業(yè)務(wù)可以以相同的方式在從庫同步數(shù)據(jù)或者單純的讀取請(qǐng)求。
從庫與從庫之間可以建立同步關(guān)系，這樣整體同步的壓力就不會(huì)壓在主庫上，避免從庫多進(jìn)而增加主庫壓力，最終實(shí)現(xiàn)了平臺(tái)能力可水平擴(kuò)展。
06
總體來說愛奇藝基礎(chǔ)數(shù)據(jù)平臺(tái)通過在技術(shù)和服務(wù)方案上的不斷改進(jìn)解決業(yè)務(wù)實(shí)際碰到的問題，在RocketMQ、HBase上也積累了一些實(shí)戰(zhàn)經(jīng)驗(yàn)。未來將繼續(xù)探索提高平臺(tái)整體服務(wù)能力、服務(wù)穩(wěn)定性、性能等方面的技術(shù)及方案。
隨著公司業(yè)務(wù)發(fā)展，除了視頻基礎(chǔ)數(shù)據(jù)，還逐步對(duì)接了 UGC 視頻、全網(wǎng)影視資料、資源位、直播、游戲、文學(xué)、電商等公司大部分業(yè)務(wù)方的基礎(chǔ)數(shù)據(jù)，支持海量業(yè)務(wù)數(shù)據(jù)的存儲(chǔ)、分發(fā)、在線查詢、離線分析等服務(wù)。?目前已有近百張數(shù)據(jù)表，總數(shù)據(jù)量數(shù)十億，數(shù)據(jù)日增長(zhǎng)百萬級(jí)，日消息量千萬級(jí)，覆蓋公司幾十個(gè)業(yè)務(wù)團(tuán)隊(duì)。
本文將從愛奇藝數(shù)據(jù)平臺(tái)在實(shí)際業(yè)務(wù)中解決HBase高可用、消息服務(wù)高可用以及平臺(tái)整體服務(wù)水平擴(kuò)展能力等方面，敘述愛奇藝的探索和實(shí)踐。
01
? ?服務(wù)能力
愛奇藝基礎(chǔ)數(shù)據(jù)平臺(tái)主要提供以下能力：
02
? ?整體架構(gòu)
- 接入層：提供HTTP、RPC協(xié)議訪問，提供統(tǒng)一的消息監(jiān)聽和離線掃描SDK
- 統(tǒng)一管理平臺(tái)：為對(duì)接業(yè)務(wù)提供便捷的開發(fā)工具，表定義查看、數(shù)據(jù)量、消息量、修改記錄，實(shí)時(shí)查詢等功能；同時(shí)也包含一站式的字段定義管理系統(tǒng)，可高效便捷地對(duì)業(yè)務(wù)表字段進(jìn)行調(diào)整。
- 服務(wù)治理：對(duì)于數(shù)據(jù)的訪問都有精細(xì)化的權(quán)限控制、流量控制等功能
03
? ?服務(wù)流程
首先需要通過統(tǒng)一管理平臺(tái)，定義好表及其的字段類型結(jié)構(gòu)，隨后會(huì)發(fā)布基于Protobuf的數(shù)據(jù)定義包，通過這個(gè)包來使用分發(fā)平臺(tái)中存儲(chǔ)的數(shù)據(jù)。
生產(chǎn)業(yè)務(wù)通過ID服務(wù)、寫入服務(wù)將數(shù)據(jù)寫入平臺(tái)，平臺(tái)會(huì)先將數(shù)據(jù)入庫HBase，后會(huì)發(fā)送一個(gè)更新通知消息，下游業(yè)務(wù)通過訂閱消息獲取到具體變更的ID及字段信息，再通過讀取服務(wù)獲取該ID的最新數(shù)據(jù)。
平臺(tái)內(nèi)部也基于消息將本次變動(dòng)的內(nèi)容記錄于HBase，方便業(yè)務(wù)排查定位問題，尤其是數(shù)據(jù)結(jié)果不對(duì)時(shí)，業(yè)務(wù)可以很快通過這個(gè)變更記錄查詢到是哪個(gè)業(yè)務(wù)在什么時(shí)間具體IP地址改動(dòng)的數(shù)據(jù)，在實(shí)際工作場(chǎng)景中使用頻率較高。
對(duì)于消息合并服務(wù)主要是對(duì)寫入觸發(fā)的消息進(jìn)行相同ID寫入的合并，減少發(fā)出的消息量，降低下游訂閱業(yè)務(wù)的處理壓力。我們針對(duì)消息區(qū)分了優(yōu)先級(jí)，不同的優(yōu)先級(jí)有不同的合并窗口時(shí)間，例如：直播等業(yè)務(wù)對(duì)時(shí)效性相對(duì)敏感，消息合并則窗口期更短。
04
? ??服務(wù)方案
??
4.1 ID服務(wù)的高可用
ID服務(wù)使用2個(gè)MySQL集群，其中一個(gè)MySQL示例只生成單數(shù)ID，另外一個(gè)MySQL生成雙數(shù)ID，這樣可以做到其中一個(gè)MySQL不可用時(shí)，另外一個(gè)MySQL可以正常提供服務(wù)。
4.2? 消息分發(fā)
平臺(tái)本身存儲(chǔ)了很多不同業(yè)務(wù)的數(shù)據(jù)表（例如：視頻、直播、圖書等），業(yè)務(wù)可以根據(jù)自己的業(yè)務(wù)需要可以訂閱單個(gè)或多個(gè)不同的業(yè)務(wù)表消息并做一定規(guī)則的過濾，而這種場(chǎng)景屬于比較普遍的，所以由平臺(tái)本身實(shí)現(xiàn)比較合理，不用每個(gè)業(yè)務(wù)都做一遍?；谶@種背景下我們最初使用了ActiveMQ的VirtualTopic做了大類的區(qū)分，但一段時(shí)間后我們發(fā)現(xiàn)這種方式并不夠靈活，無法控制的更精細(xì)。為此我們自研了一個(gè)ActiveMQ插件來滿足相對(duì)精細(xì)的消息分發(fā)控制，整體結(jié)構(gòu)如下圖：
通過管理平臺(tái)我們將規(guī)則通過一個(gè)特殊的Topic推送到插件，插件本身會(huì)監(jiān)聽這個(gè)Topic消息，將規(guī)則保存在內(nèi)存中并持久化，插件會(huì)在每一條消息發(fā)送之前對(duì)消息進(jìn)行一個(gè)路由，根據(jù)訂閱規(guī)則匹配發(fā)送到1個(gè)或多個(gè)隊(duì)列中，原理類似AOP機(jī)制。
05
? ??問題及解決方案
5.1? HBase讀取性能差的問題
由于本身平臺(tái)業(yè)務(wù)場(chǎng)景決定，一次寫入對(duì)應(yīng)N次讀取，所以在極端場(chǎng)景下，線上偶爾發(fā)生過HBase某個(gè)RegionServer宕機(jī)的情況，進(jìn)而造成大量的超時(shí)情況。
目前我們的主要解決的思路就是加緩存，讀多寫少就是緩存的主要場(chǎng)景。在數(shù)據(jù)庫選型上，我們?cè)赗edis、CouchBase、MongoDB上進(jìn)行了調(diào)研，最終選擇了MongoDB，主要的原因是Redis和CouchBase在容量上不滿足業(yè)務(wù)需求。在我們對(duì)MongoDB的壓測(cè)中，性能方面也在可接受范圍內(nèi)。
緩存方案如下：
寫入服務(wù)每次請(qǐng)求都會(huì)生成一個(gè)唯一的SessionID，我們將這個(gè)ID作為數(shù)據(jù)的版本號(hào)，緩存是否失效使用這個(gè)版本號(hào)來判斷。每次寫入時(shí)更新緩存以及讀取時(shí)緩存失效時(shí)更新緩存都為異步，主要是為了降低延時(shí)，以及避免緩存更新失敗導(dǎo)致寫入失敗。
為了保證緩存和HBase的一致性，每次請(qǐng)求都要讀取HBase中存儲(chǔ)的版本號(hào)，這也對(duì)HBase造成了較大的壓力，為了解決這個(gè)問題，我們將HBase中SessionId設(shè)為單獨(dú)列族，并設(shè)置IN_MEMORY => ‘true’來優(yōu)化。? ? ??
5.2? HBase可用性
由于全部數(shù)據(jù)都存儲(chǔ)在HBase，所以提升HBase本身的可用性就尤為重要，目前單集群內(nèi)的單節(jié)點(diǎn)故障，HBase本身的機(jī)制是可以保證的。但是如果整個(gè)集群故障或者集群所在機(jī)房出現(xiàn)了故障，如何能保證服務(wù)可用？
經(jīng)過調(diào)研目前開源版本HBase還沒有相對(duì)完善的跨機(jī)房部署方案，例如單個(gè)機(jī)房故障情況下不影響服務(wù)正常使用。
我們?cè)诮Y(jié)合服務(wù)特性的情況下設(shè)計(jì)的HBase同城主備高可用方案，如下：
Mongo作為寫入緩存，保存WAL（WriteAhead Log）Mongo三機(jī)房部署，高可用。
Synchronizer服務(wù)將WAL寫入主HBase，異步服務(wù)。
主HBase與備用HBase建立數(shù)據(jù)同步。
寫入流程：Write服務(wù)只寫入Mongo，由Synchronizer同步服務(wù)將數(shù)據(jù)同步到主HBase。
讀取流程：同時(shí)讀取Mongo和HBase，將WAL最新數(shù)據(jù)與HBase數(shù)據(jù)合并得到最新數(shù)據(jù)返回，讀取服務(wù)使用Hystrix進(jìn)行熔斷，如果主HBase宕了，Mongo中數(shù)據(jù)與備用HBase集群仍然可以合并出最新數(shù)據(jù)返回。
Mongo中WAL設(shè)置TTL，時(shí)間大于主庫到從庫的同步延遲。
目前該方案已經(jīng)在生產(chǎn)環(huán)境經(jīng)歷了2次故障，并且故障對(duì)讀寫無影響，上下游業(yè)務(wù)無感知。
5.3? ActiveMQ碰到的問題
- 單個(gè)慢消費(fèi)情況下寫入消息性能嚴(yán)重下降，直接影響業(yè)務(wù)方正常生產(chǎn)。集群無法輕易水平擴(kuò)展，易產(chǎn)生瓶頸，無法通過增加機(jī)器方式提高集群的生產(chǎn)和消費(fèi)能力。
- 解決方案
對(duì)于第一個(gè)問題我們的處理這種問題的方式也比較簡(jiǎn)單粗暴，通過之前開發(fā)的插件對(duì)每一個(gè)隊(duì)列進(jìn)行閾值控制，超過一定閾值則不再繼續(xù)發(fā)送消息并通知業(yè)務(wù)及時(shí)消費(fèi)消息，這對(duì)業(yè)務(wù)本身是有一定影響的，對(duì)業(yè)務(wù)不友好，治標(biāo)不治本。
在經(jīng)歷了較多次線上問題后，我們決定考慮其他消息中間件，在調(diào)研了市面上主流的消息中間件后我們將Kafka和RocketMQ作為備選，在選型的時(shí)候我們主要考慮幾個(gè)因素，可用性、可靠性、水平擴(kuò)展能力，在這3項(xiàng)中兩個(gè)中間件都滿足需求。
還有一個(gè)需要考慮的因素就是消息過濾或分發(fā)，因?yàn)榇媪筷?duì)列都有訂閱規(guī)則，考慮業(yè)務(wù)遷移成本問題，這個(gè)訂閱規(guī)則實(shí)現(xiàn)還是由平臺(tái)實(shí)現(xiàn)，對(duì)比發(fā)現(xiàn)RocketMQ支持在服務(wù)器端過濾，這個(gè)特點(diǎn)吸引了我們，在經(jīng)過功能驗(yàn)證后，該功能滿足需求，最終選型RocketMQ。
部署方案如下：
單集群同城3機(jī)房部署，主從部署在不同機(jī)房，保證單節(jié)點(diǎn)宕機(jī)、單機(jī)房不可用消息發(fā)送和消息消費(fèi)不受影響，并且消息消費(fèi)的時(shí)效性也不受影響。
我們還開發(fā)了基于RocketMQ客戶端的SDK，過濾規(guī)則都存儲(chǔ)在配置服務(wù)，由SDK負(fù)責(zé)將訂閱規(guī)則推送到FilterServer，業(yè)務(wù)可以更簡(jiǎn)單的遷移到RocketMQ，消息過濾在集群端，所以效率更高，可以減少不必要的消息投遞到客戶端。上線后，徹底解決了之前ActiveMQ的問題。
5.4? 擴(kuò)展讀能力
隨著業(yè)務(wù)的不斷發(fā)展，對(duì)接的業(yè)務(wù)會(huì)越來越多，現(xiàn)有讀寫邏輯相對(duì)復(fù)雜，讀取能力并不能完全達(dá)到水平擴(kuò)展的能力。為了可以更好支撐未來的業(yè)務(wù)發(fā)展，需要進(jìn)一步提升讀取能力，使服務(wù)讀取能力完全做到水平擴(kuò)展。在數(shù)據(jù)庫層面，通常有讀寫分離，也就是正常的讀請(qǐng)求操作主庫，其余純讀取的請(qǐng)求使用從庫來解決這種問題，但是由于業(yè)務(wù)場(chǎng)景限制，很多業(yè)務(wù)都是通過訂閱以及獲取最新數(shù)據(jù)的方式來同步平臺(tái)數(shù)據(jù)經(jīng)過一定的業(yè)務(wù)處理、抽取、加工成最終業(yè)務(wù)想要的數(shù)據(jù)，所以單純將所有用戶的讀取請(qǐng)求都轉(zhuǎn)為讀從庫顯然并不合適，而且這些請(qǐng)求中還有一部分讀請(qǐng)求是寫入業(yè)務(wù)的先讀后寫，但是這種方案也給了我們啟發(fā)。
由于平臺(tái)業(yè)務(wù)較復(fù)雜，無法單純?cè)跀?shù)據(jù)庫層面做讀寫分離，所以就新增一個(gè)業(yè)務(wù)層面的從庫，通過業(yè)務(wù)服務(wù)同步主庫數(shù)據(jù)，這樣下游業(yè)務(wù)可以通過從庫同步或者單純讀取數(shù)據(jù)，而且從庫可以增加多個(gè)。
服務(wù)方案如下：
新服務(wù)SlaveRead（從庫）可通過消息 讀取的方式從主庫同步最新數(shù)據(jù)，更新后發(fā)出消息，提供給下游服務(wù)使用，業(yè)務(wù)可以以相同的方式在從庫同步數(shù)據(jù)或者單純的讀取請(qǐng)求。
從庫與從庫之間可以建立同步關(guān)系，這樣整體同步的壓力就不會(huì)壓在主庫上，避免從庫多進(jìn)而增加主庫壓力，最終實(shí)現(xiàn)了平臺(tái)能力可水平擴(kuò)展。
06
? ??總結(jié)
總體來說愛奇藝基礎(chǔ)數(shù)據(jù)平臺(tái)通過在技術(shù)和服務(wù)方案上的不斷改進(jìn)解決業(yè)務(wù)實(shí)際碰到的問題，在RocketMQ、HBase上也積累了一些實(shí)戰(zhàn)經(jīng)驗(yàn)。未來將繼續(xù)探索提高平臺(tái)整體服務(wù)能力、服務(wù)穩(wěn)定性、性能等方面的技術(shù)及方案。
下載文檔
