1
我知道卡夫卡不是K/V店，但忍受着我。假設它大致使用下面的k/v API實現。每個鍵是一個主題，並且鍵的當前「值」被寫入到該主題的最後一條消息：使用Apache Kafka作爲關鍵/值存儲的副作用是什麼？
put(key, value) --> publish(topic=key, message=value)
get(key) --> consume(topic=key, offset = last_offset - 1)
此外，假設狀態不同卡夫卡簇（使用MirrorMaker雙向）之間進行復制，如允許用戶讀取/寫入更近的數據中心以減少延遲。
我已經知道了一些這樣的明顯的副作用，例如：
- 由於「鍵」映射到一個話題，你只能有1分，以保證訂購（因爲你想要最後一個值將始終放在日誌的末尾）。
- 保留策略需要考慮，因爲如果你認沽（鍵，值）離您最近的簇，儘管這在技術上是最近日誌中的最後一條消息可以刪除
- 把該鍵，MirrorMaker（由於等待時間）可以從另一組發佈了過時的關鍵，覆蓋最近的認沽值
這裏的主要問題是延遲，尤其是不同集羣之間。與傳統的k/v解決方案（如Redis，memcached或etcd）相比，您認爲這種解決方案在壓力大的工作負載下（比如，對於給定的關鍵/主題，每秒寫入數千次）以及網絡條件壓力大？
想法？
謝謝。