所以,自从我第一次听说Kafka这个概念以来,我就很喜欢它,但直到最近我才有机会亲身体验它。我想我有一个可能适用的用例,但我想从更熟悉它的人那里得到一些意见。
基本上,我在考虑一个通知系统,它可以在给定的时间段(比如30分钟)内批量发送消息,并以电子邮件、应用程序内通知或其他方式发送出去。我喜欢Kafka解决这个问题,主要是因为它固有的耐用性。我曾考虑过使用更直接的消息队列,如rabbitmq、activemq、sqs等,但我不喜欢这样做,因为它会迫使我在使用者端管理缓冲,并有丢失消息的风险。否则,我将不得不在第二个持久存储区中进行缓冲,这似乎破坏了将队列放在第一位的目的。
因此,我的想法是按用户将通知分组到分区中,然后每隔30分钟,使用者将读取最后30分钟的数据,将其聚合,并发送一个由各个通知组成的摘要通知。
我有一些担心:
我认为这是一个很好的用例是不是疯了?通过一点谷歌搜索,我没有看到很多人谈论使用Kafka正是为了这个目的,但它似乎是如此完美的我。
我应该如何处理个别通知错误?例如,一个用户在30分钟的时间内收到50个通知,这些通知将被分为3个不同的消息,分别发送出去。假设两个成功一个失败,我应该如何处理重试逻辑?我发现了一些比较新的/晦涩难懂的东西https://github.com/softwaremill/kmq 这似乎试图解决这个问题,但我有点担心,我担心这只是不适合Kafka模式。
我是不是在逆来顺受?当然,这是人们每天都在解决的问题。有没有一个更简单更明显的技术,我忽略了?
感谢您的反馈!
1条答案
按热度按时间ldxq2e6h1#
现在回答这个问题可能太迟了,我想你可能已经有了解决办法。对于其他有同样想法的用户,我想说的是,你的想法非常好,尤其是在考虑使用Kafka流时。我正在建立一个项目称为轻电子邮件现在与Kafka流和Kotlin。目前,我正在考虑每个事件发送电子邮件;然而,在Kafka流中,在一个时间窗口内将多个事件聚合在一起是非常容易的。
澄清评论中的两点。
我们不需要为每个用户创建分区。只需要确保事件属于同一个用户,并转到同一个分区。这仅仅意味着我们需要散列userid以在分区之间实现负载平衡。
当消息发送失败时,应该将其移到死信主题以供以后处理。这是为了防止当前主题被阻止。