python rq 实际部署使用简单说明
python 的rq 是一个简单，使用方便的分布式任务队列库，以下是自己关于实际使用一些总结
参考玩法
- 参考图
简单玩法流程:
- app 业务层使用rq 库，链接redis，然后将任务如队列，同时可以结合实际业务对于队列使用不同的名称（比如高中低，或者特定业务模型）
- 对于实际结合业务特点在不同的业务节点启动不同的worker 进行job 任务的监听，同时进行实际job 的执行
- 对于job 的任务以及callback 相关的参数推荐使用字符串模式，这样实际worker 执行的时候会进行方法模块的动态加载
- 关于实际job 执行的结果是否直接返回直接结果这个结合实际处理（因为方法执行结果会存储在redis 中，默认会有有效期控制）如果业务是数据比较大或者比较重要推荐还是直接写入一个中间存储中（或者直接入库）
- job 的callback 方法实际也是在worker 节点中执行的，callback 中会包含redis 的一个connection，我们可以基于此connection 进行一些额外的操作（比如利于发布订阅实现job 状态的主动推送，而不是业务方进行轮询或者间接查询模式）
- 对于实际worker 节点需要的python 代码，核心就是job 以及callback 的一些依赖（当然redis 也必须是一样的），并不需要app 业务中的东西（都是动态加载的）
- rq 版本最好一样（app 以及worker 节点的）
- rq worker 节点可以启动多个，或者使用rq 的实验特性 worker-pool 指定启动的个数
- 对于实际需要ha 的场景可以启动多实例的worker，但是并不是很重要，因为rq 数据核心先进入redis，当你worker 起来之后会自动执行，实际核心还是redis 的ha ，对于redis 的ha 可以使用哨兵，集群，或者直接使用keydb 开启双向同步
- 因为worker 节点以及app 是依赖redis 的，对于redis 的延迟以及worker 节点的资源情况，会影响job 的执行时间，业务基于延时获取状态，或者循环等待都不是特别好的方法，推荐的是基于job callback 通过redis 发布订阅进行消息的回传，机制上还是会有缺陷，但是至少不用进行资源的浪费了
基于job 回调的job 状态通知参考玩法
使用了faststream 这个方便的库，配置redis broker，在回调中通过job 中redis 的connect 通过发布消息给服务，服务进行job 任务的自动标记，而不是通过轮询或者查询redis 状态模式，这样简单一些
注意如果我们的faststream 启动了多实例，因为默认发布订阅所有订阅者都可以收到消息，我们需要进行一个判断处理（比如如果是标记状态可以基于乐观锁）
说明
以上是自己对于rq 使用的一些简单总结，大家可以按需使用
参考资料
https://python-rq.org/
https://faststream.airt.ai/latest/redis/
