前言
写这篇文章的起因是由于之前的一篇关于Kafka
异常消费,当时为了解决问题不得不使用临时的方案。
总结起来归根结底还是对Kafka不熟悉导致的,加上平时工作的需要,之后就花些时间看了Kafka
相关的资料。
何时使用MQ
谈到Kafka
就不得不提到MQ,是属于消息队列的一种。作为一种基础中间件在互联网项目中有着大量的使用。
一种技术的产生自然是为了解决某种需求,通常来说是以下场景:
- 需要跨进程通信:B系统需要A系统的输出作为输入参数。
- 当A系统的输出能力远远大于B系统的处理能力。
针对于第一种情况有两种方案:
- 使用
RPC
远程调用,A直接调用B。 - 使用
MQ
,A发布消息到MQ
,B订阅该消息。
当我们的需求是:A调用B实时响应,并且实时关心响应结果则使用RPC
,这种情况就得使用同步调用。
反之当我们并不关心调用之后的执行结果,并且有可能被调用方的执行非常耗时,这种情况就非常适合用MQ
来达到异步调用目的。
比如常见的登录场景就只能用同步调用的方式,因为这个过程需要实时的响应结果,总不能在用户点了登录之后排除网络原因之外再额外的等几秒吧。
但类似于用户登录需要奖励积分的情况则使用MQ
会更好,因为登录并不关系积分的情况,只需要发个消息到MQ
,处理积分的服务订阅处理即可,这样还可以解决积分系统故障带来的雪崩效应。
MQ
还有一个基础功能则是限流削峰,这对于大流量的场景如果将请求直接调用到B系统则非常有可能使B系统出现不可用的情况。这种场景就非常适合将请求放入MQ
,不但可以利用MQ
削峰还尽可能的保证系统的高可用。
Kafka简介
本次重点讨论下Kafka
。
简单来说Kafka
是一个支持水平扩展,高吞吐率的分布式消息系统。
Kafka
的常用知识:
Topic
:生产者和消费者的交互都是围绕着一个Topic
进行的,通常来说是由业务来进行区分,由生产消费者协商之后进行创建。Partition
(分区):是Topic
下的组成,通常一个Topic
下有一个或多个分区,消息生产之后会按照一定的算法负载到每个分区,所以分区也是Kafka
性能的关键。当发现性能不高时便可考虑新增分区。
结构图如下:
创建Topic
Kafka
的安装官网有非常详细的讲解。这里谈一下在日常开发中常见的一些操作,比如创建Topic
:
|
|
创建了三个分区的test
主题。
使用
|
|
可以列出所有的Topic
。
Kafka生产者
使用kafka
官方所提供的Java API
来进行消息生产,实际使用中编码实现更为常用:
|
|
再配合以下启动参数即可发送消息:
以及生产者的配置文件:
具体的配置说明详见此处:https://kafka.apache.org/0100/documentation.html#theproducer
流程非常简单,其实就是一些API
的调用。
消息发完之后可以通过以下命令查看队列内的情况:
其中的lag
便是队列里的消息数量。
Kafka消费者
有了生产者自然也少不了消费者,这里首先针对单线程消费:
|
|
配合以下启动参数:
其中采用了轮询的方式获取消息,并且记录了消费过程中的数据。
消费者采用的配置:
为了简便我采用的是自动提交offset
。
消息存放机制
谈到offset
就必须得谈谈Kafka的消息存放机制.
Kafka
的消息不会因为消费了就会立即删除,所有的消息都会持久化到日志文件,并配置有过期时间,到了时间会自动删除过期数据,并且不会管其中的数据是否被消费过。
由于这样的机制就必须的有一个标志来表明哪些数据已经被消费过了,offset(偏移量)
就是这样的作用,它类似于指针指向某个数据,当消费之后offset
就会线性的向前移动,这样一来的话消息是可以被任意消费的,只要我们修改offset
的值即可。
消费过程中还有一个值得注意的是:
同一个consumer group(group.id相等)下只能有一个消费者可以消费,这个刚开始确实会让很多人踩坑。
多线程消费
针对于单线程消费实现起来自然是比较简单,但是效率也是要大打折扣的。
为此我做了一个测试,使用之前的单线程消费120009条数据的结果如下:
总共花了12450毫秒。
那么换成多线程消费怎么实现呢?
我们可以利用partition
的分区特性来提高消费能力,单线程的时候等于是一个线程要把所有分区里的数据都消费一遍,如果换成多线程就可以让一个线程只消费一个分区,这样效率自然就提高了,所以线程数coreSize<=partition
。
首先来看下入口:
|
|
其中的ConsumerGroup
类:
最后真正的执行逻辑ConsumerCallable
:
理一下逻辑:
其实就是初始化出三个消费者实例,用于三个线程消费。其中加入了一些统计,最后也是消费120009条数据结果如下。
由于是并行运行,可见消费120009条数据可以提高2秒左右,当数据以更高的数量级提升后效果会更加明显。
但这也有一些弊端:
- 灵活度不高,当分区数量变更之后不能自适应调整。
- 消费逻辑和处理逻辑在同一个线程,如果处理逻辑较为复杂会影响效率,耦合也较高。当然这个处理逻辑可以再通过一个内部队列发出去由另外的程序来处理也是可以的。
总结
Kafka
的知识点还是较多,Kafka
的使用也远不这些。之后会继续分享一些关于Kafka
监控等相关内容。
项目地址:https://github.com/crossoverJie/SSM.git
个人博客:http://crossoverjie.top。