mq用的是Nats，NATS项目介绍。

server用的是Nats Streaming，消息至少一次传递，可持久化。

mq其实就是生产者、消费者模型。

项目中目前用到的是Queue Groups。Queue Groups有负载均衡的功能，发送端发送1、2、3这样三条消息，可以分别到三个不同的订阅端，订阅端服务同时开多个容器(其实就是多个k8s的pod，每个pod里一个容器)，可以加快消息的处理。处理完数据后，再ack

需求分别是离职线索自动分配、模拟聊天自动分配。

1、离职销售线索自动分配。

销售人员离职后，需要把一些未成交的数据批量重新分配给在职的销售。后台可以在开始分配前，设置从哪个离职人员分配给谁，多少条。设置完成后，可以先返回设置成功。然后用redis的NX、EX指令加锁，避免数据重复分配，EX时间是5*数据条数（秒）。同时设置一个redis key，value为数据条数。每分配完（包括调用企业微信外部联系人api转移关系）一条就用redis的DECR指令减1，当减到0时，给指定人员的企业微信应用发送通知，分配成功，转移了多少条数据，之前设置的EX时间相对长，实际系统分配更快，主动通知可以让相关人员知道可以继续下一次的分配了。

2、模拟聊天自动分配。

模拟聊天是对刚入职的销售培训话术的系统。用的是线上真实的用户聊天信息，企业微信可以导出一段时间内的聊天信息（这块是单独项目，另外运行的服务），存到数据库，作为用户聊天数据池。根据用户销售信息表、用户openid等信息，可以筛选出用户侧的聊天信息。然后满足一定条件用户的选一条。选到单个用户后，获取该用户所有聊天内容，分配给销售人员，聊天内容不能重复，用seq表示唯一。订阅端for循环，在内存中判断是否满足业务条件，满足后退出分配。