phxqueue java_<<微信开源PhxQueue：高可用、高可靠、高性能的分布式队列>>的几个问题...
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默认配置参数？
batch.size使用的是默认配置，默认值是16384。
Kafka 版本号是0.11.0.0。
我们在测试过程中只修改了如下几项配置，其余配置均使用默认值：
# 配置平衡可用性和数据可靠性
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。所以写入速度取决于最慢节点。