搜狗開源框架發(fā)布純自研C++ Kafka客戶端

作者：佚名 2020-12-28 14:36:03

企業(yè)動態(tài)

Kafka 一個fetch消息的任務(wù)由一組任務(wù)組成，其中包括獲取Kafka Broker的Meta任務(wù)、一系列的消費(fèi)者組相關(guān)的任務(wù)、獲取offset的任務(wù)和真正的拉取消息的任務(wù)。

 　　搜狗于今年7月發(fā)布了C++異步調(diào)度服務(wù)器引擎——Workflow，除了計(jì)算通信融為一體的高性能特點(diǎn)以外，還集成了多種常用的網(wǎng)絡(luò)協(xié)議，包括：Http、Redis、MySQL，所有協(xié)議都是純自研自解析，無需依賴第三方庫，而具體協(xié)議所對應(yīng)的資源復(fù)用和線程調(diào)度等都由Workflow以統(tǒng)一的方式去進(jìn)行管理，目前獲得了越來越多開發(fā)者的青睞和肯定。而最近，Workflow又支持并發(fā)布了一項(xiàng)復(fù)雜的通用網(wǎng)絡(luò)協(xié)議：Kafka，使得所有使用Workflow及其生態(tài)項(xiàng)目的開發(fā)者都可以通過統(tǒng)一而簡便的方式與Kafka交互，這也是業(yè)內(nèi)唯一一款使用C++語言實(shí)現(xiàn)的Kafka客戶端，值引得開源社區(qū)開發(fā)者們的關(guān)注。

　　一、開發(fā)背景

　　在Workflow發(fā)布Kafka客戶端之前，業(yè)內(nèi)用得比較多的是librdkafka，但這個純C的kafka客戶端有許多不足，以下是我們原先使用時遇到的部分問題：

　　1、線程資源和網(wǎng)絡(luò)資源消耗比較多

　　2、接口設(shè)計(jì)比較復(fù)雜臃腫，使用成本比較高

　　3、Kafka版本兼容性不是很好

　　4、消耗資源高，但是性能卻不高

　　5、broker主從切換低版本出現(xiàn)服務(wù)hang住情況，高版本偶發(fā)丟數(shù)據(jù)問題

　　6、異步同步偶發(fā)出現(xiàn)丟數(shù)據(jù)情況

　　針對這些問題，更好的替代方案是Workflow的Kafka客戶端：https://github.com/sogou/workflow

　　由于實(shí)現(xiàn)在Workflow的基礎(chǔ)上，作為Kafka客戶端即具有超高性能、超大吞吐和極省的資源占用等特點(diǎn)，且和其他協(xié)議的接口一樣，此Kafka客戶端還具有接口清晰，代碼可讀性強(qiáng)等優(yōu)點(diǎn)，不僅節(jié)省機(jī)器成本還節(jié)省人力維護(hù)成本，非常值得一試。

　　二、新一代高性能C++ Kafka客戶端

　　Workflow的Kafka客戶端使用接口非常簡潔，首先需要創(chuàng)建一個client對象：

　　

　　其他使用方式與框架內(nèi)的其他任務(wù)無異，使用Workflow的同學(xué)可以瞬間上手：

　　

　　為什么Workflow的Kafka客戶端能有以上的優(yōu)點(diǎn)呢?主要得益于以下三方面的細(xì)節(jié)：

　　一. 內(nèi)部基于Workflow的任務(wù)流實(shí)現(xiàn)。Workflow的核心設(shè)計(jì)理念是將任務(wù)抽象成"任務(wù)流"的概念，這樣一個任意復(fù)雜的任務(wù)可以拆分成若干個并行任務(wù)流和串行任務(wù)流，它們之間通過串聯(lián)、并聯(lián)等方式組成一個或者多個串并聯(lián)圖，然后由Workflow內(nèi)部的引擎高效異步地執(zhí)行。

　　以Kafka協(xié)議的fetch消息為例，下圖是執(zhí)行過程中任務(wù)流的串并聯(lián)圖：

　　

　　一個fetch消息的任務(wù)由一組任務(wù)組成，其中包括獲取Kafka Broker的Meta任務(wù)、一系列的消費(fèi)者組相關(guān)的任務(wù)、獲取offset的任務(wù)和真正的拉取消息的任務(wù)。前面的多個任務(wù)由于有依賴關(guān)系，所以組成串聯(lián)任務(wù);而最終拉取消息的任務(wù)和Broker的個數(shù)有關(guān)，因此可以將它轉(zhuǎn)換成一個broker數(shù)目相同的并行任務(wù)。這樣做一方面可以使得邏輯很清晰，同時也可以保證執(zhí)行的高效性。

　　二. 連接復(fù)用。傳統(tǒng)的網(wǎng)絡(luò)通信往往是在程序初始化的時候，創(chuàng)建大規(guī)模連接池來提高網(wǎng)絡(luò)吞吐，這么做的一個弊端是系統(tǒng)資源占用過多，會導(dǎo)致降低程序的魯棒性。而目前這個Kafka客戶端由于內(nèi)部是基于Workflow框架，Workflow對連接的管理做了很多優(yōu)化，可以在保證高效高吞吐的同時，將資源控制在一個合理的范圍內(nèi)。

　　三.內(nèi)存管理。為了方便用戶的使用，內(nèi)部的所有對象都基于計(jì)數(shù)實(shí)現(xiàn)，通過工廠方法創(chuàng)建任務(wù)后，在回調(diào)函數(shù)中實(shí)現(xiàn)處理邏輯即可。內(nèi)存的分配和釋放都是框架自動完成，全程無需手動操作任務(wù)級別的內(nèi)存，非常方便;同時它的邏輯又是完備自洽的，保證了高效可靠。

　　三、插件式發(fā)布，與Workflow完美融合

　　基于Workflow精巧的層次結(jié)構(gòu)，Kafka協(xié)議是以插件式發(fā)布的，即無需安裝Kafka的用戶不會把Kafka相關(guān)代碼編譯進(jìn)去，由此可以看出Workflow本身的架構(gòu)解耦和模塊對稱性都做得非常優(yōu)秀。

　　而Kafka的協(xié)議由于需要多次交互，Workflow復(fù)合任務(wù)又天生支持內(nèi)部交互的隱藏，使得整體使用上對用戶非常簡潔透明?；诙壒S模式也可以把許多全局信息統(tǒng)一管理到內(nèi)存中，也是工程上結(jié)合的一大亮點(diǎn)。

　　可以說，Kafka協(xié)議與Workflow的融合相當(dāng)完美，且目前在搜狗已經(jīng)大規(guī)模使用，經(jīng)得住工業(yè)級檢索系統(tǒng)大規(guī)模請求的實(shí)際考驗(yàn)，歡迎業(yè)內(nèi)需要的開發(fā)同學(xué)積極嘗試并與我們熱心的開發(fā)小組進(jìn)行技術(shù)交流。

文章標(biāo)題：搜狗開源框架發(fā)布純自研C++Kafka客戶端
URL地址：http://m.5511xx.com/article/dpddocc.html