kafka消息100万条需要在1分钟内新增到mysql的解决方案 kafka消息持久化多久

1、设计目标

• 消息持久化：以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上的数据也能保证常数时间复杂度的访问性能。
• 高吞吐：在廉价的商用机器上也能支持单机每秒10万条以上的吞吐量。
• 分布式：支持消息分区以及分布式消费，并保证分区内的消息顺序。
• 跨平台：支持不同技术平台的客户端（如Java、PHP、Python等）。
• 实时性：支持实时数据处理和离线数据处理。
• 伸缩性：支持水平扩展。

2、kafka优点

（1）解耦。Kafka具备消息系统的优点，只要生产者和消费者数据两端遵循接口约束，就可以自行扩展或修改数据处理的业务过程。

（2）高吞吐量、低延迟。即使在非常廉价的机器上，Kafka也能做到每秒处理几十万条消息，而它的延迟最低只有几毫秒。

（3）持久性。Kafka可以将消息直接持久化在普通磁盘上，且磁盘读写性能优异。

（4）扩展性。Kafka集群支持热扩展，Kaka集群启动运行后，用户可以直接向集群添。

（5）容错性。Kafka会将数据备份到多台服务器节点中，即使Kafka集群中的某一台加新的Kafka服务节点宕机，也不会影响整个系统的功能。

（6）支持多种客户端语言。Kafka支持Java、.NET、PHP、Python等多种语言。

3、架构

Kafka通过Zookeeper管理集群的元数据，发布订阅使用的是 send/pull模式

Kafka多区多副本的架构图，follow副本同步leader副本，为保证消息的正确性，消息只能从leader副本中读取消息

3.1、Broker

Kafka集群包含一个或者多个服务器，服务器的节点称为broker

3.2、Topic

• 每条发布到Kafka集群的消息都有一个类别，这个类别称为Topic
• 类似数据库中的表名或者ES的Index
• 物理上不同的Topic的消息分开存储
• 逻辑上一个Topic消息虽然保存于一个或者多个broker上，但用户只需要指定消息的Topic即可生成或者消费数据，而不必关心数据存于何处

3.3、Partition

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-zg2ef7lB-1624326626551)(Kafka.assets/3255441478-5dd54ee84879a_fix732.png)]

• topic的数据分割为一个或者多个partition
• 每个topic至少有一个partition，当生产者产生数据的时候，根据分配策略，选择分区然后将消息追加到指定的分区的末尾(队列)

## Partation数据路由规则
1. 指定了 patition，可以直接使用
2. 未指定 patition 但指定了key，通过对key的value进行hash选出一个patition
3. patition 和 key 都不指定，使用轮循选出一个 patition

• 每条消息都会有一个自增编号

• 标识顺序
• 用于标识消息的偏移量

• 每个 patition 中的数据使用多个 segment 文件存储。
• patition 中的数据是有序的，不同的 patition 间的数据丢失了数据的顺序。

• 标识顺序
• 用于标识消息的偏移量

• 每个partition中的数据使用多个segment文件存储
• partition中的数据时有序的，不同的partition间的数据丢失了顺序性
• 如果topic有多个partition，消费数据就不能保证顺序性。严格保证顺序性的消费场景下，需要将partition的数目设为1

4.4 Leader(Partition)

• 每个partition有多个副本，其中有且仅有一个作为Leader，Leader是当前负责数据读写的partition

1. producer 先从 zookeeper 的 “/brokers/.../state” 节点找到该 partition 的 leader
2. producer 将消息发送给 leader
3. leader 将消息写入本地 log
4. followers 从 leader pull 消息，写入本地log 后 leader 发送 ACK
5. leader 收到所有 ISR 中的 replica 的 ACK 后，增加HW（high watermark，最有commit 的 offset）并向producer发送ACK

4.5 Leader(replication)

• Follower跟随Leader，所有写请求都通过Leader路由，数据变更会广播给所有Follower，Follower与Leader保持数据同步。
• 如果Leader失效，则从Follower中选举出一个新的Leader。
• 当Follower挂掉、卡住或者同步太慢，leader会把这个follower从“in sync replicas”（ISR）列表中删除，重新创建一个Follower。

4.6 replication

• 数据会存放到topic的partation中，但是有可能分区会损坏
• 我们将分区分为Leader(1)和Follower(N)

• Leader负责写入和读取数据
• Follower只负责备份
• 保证了数据的一致性

• 备份数设置为N，表示主+备=N

## Kafka 分配Replica的算法如下
1. 将所有broker(假设共n个broker)和待分配的 partition 排序
2. 将第 i 个partition分配到第j个replica分配到第((i+j)mod n)个broker上

4.7 producer

• 生产者为数据发布者，该角色将消息发布到Kafka的topic中。
• broker接收到生产者发送的消息后，broker将该消息追加到当前用于追加数据的segment文件中
• 生产者发送消息，存储到一个partition中，生产者也可以指定数据存储的partition

4.8 consumer

• 消费者可以从broker中读取数据。消费者可以消费多个topic中的数据
• kafka提供了两套consumer API：

1. The high-level Consumer API
2. The SimpleConsumer API

• high-level consumer API 提供了一个从kafka消费数据的高层抽象，而SimpleConsumer API需要开发人员关注细节

4.9 Consumer Group

• 每个Consumer属于一个特定的Consumer Group（可为每个Consumer指定group name，若不指定group name则属于默认的group）
• 将多个消费者集中到一起去处理某一个Topic的数据，可以更快的提高数据的消费能力
• 整个消费者组共享一组偏移量(防止数据被重复读取)，因为一个Topic有多个分区

4.10 offset偏移量

• 可以唯一的标识一条消息
• 偏移量决定数据的位置，不会有线程安全的问题，消费者通过偏移量来决定下次读取的消息
• 消息被消费之后，并不被马上删除，这样多个业务就可以重复使用kafka的消息
• 我们某一个业务也可以通过修改偏移量大到重新读取消息的目的，偏移量由用户进行控制
• 消息最终还是会被删除的，默认生命周期为1周(7*24小时)

4.11 Zookeeper

• kafka通过zookeeper来存储集群的meta信息

结语

码字不易，希望能多多支持。