序言：
经过三个大版本迭代，每个大版本包含多个小版本的优化迭代！
背景：
每个订单分发成百上万个数据，可以多次分发，每个订单分发的数据不能重复，并且分发的数据要随机！
V1.0版本：
1、记录订单ID和分发数据ID；
2、给订单ID分发数据前首先查看分发了哪些数据ID，分发的数据ID不会重复分发；
3、给订单ID分发非重复数据ID的时候采用SQL语句的随机函数；
线上问题：
每天有2000以上的订单，总共分发数据达到600多万，即每天记录订单ID和数据ID的量达到600多万条，数据存储量有20多万。组装的SQL语句相当于至少2000条订单表关联600多万的记录表再关联20多万的数据表并且随机分发数据，线上项目启动最初下一个订单还能正常跑，当同时下多个订单跑一会数据量积累半个多小时造成服务器CPU占400%以上（服务器配置8核，内存16G），直接导致SQL查询缓慢，分配数据超时。
V2.0版本：
1、给数据表新增了一个排序的字段，每隔2小时打乱一次排序；
2、给订单分发数据的时间，redis记录订单ID的当前分发的数据排序指定位置，下次再分发从指定位置开始；
线上问题：
优点：服务器CPU降下来了，每次最高占30%~60%（里面还包含相关联的其他7个项目）
缺点：本质上2小时还是按顺序排序，并没有做到实时随机，并且每隔2小时打乱排序后仍会出现大几率的重复分发；
V3.0版本：
1、每隔2小时同步数据库数据到内存；
2、订单ID随机匹配获取内存中的数据，记录订单ID和内存数据ID到内存；
3、再次给订单ID分发数据前，先将内存数据中记录的数据ID删除再随机匹配获取不重复的订单ID；
4、根据业务逻辑定时删除内存中占用的数据；
优点：完美做到了给订单分发不重复的随机数据，充分解决了数据库压力极大程度降低CPU
缺点：内存占用比较多（我们服务器16G内存充分够用，并且内存数据做了清理维护）；当服务器同步分发数据到内存的时候分发数据性能很低维持在1分钟左右时间（同步分发数据到内存的时候控制不分发数据，等同步完成后分发）；当服务器重启的时候内存记录数据丢失（这个对我们项目影响不大，重启很少，丢失的数据只会造成小部分数据重复分发）