2012-12-12 107 views
4

背景重試失敗的MySQL查詢?

我在PHP`(5.2)的貝寶IPN處理程序,處理事務和存儲日期在MySQL數據庫中。該網站的活動較少。

偶爾MySQL查詢失敗。 (很少)我記錄了一切,如果PayPal消息未能得到處理,我可以查看我的日誌文件並重新發送PayPal消息。

思想/關注

但我想知道如果我可以做的過程有點更強大,而不是有放棄之前的處理器重新嘗試MySQL查詢。

我可能想等一下 - 不要立即敲擊多個查詢嘗試。

我希望能找到一些模式 - 尋找像「php mysql query retry」這樣的東西,但沒有太多的成功。

問題

  1. 是否有良好的實踐指南爲這個?

  2. 現有庫?

  3. 是一個簡單的循環和sleep之間每個查詢嘗試好,或可以有不良副作用?太原生了嗎?

+1

爲什麼不在查詢後檢查錯誤,如果爲真則重試?另一種方法只是將這個查詢標記爲「已撤消」,然後cron作業將使所有「未被採納」的數據運行並每隔幾分鐘重新執行一次。 – stasgrin

+0

所以你說在失敗的查詢後立即重試? – thomthom

+0

至於cron作業 - 我會創建一種方法來恢復剩餘事務的處理。這不僅僅是一個單一的查詢 - 而是來自前一個數據的多個集合和一些回覆。 – thomthom

回答

3

在php世界中良好的交易安全代碼並不是常態,但如果您在java或.net代碼示例中查找,有很多示例。

我見過的絕大多數好的數據庫代碼都將查詢放入函數中,並在放棄和記錄/排隊之前立即重試約3次。希望這會照顧你的問題。

最佳做法是使用innodb表並將所有關鍵的sql語句放入提交或回滾的事務中。這樣,即使某個特定的查詢失敗,您的數據仍處於一致的狀態。 (注意,如果你不小心,這也可能會增加鎖定問題)。

您不想在輪詢時做長時間的睡眠,因爲這可能會導致您的用戶瀏覽器掛起。他們需要立即回覆以確認購買是否已經完成。將作業放在隊列中使用cron作業或服務器守護進程是另一種方式,但不會爲用戶提供即時反饋,並且可能爲此目的而矯枉過正。

如果即時重試不起作用,您還有其他一些潛在的鎖定問題,您需要鍛鍊的失敗原因。

+0

對,這很有趣。我不確定實施重試是否是好的做法。在這種特殊情況下,我正在處理來自PayPal的消息,而不是人類最終用戶。我會嘗試實施一個重試系統,並仔細研究可能導致我的查詢不時失敗的原因。我自己不託管硬件,因此不能完全控制環境。這就是爲什麼我想盡可能使代碼更健壯的原因。 – thomthom