Nodejs 分布式事务

in 编程
关注公众号【好便宜】( ID:haopianyi222 ),领红包啦~
阿里云,国内最大的云服务商,注册就送数千元优惠券:https://t.cn/AiQe5A0g
腾讯云,良心云,价格优惠: https://t.cn/AieHwwKl
搬瓦工,CN2 GIA 优质线路,搭梯子、海外建站推荐: https://t.cn/AieHwfX9

事务是恢复和并发控制的基本单位,保证 ACID:原子性、一致性、隔离性、持久性。

对于全是异步的 Nodejs 而言, 并不适合做事务操作:

  1. 代码书写上:


    • try ... catch ... 是写给人看的,但是属于同步方法,局限性很大。

    • callback 简直是噩梦。

    • Promise.then(...).catch(...) 相对而言好一点。

    • ES7 的 async ... await ... 比较清爽,使用 Babel 编译,这是笔者目前找到的最人类的方式,但是和原来的 Promise 混合使用的时候有时候会出问题,因为编译之后的代码没法看,最后还得重构回 Promise

  2. 异步:


    • 异步导致有可能有意料之外的 uncaughtExceptionError

    • 对于 JAVA/C++ 这样语言,出错能直接转到 catch 中,但是 Node 不是,uncaughtExceptionError 将直接导致处理链断掉,你只能通过其他方式保证数据一致性。

虽然 Node 做事务相当非人类,但是考虑开发效率 / 成本,使用 Node 进行开发并不比换语言开差,毕竟事务只有核心业务需要用到。

单点

单机的事务相当容易保证,特别在依赖 MySQL 或者其他关系数据库时。

Nodejs 有 ORM (如 Sequelize ) 支持事务,也可以直接使用 PROCEDURE/FUNCTION

两者各有优势:

实际开发过程中可以将两者结合起来一起使用,使用 ORM 完成逻辑,使用存储过程减少 IO 次数。

单机事务

分布式

对于分布式系统,相信很多人都知道 CAP 理论,即任何一个分布式系统无法同时满足:

但是实际上 Consistency 是任何一个系统都不可能放弃的,分布式事务亦是为了保证数据一致性,有时候为了妥协另外两个特性,会放弃强一致性,保证最终一致性

解决方式

目前业界有很多解决分布式事务的方案,根据对数据一致性的强弱要求,可以选择不同的方案,但是解决思路大致如下:

  1. 两阶段提交

如 XA 协议(TM(事务管理器)和RM(资源管理器)之间的接口)。

假设有 A、B、C 三个操作,第一阶段,等待 A B C 均就绪,第二阶段,提交 A B C;如果第一阶段 A 失败了,则第二阶段回滚 B C。

两阶段提交

  1. 本地事务

使用本地消息表,将远程事务拆分成一个个本地事务,写入本地表中,然后 定时 / 使用 MQ 通知事务方。

两者各有利弊,定时扫描可能大部分时候都在做无用功,而只使用 MQ 可能会有失败 / 多次消费的问题。

  1. 使用回滚接口

如 A B 两个接口,串行处理,B 失败了回滚 A ,但是回滚也可能失败,所以也需要使用本地事务表 / MQ。

回滚接口

使用 Node 开发,1 比较重型,不适合;2 和 3 是比较好的选择:

  1. 选择一款可靠的 MQ 服务(单次消费 / 失败重试);

  2. 拆分本地事务;

  3. 不能拆分的事务,保证回滚。

举个栗子

做一个抢购系统,用户使用虚拟币进行抢购,虚拟币是另外一套系统。为了考虑到公平,每个用户还可能要限制购买上限。

这样用户一次抢购的完整流程如下:

  1. 检查购买上限

  2. 检查总数

  3. 扣除虚拟币

  4. 写入数据库

需要事务保证的地方就是 3 和 4,3 是远程事务,4 是本地事务,此栗子中必然是串行操作,3 在前,4 在后。

0x0001

这个时候流量很少,并发不高,将 3 和 4 作为一个事务,保证一起成功,而失败一起回滚。

事务 4 即使使用 ORM 完成,也能完成功能,这个时候系统能很好的工作。

0x0010

流量上升中,抢购的商品变多,并发也变大,这个时候,考虑使用 Redis 来提高性能了(牺牲强一致性):

将 购买上限 与 总数 写入 Redis,在压力转嫁到数据库之前就挡掉,由于 Redis 的强大性能,可以假设 Redis 等同于内存操作,做好回滚就可以了。

同时可以将事务 4 重构成 PROCEDURE 防止 ORM 可能回滚失败。

0x0011

流量大到数据库扛不住了,加入 MQ 服务:

version 3

使用 Redis 抗住流量,使用 MQ 抗住压力,使用 PROCEDURE 降低 IO 。

0x0011 看起来像一个可靠的系统了,但是还有一个隐患: uncaughtExceptionError 或者 程序宕掉了,这个会影响最终一致性,导致 Redis 数据与 Database 中的数据在抢购临界结束的时候不一致。

0x0100

增加最终一致性保证。

抢购的栗子有个很特别的地方,就是 total limit ,达到总数上限之后,就只有 MQ 中的部分需要处理了,因此可以很巧妙的利用时间差,即考虑在达到上限之后,取一次数据库快照,延迟一段时间之后,再对比一次数据库,判断是数据不一致还是正常逻辑。

一致性修复

这是一个投机取巧的处理方式,一定程度上可以保证最终一致性。当然,还是人最靠谱了,程序搞不定,人工修复嘛,ORZ~。

终语

分布式事务是一个很大的话题,依据业务量大小可以给出很多实现。

Nodejs 做分布式事务勉勉强强,异步里面的雷很多,不过依赖良好的设计和逻辑一样可以实现。

关注公众号【好便宜】( ID:haopianyi222 ),领红包啦~
阿里云,国内最大的云服务商,注册就送数千元优惠券:https://t.cn/AiQe5A0g
腾讯云,良心云,价格优惠: https://t.cn/AieHwwKl
搬瓦工,CN2 GIA 优质线路,搭梯子、海外建站推荐: https://t.cn/AieHwfX9
扫一扫关注公众号添加购物返利助手,领红包
Comments are closed.

推荐使用阿里云服务器

超多优惠券

服务器最低一折,一年不到100!

朕已阅去看看