设计数据密集型应用

《设计数据密集型应用》第七章(2) 事务:概念深入

2019-04-15  本文已影响0人  MeazZa

这一节,我们继续深入到事务的概念中,分析事务的ACID原则能够避免哪些出错的情况。在实际场景中,有一些事务的需要修改多行记录的,我们称之为多对象操作,另外一些是只修改一行记录的,称之为单对象操作

多对象的事务

假设一个场景,我们有一个邮件的收件箱,能够同时显示未读邮件,以及未读邮件的总数,总数可以通过以下的sql计算得到:

SELECT COUNT(*) FROM emails WHERE recipient_id = 2 AND unread_flag = true

因此这是一个需要修改数据库的多行记录才能完成的操作。

隔离性

在没有引入隔离性(Isolation)之前,用户2可能看到这样的操作数据:收件箱列表中存在一封未读邮件,但是未读邮件数为0。这种情况对应的数据库操作的过程如下图所示:

违背了隔离性

这种情况称之为Dirty Read,也就是一个事务读到了另一个事务还未commit的写操作。如果保证了事务的隔离性,则不会出现这种情况。

原子性

如果在写入的过程中出现错误,收件箱的内容和未读邮件数可能会不同步。如果是以事务方式提交,由于满足原子性,未读邮件数的更新失败时,事务会中止,并且以及插入的邮件也会回滚。

原子性避免了不一致的状态

对于多对象提交来说,需要一种方式判断属于同一事务的读写操作。在关系型数据库中,客户端通常以TCP的方式连接到服务器端,在BEGIN TRANSACTION和COMMIT之间的语句将被认为属于同一个事务。而在非关系型数据库中,并没有将操作组合的方法。即使有一些比如批量更新的API,也不一定保证操作是事务的。

单对象的事务

如果仅修改数据库中的一行数据,仍然存在原子性和隔离性的问题。考虑以下的问题,我们正在写入一个20K的json文档:

为了解决以上的问题,数据库需要对单对象操作支持原子性和隔离性。原子性可以通过日志文件实现崩溃时的恢复(例如B-Trees),隔离性可以通过对修改的对象加锁来实现,任何时刻只允许一个线程修改一个对象。

一些数据库提供了更复杂的原子操作,比如increment,不需要进行read-modify-write的循环,而是通过比如compare-and-set的操作,在数据库中的值不被修改时才会执行写操作。

多对象的事务需求

在很多分布式数据库中,他们放弃了支持多对象的事务,理由是跨分区的实现很困难,并且可以得到更好的可用性和性能。那么,多对象的事务是否可以不需要呢?

在有一些场景中,我们可以把多对象的操作,通过Key-value的数据模型,和单对象的操作来完成。但是仍然有一些场景,是必须要协调多对象数据的:

处理错误和中断

一些应用程序可以在没有事务的情况下工作,但缺少原子性会使得处理错误和中断会更加复杂,缺少隔离性会引起同步的问题。

事务的一个关键特性就是允许在发生错误时,可以安全的进行中断和重试。满足ACID的数据库会遵循以下的规则:宁可丢弃掉整个事务,也不会允许它只完成一半。

并不是所有的系统都遵循这一原则。比如对于数据副本架构采用leaderless模型的数据库,遵循的是尽可能完成最多的操作。因此在遇到错误时,不会撤销之前已经完成的操作,应用程序需要自行从该错误中恢复数据。

错误是一定会发生的,但有一些系统只会考虑乐观情况,在事务执行出错时不会进行重试,这可能会导致用户得到错误的数据。但如果在事务中断后,立即进行重试,也并不是最好的解决方案,可能会导致以下的问题:

小结

这两节介绍了关于事务的概念,包括ACID,多对象和单对象下的事务等。目前介绍的都是最严格的事务的概念,后面会介绍比事务更宽松的一些概念和实现。

上一篇 下一篇

猜你喜欢

热点阅读