Seata学习笔记三：高可用实现之ZK

Seata的高可用模式是通过TC使用db模式共享全局事务会话信息，使用非file的seata支持的第三方注册中心和配置中心来共享全局配置的方式来实现的。

Seata支持的第三方注册中心有nacos 、eureka、redis、zk、consul、etcd3、sofa、custom，支持的第三方配置中心有nacos 、apollo、zk、consul、etcd3、custom。seata官方主推的应该是nacos（毕竟是一家的），但是由于本人平常使用的注册中心一直是zk，因此首先考虑通过zk作为注册中心来实现高可用模式。

环境准备

zk环境准备

本地已安装zk的可以忽略，如果本地未安装，先在本地安装zk，具体安装自行百度。

PS: 此处如果使用的是远程zk服务器，则本地可以只下载，不安装。

数据库环境准备

1、创建数据库seata

2、执行源码（version1.2.0）script -> server -> db 下面的mysql.sql文件，建立global_table，branch_table，lock_table表。

配置信息导入zk

1、打开本地seata源码（版本1.2.0）

2、编辑script -> config-center -> config.txt文件，修改store.mode=db，修改store.db相关的数据库连接信息，其它默认即可

3、进入script -> config-center ->zk，执行 sh zk-config.sh -h 127.0.0.1 -p 2181 -z /usr/local/zookeeper-3.4.14（-z 后面的参数为你本地zk目录）

上面命令会将config.txt中的配置信息写入zk的/seata节点下。

启动tc-server

1、编辑conf下面的registry.conf文件，修改registry.type=zk，修改config.type=zk，修改registry.zk及config.zk信息，如下：

注意：config的zk配置没有cluster属性。

2、启动server，在本地seata安装目录bin目录下执行./seata-server.sh -m db （此处也可以直接编译本地源码然后启动Server模块下的Server类）。

不出意外的话，启动会报错，错误信息是从zk读取配置的时候反序列化出问题。

错误原因：序列化问题，由于使用seata自带的zk-config.sh脚本向zk写入配置信息的时候，采用的序列化方式相当于String.getBytes()，而框架读取配置的时候使用的是org.101tec包中的Zkclient客户端，反序列化使用的是该包下面的SerializableSerializer序列化类，使用的ObjectOutputStream进行反序列化，和序列化方式不一致。

该问题在1.3.0版本中解决，解决方式是seata支持序列化方式配置，支持自定义序列化方式，同时提供默认序列化实现类DefaultZkSerializer，反序列化实现为new String()。

到此处，1.2.0版本无法进行下去，由于目前1.3.0正式版本还未出，只能拉取最新的开发分支源码，本地编译打包1.3.0-SNAPSHOT版本。

后续版本切为1.3.0-SNAPSHOT（20200701），删除原zk配置信息重新导入1.3版本的config.txt文件信息。

本地源码编译后直接Idea启动Server类。启动成功。

PS：启动日志里面会有一些getConfig失败的报错，这些不用管，这些新的配置参数是1.3版本新增的，由于当前是SNAPSHOT版本，还不完善。

PS: 如果遇到getServerCharset 空指针异常，这个主要是MySQL和MySQL驱动版本不一致引起的，看https://blog.csdn.net/zcs20082015/article/details/107087589

服务启动

配置修改

简单处理，这里不再建新的模块，直接使用zhengcs-seata-storage模块作为演示。

1、修改POM，引入zkclient，修改seata版本

2、修改application.yml，将注册和配置类型改为zk

另外需要注意的是seata.tx-service-group配置参数要和zk导入的配置信息相关参数保持一致，否则会找不到server集群

启动服务

1、引入全局事务

2、启动

测试

基本功能测试

单元测试用例：

手动插入异常

执行用例：

基本功能是没问题的，更详细全面的测试这里就不介绍了，大家自行尝试。

高可用测试

上面的单机版肯定无法满足高可用，tc-server一旦宕掉，整个全局事务会无法进行回滚，同时会在seata库下面的事务表里面留下事务记录（正常处理成功后会被删除）。

seata的高可用是通过多个tc-server实例组成的集群来实现的。

启动多个tc-server实例：

通过-p参数修改启动接口，同时勾选Allow parallel run，开启多个实例。

然后启动客服端服务：

从启动日志可以看出，客户端会同时向所有几点注册TM和RM。

执行测试用例：

那，如果在数据已提交，异常退出之前把对应的tc-server节点停掉，会怎么样呢？答案是：全局事务回滚。大家自行尝试一下。

还有一种情况，如果客户端在执行过程中中断了，会怎么样？

如果客户端是单节点部署，那么：

首先，seata库下面的事务处理表里面有遗留事务处理记录，然后你会发现tc-server端日志里面会持续刷上述日志，tc-server会持续的尝试回滚该事务。最遗憾的是：哪怕客户端服务重启，也不会回滚该事务！！！

不过还好的是，这种情况毕竟是特例，如果客户端服务是集群部署，那么seata是可以正常完成事务回滚的。

结语

从上面的情况来看，起码seata对于简单的分布式事务场景的高可用支撑是没问题的，但是seata毕竟还是一个新框架，在实际的复杂的业务场景下会否出现什么问题，其实应该说出现什么问题都是可能的，这个需要实践和时间才能出真知了。

另外，seata目前没有提供控制台，没有服务集群配套的HA机制，这个不知道什么时候会出，拭目以待，seata应该会是一个很不错的分布式事务解决方案。

 

参考资料

https://seata.io/zh-cn/docs/

https://github.com/seata/seata