Kafka消息系统教程

基于DDD的EventSroucing事件溯源和CQRS的项目正在迅速发展，这里介绍两个开源项目：flowing-retail和

通过事件进行应用程序的设计是自20世纪80年代后期以来的一种实践。我们可以在前端或后端的任何地方使用事件。当按下按钮时，某些数据发生更改或执行某个后端动作。 但是事件究竟是什么呢？我们什么时候应该用它呢？缺点是什么？

Event sourcing事件溯源作为应用程序架构模式日益普及，事件溯源将应用程序所做的状态更改建模为不可变的序列，也就是“事件日志”，也就是将触发状态更改的事件存储在不可变日志中，并将状态更改重新建模为对日志中事件的响应。这里讨论Kafka Streams将如何帮助将事件溯源和CQRS付诸实践。

该文是介绍在纽约时报如何使用Kafka实现内容生产和内容消费分离的基于日志的架构(一种事件溯源Event Sourcing/CQRS的读写分离架构)。文章还阐述了使用Kafka替代传统数据库作为事实存储的原因。 原文大意如下：

所有数据流水线的唯一要求是它们不能丢失数据。可以延迟或重新排序，但不能丢失。 为了满足这一要求，大多数分布式系统实现至少保证一次(least-once)传递。实现至少一次传递的技术通常等于：“重试，重试，重试”。直到在收到消费者的确认之前，否则永远不会认为

缓存在Netflix无处不在，Netflix大量采用的是微服务架构，可以实现粒度更细的分离关注，大概部署了数百个微服务，每个都是专注做好一件事，这使得整个系统的耦合非常松散，大多数服务是无态的，也就更加易于扩展，这些服务之所以可以无状态，是因为将状态放在了缓存或持久存储中。

Apache Kafka卡夫卡是无可争议的游戏改变者。它是真正数据库分水岭技术。 MySQL数据库目前很流行数据库，在2000-2010年蓬勃发展，由于其巨大的人气，MySQL帮助刺激了2008-2009年的NoSQL的崛起。数据库历史到了一个新的时刻：传

这里介绍Slack公司是如何使用Kafka和Redis作为分布式任务队列（类似国内当当网的elastic-job），以毫秒级可靠地处理数十亿个任务。 Slack是一家提供协作工具的SaaS公司，提供聊天群组 + 大规模工具集成 + 文件整合 + 统一搜索四

该文详细介绍了Kafka消费者原理和使用策略，如果我们将消费者的偏移量使用JDBC事务或JTA事务保存起来，就能实现分布式端到端的事务，也就是通常所说的分布式事务。 消费者是否活着

Sqlstream是能够作为复制者连接到MySQL服务器，将复制事件读取到Apache Kafka的topic，这些事件能够产生JSON序列号形式的map, key是产生事件的server-id。