在多線程并發(fā)情況下，假設有兩個數據庫修改請求，為保證數據庫與redis的數據一致性，
修改請求的實現中需要修改數據庫后，級聯修改redis中的數據。
請求一：1.1修改數據庫數據		1.2 修改redis數據
請求二：2.1修改數據庫數據		2.2 修改redis數據
并發(fā)情況下就會存在1.1 ---> 2.1 ---> 2.2 ---> 1.2的情況 
（一定要理解線程并發(fā)執(zhí)行多組原子操作執(zhí)行順序是可能存在交叉現象的）
此時存在的問題就是：
	1.1修改數據庫的數據最終保存到了redis中，2.1在1.1之后也修改了數據庫數據。
	此時出現了redis中數據和數據庫數據不一致的情況，在后面的查詢過程中就會長時間去先查redis，
	從而出現查詢到的數據并不是數據庫中的真實數據的嚴重問題。
問題解決：
	修改數據庫級聯修改redis數據改為  修改數據庫數據后級聯刪除redis數據
	至于是先執(zhí)行1.2的redis刪除，還是限制性2.2的redis刪除，無關緊要。
	結果都是redis中數據已被刪除。之后的查詢就會由于redis中沒有數據而去查數據庫，
	此時即不會存在查詢到的數據和數據庫的數據不一致的情況。

上面的單刪策略情況如下：
修改請求的實現中需要修改數據庫后，級聯刪除redis中的數據。
請求一：1.1修改數據庫數據		1.2 刪除redis數據
請求二：2.1修改數據庫數據		2.2 刪除redis數據
假設現在并發(fā)存在一個查詢請求
請求三：3.1查詢redis中數據   3.2查詢數據庫數據    3.3 新查到的數據寫入redis
（一定要理解帶redis的查詢請求實現邏輯，先查redis，數據不存在查數據庫，
			查到的數據寫入redis以便以后的查詢不去直接查數據庫）
此時并發(fā)情況下就會存在1.1 ---> 1.2 ---> 3.1 ---> 3.2 ---> 2.1 ---> 2.2 ---> 3.3的情況 
此時存在的問題就是：
	此時數據庫中的數據保存的是2.1修改后的數據，而redis中保存的數據是3.2中在1.1修改數據后的結果，
	此時出現了redis中數據和數據庫數據不一致的情況，在后面的查詢過程中就會長時間去先查redis，
	從而出現查詢到的數據并不是數據庫中的真實數據的嚴重問題。

上面的單刪策略存在問題的情況如下：
請求一：1.1修改數據庫數據		1.2 刪除redis數據
請求二：2.1修改數據庫數據		2.2 刪除redis數據
請求三：3.1查詢redis中數據   3.2查詢數據庫數據    3.3 新查到的數據寫入redis
添加延時雙刪策略后的情況
請求一：1.1修改數據庫數據		1.2 刪除redis數據    1.3 延時3--5s再去刪除redis中數據
請求二：2.1修改數據庫數據		2.2 刪除redis數據    2.3 延時3--5s再去刪除redis中數據
請求三：3.1查詢redis中數據     3.2 查詢數據庫數據    3.3 新查到的數據寫入redis
雙刪策略為什么能解決問題：
因為存在了延時時間，故1.3或2.3 一定是最后執(zhí)行的一步操作（并發(fā)中的延時一定要理解）
延時的根本目的就是為了讓程序先把3.3執(zhí)行完，再去刪除redis

比較好的：   項目整合quartz等定時任務框架，去實現延時3--5s再去執(zhí)行最后一步任務
比較一般的：  創(chuàng)建線程池，線程池中拿一個線程，線程體中延時3-5s再去執(zhí)行最后一步任務（不能忘了啟動線程）
比較差的：   單獨創(chuàng)建一個線程去實現延時執(zhí)行