求教，有状态的分布式系统应该如何设计

应对业务扩张，将服务拆分并支持横向扩展，现在拆了共 a,b,c 三个服务出来，然后这三个服务要设计成可以随时横向扩展。其中有如下调用链路

a -> b -> c
a -> c

然后 c 是主要处理业务的服务，会上分布式锁，加上处理时间长，会后台执行并执行完通知上游来做其他业务操作，业务操作之后才能解锁。

因为一个业务只能在一个 c 中执行，所以解锁要找到对应的 c 。比如 a 执行业务分配到节点 1 的 c，后续交互都要找节点 1 的 c。b是批量执行业务，这一批都要到同一个c中执行完。

目前设计方案是将 c的 IP 和业务 id 写到 redis ，然后通过 redis 确定业务在哪个 c 节点上面跑着。然后要在业务处理过程中，查看状态都通过 redis 查对应 ip 再去调用服务。

比如批量任务中，a 要确定哪个 b 节点承接了这个业务，b 节点确定哪个 c 节点正在处理这批次业务。

感觉这种设计不是很好，想请教下还有没有更优雅的做法

可能描述的有点复杂，大概意思是

怎么记录在多个节点时，知道这个任务在哪个节点上，并且应用之间相对不耦合

mark2025

259 天前

@mawen0726 你这个场景使用任务队列来做应该还算简单了：
1. 发布任务消息到消息队列（带执行）
2. 收到任务消息，上锁，发布任务状态消息（已上锁）
3. 收到已上锁的行任务消息，开始执行任务。根据任务执行结果（成功、失败），发布任务状态消息（执行状态，可以包含任务结果数据）
4. 收到包含执行状态的任务消息，解锁

抽象为 4 个步骤，使用任务状态值在消息队列中来流转，可以忽略 a 、b 、c 具体服务。