标签：-- 取数据 数据存储 独立 partition 版本 负载均衡 另一个 随机
topic：生产组：P0\P1----P14
一个消费组：c0 c1 c2
依据Consumer的负载均衡分配
消费顺序“c0:p0-p4 c1:p5-p9 c2:p10-p14
问题：突然发现读offset 堆积太多 增加消费者也没用
原因： C2节点物理故障，会把数据分给C0和C1,然后C2恢复(生产上会用类似superviser从新启动挂掉的进程)，再重新分配数据，这样来来回回浪费了很多时间 每次挪回都重新洗牌，新版本已经修复此问题，所以不应该随便恢复进程
解决：应该预分配节点，比正常的多一些，这样挂点一两个也没有太大影响
消息系统负责将数据从一个应用程序传输到另一个应用程序
点对点消息系统和发布 - 订阅消息系统
Kafka专为分布式高吞吐量系统而设计。 与其他消息传递系统相比，Kafka具有更好的吞吐量，内置分区，复制和固有的容错能力，这使得它非常适合大规模消息处理应用程序。
数据存储在主题中。Topic相当于Queue。
主题被拆分成分区。 每个这样的分区包含不可变有序序列的消息。分区被实现为具有相等大小的一组分段文件。任何发布到此partition的消息都会被直接追加到log文件的尾部，每条消息在文件中的位置称为offset（偏移量），offset为一个long型数字，它是唯一标记一条消息。它唯一的标记一条消息。kafka并没有提供其他额外的索引机制来存储offset，因为在kafka中几乎不允许对消息进行“随机读写”。
每个分区消息具有称为 offset 的唯一序列标识。
副本只是一个分区的备份。 副本从不读取或写入数据。 它们用于防止数据丢失。
代理是负责维护发布数据的简单系统。 每个代理可以每个主题具有零个或多个分区。
每一个kafka实例（或者说每台kafka服务器节点）就是一个broker，一个broker可以有多个topic
Kafka有多个代理被称为Kafka集群。 可以扩展Kafka集群，无需停机。 这些集群用于管理消息数据的持久性和复制。
每当生产者将消息发布给代理时，代理只需将消息附加到最后一个段文件。实际上，该消息将被附加到分区。 生产者还可以向他们选择的分区发送消息。
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只支持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 已解决前面遇到的坑。==
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
当一个group中,有consumer加入或者离开时,会触发partitions均衡.均衡的最终目的,是提升topic的并发消费能力，步骤如下：
在项目启动之初来预测将来项目会碰到什么需求，是极其困难的。消息队列在处理过程中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口。
有时在处理数据的时候处理过程会失败。除非数据被持久化，否则将永远丢失。对于传统的message queue而言，一般会删除已经被消费的消息，而Kafka集群会保留所有的消息，无论其被消费与否
因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的；只要另外增加处理过程即可。
使用消息队列能够使关键组件顶住增长的访问压力，而不是因为超出负荷的请求而完全崩溃。
当体系的一部分组件失效，不会影响到整个系统。
获取一个消息只是”预定”了这个消息，暂时把它移出了队列。除非客户端明确的表示已经处理完了这个消息，否则这个消息会被放回队列中去，在一段可配置的时间之后可再次被处理。
在许多情况下，数据处理的顺序都很重要。消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。
在任何重要的系统中，都会有需要不同的处理时间的元素。
。消息队列提供了异步处理机制，允许你把一个消息放入队列，但并不立即处理它。你想向队列中放入多少消息就放多少，然后在你乐意的时候再去处理它们。
标签：-- 取数据 数据存储 独立 partition 版本 负载均衡 另一个 随机
原文地址：https://www.cnblogs.com/qiaoyihang/p/8794695.html
