Kafka为什么⽐RocketMQ的吞吐量要⾼

用心去追梦

于 2024-01-13 10:20:56 发布

阅读量560

点赞数 7

文章标签： kafka rocketmq 分布式

本文链接：https://blog.csdn.net/qq_33240556/article/details/135566498

版权

本文介绍了Kafka生产者采用异步发送机制提高性能但可能导致消息丢失的问题，重点讨论了配置参数如acks和batch-size对性能和可靠性的影响。同时，对比了Kafka与RocketMQ的底层实现原理，强调了磁盘顺序读写和数据传输零拷贝在高性能中的作用。

摘要由CSDN通过智能技术生成

Kafka的⽣产者采⽤的是异步发送消息机制，当发送⼀条消息时，消息并没有发送到Broker⽽是缓存起来，然后直接向业务返回成功，当缓存的消息达到⼀定数量时再批量发送给Broker。
这种做法减少了⽹络io，从⽽提⾼了消息发送的吞吐量，但是如果消息⽣产者宕机，会导致消息丢失，业务出错，所以理论上kafka利⽤此机制提⾼了性能却降低了可靠性。
Kafka配置⽂件：

server:
2	port: 8080
3
4	spring:
5	kafka:
6	bootstrap-servers: 192.168.106.131:9092,192.168.106.131:9093,192.168.1
06.131:9094
7	producer: # ⽣产者
8	#retries(设置重试次数)
9	#retries参数的值决定了⽣产者可以重发消息的次数，
10	#如果达到这个次数，⽣产者会放弃重试返回错误
11	retries: 3
12
13	#设置发送消息到本地缓冲区，如果设置了该缓冲区，
14	#消息会先发送到本地缓冲区，可以提⾼消息发送性能，
15	#默认值是33554432，即32MB
16	buffer-memory: 33554432
17
18	#kafka本地线程会从缓冲区取数据，批量发送到broker，
19	#设置批量发送消息的⼤⼩，默认值是16384，即16kb，
20	#就是说⼀个batch满了16kb就发送出去
21	batch-size: 16384
22
23	#发出消息持久化机制参数
24		#（1）acks=0： 表示producer不需要等待任何broker确认收到消息的回复，就可以继续发送下⼀条消息。性能最⾼，但是最容易丢消息。
25		#（2）acks=1： 默认--⾄少要等待leader已经成功将数据写⼊本地log，但是不需要等待所有follower是否成功写⼊。就可以继续发送下⼀
26		#条消息。这种情况下，如果follower没有成功备份数据，⽽此时leader⼜挂掉，则消息会丢失。
27		#（3）acks=-1或all： 需要等待 min.insync.replicas(默认为1，推荐配置⼤于等于2) 这个参数配置的副本个数都成功写⼊⽇志，这种策略会保证
28	#只要有⼀个备份存活就不会丢失数据。这是最强的数据保证。⼀般除⾮是⾦融级别，或跟钱
打交道的场景才会使⽤这种配置
。


29	acks: 1
 
30
31
er
32
izer
33
 
# 指定消息key和消息体的编解码⽅式
key-serializer: org.apache.kafka.common.serialization.StringSerializ value-serializer: org.apache.kafka.common.serialization.StringSerial
 
34	#消费组
35	consumer:
36	#消费分组名
37	group-id: default-group
 
38
39	#是否⾃动提交offset，默认就是true
40	enable-auto-commit: true
41
42	#latest(默认) ：只消费⾃⼰启动之后发送到主题的消息
43	#earliest：第⼀次从头开始消费，以后按照消费offset记录继续消费
44	auto-offset-reset: earliest
45
46	# 指定消息key和消息体的编解码⽅式
47	key-deserializer: org.apache.kafka.common.serialization.StringDeseri
alizer
48	value-deserializer: org.apache.kafka.common.serialization.StringDese
49	rializer
50	listener:
51	ack-mode: COUNT
52	#ack-mode: BATCH
53	#⾃动提交设置：
54
55	#RECORD：每处理⼀条commit⼀次
56	#BATCH(默认)：每次poll的时候批量提交⼀次，频率取决于每次poll的调⽤频率
57		#TIME ：达到⼀定时间间隔后，⾃动提交, 并不是⼀到就⽴⻢提交，如果此时正在消费某⼀条消息，需要等这条消息被消费完成，才能提交消费进度
58	#COUNT：消费成功的消息数到达⼀定数量后，⾃动提交  ，它并不是⼀到就⽴⻢提交，如果
此时正在消费某⼀条消息，需要等这条消息被消费完成，才能提交消费进度
59
60	#COUNT_TIME： TIME 和 COUNT 的结合体，满⾜任⼀都会⾃动提交。
61	#⼿⼯提交设置
62	#MANUAL：当每⼀批poll()的数据被消费者监听器（ListenerConsumer）处理之后,
63	#⼿动调⽤Acknowledgment.acknowledge()后提交
64	#MANUAL_IMMEDIATE：⼿动调⽤Acknowledgment.acknowledge()后⽴即提交
65
66	#由此可知，在设置为⼿动提交时，我们需要设置MANUAL或MANUAL_IMMEDIATE。
67	#ack-mode: MANUAL_IMMEDIATE