WhomHim
WhomHim
> ``` > > /** > * @author lorne > * @date 2020/8/8 > * @description > */ > public class IdUtils { > > > /** > * 创建GroupId策略...
> 是要workId不重复就行是吗？ ~~经试验，workId 不重复就行了, 假设有2个机子有 tc ，workId 相同的概率 也不过是 1/1024，id相同的概率也不会很大~~
> ObjectId就行了,24位长度也可以接受,天然的分布式id,同时也是趋势增长的,mongo就用这个. 试了下，效果还可以，除非极端情况，会有些许误差 ```java @Test public void theSameObjectId() throws InterruptedException { final CountDownLatch COUNT_DOWN_LATCH = new CountDownLatch(2); Set idSet = new HashSet(); IntStream.range(0, 2).forEach(i -> { new Thread(() -> {...
> 那可以这样来设计 > 当tc链接到tm以后，由tm来分给workid，workid的自增策略由tm来控制，为了实现全局数据统一可讲workid值记录在tm的redis下。 正有此意，虽然做法稍微比 ObjectId 的方式复杂些
> 这个我可以做 你开始做了吗
@1991wangliang 目前实现了 以下功能 - 各个 TM 之间将基于 P2P 网络互相彼此连接着 - 每当 TC 连接上一个 TM ，TM 会将其他 TM 的 ip 地址信息告诉 TC - 每个 TC 为了高可用必须连接2个以上的有效 TM 资源 ，该资源数可配置 - 当...
 最新的提交实现了如下功能： - 当 TC 连接一个以上 TM 时，执行 TC TM 间的通信事件时会随机选择一个 TM 进行通信 - TM 负载均衡的时候，与 TC 连接上那个 TM 节点 既充当客户端又是服务端，会将请求转发到P2P网络中连接数最小的 TM，后者执行完业务逻辑以后将结果发送给 与 TC 连接上的 TM ，再转发回 TC
@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 获得其他...