消息队列：RocketMQ和Kafka

kafka

高性能高吞吐原因

1.磁盘顺序读写

2.零拷贝

3.分区分段索引

4.批量压缩

5.批量读写

6.直接操作pageCache

pull和push分析

pull模式：（kafka采用的模式）

1.根据consumer的消费能力进行数据拉取，可控速率

2.可以批量或单条拉取

3.可设置不同的提交方式，实现不同的传输语义

缺点：无数据时，consumer自旋消耗cpu资源

解决：通过参数配置，空或者没到一定数量时，阻塞，释放cpu

push模式：

不会导致consumer自旋消耗cpu资源

缺点：忽略了consumer的消费能力，会导致雪崩，或网络堵塞

高可靠的解决方案

1.生产者

ack机制，0：不重试，1：leader成功即可，-1/all：ISR列表的flower都同步

unclean.leader.election.enable:false,禁止从OSR中选举；AR：所有副本

tries>1重试次数

min.insync.replicas>1，同步副本数，没满足该值前，不提供读写服务，写操作会异常

2.消费者

手动提交offset

3.broker

减少刷盘间隔

事务消息

rockedMq

架构设计

nameServer：

类似zookeeper，去中心化；broker和所有ns都需要建立长连接

producer：

去ns拉取topic所属的broker，发送消息

consumer：

去ns拉取topic所属的broker，消费消息

broker：

commitLog不区分topic

consumerQueue基于topic的索引文件

indexFile通过key或时间区间索引

queue：

类似partition，但是不存在leader和follower