Kafka 的稳定性.doc
2.虚拟产品一经售出概不退款(资源遇到问题,请及时私信上传者)
Kafka 的稳定性 Kafka 的稳定性是指 Kafka 系统在面临各种故障和异常情况下的可靠性和稳定性。为了确保 Kafka 的稳定性,Kafka 引入了事务机制,用于解决分布式事务问题。 1. 事务简介 事务是指producer 发送的多条消息组成的一个事务,这些消息需要对 consumer 同时可见或者同时不可见。producer 可能会给多个 topic,多个 partition 发消息,这些消息也需要能放在一个事务里,这就形成了一个典型的分布式事务。 1.1 事务场景 在 Kafka 的应用场景中经常是应用先消费一个 topic,然后做处理再发到另一个 topic,这个 consume-transform-produce 过程需要放到一个事务里,因为在消息处理或者发送的过程中如果失败了,消费偏移量也不能提交。 1.2 关键概念和推导 由于 producer 发送消息可能是分布式事务,所以引入了常用的 2PC,因此有事务协调者(Transaction Coordinator)。事务管理中事务日志是必不可少的,Kafka 使用一个内部 topic 来保存事务日志,这个设计和之前使用内部 topic 保存偏移量的设计保持一致。 事务日志使 Transaction Coordinator 管理的状态的持久化,因为不需要回溯事务的历史状态,所以事务日志只用保存最近的事务状态。由于事务存在 commit 和 abort 两种操作,而客户端还有 read committed 和 read uncommitted 两种隔离级别,所以消息队列必须能标识事务状态,这个被称作 Control Message。 producer 挂掉重启或者漂移到其他机器,需要能关联到之前的未完成事务,所以需要有一个唯一标识符来进行关联,这个就是 TransactionalId,一个 producer 挂了,另一个有相同 TransactionalId 的 producer 能够接着处理这个事务未完成的状态。Kafka 目前没有引入全局序,所以也没有 transaction id,这个 TransactionalId 是用户提前配置的。 TransactionalId 能关联 producer,也需要避免两个使用相同 TransactionalId 的 producer 同时存在,所以引入了 producer epoch 来保证对应一个 TransactionalId 只有一个活跃的 producer epoch。 1.3 事务语义 多分区原子写入:事务能够保证 Kafka topic 下每个分区的原子写入。事务中所有的消息都将被成功写入或者丢弃。 首先,我们来考虑一下原子读取-处理-写入周期是什么意思。简而言之,这意味着如果某个应用程序在某个 topic tp0 的偏移量 X 处读取到了消息 A,并且在对消息 A 进行了一些处理(如 B = F(A)),之后将消息 B 写入 topic tp1,则只有当消息 A 和 B 被认为被成功地消费并一起发布,或者完全不发布时,整个读取过程写入操作是原子的。 现在,只有当消息 A 的偏移量 X 被标记为已消费,消息 A 才从 topic tp0 消费,消费到的数据偏移量(record offset)将被标记为提交偏移量(Committing offset)。在 Kafka 中,我们通过写入一个名为 offsets topic 的内部 Kafka topic 来记录 offset commit。消息仅在其 offset 被提交给 offsets topic 时才被认为成功消费。 由于 offset commit 只是对 Kafka topic 的另一次写入,并且由于消息仅在提交偏移量时被视为成功消费,所以跨多个主题和分区的原子写入也启用原子读取-处理-写入循环:提交偏移量 X 到 offset topic 和消息 B 到 tp1 的写入将是单个事务的一部分,所以整个步骤都是原子的。 粉碎“僵尸实例”:我们通过为每个事务 Producer 分配一个称为 transactional.id 的唯一标识符来解决僵尸实例的问题。在进程重新启动时能够识别相同的 Producer 实例。
剩余51页未读,继续阅读
- 粉丝: 1
- 资源: 2834
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助