kafka中producer的设计与实现

由来:作为应用程序开发者,初期大量的时间花在堆砌代码上,如果想要提升整个团队的生产效率,最直观的想法就是要避免大量的重复开发和程序中的冗余代码。相信很多程序员都看多《Clean Code》或者《重构》,里面对于细节的讲述都会令初学者惊叹。但是这很难从书中获取到对于整体软件架构的深入理解,大部分程序员只能学到一些小trick。

牢骚:个人的观点,做出优美的程序固然重要,但工作中会发现很多团队在代码的小细节上过于纠结。举几个例子:

变量命名,一定要有实际意义,方便维护(排除用abc命名的情况),因为语感的差别,对于一个变量的命名有很多种,这里很多个人感觉良好的程序员会说在review时过于纠结单词的意义和顺序(实际情况,底线是可理解即可,对于工作节奏很快的公司来说,reviewer的这个纠结完全是bull shit)

函数的拆分问题,看过《重构》的肯定是见到大函数就气不打一处来,但请设计过很多系统的软件结构后再回头看自己的纠结是否有必要,设计模式、重构 bala bala bala... 不是不重要,就像吞吐量和延时不能兼顾一样,在满足项目快速向前走的同时,底线是可读,良好的封装(如果两个迥然不同的逻辑你能封装到一起,那不什么也不想说了)

Cut the bull shit,接下来就说下kafka中producer设计方法...

麻雀虽小,五脏俱全,kafka项目并不是很巨大,但是在封装服务时,producer有很多可以借鉴的地方,这里主要说软件架构。

主要描述软件架构的原因,producer的主要目的是为客户端封装访问kafka broker的复杂逻辑。之先说下最简单的封装,socket连接broker,然后发送string即可。但这样对于一个生产环境的项目来说可能就不够用了。生产环境的项目需要在统计、log、性能、feature等方面给维护的程序员提供便利,防止bug、网络问题、服务器性能等导致的错误被吞掉。下面从几个方面介绍producer的设计:

1 配置,几乎所有服务器端提供服务的组件,都采用文件方式为用户提供修改配置的渠道。producer中对应文件建立一个ProducerConfig(配置信息的抽象)提供程序的可维护性。producer的配置主要集中在一下几个方面:

  • message是否有压缩,例如utf-8
  • partition规则,允许用户自定义
  • queue buffer的大小,网络请求time out
  • batch,用户可以在吞吐量和延时之间做一定的取舍

2 维护多个producer的pool,client可能对多个broker发送message,这个pool包含了对并发的处理

3 sync和async两种发送方式的支持,sync使程序设计简单,async优化程序性能,但维护的代价相应的提高(优化性能的主要方式,异步后利用buffer queue减少i/o)

4 ack机制,主要有3种(立即返回、leader broker收到后返回,cluster收到后返回-强一致)。例如:client如果是log收集,那么低延时、可丢失的特性,可以要求broker立即返回

总体描述:
producer的软件结构非常清晰,各功能点封装在单独的文件中增加可读性。
在配置部分的设计引入继承结构细化配置的类型
统计部分的设计有一个点需要关注,不同类型的统计单独封装对象,且统计逻辑散布在业务逻辑中,并没有aop这种程度的优化,当然aop有统计范围的局限性
利用LinkedBlockingQueue设计buffer queue,和raven一样,这个数据结构在很多相似的场景都有使用

client服务封装看似简单,但具备这个基本功的程序员很少,不是过于注重细节忽略整体,就是追求速度难以维护。

kafka中producer的设计与实现
Share this