为了实现一致性，我们从事务方案转移到流处理方案

当系统变得越来越复杂，数据库会被拆分为多个更小的库，如果借助这些衍生库实现像全文搜索这样的功能，那么如何保证所有的数据保持同步就是一项很有挑战性的任务了，在最近的 QCon 伦敦会议上， Martin Kleppmann 通过演讲阐述了他的观点。

使用多个数据库时，最大的问题在于它们并不是互相独立的。相同的数据会以不同的形式进行存储，所以当数据更新的时候，具有对应数据的所有数据库都需要进行更新。保证数据同步的最常用方案就是将其视为应用程序逻辑的责任，通常会对每个数据库进行独立的写操作。这是一个脆弱的方案，如果发生像网络故障或服务器宕机这样的失败场景，那么对一些数据库的更新可能会失败，从而导致这些数据库之间出现不一致性。Kleppmann 认为这并不是能够进行自我纠正的最终一致性，至少相同的数据再次进行写操作之前，无法实现一致性：

这不是最终一致性，它更像是持续的不一致性。

传统的方案使用事务来实现原子性，但是 Kleppmann 认为这只有在一个数据库的时候才有效，如果是两个不同的数据存储的话，那么这就不太可行了。分布式事务（又称为两阶段提交）支持跨多个存储系统，但是Kleppmann 认为它也面临自身的挑战，如较差的性能和运维问题。

我们重新回过头来看一下这个问题，Kleppmann 认为有一种很简单的解决方案，那就是按照系统的顺序对所有的写操作进行排序，并且确保所有人在随后读取时遵循相同的顺序。他将其与确定性的状态机复制（deterministic state machine replication）进行了类比，对于相同的起始状态，给定的输入流在多次运行时将会始终产生相同的状态转换。

在leader（主）数据库中，同时会将所有的写入操作按照处理的顺序存储为流，然后一个或多个follower 数据库就能读取这个流并按照完全相同的顺序执行写入。这样的话，这些数据库就能更新自己的数据并成为leader 数据库的一致性备份。对于Kleppmann 来说，这是一个非常具有容错性的方案。每个follower 都遵循它在流中的顺序，在出现网络故障或宕机时，follower 数据库能够从上一次的保存点开始继续进行处理。

Kleppmann 还提到在实现上述场景时，使用 Kafka 作为工具之一。目前，他正在编写一个实现， Bottled Water ，在这个实现中，他使用了 PostgreSQL 来抽取数据变化，然后将其中继到 Kafka 中，代码可以在 GitHub 上获取到。

InfoQ 最近也发布了一个关于使用 Kafka 进行开发的演讲。

QCon 的参会者已经聆听到了 Kleppmann 的演讲， InfoQ 的读者稍后将也能看到。他还将演讲的slide 发布了出来。

查看英文原文： Moving from Transactions to Streams to Gain Consistency