五、其它中间件共同的优化

5.1 双写或多写来保证数据一致性

ISR默认值为1，ISR像不像数据库双写。

5.2 reactor模型

netty也有使用到, 以及它所用的mmap, epoll

5.3 和rocketMQ相同点

相同点

两者均利用了操作系统Page Cache的机制，同时尽可能通过顺序io降低读写的随机性，将读写集中在很小的范围内。均使用零拷贝和epoll等

不同点

存储

1. Kafka采用partition，每个topic的每个partition对应一个文件。顺序写入，定时刷盘。但一旦单个broker的partition过多，则顺序写将退化为随机写，Page Cache脏页过多，频繁触发缺页中断，性能大幅下降。
2. RocketMQ采用CommitLog+ConsumeQueue，单个broker所有topic在CommitLog中顺序写，Page Cache只需保持最新的页面即可。同时每个topic下的每个queue都有一个对应的ConsumeQueue文件作为索引。ConsumeQueue占用Page Cache极少，刷盘影响较小。

存储可靠性

• RocketMQ支持异步刷盘，同步刷盘，同步Replication，异步Replication。
• Kafka使用异步刷盘，异步Replication。

顺序消息

• Kafka和RocketMQ都仅支持单topic分区有序。
• RocketMQ官方虽宣称支持严格有序，但方式为使用单个分区。

延时消息

• RocketMQ支持固定延时等级的延时消息，等级可配置。
• kfaka不支持延时消息。

消息重复

• RocketMQ仅支持At Least Once。
• Kafka支持At Least Once、Exactly Once。

消息过滤

• RocketMQ执行过滤是在Broker端，支持tag过滤及自定义过滤逻辑。
• Kafka不支持Broker端的消息过滤，需要在消费端自定义实现。

死信队列DLQ（dead letter queue）

• RocketMQ通过DLQ来记录所有消费失败的消息。
• Kafka无DLQ。Spring等第三方工具有实现，方式为将失败消息写入一个专门的topic。

回溯消费

• RocketMQ支持按照时间回溯消费，实现原理与Kafka相同。
• Kafka需要先根据时间戳找到offset，然后从offset开始消费。

事务

• RocketMQ支持事务消息，采用二阶段提交+broker定时回查。但也只能保证生产者与broker的一致性，broker与消费者之间只能单向重试。即保证的是最终一致性。
• Kafka从0.11版本开始支持事务消息，除支持最终一致性外，还实现了消息Exactly Once语义（单个partition）。

转载请注明：arthur.dy.lee_Kafka和其它中间件共同的优化（五）