业务消息系统对于微服务架构的必要性
- 微服务中少不了 EDA事件驱动机制，进而少不了引入一套 业务消息系统处理事件
- 业务消息系统要保证消息的可靠性、一致性、可用性、事务
Kafuka 作为业务消息系统的可能性和主流性，主要用于消峰和异步解耦多组微服务
Kafuka作为业务消息系统的优势
- 时间复杂度O(1)提供消息持久化，对 TB 级数据也可以保证O(n)访问性能，可以配置保留策略
- 高吞吐，单机100k/s 以上消息传输，引入sendfile、mmap系统调用实现"零拷贝"，基于顺序 io 不是随机 io 和 clickhouse存储原理类似，
- 支持 多组server间消息分区，分布式消费，同时保证每个 partition 内消息顺序传输(offset)
- 同时支持离线数据和在线实时数据处理
- 最重要支持在线横向扩展
Exactly Once:事务性，确保分布式场景下的数据最终一致性
在0.11之前还不支持事务，只能做到 at least once、at most once ，0.11以后官方实现了一套分布式事物机制实现了 exactly once模式，这个是可以作为业务消息系统的关键
消费者消费消息时可以指定具体的读隔离级别 - at least once
读完消息先 commit。这种模式下，如果在处理完消息后 commit 之前的 Consumer crash了，下次重新开始工作还会处理刚刚没有 commit 的消息，实际上该消息已经被处理过了。 - at most once
读完消息先 commit 再处理消息。这种模式下，如果 Consumer 在 commit 后还没来得及处理消息就 crash 了，下次重新开始工作后就无法读到刚刚已提交而未处理的消息。
0.11以后引入了幂等性，producer 不论向 server 发送多少重复数据server 只能持久化一条
https://www.cnblogs.com/middleware/p/9477133.html
Replication:可用性
0.8以后引入了 Replication，相同 Partition可能会有多个 Replica选举出一个 Leader一定程度上保证了可用性
Rebalance:高可用和在线水平扩展
当新的消费者加入消费组时，会消费一个或多个分区，这些分区是之前其他消费者负责的
作为业务消息系统对比rabbitmq、rocketmq
- 使用 kafuka 一定程度上可以保证基建统一，kafuka无论对于日志分析还是实时计算都是不可替代的一个重要组成，如果业务系统也应用 kfk 一定程度上降低系统复杂度，技术栈复杂度
- 高吞吐、高可用对于业务消息系统一样重要
- kafuka官方暂时不支持延时队列、消息重试，需要自己实现，也可以考虑接入其他 mq 实现
https://juejin.cn/post/7065664161786626084
http://dockone.io/article/9820
https://zhuanlan.zhihu.com/p/365802989
