使用Kafka作为（CQRS）事件库。 好主意？
虽然我以前碰到过Kafka ，但是最近才意识到Kafka也许可以作为一个CQRS 事件库的基础。
卡夫卡支持的主要观点之一是：
- 事件捕获/存储，当然是所有的HA。
- Pub / Sub架构
- 能够重放事件日志，允许新用户在事后注册系统。
无可否认，我并不是100％熟悉CQRS /事件采购，但这似乎与事件应该是非常接近的。 有趣的是：我真的无法find关于卡夫卡被用作事件库的很多东西，所以也许我一定会错过一些东西。
那么，卡夫卡有什么遗漏，因为它是一个很好的事件？ 它会工作吗？ 使用它生产？ 对洞察力，链接等感兴趣
基本上，根据系统所接收的事务/事件来保存系统的状态，而不是仅保存通常所做的系统的当前状态/快照。 （把它看作会计中的一个总账：所有的交易最终总计到最终的状态）这允许各种各样的很酷的事情，但只是在提供的链接上阅读。
卡夫卡是一个消息系统，它与事件存储有很多相似之处，但引用他们的介绍：
Kafka集群保留所有已发布的消息，无论是否已被消费，只需要一段可configuration的时间 。 例如，如果保留时间设置为两天，那么在发布消息之后的两天内，可用于消费，之后将被丢弃以释放空间。 卡夫卡的性能在数据大小方面是有效的，因此保留大量数据不成问题。
因此，虽然消息可能无限期地保留，但是期望的是它们将被删除。 这并不意味着你不能使用这个作为事件存储，但使用其他的东西可能会更好。 看看EventStore的替代scheme。
UPDATE
卡夫卡文档 ：
事件源是应用程序devise的一种风格，其中状态更改以时间sorting的logging序列进行logging。 Kafka对非常大的存储日志数据的支持使得它成为以这种风格构build的应用程序的优秀后端。
更新2
使用Kafka进行事件采购的一个问题是所需主题的数量。 通常在事件采购中，每个实体（例如用户，产品等）都有事件的stream（话题）。 这样，实体的当前状态可以通过重新应用stream中的所有事件来重构。 每个Kafka主题由一个或多个分区组成，每个分区作为目录存储在文件系统中。 随着znodes数量的增加，ZooKeeper也将面临压力。
我是卡夫卡的原作者之一。 卡夫卡将作为事件采购的日志很好地工作。 它具有容错能力，扩展到庞大的数据大小，并具有内置的分区模型。
我们在LinkedIn上用这个表单的几个用例。 例如，我们的开源stream处理系统Apache Samza 内置了对事件采购的支持 。
我认为你没有听说过使用卡夫卡进行事件采购，因为事件采购术语在卡夫卡最受欢迎的消费者networking空间似乎并不普遍。
我在这里写了一些关于这种卡夫卡用法的文章。
