【问题标题】:Which messages should be published to a Kafka topic, and when?哪些消息应该发布到 Kafka 主题,何时发布?
【发布时间】:2020-06-24 07:41:33
【问题描述】:

我有一些服务,例如Catalog ServiceCustomer ServiceRecommendations ServiceOrder Taking Service 等等...,每个服务在Cassandra 数据库中都有自己的Keyspace

我有两个问题:

1 - 对于服务中的更改:我应该首先将更改的事件(或记录)发布到Kafka,然后从同一服务中使用它以更新其数据库,还是我应该先更新其数据库并然后将记录发布到Kafka ?

2 - 如何选择要发布到Kafka 的更改,我是否应该将所有更新发布到Kafka,即使是那些对其他服务不感兴趣的更新,例如"attribute X updated to Y for product Z"

【问题讨论】:

  • 听起来您可能想尝试事件风暴(与 kafka 细节无关)。考虑系统中发生的事件,将它们组合成逻辑片段。不要从服务的角度来考虑,而是要考虑响应什么而发生的操作序列

标签: apache-kafka domain-driven-design event-driven-design


【解决方案1】:

1) 我建议您始终尝试阅读您的文章。哪种手术更容易成功?来自 Kafka 的复制 ack,还是持久的 Cassandra upsert?如果您认为 Kafka 更耐用,那么您可以在此处编写它,然后使用 Kafka Connect 之类的工具将其写入 Cassandra(假设您确实需要 Cassandra 而不是 Global KTable,这是有争议的)

2) 没有直接的答案。如果你认为数据会以可能相关的方式被消费,那么就产生它。把它想象成任何和所有事件的审计日志。如果您想构建一个始终知道任何产品的最新状态和发生的所有更改的幂等系统,那么您可以每次将整个对象存储为 (id, product) 对,在其中整体更新整个产品,或者您可以存储更改的每个增量并从中重建状态

【讨论】:

  • 好的,第一点我就知道了。所以对于第二点,我知道一旦涉及到 Kafka,我应该尽量避免直接写入数据库,并且更喜欢使用来自 Kafka 的所有内容,即使事件完全在服务内部,因为该日志可能在未来,比如重建消费者,对吧?
  • 看来你明白了。您的服务可以在不同的线程上拥有生产者和消费者,甚至(最好通过 Kafka Streams API)。与内存调用相比,唯一的缺点是网络往返
  • @criket_007,我有另一个担心,相关的我认为:有没有办法在 Kafka 集群中对主题进行分类?例如一种说法:这些主题是关于Orders Tracking,还是我应该依赖命名约定?我仍在文档中寻找它。
  • 不幸的是,命名约定是狂野的西部。我认为主题最多可以包含 255 个字符,因此在 kebab-case 中添加前缀是我见过的最流行的标准。如果您混合使用下划线和句点,则可能更难收集指标
猜你喜欢
  • 2016-01-17
  • 2020-01-18
  • 1970-01-01
  • 1970-01-01
  • 2018-10-27
  • 2018-06-20
  • 1970-01-01
  • 2017-03-05
  • 1970-01-01
相关资源
最近更新 更多