Question

我知道Kafka不是k / v商店，但请耐心等待。假设它是使用下面的k / v API粗略实现的。每个键都是一个主题，而当前的＆＃34;值＆＃34;密钥是写入主题的最后一条消息：

put(key, value) --> publish(topic=key, message=value)
get(key) --> consume(topic=key, offset = last_offset - 1)

此外，假设在不同的Kafka集群之间复制状态（使用MirrorMaker双向），以允许用户读取/写入更近的数据中心以减少延迟。

我已经知道这样做有一些明显的副作用，例如：

因为＆＃34;键＆＃34;映射到主题，您只能有1个分区以保证排序（因为您希望最后一个值 put 始终位于日志的末尾）。
需要考虑保留策略，因为可以删除日志中的最后一条消息
如果您对离您最近的群集执行put（键，值），即使从技术上讲，该键上最近的 put ，MirrorMaker（由于延迟）可能会发布过时的来自另一个群集的密钥，覆盖您最近的放置值

这里主要关注的是延迟，尤其是不同群集之间的延迟。与传统的k / v解决方案（如Redis，memcached或etcd）相比，您认为此解决方案如何在压力较大的工作负载（例如，针对给定密钥/主题的数千次写入/秒）和紧张的网络条件下保持不变？ / p>

思想？

谢天谢地。

Answer 1

您必须考虑如何在应用程序级别管理存储，但实际上，您的问题由Kafka Streams API管理。

希望这有帮助。