BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

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

| 作者 Jan Stenberg 关注 34 他的粉丝 ,译者 张卫滨 关注 13 他的粉丝 发布于 2016年3月21日. 估计阅读时间: 3 分钟 | QCon上海2018 关注大数据平台技术选型、搭建、系统迁移和优化的经验。

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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

期待~ by 张 占辉

期待 这样不能解决数据库的高并发吧

Re: 期待~ by 蔡 凯

削峰处理,能够解决,同时也需要做业务上的库表拆分

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

2 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT