webman中數(shù)據(jù)庫清空卻仍然被定時任務(wù)訪問到，不知道算不算一個bug
由于之前項目放了一些測試數(shù)據(jù)，process下Task.php執(zhí)行定時任務(wù)，查詢出滿足要求的數(shù)據(jù)，并寫入Redis隊列，進(jìn)行短信郵件等發(fā)送通知。
然后昨天數(shù)據(jù)已經(jīng)清空了，按理說今天就不應(yīng)該有消息了，但是今天還是發(fā)送了消息，并且消息中帶有一些字段數(shù)據(jù)，說明這條記錄確實是被查詢出來了。
可能的情況是雖然清空了數(shù)據(jù)，但是定時任務(wù)依舊讀取著之前游標(biāo)之類記錄的數(shù)據(jù)，請問有辦法解決這個問題嗎？
更新一下，感覺不是數(shù)據(jù)庫的問題。
$re = Db::name('xxx')->insertGetId($data);
if($re){
redis_queue_send('task',$data);
}因為是要先寫入xxx表之后，再寫入隊列發(fā)送通知。但是查詢xxx表里面，并沒有寫入過數(shù)據(jù)。所以正常來說，re是假，就不應(yīng)該寫入隊列了。并且其他地方都沒有入口寫入這個隊列，只有這一個地方。
所以說，要想寫入隊列，re必須為真，re如果為真，xxx表里面必定有數(shù)據(jù)才對。但是xxx表里面沒有數(shù)據(jù)。。。懵逼了，求救
再補充一點，還有幾個其他的不同的消息通知，也是類似的代碼，有得隊列名也叫“task”，然后在里面if判斷執(zhí)行不同代碼，有的隊列名是其他的。之前每天會收到4個通知。然后今天只有1條通知了。也就是說，昨天清空了數(shù)據(jù)庫之后，有3條確實沒有通知了，但是還是有1條在異常通知?，F(xiàn)在就很懵，這條記錄是如何一直存在且通知的。。。
3個回答
這種情況基本上是烏龍了，清空表不影響插入，插入成功自然可以如隊列發(fā)郵件。
至于查詢數(shù)據(jù)庫沒有插入的數(shù)據(jù)，有以下可能性。
1、你以為插入的是A服務(wù)器的數(shù)據(jù)庫，實際是B服務(wù)器，俗稱搞錯服務(wù)器了。
2、你以為插入的是A數(shù)據(jù)庫，實際上插入的是B數(shù)據(jù)庫，搞錯庫了。
3、你以為插入的是A表，實際插入的是B表，搞錯表了。
4、插入數(shù)據(jù)庫后，表被定時腳本或者其他人清空了。
還有一種可能是，你的隊列是延遲隊列，比如是延遲到第二天發(fā)郵件。數(shù)據(jù)庫清空了，但是隊列里數(shù)據(jù)沒清空，第二天還是可以發(fā)郵件。
還有可能其它地方入的隊列，比如業(yè)務(wù)搞錯隊列，或者你清空的數(shù)據(jù)庫沒有關(guān)系的業(yè)務(wù)入的隊列。比如就是其它業(yè)務(wù)也有task命名的隊列，業(yè)務(wù)搞混了。
-
xiaobai1 2021-04-01感謝回復(fù)。
1、確認(rèn)過服務(wù)器數(shù)據(jù)庫，確實就這一個，不會搞錯。
2、數(shù)據(jù)庫也沒有搞錯，也是只有一個
3、表也不會搞錯，確實是同一個表，因為清空之前是正確的，后續(xù)也沒有做任何修改。
4、項目是我自己開發(fā)的，不會有其他人去碰的。而且從發(fā)送了郵件，到去查看這個表，也就一會的工夫，也不會有人如此坑我。。。
隊列也不會延遲，用的是即時發(fā)送的，并沒有延遲一天。
我這邊雖然寫的task，但其實名字更加復(fù)雜，不會有重名情況發(fā)生，我也遍歷搜索了所有文件，確認(rèn)只有這一處。而且即使重名，也不應(yīng)該發(fā)送的是我這邊的消息
我這邊能想到的情況都無法去解釋這個事情，很頭疼。。。 -
你說了那么多，代碼也沒幾行。你這代碼不能完整地表達(dá)你的邏輯。
-
xiaobai1 2021-04-01
我覺得足夠了，如果真的有人遇到過，或者了解相關(guān)知識，是可以明白的。如果沒遇到過，給了完整代碼也沒有作用。
邏輯很清晰，首先在我指定的時間定時發(fā)送了郵件，代表一定是在指定時間執(zhí)行了redis隊列任務(wù)。
而相關(guān)代碼塊，整個項目只有上述那幾行有，就說明，定時任務(wù)要么執(zhí)行了那幾行代碼，要么發(fā)生了其他奇怪的事情。
目前我只能假設(shè)是通過上面的代碼去執(zhí)行的redis_queue_send，那就代表上面的代碼的re一定需要為真（re那條是一個日志代碼，寫入了一個發(fā)送記錄日志，表示今天已經(jīng)發(fā)送過）。既然為真了，那么數(shù)據(jù)庫里面應(yīng)該有那條記錄才對。而數(shù)據(jù)庫里面沒有，這又是一個不合理的地方。
如果數(shù)據(jù)庫里面沒有記錄，那么理應(yīng)會重復(fù)發(fā)生這個郵件，但是沒有重復(fù)發(fā)送，說明定時任務(wù)讀取的數(shù)據(jù)庫里面是有發(fā)送記錄日志的，所以今天才只發(fā)送了一次。
但是我看不見這條日志，說明可能會存在一個幽靈數(shù)據(jù)庫，里面存在著這些數(shù)據(jù)記錄，但是我這邊確實檢查過了，使用的數(shù)據(jù)庫確認(rèn)百分比沒問題。所以這個幽靈數(shù)據(jù)庫是存在哪里的？
而且，我已經(jīng)清空數(shù)據(jù)庫了，發(fā)送郵件的前提條件是某條數(shù)據(jù)滿足某個要求，這條數(shù)據(jù)都被我刪除了，數(shù)據(jù)庫里面已經(jīng)沒有了，他是如何讀取到的這條數(shù)據(jù)，是緩存還是其他長連接導(dǎo)致的問題？
反正就是感覺可能有一個幽靈數(shù)據(jù)庫（可能是我的知識盲點），或者是redis隊列的bug。
而且我覺得restart一下估計就會恢復(fù)，肯定是觸發(fā)了某些奇怪的東西。
代碼方面就是正常的代碼，就算把項目源碼放上來了，沒有遇到過這種情況的人，估計也是沒辦法解答的。在這只是希望學(xué)過相關(guān)知識，或者有遇到過相關(guān)情況的朋友，來給個解決方案。。。 -
JustForFun 2021-04-01
@7646:你放的數(shù)據(jù)庫插入代碼對解決問題沒什么用。關(guān)鍵的任務(wù)代碼沒給出來，也沒有相關(guān)的調(diào)試信息，跟相關(guān)情況關(guān)系不大。。
-
