异步任务优化の(零)

前提

这个是我目前的工作中遇到的问题，且亟需解决的问题
现状

1. 我们的项目目前是集群 单体 应用，正在准备往微服务上迁移，但是还是刚开始
2. 因为是单体应用，Web容器 性能压力很大，服务器经常CPU飙满
3. 异步任务的任务列队是存在内存中的，一旦容器重启(如发布)，那么部分任务全部丢失，导致数据不一致的问题

基于上面两点，我们目前打算把服务里的那些异步任务全部迁出去
到别的容器里去执行

总体思路

1. 容器A作为生产者，调用我们的异步任务工具类
2. 异步任务工具类，通过一些手段和方法，把一些信息 写到消息队列里
3. 容器B作为消费者，收到消息，进行消费

我在实现步骤二的时候，其实遇到了很多的困难
也尝试了很多的方案，后续的博客会逐一写出来

产生的新问题

目前我想到的有两个和重启相关的问题
一个是重启导致代码运行中断
二是更新容器导致逻辑不一致

1. 运行中断

一个方法运行到一半退出了，会产生数据不一致的问题
可以通过事务来解决

2. 更新容器

我们的代码一直在更新、迭代
对一条消息来说，生产和消费的逻辑，大部分是在同一个迭代里完成的
但是因为我们的异步任务都是调用某一个类的方法，后续这个方法可能逻辑有所调整
所以可能会导致潜在的一些问题
（注意 因为我在实验的时候发现，不管什么方案，实际执行的时候，是去找到指定的一个方法，然后传参进行调用的，所以执行的是最新的代码）

消息队列消费性能

目前采用的分区顺序消息

暂时定的策略是
每一个service 划分到一个区， 区名(ShardingKey) 为 类名
每一个service发出的异步任务，遵循 FIFO