1.Kafka简介
Kafka 本质上是一个 MQ（Message Queue），使用消息队列的优点：
解耦：允许独立的扩展或修改队列两边的处理过程。
可恢复性：即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。
缓冲：有助于解决生产消息和消费消息的处理速度不一致的情况。
灵活性和峰值处理能力：不会因为突发的超负荷的请求而完全崩溃，消息队列能够使关键组件顶住突发的访问压力。
异步通信：消息队列允许用户把消息放入队列但不立即处理它。
先介绍消息队列的优点：
消息队列：
消息队列的异步处理
主要应用于短信通知、终端状态推送、App推送、用户注册等。
同步处理：
我们同步处理的话，我们执行下一个步骤需要等上个步骤完成才能执行下一步，这样网速就很慢了，但是我们是不是可以将库存作为生产者，在库存和订单，短信，统计之间加一个消息队列的话，并且开启订单，短信，统计三个(消费者)线程，分别处理自己的任务，那么我们在库存里拿出以后(生产者生产后立马返回再去生产放到消息队列里，然后通知消费者线程去消费)这样我们就不需要一步一步
的等待
异步处理：
异步处理的优势：更快速返回结果；减少等待，实现并发处理，提升系统总体性能。
消息队列的模式可以有：
（1）1对1：读取之后立刻从队列中移除消息。
（2）1对多：这种模型是发布订阅模型，消息队列的元素可以被重复消费。至于何时删除消息，可以设置消息的存活周期；比如kafka可以设置24H后删除消息。
消息队列的流量控制（削峰）
在秒杀场景下的下单状态，使用消息队列隔离网关和后端服务，以达到流量控制和保护后端服务的目的。
设置消息队列的最大限制数量，在达到最大数量时网关不再生产消息到消息队列中。
可以这么想：有一个商品秒杀活动，商品数量为100，当消息队列的数量达到100时不再生产秒杀成功消息，直接返回秒杀失败给用户，只有1到100的用户秒杀成功 获得商品。
那么我们以服务器设计的角度去思考，在某一时刻，我们是为秒杀服务提供服务的生产者，我们生产到消息队列的数量达到100的时候就不再生产，而我们的客户端再去网上秒杀购物的时候，从消息队列里拉取，当看到消息队列为空(也就是货物为0)，那么就返回秒杀失败
消息队列的服务解耦
A系统负责数据分发，其他系统调用A系统提供的接口处理数据；当新增一个系统时，A系统需要改代码调用新的系统，并实现新的接口给新的系统去调用。这种方式是系统间高度耦合。
使用消息队列，A系统负责将数据分发到MQ，消费端根据需要从MQ获取消息即可，不需要就取消MQ的消费。
消息队列的发布订阅
用户需要先去注册，才能收到相关消息。
比如游戏里面跨服：
（1） 广播今天整体还剩多少把屠龙刀可以暴。
（2） 广播用户暴的屠龙刀的消息。
消息队列的高并发缓冲
这个和消息队列的流量控制（削峰）有些类似。区别在于，这里没有大小限流，可能在某个时间点会出现超过后端处理能力的访问；比如后端处理能力是50000每秒，在某个时间点出现每秒80000的访问，这就可能造成击穿。
针对此情况，消息全部放入消息队列，消息队列提供可以把数据固化到磁盘的能力，降低高峰数据对后端的短暂冲击。
比如，后端处理能力50000，某个短暂时间点（比如一秒的时间）数据访问达到80000，消息队列将多的数据缓存到磁盘，后端仍然处理50000数据；冲击点退去后，访问数据降到了30000，那么消息队列将把缓存的数据放到后端处理。
比如kafka 日志服务、监控上报。
2.Kafka的架构
Kafka只写数据到leader副本，也只从leader副本获取数据。如果leader失效，会重新选择出leader(从Follower副本中选出，并且得是在同一个topic中的)。
优点类似MySQL的主从关系，写数据都是到主机里面，但是读数据不一样，Kafka读数据只能从主机里面读。
1.Kafka 存储的消息来自任意多被称为 Producer 生产者的进程。数据从而可以被发布到不同的 2.Topic 主题下的不同 Partition 分区。
在一个分区内，这些消息被索引并连同时间戳存储在一起。其它被称为 Consumer 消费者的进程可以从分区订阅消息。
3.Kafka 运行在一个由一台或多台服务器组成的集群上，并且分区可以跨集群结点分布。
2.1 Kafka 一些重要概念
Producer：消息生产者，向 Kafka Broker 发消息的客户端。
Consumer：消息消费者，从 Kafka Broker 获取消息的客户端。
Consumer Group：消费者组（CG），消费者组内每个消费者负责消费不同分区的数据，提高消费能力。一个分区只能由组内一个消费者消费，消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。
(注意！！！当同组消费组订阅了同一个topic的话，那么同组消费者在消费消息队列的内容的话，那么每次只能由组内任意一个消费者进行消费，不能同时消费组内的所有消费者同时消费)
Broker：一台 Kafka 机器就是一个 Broker。一个集群(kafka cluster)由多个 Broker 组成。一个Broker 可以容纳多个 Topic。
Topic：可以理解为一个队列，Topic 将消息分类，生产者和消费者面向的是同一个Topic。
(其实这么设计主要是理解为一个逻辑上的存储，比如某个公众号的内容都存在topic上面，在物理上是存在每个partition)
Partition：为了实现扩展性，提高并发能力，一个非常大的 Topic 可以分布到多个 Broker （即服务器）上，一个 Topic 可以分为多个 Partition，同一个topic在不同的分区的数据是不重复的，每个 Partition 是一个有序的队列，其表现形式就是一个一个的文件夹。
(物理上表示的存储单元)
Replication：每一个分区都有多个副本，副本的作用是做备胎。当主分区（Leader）故障的时候会选择一个备胎（Follower）上位，成为Leader。在kafka中默认副本的最大数量是10个，且副本的数量不能大于Broker的数量，follower和leader绝对是在不同的机器，同一机器对同一个分区也只可能存放一个副本（包括自己）。
Message：消息，每一条发送的消息主体。
Leader：每个分区多个副本的“主”副本，生产者发送数据的对象，以及消费者消费数据的对象，都是 Leader。
Follower：每个分区多个副本的“从”副本，实时从 Leader 中同步数据，保持和 Leader 数据的同步。Leader 发生故障时，某个 Follower 还会成为新的 Leader。
Offset：消费者消费的位置信息，监控数据消费到什么位置，当消费者挂掉再重新恢复的时候，可以从消费位置继续消费。同一主题，不同的分区，它们的offset是独立的。
ZooKeeper：Kafka 集群能够正常工作，需要依赖于 ZooKeeper，ZooKeeper 帮助 Kafka 存储和管理集群信息。
！！！注意在我们启动kafka集群的时候，需要先启动zookeeper才能启动kafka
2.2 工作流程
不同的partition的offerset 是独立的。
Kafka 中消息是以 Topic 进行分类的，生产者生产消息，消费者消费消息，面向的都是同一个 Topic。(就是我们前面提到的topic是逻辑上的概率)
Topic 是逻辑上的概念，而 Partition 是物理上的概念，每个 Partition 对应于一个 log 文件，该 log 文件中存储的就是 Producer 生产的数据。Producer 生产的数据会不断追加到该 log 文件末端（顺序写），且每条数据都有自己的 Offset。
消费者组中的每个消费者，都会实时记录自己消费到了哪个 Offset，以便出错恢复时，从上次的位置继续消费。
我们的partition上会记录offset，这个offest代表消费者消费的位置，以便出错恢复时，从上次的位置继续消费
日志默认在：/tmp/kafka-logs
2.3 文件存储
Kafka文件存储也是通过本地落盘的方式存储的，主要是通过相应的log与index等文件保存具体的消息文件。
生产者不断的向log文件追加消息文件，为了防止log文件过大导致定位效率低下，Kafka的log文件以1G为一个分界点，当.log文件大小超过1G的时候，此时会创建一个新的.log文件，同时为了快速定位大文件中消息位置，Kafka采取了分片和索引的机制来加速定位。
在kafka的存储log的地方，即文件的地方，会存在消费的偏移量以及具体的分区信息，分区信息的话主要包括.index和.log文件组成，
所以总结一句话，就是一个topic有多个partition，一个partition对应一个log文件，我们的生产者生产的数据写到topic的时候就是写入到该topic的partition中也就是写到log文件中，log文件又分为多个segment，一个segment对应两个文件.index和.log文件
2.4 副本原理
副本机制（Replication），也可以称之为备份机制，通常是指分布式系统在多台网络互联的机器上保存有相同的数据拷贝。副本机制的好处在于：
提供数据冗余（即提高可用性）。
提供高伸缩性（支撑更高的读请求量）。
改善数据局部性（降低系统延时）。
目前Kafka只实现了副本机制带来的第 1 个好处，即是提供数据冗余实现高可用性和高持久性。
在kafka生产环境中，每台 Broker 都可能保存有各个主题下不同分区的不同副本，因此，单个 Broker上存有成百上千个副本的现象是非常正常的。
比如了一个有 3 台 Broker 的 Kafka 集群上的副本分布情况。主题 1 分区 0 的 3 个副本分散在 3 台 Broker 上，其他主题分区的副本也都散落在不同的 Broker 上，从而实现数据冗余。
上述的话总结一下就是每个broker对应一个kafka服务器，一个broker下保存多个topic的partition，那么我们如果有多个broker的话，并且每个类型的topic的分区保存在多个kafka服务器上(broker上)，可能比如topic1的follower副本保存在broker2，topic1的leader副本保存在broker3下，这样冗余的把数据分布在多个kafka服务器上的话，那么如果某一个服务器宕机的话
并且某个topic的leader副本下线了，那么我们就可以用其他kafka服务器(broker)中选出follower作为leader副本，当之前下线的副本上线之后，作为follower加入到kafka集群当中
Kafka是基于领导者（Leader-based）的副本机制：
1. 在 Kafka 中，副本分成两类：领导者副本和追随者副本。每个分区在创建时都要选举一个副本，称为领导者副本，其余的副本自动称为追随者副本。
2.Kafka 副本机制中的追随者副本是不对外提供服务的。
3.当领导者副本挂掉了，或领导者副本所在的 Broker 宕机时，Kafka 依托于 ZooKeeper 提供的监控功能能够实时感知到，并立即开启新一轮的领导者选举，从追随者副本中选一个作为新的领导者。老 Leader 副本重启回来后，只能作为追随者副本加入到集群中。
2.5 分区和主题的关系
- 一个分区只属于一个主题。
- 一个主题可以有多个分区。
- 同一主题的不同分区内容不一样，每个分区有自己独立的offset。
- 同一主题不同的分区能够放置到不同节点的broker。
- 分区规则设置得当可以使得同一主题的消息均匀落在不同的分区。
深入浅出理解kafka ---- 万字总结（下）：
https://developer.aliyun.com/article/1393784?spm=a2c6h.24874632.expert-profile.13.6af22f31AcelSW
