小编Bri*_*ook的帖子

我知道 Kafka 不是 ak/v 商店，但请耐心听我说。假设它是使用下面的 k/v API 来粗略实现的。每个键都是一个主题，键的当前“值”是写入该主题的最后一条消息：

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

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

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

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

这里主要关注的是延迟，尤其是不同集群之间的延迟。与 Redis、memcached 或 etcd 等传统 k/v 解决方案相比，您认为该解决方案在压力大的工作负载（例如，给定键/主题上每秒数千次写入）和压力网络条件下的表现如何？

想法？

非常感谢你。