背景

事情是這樣的，在公司內(nèi)部新開(kāi)發(fā)了一個(gè)功能還沒(méi)有上線，目前部署在測(cè)試環(huán)境，Node服務(wù)會(huì)開(kāi)啟一個(gè)定時(shí)任務(wù)，每5分鐘會(huì)處理好一部分?jǐn)?shù)據(jù)寫(xiě)入到mysql數(shù)據(jù)庫(kù)中。

在這之前，一切都運(yùn)行正常，中秋節(jié)后上班第一天打開(kāi)后臺(tái)系統(tǒng)發(fā)現(xiàn)沒(méi)有數(shù)據(jù)展示了，然后查詢數(shù)據(jù)庫(kù)發(fā)現(xiàn)歷史存儲(chǔ)的數(shù)據(jù)都沒(méi)了，沒(méi)了?，F(xiàn)在只會(huì)存儲(chǔ)最新的定時(shí)任務(wù)執(zhí)行后的數(shù)據(jù)?？稍诖酥g沒(méi)有修改過(guò)任何代碼，這個(gè)就神奇了。

頭疼時(shí)間

查看寫(xiě)入的數(shù)據(jù)始終都只會(huì)存儲(chǔ)最新的數(shù)據(jù)，則檢查是否沒(méi)有觸發(fā)更新的邏輯，全部都命中新增的邏輯。

const isExist = await this.Model.findOne({
  where: {
    projectId
  }
});
if (isExist) {
  await isExist.destroy()
  updateList.push(item)
} else {
  createList.push(item)
}

現(xiàn)在的邏輯是將新增和更新分開(kāi)處理，經(jīng)檢查發(fā)現(xiàn)所有的isExist都是null，導(dǎo)致全部命中新增的邏輯?？墒菙?shù)據(jù)庫(kù)中明明是有數(shù)據(jù)的，為什么查詢不出來(lái)呢？懷疑是有第三方數(shù)據(jù)存在臟數(shù)據(jù)之類的情況，所以我將數(shù)據(jù)庫(kù)現(xiàn)存數(shù)據(jù)全部清空，重新寫(xiě)入查看效果。結(jié)果第一次寫(xiě)入是正常的，后續(xù)還是不會(huì)觸發(fā)更新，經(jīng)過(guò)查詢發(fā)現(xiàn)每次寫(xiě)入數(shù)據(jù)庫(kù)大約十幾秒數(shù)據(jù)就被清空了。

可是在寫(xiě)入后的代碼邏輯中是沒(méi)有執(zhí)行刪除數(shù)據(jù)的處理，而且每次都是穩(wěn)定復(fù)現(xiàn)，寫(xiě)入后就被刪除了，查詢無(wú)果無(wú)奈找到db幫找原因。db查詢?nèi)罩窘o出的結(jié)論就是有定時(shí)執(zhí)行刪除的邏輯。

看到日志只能繼續(xù)在代碼中找原因了。由于此時(shí)是使用的 sequelize 的 bulkCreate 批量創(chuàng)建數(shù)據(jù)，所以開(kāi)始懷疑是不是這個(gè)批量處理的過(guò)程中出現(xiàn)了問(wèn)題，當(dāng)初是因?yàn)槊看螆?zhí)行的數(shù)據(jù)量太多所以沒(méi)有選擇單條執(zhí)行，這個(gè)時(shí)候?yàn)榱伺挪閱?wèn)題，所以我改成了單條數(shù)據(jù) create 方式創(chuàng)建數(shù)據(jù)。

this.Model.bulkCreate(list)

修改為：

for (const item of list) {
  this.Model.create(item)
}

結(jié)果不出意外的還是定時(shí)被刪除了，?? 然后開(kāi)始懷疑是事務(wù)沒(méi)有提交的問(wèn)題，雖然此邏輯是完全不需要用到事務(wù)操作，但還是抱著懷疑的心態(tài)試試看。

let transaction;
try {
  // 建立事務(wù)對(duì)象
  transaction = await this.ctx.model.transaction();
  for (const item of list) {
    // 事務(wù)增操作
    await this.Model.create(item, {
        transaction,
    });
    // 提交事務(wù)
    await transaction.commit();
  }
} catch (err) {
    // 事務(wù)回滾
    await transaction.rollback();
}

結(jié)果不出意外的還是定時(shí)被刪除了，??????此時(shí)已經(jīng)沒(méi)有改動(dòng)的余地了，此時(shí)的天都已經(jīng)黑了，可是問(wèn)題還沒(méi)解決，只能繼續(xù)面向百度編程了，此時(shí)搜索到也有同一個(gè)人遇到這樣的問(wèn)題，他的解決方案是修改表名稱，這時(shí)候也只能死馬當(dāng)作活馬醫(yī)了。

結(jié)果出意外的恢復(fù)正常寫(xiě)入以及更新了。

為什么更改了表名稱后就正常呢，思來(lái)想去也想不出為什么。結(jié)果今天在重新部署服務(wù)的時(shí)候看了一眼歷史部署記錄，發(fā)現(xiàn)了端倪。就在假期的最后一天晚上有一個(gè)部署記錄，然后我回看了和最開(kāi)始發(fā)生數(shù)據(jù)異常的時(shí)間段相差無(wú)幾。基本就可以斷定和此次部署有很大的關(guān)系，由于公司內(nèi)部的部署方案有docker和虛擬機(jī)兩種方式，導(dǎo)致每個(gè)時(shí)間段都會(huì)有兩個(gè)定時(shí)任務(wù)同時(shí)執(zhí)行，由于數(shù)據(jù)處理的過(guò)程中需要查詢第三方數(shù)據(jù)，最后兩邊寫(xiě)入的時(shí)間會(huì)存在一定的延時(shí)，導(dǎo)致寫(xiě)好的數(shù)據(jù)被另一邊執(zhí)行了刪除的邏輯，由于那臺(tái)服務(wù)器一直未更新修改的代碼，一直執(zhí)行的是最開(kāi)始那份先刪除再更新的邏輯。至于為啥執(zhí)行了刪除但是沒(méi)有更新，猜想是刪除后更新的邏輯出錯(cuò)了。這也是為什么修改了表名稱后就正常了，因?yàn)槟桥_(tái)服務(wù)器上面還是舊的代碼，新增刪除不能讀到之前的那張表了，問(wèn)題到此終于是告一段落了。

總結(jié)

到此是否感覺(jué)看了一個(gè)大烏龍事件，最終的原因和代碼沒(méi)有任何關(guān)系，但是卻三番五次的改動(dòng)無(wú)果。在排查過(guò)程中還有很多沒(méi)有寫(xiě)的，比如懷疑重復(fù)數(shù)據(jù)導(dǎo)致所以增加唯一索引，懷疑自增ID多大重新清零，但是這個(gè)改動(dòng)的過(guò)程中也學(xué)到了不少新的知識(shí)，如何使用事務(wù)，新增唯一索引，修改表名稱，重置自增ID等很多服務(wù)端相關(guān)的知識(shí)。最后的總結(jié)是遇到問(wèn)題先不要質(zhì)疑代碼，從系統(tǒng)層面，運(yùn)行版本，環(huán)境變量，運(yùn)維等方面也要有一定的思考

到此這篇關(guān)于Mysql寫(xiě)入數(shù)據(jù)十幾秒后被自動(dòng)刪除了如何解決的文章就介紹到這了,更多相關(guān)Mysql數(shù)據(jù)自動(dòng)刪除內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論