<<微信开源PhxQueue：高可用、高可靠、高性能的分布式队列>>的几个问题

[nereuschen]

关于这篇文章，我有几个疑问：

1.测试结果表格里面的kafka同步刷盘和异步刷盘，我认为不准确，会误导用户，因为同步刷盘意味着log.flush.interval.messages=1.而我的理解是文中想表达的是kafka消息同步复制和消息异步复制，即acks=-1和acks=1。因为producer的send()已经是异步发送消息了。

2.关于一些配置数据，我想了解一下
（1）开启 Producer Batch，batch.size设置的多大？
（2）使用的是哪个版本的kafka? 0.11.0?
（3）基准测试中修改了哪些kafka的server默认配置参数？

3.ISR VS Paxos ,采用ISR而不采用Paxos，kafka当初设计时考虑到，如果采用Paxos，集群中如果容忍2个节点不可用，需要部署5个节点，而ISR只用部署3个节点
文章说同步延时取决于最慢的节点，这个我的理解是kafka从0.8.2版本引入min.insync.replicas，主要是平衡可靠性和吞吐量，根据文中的设置参数min.insync.replicas=2，意味着3个节点中只要有2个消息复制成功，就返回ack，而不是取决于最慢的节点

4.感觉这篇文章不是一个人写的，因为有些概念不一致，尤其是kafka的一些新特性是在不同版本中才具备的，文中出现不一致的情况，比如我提到的第三个问题

[chaozh]

刚想问差不多的问题！期待官方解答

[unixliang]

@nereuschen @chaozh 你好，我来解答一下哈

---

1.测试结果表格里面的kafka同步刷盘和异步刷盘，我认为不准确，会误导用户，因为同步刷盘意味着log.flush.interval.messages=1.而我的理解是文中想表达的是kafka消息同步复制和消息异步复制，即acks=-1和acks=1。因为producer的send()已经是异步发送消息了。

	入队 QPS（w/s）	平均耗时（ms）
PhxQueue（同步刷盘）	18	90
Kafka（异步刷盘）	18	120
Kafka（同步刷盘）	9	290

表格里所对比的，确实是Kafka的同步刷盘和异步刷盘，区别在于有没有log.flush.interval.messages=1。

另外，文中关于 Kafka 的测试，都是同步复制，并没有测试异步复制。
因为测试所针对的场景是：

• 少数派节点离线后整体仍可用；
• 数据不丢。
  而异步复制并不能满足该场景。

所以文中所有关于 Kafka 的测试，都有如下配置：

replication.factor=3
min.insync.replicas=2
request.required.acks=-1

这也是 Kafka 文档里推荐的配置，详见min.insync.replicas配置项的解析：

When used together, min.insync.replicas and acks allow you to enforce greater durability guarantees. A typical scenario would be to create a topic with a replication factor of 3, set min.insync.replicas to 2, and produce with acks of "all". This will ensure that the producer raises an exception if a majority of replicas do not receive a write.

---

2.关于一些配置数据，我想了解一下
（1）开启 Producer Batch，batch.size设置的多大？
（2）使用的是哪个版本的kafka? 0.11.0?
（3）基准测试中修改了哪些kafka的server默认配置参数？

1. batch.size使用的是默认配置，默认值是16384。
2. Kafka 版本号是0.11.0.0。
3. 我们在测试过程中只修改了如下几项配置，其余配置均使用默认值：

# 配置平衡可用性和数据可靠性
replication.factor=3
min.insync.replicas=2
request.required.acks=-1

# 提高 Kafka 副本同步效率，默认值为 1
num.replica.fetchers=6

# 同步刷盘开关，测同步刷盘时值为 1，测异步刷盘时使用默认值
log.flush.interval.messages=1

---

3.ISR VS Paxos ,采用ISR而不采用Paxos，kafka当初设计时考虑到，如果采用Paxos，集群中如果容忍2个节点不可用，需要部署5个节点，而ISR只用部署3个节点

replication.factor=3
min.insync.replicas=2
request.required.acks=-1

Kafka 在这种配置下，3节点部署，若2个节点不可用，整体就不可用了。

---

文章说同步延时取决于最慢的节点，这个我的理解是kafka从0.8.2版本引入min.insync.replicas，主要是平衡可靠性和吞吐量，根据文中的设置参数min.insync.replicas=2，意味着3个节点中只要有2个消息复制成功，就返回ack，而不是取决于最慢的节点

以下是 Kafka 文档中min.insync.replicas的解释：

When a producer sets acks to "all" (or "-1"), min.insync.replicas specifies the minimum number of replicas that must acknowledge a write for the write to be considered successful. If this minimum cannot be met, then the producer will raise an exception (either NotEnoughReplicas or NotEnoughReplicasAfterAppend).

min.insync.replicas=2 的意思并不是“3个节点中只要有2个消息复制成功，就返回ack”，而是：“ISR中存在至少2个节点，才能保证消息被写入”。

这里需要明确“返回ack”的时机。
当3个节点均运行正常时，它们都会成为ISR，而request.required.acks=-1这项配置要求所有ISR节点返回ack后，才能向producer返回ack，详见Kafka文档中关于acks的定义：

acks=all This means the leader will wait for the full set of in-sync replicas to acknowledge the record. This guarantees that the record will not be lost as long as at least one in-sync replica remains alive. This is the strongest available guarantee. This is equivalent to the acks=-1 setting.

也就是说，ISR中3个节点都返回ack后，才能向producer返回ack。所以写入速度取决于最慢节点。

[nereuschen]

理解了

[nereuschen]

5.基准测试中使用的哪种语言的kafka client?如果是使用的java client,那么默认的linger.ms=0，意味着消息是实时发送的，batch不起作用，可以尝试把linger.ms调大到100、200，看看异步/同步刷盘的QPS的变化？

6.同步刷盘、不开启batch这个才是实际业务场景经常用到的，所以我比较关注在同步刷盘不开启batch时，kafka和PhxQueue在压测时瓶颈在什么地方？

[unixliang]

5.基准测试中使用的哪种语言的kafka client?如果是使用的java client,那么默认的linger.ms=0，意味着消息是实时发送的，batch不起作用，可以尝试把linger.ms调大到100、200，看看异步/同步刷盘的QPS的变化？

是用 java client，用的是 org.apache.kafka.tools.ProducerPerformance，底层是 KafkaProducer。
虽然linger.ms=0，但是 batch 还是生效的，Kafka 在高负载情况下，相近时间发出的请求一般也会组成 batch。在 Producer 不 batch 的情况下，以测试机的性能，180w qps 是无法达到的。
linger.ms 的作用是做类似 TCP Nagle 算法的主动延迟，针对的是请求量不大的情况下，进一步减低机器负载，在压测场景下不会发挥作用。

6.同步刷盘、不开启batch这个才是实际业务场景经常用到的，所以我比较关注在同步刷盘不开启batch时，kafka和PhxQueue在压测时瓶颈在什么地方？

我们认为实际在线业务较难在 Producer 端做 batch，但是在存储层这个黑盒内做 batch 是比较合适的，不仅聚合效果好，而且业务无感知，对性能提升很大。

文中已有 PhxQueue 和 Kafka 在关闭 Producer 端 batch 后的测试结果，就是上面做第一点答复时贴的表格。

关于压测瓶颈：PhxQueue 瓶颈在 cpu，大概在70%+；Kafka 因为同步刷盘写放大的原因，瓶颈在硬盘写带宽。

[nereuschen]

感谢！