1 背景

场景：
A服务每秒发送200个消息
B服务每秒处理100个消息

问题：
B服务会被压垮，那如何保证B能正常处理所有A的消息

方案：
增加中间层处理，该中间层可以是消息队列Kafka

kafka_18">2 kafka的架构来源

2.1 增加消息队列

基于上面的背景，我们可以在可以在B服务的内存中加一个队列，那什么是消息队列呢？

如上图的队列其实就是个链表，链表的每个节点就是一个消息，每个节点也有个序号叫做offset

B服务消费消息队列的消息，更新offset，如果处理的不及时，消息就会堆积在队列里，如果B服务重启，消息就都丢失了！将消息队列从B中挪出来作为一个单独的进程，即单独的服务，这样就互不影响。这样就有了简陋的消息队列。

2.2 高性能

如果B服务消费情况较差，可以增加消费者，增大消息队列的消费速度，与此同时可以增加生产者的数量，提高消息的吞吐量

当生产者和消费者的数量增多后会争抢同一个消息队列，抢不到的一方就要等待，比较浪费时间！

这时候就要增加消息队列了！每个消息队列就是一个topic
生产者按照topic将数据投递到不同的消息队列中，消费者根据topic订阅不同的topic
但是单个topic的消息可能过多

可以将单个队列拆分好几段，每一段就是一个partition，每个消费者消费一个partition，
随着partition增多会影响单机性能，导致CPU过高，影响整体系统性能。
可以增加节点去缓解CPU的压力

2.3 高可用

如果partition所在节点故障会导致消息丢失，那就谈不上高可用了。此时我们就可以给partition增加副本，叫做ReplicaSet。

leader 负责应付生产者和消费者的请求，followers只管同步leader 的数据

把leader 和follower 分别部署在两个主机上，当其中一台挂掉，也不会影响另外一台的工作。如果主节点挂了还能从follower 中选出新的leader

2.4 持久化和过期策略

如果一个partition的主文件及副本文件的机器都宕机了，那么数据就都丢了

所以我们的数据不应该放在内存里，应该放在磁盘上，即使服务挂了，重启服务后也可以从磁盘中读取数据

磁盘容量有限，日积月累，数据量极大，此时就有了保留策略（retention policy）。

2.5 Consumer Group

新增消费者的时候只能根据最新的offset消费，如果想让新增的消费者从某个offset开始消费，如何处理？

于是就有了消费者组的概念，不同消费者组维护自己的消费进度

2.6 Zookeeper

组件过多，每个组件都有自己的数据和状态，所以需要有个组件来统一维护这些状态信息，于是我们有了Zookeeper，它会定期和broker通讯，获取Kafka状态，以此判断，是不是有broker挂了，某些消费组消费到哪里了

3 Kafka架构图

4 Kafka的应用场景

削峰填谷：秒杀活动、大数据和日志异构同步等