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