《Kafka 设计解析（一）：Kafka 背景及架构介绍》学习笔记
MQ的作用：
1.解耦：将数据生产方和数据消费方解耦。数据生产方Pruducer只需要关心数据生产；数据消费放Consumer只需要关心数据消费。而不必关心其中的传输过程，该过程交给MQ保证。
试想，Producer生产出数据后使用Http请求将数据发送Consumer，如果发送失败，那么是生产方的责任还是消费方的责任？如果生产方保证消息发送失败的重试机制，那么相当于
将不属于数据生产的逻辑加入了Producer。
2.削峰：当Producer（不一定是内部系统，可能是外部系统，例如开放给外部的http接口，接口访问量暴增）生产的数据量突然暴增，Consumer的吞吐量无法满足数据量的升高。因此，
必然会导致数据的堆积，慢慢会压垮整个系统。因此，需要引入MQ对Producer生产的数据进行排队，Consumer无法及时消费掉的数据会堆积在MQ中，而不至于直接压垮Consumer。
3.异步：Consumer和Producer之间可能吞吐量存在不同。因此，数据的生产和消费可以不同步。引入MQ可以使得数据生产和消费的流程异步化。
文章中的：
4.可恢复性： 系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。
5.顺序性：在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。Kafka 保证一个 Partition 内的消息的有序性。
Http请求由于网络延迟的影响，导致先发送的请求不一定先到达目标服务，更不一定先获得目标服务的响应。如果把请求生产到MQ中，则能保证请求的顺序性。
Kafka名词解释：
1.Broker：Kafka结点
2.Controller：在Kafka集群中会有一个或者多个broker，其中有一个broker会被选举为控制器（Kafka Controller），它负责管理整个集群中所有分区和副本的状态。当某个分区的leader副本出现故障时，由控制器负责为该分区选举新的leader副本。
当检测到某个分区的ISR集合发生变化时，由控制器负责通知所有broker更新其元数据信息。当使用kafka-topics.sh脚本为某个topic增加分区数量时，同样还是由控制器负责分区的重新分配。
Controller选举机制：所有Broker结点一起去ZK注册临时结点/Controller，由于只有一个Broker会注册成功，因此注册成功的这个Broker会成为Controller，其他失败的Broker会根据失败信息判断出集群中已经存在Controller。
3. Topic：每条发布到 Kafka 集群的消息都有一个类别，这个类别被称为 Topic，Topic中的数据不保证顺序，除非Parition为1。（物理上不同 Topic 的消息分开存储，逻辑上一个 Topic 的消息虽然保存于一个或多个 broker 上但用户只需指定消息的 Topic 即可生产或消费数据而不必关心数据存于何处）
4. Partition：一个Topic的数据物理上被划分多1个或多个Partition，分布在不同Broker上，单个Partition内部数据是顺序的。随着Partition数量的增多，Topic的吞吐量会变大。
5.Producer：数据生产者，将生产的数据推送至Kafka集群。
6.Consumer：数据消费者，从Kafka集群拉取数据进行消费。
7. Consumer Group：消费组，Kafka保证在整个集群稳定运行的情况下（不发生Reblance），每个Partition中的数据只会被Consumer Group中的一个Consumer消费。可为每个 Consumer 指定 group name，若不指定 group name 则属于默认的 group。
8. Offset：每个Consumer Group在每个Partition中都有几个Offset值，记录该CG消费到了Parititon中的哪个数据。 offset记录在一个名为 __consumer_offsets 的Topic中。
9. Parittion Replication：由于每个Topic被划分成1个货多个Partition，因此一个Topic的数据被划分成多份分别存储在不同Kafka Broker上，如果某个Broker出现故障，会导致存储在该Broker的这部分数据丢失。
因此，Kafka提出了Replication概念。每个Topic可以设置1个或多个Replication，对Partition的数据进行冗余备份。若Replication数量被设为3，则代表每个Parititon的数据在Kafka集群中
存在3份；如果Replication数量被设为1，则代表每个Parititon的数据在Kafka集群中只存在一份。
10. Partition Leader：由于Replication的存在，因此每个Partittion的数据存在于多个Broker结点。因此，需要选出Parittion Leader，Producer和Consumer对该Parititon的数据的读、写只和Paritition Leader交互。其他Replication的Broker
只作为该Partition的Follower，Leader会向Follower不断同步数据。如果当Leader挂掉后，Controller会指定新的Partition Leader。
Partition：
Producer 发送消息到 broker 时，会根据 Paritition 机制选择将其存储到哪一个 Partition。如果 Partition 机制设置合理，所有消息可以均匀分布到不同的 Partition 里，这样就实现了负载均衡。如果一个 Topic 对应一个文件，那这个文件所在的机器 I/O 将会成为这个 Topic 的性能瓶颈，而有了 Partition 后，不同的消息可以并行写入不同 broker 的不同 Partition 里，极大的提高了吞吐率。可以在 $KAFKA_HOME/config/server.properties 中通过配置项 num.partitions 来指定新建 Topic 的默认 Partition 数量，也可在创建 Topic 时通过参数指定，同时也可以在 Topic 创建之后通过 Kafka 提供的工具修改。
在发送一条消息时，可以指定这条消息的 key，Producer 根据这个 key 和 Partition 机制来判断应该将这条消息发送到哪个 Parition。相同key的消息会被发送到同一个Partition中，但不保证Partition只存在一个Key的数据（这一点是个人猜测）。
至少一次消费、至多一次消费、仅有一次消费：
至少一次消费：1、接收数据 2、处理数据 3、提交Offset
之多一次消费：1、接收数据 2、提交Offset 3、处理数据
仅有一次消费：1、接收数据 2、处理数据但处理结果不落库 3、落库和Offset一起提交（分布式事务）