codingapi
6.0 TM模块的负载均衡
TM与TC模块采用的p2p网络结构，在TC端不是p2p网络，在TM上采用的是p2p方式。负载均衡要结合p2p网络优势来实现，存储统一数据库，可以采用redis或者mysql集群。
@1991wangliang 目前实现了 以下功能
- 各个 TM 之间将基于 P2P 网络互相彼此连接着
- 每当 TC 连接上一个 TM ，TM 会将其他 TM 的 ip 地址信息告诉 TC
- 每个 TC 为了高可用必须连接2个以上的有效 TM 资源 ，该资源数可配置
- 当 TC 仅有2个连接对象时则会询问 TM 更多的资源，然后去连接保持多个在线资源
同时，我对于端对端网络的优势还是有疑惑。 TM模块的负载均衡是否可以这样做： 当 TM 结点接收到 TC 发送的消息时，将其消息广播到 p2p 网络中的其他 TM 节点 并选择连接数最小的那个节点。这个节点执行消费消息并执行 redis 的一些操作
最新的提交实现了如下功能：
- 当 TC 连接一个以上 TM 时，执行 TC TM 间的通信事件时会随机选择一个 TM 进行通信
- TM 负载均衡的时候，与 TC 连接上那个 TM 节点 既充当客户端又是服务端，会将请求转发到P2P网络中连接数最小的 TM，后者执行完业务逻辑以后将结果发送给 与 TC 连接上的 TM ，再转发回 TC
需要弄的这么复杂吗？ 这两天看了下seata的源码，感觉seata在这块的实现简单一些（也是有问题，直接拨网线它的数据就有问题了）。 我觉得改良后可以这么做: TM启动时往redis注册自己的ip:port, 带过期时间，TM需要定时再刷新以保持redis中的key存在（seata没有定时刷新）。 TC启动时从redis获取所有已经注册的TM的ip:port. 获取后TC再去连接TM. TC也会定时刷新，重新拉取TM列表(seata没有定时刷新)。 上面说的定时刷新的时间可以长一点，比如90s, 以减少对redis的请求。 为了追求实时性，TC可以subscribe channel, TM启动时pushlish一下（seata只有pub/sub, 同时使用了shutdownhook来pub TM的下线事件）。
当然这不是p2p的，是注册中心制的。
我只是疑惑做成p2p这么复杂有什么好处。 5.x版本在注册这块的bug就导致不改源码基本就不可用。
BTW, 6.0版本现在达到能在开发环境使用的地步了吗?
@oneingfw
目前的提交已经实现了你所说的
TM启动时往redis注册自己的ip:port, 带过期时间，TM需要定时再刷新以保持redis中的key存在（seata没有定时刷新）。 TC启动时从redis获取所有已经注册的TM的ip:port. 获取后TC再去连接TM. TC也会定时刷新，重新拉取TM列表(seata没有定时刷新)。
也就是说同时利用到了 p2p 的连接优势进行负载均衡和 注册中心制 的方式来进行心跳检测。 p2p的优点在于，只要 TC 跟 TM集群其中一个 TM 保持链接就能利用起 TM 集群的所有资源。但我认为 p2p 网络优势更适用于上传下载这种耗费资源的场景。 我觉得 TC 如果引入 redis 可能不太好，tx-lcn 作为框架级别的项目，能尽量少依赖就少依赖为好，目前 TC 获得其他 TM 都是通过与 TM 的消息事件获得的。
当前的一个机制的确是有点复杂，后续的提交我会好好考虑一下优化。
另外，6.0 版本现在尚在开发阶段，挺多功能都不可用的