:::warning kafka使用的是zookeeper，rocketmq自定义了namesrv组件。 ::: kafka的高可用利用了zk的选主能力。
    rocketmq不需要该能力且rocketmq采用java实现，所以自定义了namesrv主键来保证技术栈的统一。
    :::warning broker节点挂掉之后，kafka和rocketmq分别如何处理？ ::: 考虑两个点：

    1. 如何保证挂掉的broker上的消息数据不丢失？
    2. 如何保证后续继续该broker的生产者发送服务继续可用？

    kafka通过topic拆分为多个partition，每个partition在多个broker进行数据冗余，称为follower replica（ISR），但是follower不对外提供读写能力，只从leader进行数据同步。挂掉的broker持有的leader replica会通过zk选主的方式将其他broker的follower升级leader，follower中冗余了不超过可配置差值的消息数据（不丢失），同理原本发送给broker的消息会发送给升级为leader的broker节点（继续服务）。
    rocketmq同样也是将topic拆分为多个message queue，每个mq在多个broker中也进行了数据冗余，称为slave queue，和kafka区别的在于slave面向consumer group提供读的能力，所以挂掉的broker持有master queue的消息数据会通过slave消费完毕（不丢失），通过DefaultMQProducer（生产者客户端）的逻辑，会将消息发送给其他可用的master queue（继续服务）。
    :::warning kafka和rocketmq如何保证顺序消费？ ::: 由于kafka和rocketmq在架构上几乎一致，所以顺序消费的处理也是一致的。

    1. 全局有序：消除并行保证串行，也就是存储端只发送给一个broker，消费端只用一个consumer实例进行消费，可以保证全局有序，带来的问题也很明显，无法享受的broker水平扩展带来的高吞吐量优势。
    2. 局部有序：考虑的这样的事实：一般只需要保证userid下的一系列操作、orderId下的一系列操作有序，不同领域主体之间的消息无需有序。也就是要将同一个领域主体发送的同一个broker下，所以两者都提供broker的路由规则的自定义能力。分别对应rocketmq的MessageQueueSelector和kafka的PartitionAssignmentStrategy

    :::warning kafka和rocketmq的rebalance机制？ :::