TM集群特点
1） 所有节点对等，为P2P结构，不存在主从节点。
2) 节点之间无数据通信，也就是讲,节点之各节点相互独立。（TM有无交换信息待确认？）
TM集群示例图
TC端
TC端会保存所有TM的实例清单
TM端
TM端会提供一些接口，反应当前的状态信息，比如最近一段时间内的并发量，请求成功率等。以方便TC选择合适的TM端进行请求
事务发起方使用TM时序图
- 本地服务A（TC1）在启动时读取本地TM集群配置。
- 使用客户端负载均衡，由负载均衡策略，决定使用哪一个TM节点
- 当前选择节点2，将当前事务组所处TM节点保存到TransactionInfo
- 服务A调用服务B，在RPC调用的过程，也会携带TM节点信息
- 服务B在加入事务后，加入到调用发起方所在事务组
- 继续执行后续内容
这样，tc调用的TM节点会使用当前的负载均衡策略选择节点，相对於单TM节点，TM集群分摊了整个应用的调用压力，可以很好的提高并发量。
总结来说，该机制主要有以下特点
- 使用客户端负载均衡 ，由事务发起方TC决定使用哪个TM
- 服务A和服务B在进行RPC调用时，需携带事务发起方所在TM节点
常用负载均衡策略
-
轮询策略（RoundRobinRule）
轮询策略就是拿到所有的服务节点的列表，对所有节点进行固定排序，挨个请求
当请求到最后一个节点的情况下，下次请求从第一个节点开始 -
随机策略（RandomRule）
拿到所有的服务节点的列表后，对现有可访问节点，随机抽取一个进行访问 -
并发量最小可用策略
TC定时主动去拉去TM的状态信息，TM会返回最近一段时间的并发量统计数据，选择一个并发量最小的并且可用的TM去访问。
其他可用策略待添加
客户端负载均衡技术选型方案
一、 自己实现
维护TM列表
tc本地配置文件会配置所有TM集群的节点
txlcn:
tm:
server: 192.168.100.1:8070,192.168.100.2:8070,192.168.100.3:8070
TC会定时检查列表中的TM状态。维护可用TM列表
负载均衡
自己去实现所有负载均衡策略
优缺点
优点： 适用性强，适合所有体系结构比如Dubbo，spring cloud
缺点：需要自己开发，刚出来肯定不完善
二、使用现成为微服务体系内组件
以Spring Cloud为例
维护TM列表
所有TM都注册到nacos中，由Nacos维护TM列表
负载均衡
由Ribbon实现负载均衡，Ribbon有比较完善的负载均衡策略
优缺点
优点： 复杂实现都存在，调用即可
缺点：适用性差，不同体系结构使用组件不一样，比如注册中心有eureka，nacos，zookeeper，consul等，各不相同，需要做兼容处理