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

by Jan Stenberg on Mar 13, 2016

摘要：

在系统中，众多的数据库之间很少是彼此独立的，相反，有一些相同的数据会分散存储到其中的多个数据库中。通过事务来保证所有数据之间的同步是一种脆弱的方案。如果将变更按照流的方式进行组织，并且遵循创建时的顺序，那么这会是一种更加简单和更加具有弹性的方案，Martin Kleppmann在最近的QCon伦敦中，通过演讲阐述了该方案。

当系统变得越来越复杂，数据库会被拆分为多个更小的库，如果借助这些衍生库实现像全文搜索这样的功能，那么如何保证所有的数据保持同步就是一项很有挑战性的任务了，在最近的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