微服务架构本地尝试(7)-分布式事务

2019年3月10日 5407点热度 2人点赞 0条评论

来了解一下分布式事务,事务简单来说就是:"要么什么都不做,要么做全套"

本地事务

平常我们的事务都是在同一个数据库中执行.

举个栗子:当你发帖的时候,需要发表帖子存入数据库,然后再给这个发帖的用户增加积分.如果帖子存入数据库失败,那么就不再往下执行;但是你增加积分失败了,然而你的帖子已经发布出去了,总不可能再去删除刚刚发的那条帖子吧.如果你使用了事务的话,那么可以在一项失败的时候,回滚事务,一切就像没有发生一样.

ACID模型

说到事务就不得不说A(原子性)C(一致性)I(隔离性)D(持久性),来贴一下百科说明.

Atomicity（原子性）：一个事务（transaction）中的所有操作，或者全部完成，或者全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被恢复（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。即，事务不可分割、不可约简。
Consistency（一致性）：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设约束、触发器、级联回滚等。
Isolation（隔离性）：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括读未提交（Read uncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化（Serializable）。
Durability（持久性）：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。

分布式事务

像上面一样的场景,但是这个时候我们是微服务架构啦.帖子数据库和积分数据库不在一起,他们分别在两个不同的数据库上面.

如果发帖失败,我们可以选择不再往下走,增加积分(我就当发帖先执行,积分增加后执行).但是如果发帖成功了,但是积分增加失败,这样就导致了数据的不一致.这种情况还算好,但是如果订单下成功了,钱没扣,造成的损失就大了不是.

于是我们需要通过一些手段,实现不同数据库之间的事务,这就是分布式事务了.

还有一些分库分表的应用也会用到分布式事务.

CAP定理

CAP定理指的是在分布式系统中最多只能满足C,A,P中的两个需求.

一致性(Consistency)

一致性指的在不同的服务器中,数据都是一致的.在分库分表的环境下,这个一致指的是A库中的A表和B库中的A表里面的数据是一模一样的;在我们上面所说的场景中指的是,发帖应得到的积分,和我们实际的积分数量应该是一致的.(为什么说这些,因为我感觉好多地方说的一致都是指的前者,我这个理解应该没错吧hhh)

一致性也可以分为下面3类
* 强一致性:执行完成后,后面不管什么时候读取,数据都是更新完毕后的.比如发完贴之后,我立刻就可以看到我的积分增加.
* 弱一致性:执行完成后,不能保证数据会更新,多久会更新.比如发完贴之后,过了很久很久,我的积分都不一定变化了.(感觉是不是失败了...可能是某些场景下的吧)
* 最终一致性:执行完后,一段时间内,数据更新.比如发帖完之后,过了一两秒,我就能看到我的积分变化了.这个是弱一致性的一种特殊情况,大多数分布式系统也是采用这种模式.