大家好，欢迎来到IT知识分享网。

首先我们看一下如果我们的服务没有消息队列是怎么样的？

上面的系统架构涉及的子系统，存储，数据库，服务种类很多，并且它们之间存在很强的耦合性。这样，会造成以下的问题：面系统的问题

• 强耦合带来的维护成本极高

比如订单app的订单状态有时候要实时主动地同步给财务app的。如果财务app的api接口发生了变化那么订单app的代码也要相应的变化，这样的成本相当的高。这样的设计，一旦其中一个子系统发生了变化，就可能影响其他多个子系统，这样简直就是一场灾难。

• 无法保证顺序性：

服务直接的交互有时候是多线程的这样无法保证顺序性，如数据交互时财务app和订单app都有可能是多线程的。即使是单线程由于超时重试等也会造成顺序的不一致。

• 数据可靠性不高：

还要考虑数据的可靠性，毕竟仅仅通过网络进行数据传输有可能是失败的，同时失败重传有可能会造成数据的重复发送。

• 数据一致性不好把控：

比如订单app和财务app在交互数据时，订单app宕机了，重新上线后，应该恢复到之前的传输位置继续传输。尤其对于非幂等性的操作，如 果恢复到错误的位置，就会导致错误的结果。

• 水平扩展性差：

随着业务的增长，应用之间交换数据的数据量会不断地增长，水平扩展性好的数据传输方式就很重要了。

Kafka是如何解决上述问题的呢？

解耦

kafka作为应用间数据传输的代理层。只需要面向Kafka编程即可。这样，在需要进行数据交换的子系统之间形成了一个基所有的存储只与Kafka通信，开发人员不需要再去了解各个子系统、服务、存储的相关接将Kafka作为整个系统的中枢,负责在任意两个系统之间传递数据。只要数据交互的双方知道消息存放的Topic、消息中数据的格式。当需要扩展消息格式时，只需要修改相关子系统的Kafka客户端即可。就像是一个生产者-消费者模式。

数据的持久化

一般认为网络传输是不可靠的，当数据在两个组件之间进行传递的时候，传输过程可能会失败。除非数据被持久化到磁盘上，否则会造成消息的丢失。当kafka作为数据传输的中间层的时候，即使调用方宕机或kafka本身宕机都不会影响数据传输，因为数据都保存在kafka节点的磁盘上。

扩展性

Kafka 的每个Topic(主题)都可以分为多个Partition(分区)，每个分区都有多个 Replica(副本)，实现消息冗余备份。每个分区中的消息是不同的，这类似于数据库中水平切分的思想，提高了并发读写的能力。

容灾

同一分区的不同副本中保存的是相同的消息，副本之间是一主多从的关系，其中Leader 副本负责处理读写请求，Follower 副本则只与 Leader 副本进行消息同步，当Leader 副本出现故障时，则从 Follower 副本中重新选举 Leader副本对外提供服务。这样，通过提高分区的数量，就可以实现水平扩展;通过提高副本的数量，就可以提高容灾能力。除了服务端，Kafka还支持Consumer 的水平扩展能力。我们可以让多个Consumer 加入一个Consumer Group(消费组)，在一个Consumer Group中，每个分区只能分配给一个Consumer 消费。当Kafka服务端通过增加分区数量进行水平扩展后，我们可以向Consumer Group 中增加新的 Consumer 来提高整个Consumer Group 的消费能力。当Consumer Group 中的一个 Consumer 出现故障下线时，会通过Rebalance 操作将下线Consumer 负责处理的分分配给其他Consumer继续处理;当下线Consumer 重新上线加入Consumer Group 时，会再进行一次 Rebalance 操作.重新分配分区。

顺序性

Kafka保证一个Partition内消息的有序性，但是并不保证多个partition 之间的数据有顺序。具体是通过一个partition只允许一个生产者增加消息，同时一个partition只允许一个消费者来消费消息。

流量削峰

流量削锋也是消息队列中的常用场景，一般在秒杀或团抢活动中使用广泛

应用场景：秒杀活动，一般会因为流量过大，导致流量暴增，应用挂掉。为解决这个问题，一般需要在应用前端加入消息队列。

• 可以控制活动的人数
• 可以缓解短时间内高流量压垮应用

异步通信

Kafka为系统提供了异步处理能力。例如，两个系统需要通过网络进行数据交换，其中生产端可以把一个消息放入Kafka中后立即返回继续执行其他工作，不需要等待消费端的响应。生产端将处理结果放入 Kafka 中后，消费端可以从其中获取并解析响应。

写在最后

本人在掘金发布了小册，对kafka做了源码级的剖析。

欢迎支持笔者的掘金小册：《Kafka 源码精讲》（请在稀土掘金网站或app中搜索相关课程）