[PHP] Laravel常見報錯總結（持續更新）

通過查詢 laravel 源代碼，可以确認異常是在 setpdo 方法中抛出的：

按字面意思了解，出現此錯誤是因為在開啟了事務的情況下，切換了資料庫連接配接。不過有時候，即便代碼裡沒有顯式的切換資料庫連接配接，也有可能出現此錯誤。比如說在執行查詢語句出錯的時候，系統會通過 tryagainifcausedbylostconnection 方法判斷問題是不是因為丢失連接配接導緻的，如果是，那麼系統會通過 reconnect 方法重新連接配接，在重新連接配接的時候，系統會通過 disconnect 方法執行一些清理工作，其中調用了 setpdo 方法。

理清了前因後果，自然就知道如何解決問題了：檢查網絡情況，确認資料庫連接配接丢失的原因，這可能是某個裝置有問題，也可能是某個 timeout 設定不當所緻。

一個相對 dirty 的處理方法是在查詢前執行一下 db::reconnect() 方法重新連接配接一下資料庫。

此問題實際上和 laravel 沒太大關系，而是隊列服務 beanstalk 導緻的。

要解決這個問題，需要先了解一個消息的生命周期：當一個消息被放入隊列的時候，它就進入了 ready 狀态，與此同時，它會關聯一個 ttr（time to run） 計時器，表示此消息允許運作的時間，當此消息被消費時，它就進入了 reserved 狀态，消費完後，此消息就會被删除，如果消費的時間過長，比 ttr 還長，那麼系統會認為認為此消費者已經挂了，進而會把消息從 reserved 狀态退回到 ready 狀态，交給另一個消費者重新處理。于是乎同一個消息可能會被多個消費者處理，第一個處理完的消費者可以正常的删除消息，而其餘的消費者在删除消息的時候就會報無法删除的錯誤。

解決方法很簡單，首先，需要確定 ttr 的設定不能太小；其次，實際上 beanstalk 提供了一個專門的 touch 指令來解決執行時間過長的問題，此外，有些時候我們可能需要在應用層面上通過加鎖來規避同一個消息被多個消費者同時處理的情況。

在激活了 laravel 讀寫分離的前提下，當消費者處理消息的時候，可能會收到類似錯誤。一個有潛在問題的隊列指令大概如下所示：

很明顯，當開啟了 laravel 讀寫分離的時候，因為主從延遲的緣故，是以 find 可能查詢不到相應的資料，一旦我們分析到了這裡，那麼很可能會把寫法修改成下面的樣子：

也就是說，通過 laravel 的 onwriteconnection 方法把查詢固定在主伺服器上，不過實際上無效。問題症結在于反序列化的時候，系統會在從伺服器上一次 findorfail 調用。

因為我們無法 hack 到架構内部，是以 onwriteconnection 就沒有意義了。其實換個角度看問題，隻要在系列化的時候，保證别用資料庫對象做屬性即可：