你可能用错了 kafka 的重试机制.docxVIP

  1. 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
  2. 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  3. 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  4. 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  5. 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  6. 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  7. 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
你可能用错了 kafka 的重试机制 Kafka 是用来处理数据流的系统。从概念上讲,我们可以认为 Kafka 包含三个基本组件: ? 一个大事日志(Event Log),消息会发布到它这里 发布者(Publisher),将消息发布到大事日志 消费者(Consumer),消费(也就是使用)大事日志中的消息 ? 与 RabbitMQ 之类的传统消息队列不同,Kafka 由消费者来打算何时读取消息(也就是说,Kafka 接受了拉取而非推送模式)。每条消息都有一个偏移量(offset),每个消费者都跟踪(或提交)其最近消费消息的偏移量。这样,消费者就可以通过这条消息的偏移量恳求下一条消息。 主题 大事日志分为几个主题(topic),每个主题都定义了要发布给它的消息类型。定义主题是我们这些工程师的责任,所以我们应当记住一些阅历法则: ? 每个主题都应描述一个其他服务可能需要了解的大事。 每个主题都应定义每条消息都将遵照的一个独一模式(schema)。 分区和分区键 主题被进一步细分为多个分区(partition)。分区使消息可以被并行消费。Kafka 允许通过一个分区键(partition key)来确定性地将消息安排给各个分区。分区键是一段数据(通常是消息本身的某些属性,例如 ID),其上会应用一个算法以确定分区。 这里,我们将消息的 UUID 字段安排为分区键。生产者应用一种算法(例如依据分区数修改每个 UUID 值)来将每条消息安排给一个分区。 ? 以这种方式使用分区键,使我们能够确保与给定 ID 关联的每条消息都会发布到单个分区上。 ? 还需要留意的是,可以将一个消费者的多个实例部署为一个消费者组。Kafka 将确保给定分区中的任何消息将一直由组中的同一消费者实例读取。 在微服务中使用 Kafka Kafka 格外强大。所以它可用于多种环境中,涵盖众多用例。在这里,我们将重点引见微服务架构中最常见的用法。 跨有界上下文传递消息 当我们刚开头构建微服务时,我们很多人一开头接受的是某种中心化模式。每条数据都有一个驻留的单一微服务(即单一真实来源)。假如其他任何微服务需要访问这份数据,它将发起一个同步调用以检索它。 ? 这种方法导致了很多问题,包括同步调用链较长、单点毛病、团队自主权下降等。 ? 最终我们找到了更好的方法。在今日的成熟架构中,我们将通信分为命令处理和大事处理。 ? 命令处理通常在单个有界上下文中执行,并且往往还是会包含同步通信。 ? 另一方面,大事通常由一个有界上下文中的服务发出,并异步发布到 Kafka,以供其他有界上下文中的服务消费。 左侧是我们以前设计微服务通信的方式:一个有界上下文(由虚线框表示)中的服务从其他有界上下文中的服务接收同步调用。左边是我们如今的做法:一个有界上下文中的服务发布大事,其他有界上下文中的服务在本人空闲时消费它们。 ? 例如,以一个 User 有界上下文为例。我们的 User 团队会构建担任启用新用户、更新现有用户帐户等任务的应用程序和服务。 ? 创建或修改用户帐户后,UserAccount 服务会将一个相应的大事发布到 Kafka。其他感爱好的有界上下文可以消费该大事,将其存储在本地,使用其他数据添加它,等等。例如,我们的 Login 有界上下文可能想晓得用户的当前名称,以便在登录时向他们致意。 我们将这种用例称为跨边界大事发布。 ? 在执行跨边界大事发布时,我们应当发布聚合(Aggregate)。聚合是自包含的实体组,每个实体都被视为一个单独的原子实体。每个聚合都有一个“根”实体,以及一些供应附加数据的从失实体。 ? 当管理聚合的服务发布一条消息时,该消息的负载将是一个聚合的某种表示方式(例如 JSON 或 Avro)。重要的是,该服务将指定聚合的独一标识符作为分区键。这将确保对任何给定聚合实体的更改都将发布到同一分区。 出问题的时候怎样办? 虽然 Kafka 的跨边界大事发布机制显得相当优雅,但到底这是一个分布式系统,因而系统可能会有很多错误。我们将关注或许是最常见的恼人问题:消费者可能无法成功处理其消费的消息。 我们现在该怎样办? 确定这是一个问题 团队做错的第一件事就是根本没无意识到这是一个潜在的问题。消息失败时有发生,我们需要制定一种策略来处理它……要未雨绸缪,而非亡羊补牢。 ? 因而,了解这是一种迟早会发生的问题并设计针对性的处理方案是我们要做的第一步。假如我们做到了这一点,就应当向本人表示一点庆祝。现在最大的问题仍旧存在:我们该如何处理这种情况? 我们不能一直重试那条消息吗? 默认情况下,假如消费者没有成功消费一条消息(也就是说消费者无法提交当前偏移量),它将重试同一条消息。那么,莫非我们不能简约地让这种默认行为接管一切,然后重试消息直到成功吗? ? 问题是这条消息可能

文档评论(0)

bob157641554 + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档