Saas系统多任务分发排队

需要考虑的技术点

监控

任务处理监控（待处理数量，耗时统计），可视化

• mq看板查看mq中间件消息堆积情况
• 线程池工作任务处理监控，排队中待处理的任务，拥堵情况
• jvm、cpu、内存等的负载监控
• mysql慢sql、长事务

优先级排队处理机制

可以动态插队吗

• 这里可以根据用户等级拆分不同主题的队列，如免费版的topic和vip版的topic，里面调度逻辑一模一样，只不过对应不同的消费者，发送使用的账号可能也不同
• 如果业务量确实超过1个账号的发送上限，考虑维护多个发送账号

限流机制

• 目前消息从mq到消费端多是推模式，控制消费端并发的线程数（如果是拉模式的，消费端控制消息拉取的速率)
• 对接第三方网络请求加令牌桶算法限流避免超过对方阈值

幂等

避免同个用户重复发送

• 商品刊登一条发布记录对应一个商品的，可以用发布记录ID+状态做幂等校验，在mq消费端消费一条消息的时候，可以根据发布记录ID加锁，避免同时有多个线程在消费同一条消息
• 像EDM这种单个广告量比较大，需要拆批的，可以根据广告ID+批次ID加分布式锁处理，幂等也是

网络请求优化

第三方对接网络请求的优化

• 请求合并，数据包压缩，网络模型
• 这里最佳实践是不要把网络请求放在事务里，容易造成长事务影响其他服务的数据库读写性能

数据存储与架构

发布任务比较多，存储的问题

• 业务参数数据加密压缩
• 业务校验或第三方返回的失败原因存储
• 分库分表（单表转分库分表，或分库分表扩容，怎么迁移数据）或分布式数据库
• 敏感数据，如手机号、邮箱等的加密
• mq本身，集群模式，分区分片，消息堆积能力要强
• mq多节点消费

插队

基础方案

缓存存储任务优先级（用户维度或任务维度）,定时任务根据缓存元数据（获取优先处理的任务）扫描表，组装消息到mq中间件

人工线下处理

非常规操作，如果客户催得急。通过message-key搜索出队列消息拿到mq的body信息，手工发送消息到队列头部，后面消费到相同的幂等处理就好。

待续