为何要用Kafka实现消息系统

消息系统非消息队列，Kafka具有消息队列和发布/订阅两种模式，两种传统的消息模式，但重要的是，Kafka同时兼容两种，而且灵活，强大

单独看这两种模式：

队列模式

可以替代MQ的原因，估计也是很多人的第一印象：大数据的MQ，高吞吐的MQ。
一组的Kafka消费者读取一个Kafka Topic, 每条消息只被其中的一个消费者消费一次。这样就能切分数据流由多个消费者实例来进行处理，处理能力水平扩展。

发布/订阅模式

广播模式，一条消息可以广播给所有的消费者，可以实现多个应用的并发加载。

可以说两种模式都不是Kafka独有的，有各种MQ，也有Redis可以进行发布/订阅。其实Kafka取胜点就是大和快：高吞吐和低延迟。因为天生具有分布式特性，通过消费者组的概念每个主题都能同时采用了两种模式（不是常见那种模式A或模式B，而是模式AB），这样既能实现顺序的时间消费，又能支持多实例的处理，还能够确保可水平扩展，高可用。简单说理由，就是“我全都要”。这也是大数据和未来人工智能的一种趋势，专注但必须要突破之前想象的限制。Kafka不能说处处有优势，有时在业务上比传统方法显得“单纯可爱”，但在大和快上更有创造空间。犹如货车和跑车的发动机，并不是量的区别。
另外，相比传统消息系统，kafka有更强的消息序列保证，更适合多实例并发的场景。比如：MQ架构里一个系统挂掉导致消息队列堵塞进而影响其它系统。