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