神刀安全网

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

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

转载本站任何文章请注明:转载至神刀安全网,谢谢神刀安全网 » 为了实现一致性,我们从事务方案转移到流处理方案

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址
分享按钮