記 Laravel Observer 導致 Redis 佇列異常

lidongyoo發表於2021-10-29
LaravelServerRedis佇列

1、業務邏輯

新建某個模型之後，利用 Observer 模型事件 Created 推入非同步簡訊傳送佇列

App\Http\Controllers\UsersController

    public function store(User $user)
    {
        \DB::beginTransaction();

        try{
            $input = request()->validated();
            $user->fill($input);
            $user->save();
            //do something......
            //其他資料表操作

            \DB::commit();
        } catch ($e \Exception) {
            \DB::rollBack();
        }

    }

App\Observers\UserObserver 

class UserObserver
{
    public function created (User $user)
    {
        dispatch(new SmsQueue($user));
    }
}

2、發現異常

業務部門反饋偶爾有使用者收取不到簡訊通知，我便檢視日誌發現偶爾有錯誤異常：No query results for model [App\Models\User]. 表示找不到對應的模型

我敲不應該啊，我是在建立模型之後再進行佇列呼叫……，遂對業務程式碼再進行仔細核查猜測應該是受事務影響。

驗證猜想：

    public function store(User $user)
    {
        \DB::beginTransaction();

        try{
            $input = request()->validated();
            $user->fill($input);
            $user->save();
            //do something......
            //其他資料表操作

            sleep(3); //三秒之後再提交事務            
            \DB::commit();
        } catch ($e \Exception) {
            \DB::rollBack();
        }

    }

果然在等待三秒之後提交佇列異常已是 100% 觸發。

3、原因分析

  1. $user->save() 這個方法建立資料成功，便會一併觸發排程器，將模型事件一一執行。
  2. 在事件中推送模型至佇列中，而佇列程式在不間斷消費佇列中資料。
  3. 在大部分情況下 do something 處理速度正常的話，佇列程式將會照常執行。
  4. 如果在 do something 階段偶爾出現延遲，造成事務還未 commit 而佇列已經開始消費新模型；故引發上述錯誤。

然後我在搜尋 Github Issues 記錄時，發現此問題在 2015 年的一個 Issue 已經有人提出，而在 Laravel 8.X 中終於新增了對事務模型事件的支援；文件地址，在社群文件似乎並沒有找到相關說明~

由於我的版本是 6.x 所以用不了這個新特性[哭唧唧]~~

4、解決異常

1. 修改 MySQL 事務隔離級別（不推薦）

這裡涉及到 MySQL 的事務隔離級別，InnoDB 引擎的預設隔離級別是 REPEATABLE READ，關於各個級別的區別可以在 官方文件 找到。

將隔離級別切換到 READ UNCOMMITTED 即可解決此問題，但是為了防止出現更大的問題我勸你別用這種方式~

2. 增加事件監聽

檢視原始碼得知在事務完成之後，會呼叫對應的事件，所以只需增加對事件的監聽即可。

image-20211029160303394

  1. 新增類 App\Handlers\TransactionHandler 

    class TransactionHandler
{
    public array $handlers;

    public function __construct()
    {
        $this->handlers = [];
    }

    public function add(\Closure $handler)
    {
        $this->handlers[] = $handler;
    }

    public function run()
    {
        foreach ($this->handlers as $handler) {
            $handler();
        }
    }
}

  2. 建立輔助函式 app/helpers.php

    
if (! function_exists('after_transaction')) {
    /*
     * 事務結束之後再進行操作
     * */
    function after_transaction(Closure $job)
    {
        app()->singletonIf(\App\Handlers\TransactionHandler::class, function (){
            return new \App\Handlers\TransactionHandler();
        });
        app(\App\Handlers\TransactionHandler::class)->add($job);
    }
}

  3. 建立監聽 App\Listeners\TransactionListener

    
namespace App\Listeners;

use App\Handlers\TransactionHandler;

class TransactionListener
{
    public function handle()
    {
        app(TransactionHandler::class)->run();
    }
}

  4. 繫結監聽 App\Providers\EventServiceProvider

    
namespace App\Providers;

use App\Listeners\TransactionListener;
use Illuminate\Database\Events\TransactionCommitted;
use Illuminate\Database\Events\TransactionRolledBack;
use Illuminate\Foundation\Support\Providers\EventServiceProvider as ServiceProvider;;

class EventServiceProvider extends ServiceProvider
{
    /**
     * The event listener mappings for the application.
     *
     * @var array
     */
    protected $listen = [
        TransactionCommitted::class => [
            TransactionListener::class
        ],
        TransactionRolledBack::class => [
            TransactionListener::class
        ]
    ];
}

  5. 更改呼叫方式 App\Observers\UserObserver 

class UserObserver
{
    public function created (User $user)
    {
        after_transaction(function() use ($user) {
            dispatch(new SmsQueue($user));
        });
    }
}

OK，一個優雅的解決方式就完成了~~

本作品採用《CC 協議》，轉載必須註明作者和本文連結

相關文章