http: www confluent io blog event-sourcing-cqrs-stream-processing-apache-kafka-whats-connection Event sourcing as an ap


Event sourcing as an application architecture pattern is rising in popularity. Event sourcing involves modeling the state changes made by applications as an immutable sequence or “log” of events. Instead of modifying the state of the application in-place, event sourcing involves storing the event that triggers the state change in an immutable log and modeling the state changes as responses to the events in the log. We previously wrote about event sourcing, Apache Kafka and how they are related. In this post, I explore these ideas further and show how stream processing and, in particular, Kafka Streams helps to put Event sourcing and CQRS into practice.

事件驱动(Event sourcing)作为应用程序架构的一种模式现在越来越流行了。事件驱动包括了将应用程序产生的状态改变数据建模成不可变的序列、或者说是事件的日志。它不是直接就地修改应用程序的状态,事件驱动会将触发状态改变的事件存储到一个不可变的日志,在日志中将状态改变建模成针对发生事件的响应。在 之前的文章 中,我们阐述了事件驱动和Kafka的关系。本篇文章,我们会更进一步探索这些思想,并且会展示流处理,更准确的说是Kafka Streams,怎么帮助我们将事件驱动和CQRS运用在实际中。

Let’s take an example. Consider a Facebook-like social networking app (albeit a completely hypothetical one) that updates the profiles database when a user updates their Facebook profile. There are several applications that need to be notified when a user updates their profile — the search application so the user’s profile can be reindexed to be searchable on the changed attribute; the newsfeed application so the user’s connections can find out about the profile update; the data warehouse ETL application to load the latest profile data into the central data warehouse that powers various analytical queries and so on.


译:Kafka事件驱动和流处理 基于事件驱动的架构

Event sourcing involves changing the profile web app to model the profile update as an event — something important that happened — and write it to a central log, like a Kafka topic. In this state of the world, all the applications that need to respond to the profile update event, merely subscribe to the Kafka topic and create the respective materialized views – be it a write to cache, index the event in Elasticsearch or simply compute an in-memory aggregate. The profile web app itself also subscribes to the same Kafka topic and writes the update to the profiles database.



There are several advantages to modeling applications to use event sourcing — It provides a complete log of every state change ever made to an object; so troubleshooting is easier. By expressing the user intent as an ordered log of immutable events, event sourcing gives the business an audit and compliance(合规性审计) log which also has the added benefit of providing data provenance(起源). It enables resilient(弹性) applications; rolling back applications amounts to rewinding(绕回) the event log and reprocessing data. It has better performance characteristics; writes and reads can be scaled independently. It enables a loosely coupled(松耦合) application architecture; one that makes it easier to move towards a microservices-based architecture. But most importantly:

Event sourcing enables building a forward-compatible(向前兼容) application architecture — the ability to add more applications in the future that need to process the same event but create a different materialized view.


For the upsides mentioned above, there are some downsides as well. Event sourcing has a higher learning curve(曲线); it is a new and unfamiliar programming model. The event log might involve more work to query it as it requires converting the events into the required materialized state suitable to query.

That was a quick introduction to event sourcing and some tradeoffs. This article is not meant to go into details of event sourcing or advocate for it’s usage. You can read more about event sourcing and various tradeoffs here .




CQRS和Kafka Streams


方案2:应用程序状态存储到Kafka Streams的本地状态

Kafka Streams的交互式查询