python程式設計專案中線上問題排查與解決

文 |&程式設計客棧nbsp;極光

**：python 技術「id: pythonall」

最近開發中遇到個小問題，因為業務上的設計存在問題，導致資料庫表總是被鎖，而且是不定期的鎖定，導致伺服器執行異常，最後經過排查原因是多執行緒同時更新同一表中同一條記錄導致問題。今天就來跟大家說說該如何避免這種問題。

最近因為公司業務需要，uxnvagmwlv產品設計了一套業務系統，據說會有很多內部和外部人員使用，拿到系統說明我們研發部門拼命加班趕時間，經歷了兩個月的後終於把系統上線執行。程式設計客棧

剛開始用的人少，並沒有出現什麼問題，感覺系統還是很穩定，隨著後來用的人越來越多，系統就開始出現一些莫名其妙的問題，其中就有某些業務資訊在更新的時候總是報錯，查日誌就發現是表記錄被鎖定導致更新失敗。

找到錯誤問題後我們就開始一遍遍的翻日誌，各種分析查詢到底是什麼原因導致了表記錄被鎖。最後發現這個表的狀態字段，存在多個介面方法同時更新的情況，而且經常是同時操作的。也就是資料庫中存在多個會話同時操作同一表中同一行記錄，從而導致表記錄被鎖。

那定位到問題，要如何解決呢？這裡我們先了解兩個名詞：

悲觀鎖（pessimistic lock）：簡單解釋就是很悲觀，每次去拿資料的時候都認為別人會修改，所以每次在修改資料的時候都會上鎖，這樣別人想修改這個資料就會等待一直到它能拿到鎖。

樂觀鎖（optimistic lock）：這個正好相反，就是很樂觀，每次去修改資料的時候都認為別人不會修改，所以不會上鎖，但是在提交更新的時候會判斷一下在此期間別人有沒有去更新這個資料。樂觀鎖適用於讀多寫少的應用場景，這樣可以提高吞吐量。

通過這兩種方式就能解決問題，不過選哪種比較好，我們來簡單分析下：

好了，經過以上分析，已經有了比較清晰的解決思路，剩下就是碼**了：

/*** 樂觀鎖更新

* @param id

* @return

*/public boolean update(int id)", id);

cnt = update("update table_user set version=version + 1, status = 2 where id=# and version=#", id, user.version());

if(cnt > 0)

}return false;

}這裡只是基於 mysql 自身特性解決這個問題，當然還有很多其他的方式可以解決，例如通過 redis 或者 mq 訊息佇列等，如果大家感興趣我們可以以後再介紹。