我知道Kafka不是一个k/v商店，但请容忍我。假设它是使用下面的k/vapi大致实现的。每个键都是一个主题，键的当前“值”是写入主题的最后一条消息：
put(key, value) --> publish(topic=key, message=value)
get(key) --> consume(topic=key, offset = last_offset - 1)此外，假设在不同的kafka集群之间复制状态（双向使用mirrormaker），以允许用户读/写到更近的数据中心，从而减少延迟。
我已经知道这样做的一些明显的副作用，例如：
由于一个“键”Map到一个主题，为了保证排序，您只能有一个分区（因为您希望最后一个值总是放在日志的末尾）。
需要考虑保留策略，因为日志中的最后一条消息可能会被删除
如果您对离您最近的集群执行put（键、值），即使从技术上讲这是对该键的最新put，mirrormaker（由于延迟）可能会从另一个集群发布过期的键，从而覆盖您最近的put值
这里主要关注的是延迟，特别是不同集群之间的延迟。与传统的k/v解决方案（如redis、memcached或etcd）相比，您认为这种解决方案在紧张的工作负载（例如，对给定的键/主题每秒数千次写入）和紧张的网络条件下能起到什么作用？
思想？
谢谢你的好意。
1条答案
按热度按时间zmeyuzjn1#
kafka可以作为kv事件存储，实际上已经实现了一个改进：https://cwiki.apache.org/confluence/display/kafka/kip-67%3a+queryable+state+for+kafka+streams
下面是几个链接，其中有更多示例说明如何使用kafka流查询存储在kafka中的状态：https://blog.codecentric.de/en/2017/03/interactive-queries-in-apache-kafka-streams/, https://www.confluent.io/blog/unifying-stream-processing-and-interactive-queries-in-apache-kafka/
默认情况下，它使用rocksdb，但可插入：https://www.confluent.io/blog/introducing-kafka-streams-stream-processing-made-simple/
您必须考虑如何在应用程序级别管理存储，但实际上，您的问题是由kafka streams api管理的。
希望这有帮助。