我正在使用Kafka,我们有一个用例来构建一个容错系统,甚至连一条消息都不会错过.所以这就是问题所在：
如果由于任何原因(ZooKeeper down,Kafka broker等)向Kafka发布失败,我们如何能够有效地处理这些消息并在事情再次恢复后重播它们.正如我所说的那样,即使单个消息失败也无法承受.
另一个用例是我们还需要在任何给定时间点知道有多少消息由于任何原因而无法发布到Kafka,例如计数器功能,现在这些消息需要再次重新发布.
如果由于任何原因(ZooKeeper down,Kafka broker等)向Kafka发布失败,我们如何能够有效地处理这些消息并在事情再次恢复后重播它们.正如我所说的那样,即使单个消息失败也无法承受.
另一个用例是我们还需要在任何给定时间点知道有多少消息由于任何原因而无法发布到Kafka,例如计数器功能,现在这些消息需要再次重新发布.
其中一个解决方案是将这些消息推送到某个数据库(如Cassandra,其中写入速度非常快,但我们还需要计数器功能,我猜Cassandra计数器功能并不是那么好,我们不想使用它.)可以处理这种负载也为我们提供了非常准确的计数器设施.
这个问题更多来自架构方面,然后是使用哪种技术来实现这一目标.
PS：我们处理像3000TPS这样的地方.因此,当系统启动失败时,这些失败的消息可以在非常短的时间内快速增长.我们正在使用基于java的框架.
谢谢你的帮助！
解决方法
Kafka以分布式,容错的方式构建的原因是处理与您的问题完全相同的问题,核心组件的多次故障应该避免服务中断.要避免关闭Zookeeper,请至少部署3个Zookeepers实例(如果这是在AWS中,请在可用区域中部署它们).要避免代理失败,请部署多个代理,并确保在生产者bootstrap.servers属性中指定多个代理.要确保Kafka集群已将您的消息写入持久的庄园,请确保在生产者中设置了acks = all属性.当所有同步副本确认收到消息时(以吞吐量为代价),这将确认客户端写入.您还可以设置排队限制,以确保如果对代理的写入开始备份,您可以捕获异常并处理它并可能重试.
使用Cassandra(另一个经过深思熟虑的分布式,容错系统)来“分级”你的写入似乎不会给你的架构增加任何可靠性,但确实增加了复杂性,而且Cassandra没有被编写为一个消息队列一个消息队列,我会避免这种情况.
如果配置正确,Kafka应该可以处理所有的消息写入并提供适当的保证.