别再混淆事件源（Event Sourcing）和消息流（Message Streaming）了！
别再混淆事件源（Event Sourcing）和消息流（Message Streaming）了！
0 前言
Kafka 不适合事件溯源，Kafka适合消息流。这两种事物需要不同存储机制。
- 事件溯源（Event Sourcing），需DB充当事件日志，为事件溯源存储的事件必须以某种方式编写，以便将来的读取能够快速组装属于单个聚合的较小（更小的）事件流最初发射它们的。这需要随机访问索引
- 消息流（Message Streaming），需要的存储本质上是个记录消息元素的“flat file”。消息元素按序单独写，然后按序读。这需要一个从第一到最后一个的顺序索引
1 细分
除了聚合子流，事件源域模型的所有事件通常都按照聚合最初发出的时间顺序作为全序事件流。为此还需要一个顺序索引。因此，事件溯源数据库须支持两种类型的索引。
而Kafka不适合事件溯源数据库记录。记录消息的是topic。Kafka 是一个消息日志，可有很多topic。 Kafka 有一个索引，即全序消息流的序列号。
因此，将消息写入Kafka topic后，由于随机访问索引并不存在，无法随机读取消息。Kafka也根本不是为此而设计的。
使用 Kafka，如需读取最初由单个聚合实例发出的小（或较小）事件流，你将不得不从第一条消息扫描到最后一条，以确保你没错过读取单个聚合流中的所有事件。这将导致 O(N) 读取时间——随每个新消息的写入，读取速度变慢。你有 10 亿个总事件，需读取其中任意 5 个作为单个聚合事件流？"不可能发生"。
对那些认为自己可以超越物理学的顽固的人，还有如下关键点：
2 补充
“我知道，我知道！我将为每个聚合实例使用不同的topic！”如果 Kafka 的设计目的是在单broker下支持数百万、数十亿到数万亿个topic，那也没关系。但事实并非如此。
“我知道，我知道！我将使用 K-Table 维护每个聚合实例的快照，以便我快速读取它们！”重构聚合的状态必须优先于消耗所有事件的完全有序流。如果你尝试这样做，你的 K-Table 快照最终只会与真实的当前聚合状态一致 - 聚合无法可靠地读取它自己的状态。
虽然很常见，但事件溯源解决方案支持从日志中重新补充各个域对象并不是绝对必要的。如某些实现从单个流重建整个系统状态。这一切都取决于具体要求。
关注我，紧跟本系列专栏文章，咱们下篇再续！
作者简介：魔都国企技术专家兼架构，多家大厂后台研发和架构经验，负责复杂度极高业务系统的模块化、服务化、平台化研发工作。具有丰富带团队经验，深厚人才识别和培养的积累。
参考：