一個故障的生命週期

這是一個關於mysql的故事

前奏：

記錄移動設備id在移動開發中應該是很常見的操做，通常的流程是：移動設備在應用商店中下載app後打開，這時客戶端程序會將獲取設備信息並提交到服務器端接口入庫。可是因爲XX緣由咱們須要在這以前再加一個一樣的請求，也就是在這以前有可能已經寫入數據庫了，可是還要再走一遍相同的邏輯。

症狀：

當我寫好程序交由客戶端同窗去測試的時候，難以想象的事情發生了：有大概20%的機率會報錯「Duplicate entry XXX」(此處省去30字)，而後客戶端同窗還反映說若是兩個請求間隔1秒鐘就沒問題。

分析

我看完代碼後發現邏輯是這樣的：model文件裏首先判斷設備id是否存在，不存在則寫入。結合以前的反饋我判定：第一次寫入成功且第二次判斷時爲空的時候，再寫入的時候數據庫裏已經有數據了。運維同窗說服務器mysql是讀寫分離的，也就是說出現這種問題的緣由是：第一次訪問服務器時若是設備id不存在（slave）則寫入master，這時master開始向slave同步，第二次訪問服務器時若是以前的同步完成了則不會二次寫入，若是同步沒有完成則會第二次寫入master，這時就報錯了。

解決

1.既然客戶端同窗說延遲1秒就ok了淡然能夠這樣幹，可是這個時間其實和同步時間相關的，不必定是這個數字，有必定的風險，因此不建議採納，可是救急是能夠的。

2.個人方案是：第一次寫入的時候將當前的設備id保存在memcache中，第二次訪問的時候直接斷定memcache中是否存在，保存時間的話，設置個10秒鐘基本就夠了。

結語：

其實這種連續寫入同一數據到同一表中的需求不是不少，可是業務需求千奇百怪，熟悉業務的同時也要熟悉生產環境，這樣才能快速定位問題，解決問題。