【工作中场景以及解决方案系列二】没有终态的数据状态的批处理修改

前言

该系列的上一篇文章讲解了有终态的数据状态的批处理修改,万物皆如此，有黑就有白，又反就有正，那么有终态就会有没有终态。小伙伴们再看完上一篇文章想到这种场景了没？如果没有就细细看一下这篇文章哦~

场景解释（无终态的数据状态的批处理修改）

有终态的场景，现实逻辑中有很多，因为有开始就有介绍嘛，比如一个项目的结束，一场电影的结束。。。。
那么无终态的场景呢？相信大家都会或多或少在玩游戏或者其他涉及到账号相关的时候会遇到封号或者账号过期失效再激活的场景，对于这样的账号来说，有账号终态吗？是激活？还是失效？显然都不是，他们是一个循环，会不断的变更状态_{我这样去说相信大家应该领悟到无终态的数据状态的批处理修改的场景了吧}

场景示例

身份证实名信息同步：因为身份证有有效期，而且可能会进行修改名字，同时也不排除身份证号的修改，所以是没有终态；
账号的冻结和解冻；

解决方案

相对于有终态的数据，无终态不会出现多次重复执行的情况，但是出现了大数据量分批执行如何在保证执行一遍不会重复执行前面数据，譬如：一共5000条数据，我一次执行500条数据，我下一次的执肯定不能包括这次执行的500条数据，也就是说我全部执行完要10次。
显然我们在上一篇文章中用数据库的一个执行状态位是不能解决的，有人会说为啥不能解决呢，我执行完一组数据就修改这一组的执行状态表示这批次的数据已经执行完毕，等全部数据执行完以后，发现没可执行的数据了，再把所有数据的执行状态修改为未执行，不可否认，这种方案可行，但是面对千万级别的数据量，所有数据修改一次状态所消耗的io资源是多少，会不会因为频繁的刷表，机器完全扛不住呢？
这时又有人会说，我可以记录一个update的时间，每次通过时间去判断是否执行过，虽然相对于上一种方法减少了一次的修改状态的操作，但是你全部执行完一遍也是需要全部修改一遍数据的，我们都知道，对于这样数据我们应该只对有修改的数据进行update，没有修改就直接continue了。那这也不行，那也不行，那你说怎么办吧。
首先我们看一下这个需求的关键点是什么呢?其实就是如何标记已经执行过的数据，而且还不影响下一轮的执行。无非需要一个标识位罢了。
这里我引入了缓存，我用的是redis，你们也可以用一个数据库的标识，常亮标识都行。我首先对要处理的数据进行排序，用主键ID，每次执行一批次数据，然后记录最后一个ID（我用的是升序），下次在执行大于这个ID的一批次数据，在最后一次执行发现执行数量小于我一批次要执行的数量，ID置0，不就解决了嘛=￣ω￣=

总结

总结一下我为啥要用缓存，因为Redis缓存可以在服务集群部署或者是多线程的执行保证标识位的修改是原子性的，也就不会出现没有执行或者多执行的情况。也同时想为后面的分享做一点基础，让大家先了解一下缓存和集群的概念。

写完发现我咋这么啰嗦呢，还都是文字，以后会改进，让大家多看图片，少读文字=￣ω￣= 浅浅画图中～