【工作中場景以及解決方案系列二】沒有終態的資料狀態的批處理修改

前言

該系列的上一篇文章講解了有終態的資料狀態的批處理修改,萬物皆如此，有黑就有白，又反就有正，那麼有終態就會有沒有終態。小夥伴們再看完上一篇文章想到這種場景了沒？如果沒有就細細看一下這篇文章哦~

場景解釋（無終態的資料狀態的批處理修改）

有終態的場景，現實邏輯中有很多，因為有開始就有介紹嘛，比如一個專案的結束，一場電影的結束。。。。
那麼無終態的場景呢？相信大家都會或多或少在玩遊戲或者其他涉及到賬號相關的時候會遇到封號或者賬號過期失效再啟用的場景，對於這樣的賬號來說，有賬號終態嗎？是啟用？還是失效？顯然都不是，他們是一個迴圈，會不斷的變更狀態_{我這樣去說相信大家應該領悟到無終態的資料狀態的批處理修改的場景了吧}

場景示例

身份證實名資訊同步：因為身份證有有效期，而且可能會進行修改名字，同時也不排除身份證號的修改，所以是沒有終態；
賬號的凍結和解凍；

解決方案

相對於有終態的資料，無終態不會出現多次重複執行的情況，但是出現了大資料量分批執行如何在保證執行一遍不會重複執行前面資料，譬如：一共5000條資料，我一次執行500條資料，我下一次的執肯定不能包括這次執行的500條資料，也就是說我全部執行完要10次。
顯然我們在上一篇文章中用資料庫的一個執行狀態位是不能解決的，有人會說為啥不能解決呢，我執行完一組資料就修改這一組的執行狀態表示這批次的資料已經執行完畢，等全部資料執行完以後，發現沒可執行的資料了，再把所有資料的執行狀態修改為未執行，不可否認，這種方案可行，但是面對千萬級別的資料量，所有資料修改一次狀態所消耗的io資源是多少，會不會因為頻繁的刷表，機器完全扛不住呢？
這時又有人會說，我可以記錄一個update的時間，每次通過時間去判斷是否執行過，雖然相對於上一種方法減少了一次的修改狀態的操作，但是你全部執行完一遍也是需要全部修改一遍資料的，我們都知道，對於這樣資料我們應該只對有修改的資料進行update，沒有修改就直接continue了。那這也不行，那也不行，那你說怎麼辦吧。
首先我們看一下這個需求的關鍵點是什麼呢?其實就是如何標記已經執行過的資料，而且還不影響下一輪的執行。無非需要一個標識位罷了。
這裡我引入了快取，我用的是redis，你們也可以用一個資料庫的標識，常亮標識都行。我首先對要處理的資料進行排序，用主鍵ID，每次執行一批次資料，然後記錄最後一個ID（我用的是升序），下次在執行大於這個ID的一批次資料，在最後一次執行發現執行數量小於我一批次要執行的數量，ID置0，不就解決了嘛=￣ω￣=

總結

總結一下我為啥要用快取，因為Redis快取可以在服務叢集部署或者是多執行緒的執行保證標識位的修改是原子性的，也就不會出現沒有執行或者多執行的情況。也同時想為後面的分享做一點基礎，讓大家先了解一下快取和叢集的概念。

寫完發現我咋這麼囉嗦呢，還都是文字，以後會改進，讓大家多看圖片，少讀文字=￣ω￣=