slave
操作系统
master
消费者
生产者
无法完全保证不丢失，只能相对保证不丢失RocketMQflushDiskType，刷盘策略，同步和异步，异步能极大程度保证不丢失，10ms一次，但是IO压力很大，异步200ms一次；kafkaflush.ms，配置刷盘间隔，频率，消息累计量等RabbitMQ通过对消息做持久化，然后将publisher confirms配置为correlated来实现数据保存
3
RocketMQ1、普通集群，所有消息以master为主，即便slave没有完全同步，此时master又挂了，slave也不会变成master，等master重新起来后，继续将消息同步到slave2、DLedger模式，master挂了，slave会自行选举leader，但是无法保证消息不丢失kafka只有选举模式，但是可以通过ACKS=all的模式，来极大程度的保证数据不丢失RabbitMQ镜像队列，可以通过配置一些策略，例如配置when-synced，只有完全与主节点同步后才能晋升为master，也可以配置同步批次大小，来控制同步频率
RocketMQ1、异步发送，无法保证；2、同步发送，消息安全性高，但是效率低，内部通过juc锁实现；3、异步发送，并通过SendCallback来监听消息是否送达，但是sendCallback是一个子线程，会增加客户端负担，且producer不能直接shutdown，要结合业务再关闭；kafkasend后，返回的是future，此时可以调用get方法，会转为同步方式，获取发送结果，从结果中判断是否发送成功RabbitMQ1、同步发送，通过waitForConfirmsOrDie来实现，等待消息发送完成，失败会catch捕获；2、异步发生，和rocketMQ的3类似，可以开启confirmSelect，在ack和nack中判断消息的响应情况
RocketMQ本身就具备消息的重发机制，只要消费者端没有返回确认，就会重发，重发次数达到上限16次后，会进入死信队列，可以修改死信队列的权限，再去读取数据kafka采用手动提交偏移量的方式，此时有同步提交和异步提交，同步更能保证数据的完整性，但是对性能影响较大RabbitMQ如果消费者端，没有响应，会重新发送，另外acknowledge-mode建议设置为手动模式，再结合死信队列，对于发送异常/超时/被拒绝的消息，就可以去死信队列中获取
1
MQServer
2
4
