Feacar(Fast EAsy Comit and Rollback),这个东西是阿里今年新开源的一款高性能分布式事务框架,虽然市面上有很多了,比如tcc-transaction,ByteTCC
ByteTCC还有一个官网讲解TCC的事务百特开源官网. 虽然框架有多个,但是阿里的引起的动静更大,还是亲自体验一番。
概念
在业务拆分为多个模块的时候,每个模块都有自己的数据库的时候,如何保证数据一致性呢?Fescar将一个大的分布式事务拆分为多个分支事务,每个分支事务即本地的事务。
它有三个组件:
- TC(Transaction Coodinator):事务协调器,维护全局和分支事务的状态,驱动全局的提交或者回滚
- TM(Transaction Manager):定义全局事务的范围,开始,提交,回滚一个全局的事务
- RM(Resource Mamager):管理分支事务的资源,与TC进行通信,注册分支的事务,告知TC分支事务的状态,驱动分支事务的提交或回滚。
典型的Fescar分布式事务周期:
- TM让TC来开启一个全局事务,TC生成一个XID来表示当前的全局事务
- XID在微服务的调用链中进行传播,所有服务得知当前事务的XID
- RM像TC注册当前XID对应的事务。
- TM让TC来提交或者回滚当前XID对应的全局事务
- TC告诉所有XID对应的的分支事务来结束提交或者回滚。
预备软件
- MySQL
- Zookeeper
- Fescar,这个协调者组件还是单独运行的。
使用
-
下载Fescar的案例代码,github.com/fescar-grou…
这次演示,只需要使用案例代码的dubbo模块即可。
- 启动MySQL,创建表,创建语句在项目中也有。
CREATE DATABASE fescar_demo;
DROP TABLE IF EXISTS `storage_tbl`;
CREATE TABLE `storage_tbl` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`commodity_code` varchar(255) DEFAULT NULL,
`count` int(11) DEFAULT 0,
PRIMARY KEY (`id`),
UNIQUE KEY (`commodity_code`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
DROP TABLE IF EXISTS `order_tbl`;
CREATE TABLE `order_tbl` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`user_id` varchar(255) DEFAULT NULL,
`commodity_code` varchar(255) DEFAULT NULL,
`count` int(11) DEFAULT 0,
`money` int(11) DEFAULT 0,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
DROP TABLE IF EXISTS `account_tbl`;
CREATE TABLE `account_tbl` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`user_id` varchar(255) DEFAULT NULL,
`money` int(11) DEFAULT 0,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
复制代码
- 在案例代码的jdbc.properties文件中,配置好MySQL的链接地址与密码。
- 在dubbo配置文件中,指定服务注册中心地址。依次配置accout, order,storage。还有business
- 记得启动zookeeper,单机版的直接运行就好,关于ZooKeeper的使用参考Zookeeper入门,另外启动fescar,启动fescar的时候记得要提前创建好目录,否则会报目录不存在异常。
# 启动ZooKeeper
/bin/zkServer.sh start
# 启动fescar
mkdir /Users/aihe/tmp/fescar
./bin/fescar-server.sh 8091 /Users/aihe/tmp/fescar
复制代码
-
按照顺序,启动DubboAccountServiceStarter,DubboOrderServiceStarter,DubboStorageServiceStarter,最后启动DubboBusinessTester。
-
在业务代码中,项目故意抛出了异常,可以分别运行抛出异常与不抛出异常的,来检查分布式事务是否有生效。
- 最后检查数据库,符合预期,要么每个服务的数据都有入库,要么都没有入库。
分析
看看Fescar的日志,在成功和失败的时候都有日志。
在失败的时候,就是告诉分支事务都进行回滚操作。最后断开与服务的链接
在成功的时候,获取到所有的分支事务状态,然后进行全局的提交。最后断开与服务的连接
最后
就说到这了,主要觉得fescar运行在本地感觉有点怪,不过官网说它有不同的运行方式,期待后面有更全的文档用法吧。分布式事务一般降低服务的吞吐量,公司用的定时任务补偿与查询的方式比较多。