先说说遇到的坑 回顾下kafka
topic：生产组：P0P1----P14
一个消费组：c0 c1 c2
依据Consumer的负载均衡分配
消费顺序“c0:p0-p4 c1:p5-p9 c2:p10-p14
问题：突然发现读offset 堆积太多 增加消费者也没用
原因： C2节点物理故障，会把数据分给C0和C1,然后C2恢复(生产上会用类似superviser从新启动挂掉的进程)，再重新分配数据，这样来来回回浪费了很多时间 每次挪回都重新洗牌，新版本已经修复此问题，所以不应该随便恢复进程
解决：应该预分配节点，比正常的多一些，这样挂点一两个也没有太大影响
消息系统概念
消息系统负责将数据从一个应用程序传输到另一个应用程序
点对点消息系统和发布 - 订阅消息系统
kafka概念
Kafka专为分布式高吞吐量系统而设计。 与其他消息传递系统相比，Kafka具有更好的吞吐量，内置分区，复制和固有的容错能力，这使得它非常适合大规模消息处理应用程序。
架构
Topics（主题）
数据存储在主题中。Topic相当于Queue。
主题被拆分成分区。 每个这样的分区包含不可变有序序列的消息。分区被实现为具有相等大小的一组分段文件。任何发布到此partition的消息都会被直接追加到log文件的尾部，每条消息在文件中的位置称为offset（偏移量），offset为一个long型数字，它是唯一标记一条消息。它唯一的标记一条消息。kafka并没有提供其他额外的索引机制来存储offset，因为在kafka中几乎不允许对消息进行“随机读写”。
Partition（分区）
- 一个Topic可以分成多个Partition，这是为了平行化处理。
- 每个Partition内部消息有序，其中每个消息都有一个offset序号。
- 一个Partition只对应一个Broker，一个Broker可以管理多个Partition。
Partition offset（分区偏移）
每个分区消息具有称为 offset 的唯一序列标识。
Replicas of partition（分区备份）
副本只是一个分区的备份。 副本从不读取或写入数据。 它们用于防止数据丢失。
Brokers（经纪人）
代理是负责维护发布数据的简单系统。 每个代理可以每个主题具有零个或多个分区。
每一个kafka实例（或者说每台kafka服务器节点）就是一个broker，一个broker可以有多个topic
Kafka Cluster（Kafka集群）
Kafka有多个代理被称为Kafka集群。 可以扩展Kafka集群，无需停机。 这些集群用于管理消息数据的持久性和复制。
Producers（生产者）
每当生产者将消息发布给代理时，代理只需将消息附加到最后一个段文件。实际上，该消息将被附加到分区。 生产者还可以向他们选择的分区发送消息。
Consumers（消费者）
Consumers从broker处读取数据。 消费者订阅一个或多个主题，并通过从代理中提取数据来使用已发布的消息。
Consumer自己维护消费到哪个offet
offet的存放位子依据消费类型的不同，如果JAVA API 消费则是存放在zookeeper，如果是kafka默认自带的消费则是存放在kafka自带的topic【__consumer_offsets】
每个Consumer都有对应的group
group是queue消费模型：各个Consumer消费不同的partition，因此一个消息在group内只消费一次
group是publish-subscribe消费模型：各个group各自独立消费，互不影响，因此一个消息被每个group消费一次。
这是kafka用来实现一个topic消息的广播（发给所有的consumer）和单播（发给任意一个consumer）的手段。
Kafka数据处理步骤
- 1、Producer产生消息，发送到Broker中
- 2、Leader状态的Broker接收消息，写入到相应topic中
- 3、Leader状态的Broker接收完毕以后，传给Follow状态的Broker作为副本备份
- 4、Consumer消费Broker中的消息
Consumer与topic关系
kafka只支持Topic
每个group中可以有多个consumer，每个consumer属于一个consumer group; 通常情况下，一个group中会包含多个consumer，这样不仅可以提高topic中消息的并发消费能力，而且还能提高"故障容错"性，如果group中的某个consumer失效那么其消费的partitions将会有其他consumer自动接管。
总结：
一个group中的consumer只会消费一个topic的一条消息，每个consumer消费不同的partition。
在kafka中,一个partition中的消息只会被group中的一个consumer消费(同一时刻)；
一个Topic中的每个partions，只会被一个"订阅者"中的一个consumer消费，不过一个consumer可以同时消费多个partitions中的消息。
kafka的设计原理决定,对于一个topic，同一个group中不能有多于partitions个数的consumer同时消费，否则将意味着某些consumer将无法得到消息。但是在设计的时候个人觉得可以多些consumer 已解决前面遇到的坑。
Kafka消息的分发
Producer客户端负责消息的分发
kafka集群中的任何一个broker都可以向producer提供metadata信息,这些metadata中包含"集群中存活的servers列表"、"partitions leader列表"等信息；
当producer获取到metadata信息之后, producer将会和Topic下所有partition leader保持socket连接；
消息由producer直接通过socket发送到broker，中间不会经过任何"路由层"。事实上，消息被路由到哪个partition上由producer客户端决定，比如可以采用"random""key-hash""轮询"等。
如果一个topic中有多个partitions,那么在producer端实现"消息均衡分发"是必要的。
在producer端的配置文件中,开发者可以指定partition路由的方式。
Producer消息发送的应答机制
设置发送数据是否需要服务端的反馈,有三个值0,1,-1
0: producer不会等待broker发送ack
1: 当leader接收到消息之后发送ack
-1: 当所有的follower都同步消息成功后发送ack
request.required.acks=0
Consumer的负载均衡
当一个group中,有consumer加入或者离开时,会触发partitions均衡.均衡的最终目的,是提升topic的并发消费能力，步骤如下：
- 1、假如topic1,具有如下partitions: P0,P1,P2,P3
- 2、加入group A 中,有如下consumer: C0,C1
- 3、根据partition索引号排序: P0,P1,P2,P3
- 4、根据consumer.id排序: C0,C1
- 5、计算倍数: M = [P0,P1,P2,P3].size / [C0,C1].size,本例值M=2(向上取整)
- 6、然后依次分配partitions: C0 = [P0,P1],C1=[P2,P3],即Ci = [P(i * M),P((i + 1) * M -1)]
副本机制
由于Producer和Consumer都只会与Leader角色的分区副本相连，所以kafka需要以集群的组织形式提供主题下的消息高可用。kafka支持主备复制，所以消息具备高可用和持久性。
一个分区可以有多个副本，这些副本保存在不同的broker上。每个分区的副本中都会有一个作为Leader。当一个broker失败时，Leader在这台broker上的分区都会变得不可用，kafka会自动移除Leader，再其他副本中选一个作为新的Leader。
创建副本的2种模式——同步复制和异步复制
kafka维护了一个同步状态的副本集合（a set of In-Sync Replicas），简称ISR，集合中的节是和leader保持高度一致，任何一条消息只有被这个集合中的每个节点读取并追加到日志中，才会向外部通知说“这个消息已经被提交”。
只有当消息被所有的副本加入到日志中时，才算是“committed”，只有committed的消息才会发送给consumer，这样就不用担心一旦leader down掉了消息会丢失。
消息从leader复制到follower, 我们可以通过决定Producer是否等待消息被提交的通知(ack)来区分同步复制和异步复制。
同步复制流程：
- producer联系zk识别leader
- 向leader发送消息
- leadr收到消息写入到本地log
- follower从leader pull消息
- follower向本地写入log
- follower向leader发送ack消息
- leader收到所有follower的ack消息
- leader向producer回传ack
异步复制流程：和同步复制的区别在于，leader写入本地log之后，直接向client回传ack消息，不需要等待所有follower复制完成。
kafka支持副本模式，那么其中一个Broker里的挂掉，一个新的leader就能通过ISR机制推选出来，继续处理读写请求。
介绍完kafka的基本概念，简单提一下为什么要用kafka
解耦
在项目启动之初来预测将来项目会碰到什么需求，是极其困难的。消息队列在处理过程中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口。
冗余
有时在处理数据的时候处理过程会失败。除非数据被持久化，否则将永远丢失。对于传统的message queue而言，一般会删除已经被消费的消息，而Kafka集群会保留所有的消息，无论其被消费与否
扩展性
因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的；只要另外增加处理过程即可。
灵活性 & 峰值处理能力
使用消息队列能够使关键组件顶住增长的访问压力，而不是因为超出负荷的请求而完全崩溃。
可恢复性
当体系的一部分组件失效，不会影响到整个系统。
获取一个消息只是”预定”了这个消息，暂时把它移出了队列。除非客户端明确的表示已经处理完了这个消息，否则这个消息会被放回队列中去，在一段可配置的时间之后可再次被处理。
顺序保证
在许多情况下，数据处理的顺序都很重要。消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。
缓冲
在任何重要的系统中，都会有需要不同的处理时间的元素。
理解数据流 异步性
。消息队列提供了异步处理机制，允许你把一个消息放入队列，但并不立即处理它。你想向队列中放入多少消息就放多少，然后在你乐意的时候再去处理它们。