消息隊(duì)列作為智聯(lián)招聘非常重要的平臺(tái)級(jí)服務(wù)負(fù)責(zé)全業(yè)務(wù)線的消息投遞。有很多非常典型的業(yè)務(wù)場(chǎng)景，我們用一個(gè)業(yè)務(wù)場(chǎng)景簡(jiǎn)歷投遞來(lái)說(shuō)明消息隊(duì)列為業(yè)務(wù)提供的支持

 

 

圖 1. 簡(jiǎn)歷投遞業(yè)務(wù)

當(dāng) C 端用戶發(fā)生一次簡(jiǎn)歷投遞的時(shí)候會(huì)先發(fā)送一條消息到消息隊(duì)列服務(wù)，C 端中臺(tái)、B 端中臺(tái)以及平臺(tái)級(jí)的基礎(chǔ)服務(wù)會(huì)從消息隊(duì)列消費(fèi)這條消息進(jìn)行自己的業(yè)務(wù)邏輯處理比如寫 DB、通知 B 端企業(yè)等，在這個(gè)場(chǎng)景中消息隊(duì)列為投遞業(yè)務(wù)提供了很好異步解耦支持，在高峰期的時(shí)候可以提供很好的削峰作用以保障各業(yè)務(wù)系統(tǒng)的穩(wěn)定運(yùn)行。

上面的這個(gè)場(chǎng)景是非常典型的工作隊(duì)列場(chǎng)景，在工作隊(duì)列中大多數(shù)是為了實(shí)現(xiàn)業(yè)務(wù)場(chǎng)景支持在線服務(wù)而設(shè)定的，往往具有以下特點(diǎn)：

♦ 一條消息會(huì)被多個(gè)業(yè)務(wù)方消費(fèi)
♦ 多個(gè)業(yè)務(wù)方之間廣播方式消費(fèi) (每個(gè)業(yè)務(wù)方消費(fèi)完整的一份數(shù)據(jù))
♦ 單個(gè)業(yè)務(wù)方采用集群消費(fèi)模式 (每個(gè) consumer 消費(fèi)部分?jǐn)?shù)據(jù))
♦ 每條消息都需要確保送達(dá)，消息隊(duì)列會(huì)采用重試的機(jī)制來(lái)保證這一點(diǎn)
♦ 重要業(yè)務(wù)消息需要提供跟蹤機(jī)制可以查詢整個(gè)消息的生命周期
♦ 還有一些業(yè)務(wù)的需求會(huì)使用到延時(shí)消息，定時(shí)消息等。

基于 RabbitMQ 的自研 MQService

RabbitMQ 作為一款非常成熟的消息隊(duì)列產(chǎn)品可以很好的應(yīng)對(duì)工作隊(duì)列的場(chǎng)景，當(dāng)然也有一些不足比如單隊(duì)列的擴(kuò)展能力、延時(shí)消息支持的不夠好等。我們?cè)?RabbitMQ 基礎(chǔ)上又做了一層抽象 (MQService)，將 RabbitMQ 看做一個(gè)消息服務(wù)的存儲(chǔ)節(jié)點(diǎn)來(lái)用，在 Zookeeper 中會(huì)記錄 Topic 的數(shù)據(jù)在 RabbitMQ 節(jié)點(diǎn)的分布并增加了容錯(cuò)的特性來(lái)保證存儲(chǔ)節(jié)點(diǎn)失敗的情況下可以持續(xù)提供消息寫入能力。在招聘旺季消息隊(duì)列每天約承載數(shù) 10 億的消息投遞。

MQService 整體結(jié)構(gòu)如下：

 

 

圖 2.MQService 架構(gòu)

用戶可以通過(guò) Thrift 協(xié)議、Http 協(xié)議、MQTT 來(lái)做消息的發(fā)送和消費(fèi)。用戶也可以注冊(cè) Http 回調(diào)接口來(lái)消費(fèi)消息。默認(rèn)的 Java 客戶端封裝了 Thrift 協(xié)議及 MQTT 的消息生產(chǎn)及消費(fèi)，其他語(yǔ)言并沒(méi)有封裝對(duì)應(yīng)的客戶端而是通過(guò) Http 協(xié)議進(jìn)行消息的生產(chǎn)和消費(fèi)，整體智聯(lián)招聘也是以 Java 做后臺(tái)服務(wù)為主。

接下來(lái)我們看一下通過(guò) zookeeper 維護(hù)的 Topic 與 RabbitMQ 分組以及 RabbitMQ 節(jié)點(diǎn)的關(guān)系。

 

 

每個(gè) Topic 都對(duì)對(duì)應(yīng)到一個(gè) Group，每個(gè) Group 下會(huì)掛一些 RabbitMQ 節(jié)點(diǎn)。當(dāng) producer 發(fā)送一條消息時(shí) MQService 會(huì)從緩存中拿到對(duì)應(yīng)這個(gè) Topic 可用的 RabbitMQ 節(jié)點(diǎn)的列表，MQService 會(huì)通過(guò)負(fù)載均衡策略選擇其中的一個(gè) RabbitMQ 節(jié)點(diǎn)進(jìn)行寫入，寫入失敗會(huì)重試下一個(gè)節(jié)點(diǎn)直到寫入成功。單個(gè)節(jié)點(diǎn)如果寫入失敗次數(shù)在一定時(shí)間內(nèi)達(dá)到一個(gè)特定值會(huì)觸發(fā)熔斷機(jī)制，單個(gè) RabbitMQ 節(jié)點(diǎn)在熔斷期間不對(duì)外提供寫入及查詢服務(wù)。

通過(guò)上面的介紹，大家應(yīng)該可以對(duì) MQService 有一個(gè)直觀的印象，這里不再詳細(xì)展開來(lái)介紹實(shí)現(xiàn)的細(xì)節(jié)。

以 Kafka 為中心的流批處理

首先 Kafka 在智聯(lián)有招聘有大規(guī)模的應(yīng)用，每天的數(shù)據(jù)傳輸量大約在數(shù)十 TB 量級(jí)，覆蓋的范圍包括 ELK、實(shí)時(shí)計(jì)算等。我們還是以計(jì)算每天不同時(shí)間端的投遞量為例子來(lái)介紹 Kakfa 在這個(gè)場(chǎng)景下的使用。

 

 

圖 3. 基于 Kafka 的 Streaming 模型

這是一個(gè)非常經(jīng)典的流式計(jì)算的架構(gòu)，通過(guò)采集業(yè)務(wù)日志入 Kafka，再通過(guò) Spark/Flink 之類的計(jì)算框架做計(jì)算工作。在計(jì)算投遞量的場(chǎng)景中，我們通過(guò)將計(jì)算結(jié)果按小時(shí)以及職位為維度將計(jì)算結(jié)果保存在 MySQL 中，也會(huì)將明細(xì)數(shù)據(jù)存儲(chǔ)在 Hive 中供離線計(jì)算使用。

那么很容易發(fā)現(xiàn)同一個(gè)業(yè)務(wù)場(chǎng)景但是數(shù)據(jù)來(lái)源是不一樣的，一個(gè)是業(yè)務(wù)方發(fā)送至 MQService 的一個(gè)是通過(guò) Logstash 采集業(yè)務(wù)端日志來(lái)做的，那么我們?nèi)绾蝸?lái)保證這兩份數(shù)據(jù)的一致性?即使不通過(guò)采集日志，業(yè)務(wù)方去雙寫又如何來(lái)保證一致性呢?這樣也給用戶帶來(lái)額外的負(fù)擔(dān)。

矛盾點(diǎn)在于 MQService 很難融入到流行的實(shí)時(shí)計(jì)算框架或者批處理框架，而 Kafka 也應(yīng)用在工作隊(duì)列模式下顯得有點(diǎn)力不從心。主要體現(xiàn)在 Kakfa 數(shù)據(jù)消費(fèi)的支持，Partition 數(shù)量與 Consumer 數(shù)量的綁定造成的 Partition 數(shù)量要跟著 consumer 的消費(fèi)能力決定，業(yè)務(wù)方處理數(shù)據(jù)很難保證一批數(shù)據(jù)都能夠成功處理，做 offset commit 的時(shí)候也是無(wú)法達(dá)到用戶的預(yù)期。這是基于產(chǎn)品在業(yè)務(wù)場(chǎng)景的匹配上而討論論的，就像 Kafka 介紹的那樣 (A distributed streaming platform)。

因此在 2018 年初時(shí)我們提出了通過(guò)一套方案來(lái)解決“工作隊(duì)列 + Streaming”的想法，也就是事件中心，期望事件中心可以承載智聯(lián)全業(yè)務(wù)線用戶行為、中臺(tái)以及后臺(tái)的業(yè)務(wù)事件傳遞。產(chǎn)品和業(yè)務(wù)系統(tǒng)在服務(wù)過(guò)程中會(huì)產(chǎn)生事件，事件是在先前定義好的，對(duì)于事件的生產(chǎn)方無(wú)需關(guān)心事件的消費(fèi)，只需要關(guān)心事件的格式定義以及事件的生產(chǎn)。事件的消費(fèi)方可以在事件中心去查閱自己想要的訂閱的事件來(lái)申請(qǐng)訂閱，甚至是數(shù)據(jù)產(chǎn)品也可以在事件中心去找找靈感。

這樣我們不需要關(guān)心兩個(gè)消息中間件數(shù)據(jù)的一致性問(wèn)題，一份數(shù)據(jù)就可以匹配“工作隊(duì)列 + Streaming”場(chǎng)景，對(duì)資源消耗、系統(tǒng)運(yùn)維都有很好的改善。

工作隊(duì)列 + Streaming 場(chǎng)景全新訴求

有了這個(gè)想法之后我們開始總結(jié)我們需要的是一個(gè)什么樣的產(chǎn)品，然后圍繞我們的需求去做設(shè)計(jì)工作和技術(shù)調(diào)研工作。我們總結(jié)了我們一些訴求如下：

容災(zāi)能力及一致性

數(shù)據(jù)做分布式存儲(chǔ)并且在分布式環(huán)境中要保證一致性。有一些重要的業(yè)務(wù)是依賴消息可靠性以及數(shù)據(jù)一致性的，所以在技術(shù)選型的時(shí)候如果在一個(gè)支持一致性的模型下去弱化一致性提升可用性是比較容易的，但是如果在一個(gè)沒(méi)有一致性模型的方案上去做一致性這將會(huì)需要一個(gè)很大的改動(dòng)。

單 Topic 擴(kuò)展能力

就像在 MQService 描述的那樣，同一個(gè) Topic 可以利用多個(gè)節(jié)點(diǎn)來(lái)做橫向擴(kuò)展。Kafka 在這一點(diǎn)做了很好的抽象 (Partition)。同一個(gè) Partition 的事件可以提供順序性消費(fèi)。

累計(jì)簽收與單條簽收

累計(jì)簽收主要應(yīng)用在 Streaming 場(chǎng)景下，而單條簽收可以很好的匹配工作隊(duì)列的場(chǎng)景，就像一次簡(jiǎn)歷投遞的業(yè)務(wù)處理，業(yè)務(wù)本身沒(méi)有順序性的要求，單條簽收可以很好的支持消費(fèi)者的消費(fèi)能力擴(kuò)展。而在累計(jì)簽收模式下單分區(qū)是要保證順序性的。

事件回溯能力

我們需要根據(jù)不同的事件來(lái)決定保留的時(shí)長(zhǎng)或大小，可以為一些想要拿到歷史事件的業(yè)務(wù)提供支持，我們也可以看到這也是 MQService(上文提到的) 薄弱的地方，MQService 是無(wú)法給用戶提供回溯能力的。

基于上面的一些主要的特性我們開始了技術(shù)選型的調(diào)研工作。經(jīng)過(guò)了一段時(shí)間的調(diào)研工作后，我們發(fā)現(xiàn)開源的消息中間件產(chǎn)品兼顧容災(zāi)能力和一致性的產(chǎn)品幾乎沒(méi)有，因此我們產(chǎn)生了一個(gè)想法，那就是基于一個(gè)強(qiáng)一致性的分布式日志存儲(chǔ)系統(tǒng)來(lái)做隊(duì)列功能的開發(fā)，期間也考慮過(guò)使用 Raft 協(xié)議 +Log 存儲(chǔ)，但是最終還是 Bookkeeper 吸引了我們的關(guān)注。Bookeeper 提供了開箱即用的 API，同時(shí)它在 Twitter、Hadoop 已經(jīng)有大規(guī)模應(yīng)用的場(chǎng)景，其穩(wěn)定性以及成熟度等都是可以保證的。因此我們?cè)诖蠹s 5 月份的時(shí)候已經(jīng)開始做基于 Bookkeeper 事件中心的一些設(shè)計(jì)工作，在接觸 Bookkeeper 社區(qū)的的時(shí)候才了解到 Apache Puslar，通過(guò)了一段時(shí)間對(duì) Apache Pulsar 的了解以及對(duì)社區(qū)活躍度的觀察，在 Apache Pulsar 社區(qū)小伙伴們的大力支持下，我們決定基于 Apache Pulsar 來(lái)搭建我們的事件中心。

為什么選擇 Apache Pulsar ?

Apache Pulsar 有很多特性在滿足事件中心需求的前提了還給了我們更多的驚喜，為更多的場(chǎng)景提供非常好的解決方案。

靈活的可用性和一致性選擇

在每個(gè) Topic 中由一系列的 Ledger 構(gòu)成，每個(gè) Ledger 有三個(gè)關(guān)鍵配置：

♦ Ensemble Size (E)
♦ Write Quorum Size (Qw)
♦ Ack Quorum Size (Qa)

Ensemble Size (E) 決定了 Pulsar 寫入 Ledger 可用的 Bookies 池的大小。

Write Quorum (Qw) 是 Pulsar 將要寫入的實(shí)際的 Bookies 數(shù)量�？梢缘扔诨蛘咝∮� E。

 

 

圖 4.E = 3 Qw = 3

當(dāng) Qw 小于 E 時(shí)，以條帶化的方式分配讀 / 寫即每個(gè) Bookie 只提供讀寫請(qǐng)求的子集。因此可以提升吞吐量，降低延遲。這也是提升單個(gè) Partition 吞吐能力的一個(gè)很好的方案，這也得益于基于 Segment 為物理單元的存儲(chǔ)設(shè)計(jì)。消息通過(guò) Robin 的方式寫入指定的 Bookie，在查詢消息是可以根據(jù) MessageId 取模即能獲得所在的 Bookie 列表。

 

 

圖 5.E = 5 Qw = 3

Ack Quorum (Qa) 是確認(rèn)寫入 Bookies 的數(shù)量，Pulsar Broker 將確認(rèn)發(fā)送給客戶端。為了一致性，Qa 應(yīng)該是：(Qw + 1) / 2 或者更大。

這個(gè)特性可以很好的讓我們?cè)诳捎眯院鸵恢滦陨先プ鲞x擇。

訂閱的抽象

單隊(duì)列的擴(kuò)展 Kafka 為我們做了很好的抽象，Apache Pulsar 也基本采用相同的思路。而對(duì)于訂閱的抽象，我們認(rèn)為 Apache Pulsar 再一次為我們做了很好的抽象，通過(guò) 3 種不同的訂閱方式來(lái)匹配不同的使用場(chǎng)景。

 

 

圖 6.Apache Pulsar 對(duì)訂閱的抽象

消息存儲(chǔ)在 Topic 中。邏輯上一個(gè) Topic 是日志結(jié)構(gòu)，每個(gè)消息都在這個(gè)日志結(jié)構(gòu)中有一個(gè)偏移量。Apache Pulsar 使用游標(biāo)來(lái)跟蹤偏移量。生產(chǎn)者將消息發(fā)送到一個(gè)指定的 Topic，Apache Pulsar 保證消息一旦被確認(rèn)就不會(huì)丟失 (正確的配置和非整個(gè)集群故障的情況下)。

消費(fèi)者通過(guò)訂閱來(lái)消費(fèi) Topic 中的消息。訂閱是游標(biāo) (跟蹤偏移量) 的邏輯實(shí)體，并且還根據(jù)不同的訂閱類型提供一些額外的保證

♦ Exclusive(獨(dú)享) - 一個(gè)訂閱只能有一個(gè)消息者消費(fèi)消息

♦ Shared(共享) - 一個(gè)訂閱中同時(shí)可以有多個(gè)消費(fèi)者，多個(gè)消費(fèi)者共享 Topic 中的消息

♦ Fail-Over(災(zāi)備) - 一個(gè)訂閱同時(shí)只有一個(gè)消費(fèi)者，可以有多個(gè)備份消費(fèi)者。一旦主消費(fèi)者故障則備份消費(fèi)者接管。不會(huì)出現(xiàn)同時(shí)有兩個(gè)活躍的消費(fèi)者。

一個(gè) Topic 可以添加多個(gè)訂閱。訂閱不包含消息的數(shù)據(jù)，只包含元數(shù)據(jù)和游標(biāo)。

Apache Pulsar 通過(guò)允許消費(fèi)者將 Topic 看做在消費(fèi)者消費(fèi)確認(rèn)后刪除消息的隊(duì)列，或者消費(fèi)者可以根據(jù)游標(biāo)的回放來(lái)提供隊(duì)列和日志的語(yǔ)義。在底層都使用日志作為存儲(chǔ)模型。

這為我們通過(guò)一套系統(tǒng)支持工作隊(duì)列和 Streaming 的訴求提供了很好的支持，在工作隊(duì)列場(chǎng)景我們使用 share 模式，在 Streaming 模式我們使用 Failover 或者 Exclusive。我們只需要一份數(shù)據(jù)就可以同時(shí)支持兩種場(chǎng)景。

更好的 IO 和存儲(chǔ)設(shè)計(jì)

當(dāng)在 Bookie 上寫入數(shù)據(jù)時(shí)，首先將該消息寫入日志文件，這是一個(gè)預(yù)寫日志 (WAL), 它可以幫助 Bookkeeper 在發(fā)生故障時(shí)避免數(shù)據(jù)丟失。它與關(guān)系型數(shù)據(jù)庫(kù)持久化保證的機(jī)制相同。

寫入預(yù)寫日志的操作完成后會(huì)將數(shù)據(jù)放入緩存。寫入的緩存會(huì)在內(nèi)存中做積累并定期進(jìn)行排序和刷盤。對(duì)寫入進(jìn)行排序以便將同一 Ledger 的條目放在一起，從而提高讀取性能。如果條目以嚴(yán)格的時(shí)間順序?qū)懭�，在讀取時(shí)無(wú)法利用磁盤的高效順序操作

Bookkeeper 容許將磁盤 IO 做讀寫分離。寫入都按順序?qū)懭肴罩疚募�可以存�?chǔ)在專用的磁盤上，并且可以批量刷盤以獲得搞得吞吐量。除此之外從寫入操作來(lái)看沒(méi)有其他的同步磁盤 IO 操作，數(shù)據(jù)都是寫入到內(nèi)存的緩存區(qū)。

寫緩存通過(guò)異步的方式批量將條目寫入到日志文件和 RocksDB，因此，一個(gè)磁盤用于同步寫入日志文件，另一個(gè)磁盤用于異步寫入數(shù)據(jù)和讀取操作，

 

 

圖 7.Apache Pulsar 的 IO 及存儲(chǔ)設(shè)計(jì)

在存儲(chǔ)設(shè)計(jì)上 Bookkeeper 以 Segment 為中心設(shè)計(jì)對(duì)系統(tǒng)擴(kuò)容、冷熱數(shù)據(jù)分離提供了很好的支持。在擴(kuò)容方面通過(guò)增加 Bookie 節(jié)點(diǎn)就可以分擔(dān)整個(gè)集群的存儲(chǔ)壓力，在冷熱數(shù)據(jù)分離方面通過(guò)將 Segment 搬遷至二級(jí)存儲(chǔ)如 S3、OSS 等更廉價(jià)的存儲(chǔ)設(shè)備中，支持在線業(yè)務(wù)往往使用 SSD 來(lái)做存儲(chǔ)。因此我們可以兼顧熱數(shù)據(jù)的高性能與冷數(shù)據(jù)的大空間存儲(chǔ)。

 

 

圖 8.Bookie 擴(kuò)容

 

 

圖 9. 冷數(shù)據(jù)搬遷

在 IO 和存儲(chǔ)設(shè)計(jì)上以及 Offload 的特性給了我們更多的驚喜，可以更好的為我們?cè)诓挥绊懺诰�業(yè)務(wù)的支持上兼顧大量事件存儲(chǔ)需求的痛點(diǎn)，大大的降低了冷數(shù)據(jù)的存儲(chǔ)成本。我們計(jì)劃將冷數(shù)據(jù)存儲(chǔ)至 OSS。

上面挑選了 Apache Pulsar 非常核心的 3 個(gè) messaging 特性來(lái)做介紹，這與事件中心的初衷是非常匹配的，然而 Apache Pulsar 遠(yuǎn)不止這些，有完善的多租戶特性提供 Topic 的分層次管理，多種 Schema 的支持為數(shù)據(jù)校驗(yàn)、序列化提供更便捷的方式，輕量級(jí)的 Pulsar Function 以及 Pulsar SQL 都是非常值得去探索的特性，這里就不一一展開介紹了。

Apache Pulsar 在智聯(lián)招聘的落地實(shí)踐

下面將介紹 Apache Pulsar 在智聯(lián)招聘落地過(guò)程中的一些實(shí)踐

為 Namespace 設(shè)置合理的 Backlog Quota

Pulsar 為我們提供了 Backlog 的機(jī)制能夠記錄每個(gè) Subscription 的消費(fèi)狀況。也提供了 Backlog Quota 的設(shè)置，主要可以設(shè)置 Backlog 大小以及達(dá)到閾值時(shí)的控制策略。

Backlog Quota 的控制策略有 3 種：

♦ producer_request_hold
♦ producer_exception
♦ consumer_backlog_eviction

producer_request_hold 作為默認(rèn)配置，在達(dá)到 Backlog 設(shè)置的大小閾值后會(huì) block producer 發(fā)消息操作，這個(gè)配置不適合用于消息發(fā)送方是在線業(yè)務(wù)的使用場(chǎng)景。

producer_exception 在達(dá)到 Backlog 設(shè)置的大小閾值后，producer 會(huì)快速失敗。

consumer_backlog_eviction 在達(dá)到 Backlog 設(shè)置的大小閾值后會(huì)將 subscription 未簽收的頭部數(shù)據(jù)逐出，可以理解為自動(dòng)簽收。其實(shí)這個(gè)和 producer_exception 的區(qū)別在于 producer_exception 對(duì)于訂閱方將會(huì)丟失尾部數(shù)據(jù)，而 consumer_backlog_eviction 是丟失頭部數(shù)據(jù)。

我們大部分使用 consumer_backlog_eviction 策略。目前 Pulsar 支持在 namespace 級(jí)別設(shè)置這個(gè)策略，在 2.2.0 版本可以在 broker.conf 文件修改全局策略。將 Backlog 作為一個(gè)重點(diǎn)的監(jiān)控項(xiàng)監(jiān)控起來(lái)也是非常有必要的，后面會(huì)說(shuō)到這部分。

增加 MaxProducersPerTopic 限制

防止錯(cuò)誤或者惡意的 Client 使用造成 Broker 維持大量的 Producer 對(duì)象。Broker 默認(rèn)的配置是不限制的，增加限制可以提升 Pulsar Cluster 的安全性。

Pulsar 提供兩種方式來(lái)設(shè)定 MaxProducerPerTopic
broker.conf 中設(shè)置 maxProducersPerTopic
通過(guò)./pulsar-admin namespaces set-max-producers-per-topic -p

目前我們?cè)?broker.conf 中的 maxProducersPerTopic = 10000，如果 namespace 有個(gè)性需求的話通過(guò) ./pulsar-admin namespaces set-max-producers-per-topic -p 設(shè)置。

Apache Pulsar 監(jiān)控與報(bào)警

Pulsar 提供豐富的 Prometheus 指標(biāo)信息輸出，我們可以這些指標(biāo)信息來(lái)做好 Pulsar 的監(jiān)控報(bào)警。Pulsar 的客戶端也記錄了豐富的指標(biāo)，我們做了一個(gè) client 的擴(kuò)展包將 client 的節(jié)點(diǎn)信息記錄在 Zookeeper 中，由 Prometheus 自動(dòng)發(fā)現(xiàn)，這樣 Client 端的指標(biāo)信息由 Prometheus 采集。

配合 Grafana 的監(jiān)控展示，實(shí)時(shí)了解集群的狀態(tài)

 

 

圖 10. 集群狀態(tài)看板 -1

 

 

圖 11. 集群狀態(tài)看板 -2

 

 

圖 12. 分 Namespace 狀態(tài)展示

報(bào)警規(guī)則配置：

♦ Client 發(fā)送失敗次數(shù)
♦ Backlog 超閾值
♦ Rates/Network 超閾值
♦ Client > 50ms 延遲
♦ Broker > 50ms 延遲
♦ Storage Size 超閾值

Pulsar 多集群流量切換

為了避免集群整體不可用，我們通過(guò) Zookeeper 控制 Client 的連接串。基于 Pulsar Client 的 Service URL Provider 基礎(chǔ)上做的二次開發(fā)。在 Zookeeper 中存儲(chǔ)的 Pulsar 連接串改變的時(shí)候，Client 會(huì)自動(dòng)斷掉當(dāng)前的連接并重新與新的 Pulsar 地址進(jìn)行連接。

為重要業(yè)務(wù)提供消息鏈路追蹤

我們基于 Pulsar Client 的 Interceptor 接口以及 Zipkin 進(jìn)行二次開發(fā)，為了實(shí)現(xiàn)消息的鏈路跟蹤。消息鏈路跟蹤的方案是通過(guò)日志采集統(tǒng)一入 Hbase。每條消息都具備消息鏈路跟蹤成本是昂貴的，并不適用于所有的場(chǎng)景，更適應(yīng)與一些比較重要切消息量不太大的場(chǎng)景，當(dāng)然這個(gè)根據(jù)不同的業(yè)務(wù)而定。

總結(jié)

我們通過(guò)介紹之前的消息中間件在智聯(lián)招聘的應(yīng)用情況來(lái)說(shuō)明我們的痛點(diǎn)所在，我們計(jì)劃打造一個(gè)可以解決當(dāng)下痛點(diǎn)的產(chǎn)品來(lái)支撐智聯(lián)招聘的業(yè)務(wù)。我們通過(guò)一段時(shí)間的技術(shù)選型工作后最終選擇了 Apache Pulsar 作為我們的搭建企業(yè)級(jí)事件中心的基礎(chǔ)。

截止目前事件中心接入的事件種類約 100 個(gè)，每天產(chǎn)生 5 億事件量。部分業(yè)務(wù)通過(guò)灰度的方式接入，計(jì)劃在 11 月底能夠接入 20 億事件量 / 日。

智聯(lián)招聘也在持續(xù)為 Apache Pulsar 社區(qū)貢獻(xiàn)新的特性比如 Dead Letter Topic， Client Interceptors 等，智聯(lián)招聘有很多業(yè)務(wù)場(chǎng)景也非常依賴延時(shí)消息特性，后面我們也會(huì)在 Pulsar 上貢獻(xiàn)此特性。

感謝 Apache Pulsar 社區(qū)小伙伴們?cè)陧?xiàng)目落地過(guò)程中的技術(shù)支持。

標(biāo)簽： Mysql ssd 安全 數(shù)據(jù)庫(kù)

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請(qǐng)聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請(qǐng)與原作者聯(lián)系。