@aarontian
当时认为 c 去锁定资源，就认为 c 去上锁了，其实还说漏了一些，c 和资源会建立 ws 连接，所以当时就更认为要在 c 上锁...
希望可以看看我新的回复，看看这种设计怎么样，算是第一次做种比较复杂的设计

@Plutooo
其实正是这个线程的问题，才让我发帖问的，原本我以为 redisson 只是简单的 key 相同解锁...
后面稍微深入了一下，其实就是分了两个类型
1. 线程 id 必须一样
2. lockasync ，指定一个 id ，使用相同 id 上锁解锁即可（可以联想场景 reactor java ，每个场景都可能是不同的线程执行的）

但是抛开这个不谈，原本要维护下游 ip 还是很垃圾的设计...

@luofuchuan668
大佬能看下我新回复的，评价一下吗

@huzhizhao
现在的设计是消息队列中：
主题 1 关于任务发布（ a 、c 发布的任务，类型字段区分开）
主题 2 关于任务接收成功的响应，让 a 、c 知道任务在执行了
主题 3 关于执行中的数据
主题 4 关于任务的中断、取消

所有的 c 实例对于主题都属于同一个消费组，共同监听主题 1 抢任务执行，发布到主题 2 响应上游正在执行，同时将结果发布到主题 3 。主题 4 则是不同消费组，收到取消的消息判断自身有没有在执行对应业务，没有则忽略

所有的 a 、b 实例都是一个单独的消费组，监听主题 2 确定任务发布成功（没响应则重试 5 次），监听主题 3 获取结果（结果实体包含消费组信息，消费组不一致忽略消息）

感觉这样设计强依赖了消息队列，但是可以不管下游的 ip 了，也不知道好不好，但是也没机会再改了 - -

@mark2025
当时没设计好，后面重新捋了下，将上锁和解锁都放在同一端了
当时不想大动代码（屎山），就想着 c 上锁，a 、c 解锁

@mark2025
因为业务场景锁有业务在生命周期内固定使用某个资源的场景，感觉自己写一套去维护资源的状态，还不如用分布式锁来的直接...

@czsas
@server
感谢感谢，现在回头看看这些框架。
之前纠结要维护 ip 是因为觉得中断，暂停等操作要通知对应的 c 服务。但是后面捋了下，一个业务只会在一个 c 里面执行，要做什么操作直接广播所有 c （通过消息队列），c 来判断有没有在运行这个就可以了。没有运行则不做任何操作

@cowcomic
这里的最底层的资源其实是 jupyter ，用来运行一些大型算法得出结果。然后印个 jupyter 同时只能跑一个算法，所以需要资源锁定。c 服务就是干这个事的。然后 a 和 b 其实就是一个算法只跑单次和按时间纬度跑多次的区别，因为跑多次且结果有上下关联，所需内存大，所以也抽两个了（原本放一块）

然后之前 c 跟业务耦合了，最初拆的就来回解锁了。后面把 c 拆得只跟 jupyter 交互，是个无状态的。a 、b 服务发算法任务让 c 自己去抢，中断执行 ab 也是发消息队列，c 监听到检查自己有没有正在运行对应的业务（算法 id 唯一），没有则忽略。

我之前纠结要维护 ip 是因为觉得中断，暂停等操作要通知对应的 c 服务。但是后面捋了下，一个业务只会在一个 c 里面执行，要做什么操作直接广播所有 c （通过消息队列），c 来判断有没有在运行这个就可以了。

然后上锁放在上游（ a 、b 服务）里面，在让 c 运行前上锁，c 运行完通知后解锁。

@1402851639
这几天忙忘记回了，后面重新拆了下。
将所有要执行的东西都提交到消息队列中，让下游去抢。如果执行的要中断，上游也是发消息队列，下游监听自己有没有在处理这个业务，没有就忽略。
将所有相关场景都改成这样了，不知道这样的设计好不好...

@k9982874
不过感觉可以按这种方式再想下怎么改，确实可能设计复杂了

@JasonGrass
感觉再拆就不好维护了...
不过可能是我没拆好，感觉还得思考下

@k9982874
因为 c 在执行任务的时候，上了锁，锁定了某个资源，因为处理时间长，锁定时间久
代码在写的时候，不是常规的写法....
lock.lock
try{
dosomething()
}
finally{
lock.unlock
}


而是起了个线程来上锁，等 a 确定完业务执行完，再去通知持锁的 c 解锁。因为用的 redisson 的 lock ，所以要找回对应的节点 c 才能解锁...

@tairan2006 貌似跟 1 楼提的消息队列方式很像，我思考一下怎么设计

@k9982874
消息队列用了，但是用来处理业务中产出的各种数据实时推送...
没想好记录任务在哪个节点这个层面怎么用...

@molezznet 我又试了下，直接用桥接模式是可以的（前提是网卡要对，要能公网访问）。nat 的话，配置 ipv6 那里，用你当前所在的真实 ipv6 配置前 112 位，即 xxxx::xxxx/16 ，则可以分配到，貌似虚拟的分配不到，fd 开头的

@molezznet 我看了下我的 vmware 虚拟机，nat 模式，开了 ipv6 ，虚拟机配了 ipv6 ，确实也拿不到 ipv6 ，还没深究过什么情况...

@lxqxqxq 一加 13 刷氧系统（狗头

学 Wireshark 吧，感觉这个最好使

@wsseo
@yanyanjia
@rulagiti
@zwy100e72
周末换了路由器再去测试，发现没问题了。然后再换回小米路由器，也正常了....
接着回看之前异常状态下 windows 拿到的 ipv6 地址，也是怪怪的，只有一个 ipv6 地址，没有临时 ipv6 地址啥的（印象中有 4 个）
也不知道是哪个环境出问题了，现在服务器能正常获取到 ipv6 地址了
以后遇事不决还是先重启大法吧

非常感谢解答~学会了挺多新知识