Die Verwendung von Observer-Ereignissen in Laravel verursacht ein Redis-Warteschlangenausnahmeproblem

In der Tutorial-Kolumne von Laravel erfahren Sie mehr über die durch Laravel Observer verursachte Redis-Warteschlangenausnahme. Ich hoffe, dass sie für alle hilfreich ist!

                                                                                                                ?? >

    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();
        }

    }

2. Es wurden Anomalien gefunden

Die Geschäftsabteilung berichtete, dass Benutzer gelegentlich keine SMS-Benachrichtigungen erhalten konnten, daher habe ich die Protokolle überprüft und festgestellt, dass es gelegentliche Fehlerausnahmen gab: Keine Abfrageergebnisse für das Modell [AppModelsUser]. bedeutet, dass das entsprechende Modell nicht gefunden werden kann.

Ich habe den Warteschlangenaufruf nach der Erstellung des Modells getätigt ... Dann habe ich den Geschäftscode sorgfältig überprüft und vermutet, dass er von der Transaktion betroffen ist. AppHttpControllersUsersController

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

AppObserversUserObserver

    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();
        }

    }

2、发现异常

业务部门反馈偶尔有用户收取不到短信通知，我便查看日志发现偶尔有错误异常：No query results for model [AppModelsUser]. 表示找不到对应的模型

我敲不应该啊，我是在创建模型之后再进行队列调用……，遂对业务代码再进行仔细核查猜测应该是受事务影响。

验证猜想：

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();
        }
        $this->handlers = [];
    }}

果然在等待三秒之后提交队列异常已是 100%  触发。

3、原因分析

• $user->save() 这个方法创建数据成功，便会一并触发调度器，将模型事件一一执行。

• 在事件中推送模型至队列中，而队列进程在不间断消费队列中数据。

• 在大部分情况下 do something 处理速度正常的话，队列进程将会照常运行。

• 如果在 do something 阶段偶尔出现延迟，造成事务还未 commit 而队列已经开始消费新模型；故引发上述错误。

然后我在搜索 Github Issues 记录时，发现此问题在 2015 年的一个 Issue 已经有人提出，而在 Laravel 8.X 中终于新增了对事务模型事件的支持；learnku.com/docs/laravel/8.x/eloqu... ，在社区文档似乎并没有找到相关说明~

由于我的版本是 6.x 所以用不了这个新特性[哭唧唧]~~

4、解决异常

1. 修改 MySQL 事务隔离级别（不推荐）

这里涉及到 MySQL 的事务隔离级别，InnoDB 引擎的默认隔离级别是 REPEATABLE READ，关于各个级别的区别可以在 官方文档 找到。

将隔离级别切换到 READ UNCOMMITTED 即可解决此问题，但是为了防止出现更大的问题我劝你别用这种方式~

2. 增加事件监听

查看源码得知在事务完成之后，会调用对应的事件，所以只需增加对事件的监听即可。

1. 新增类 AppHandlersTransactionHandler

   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);
       }}

2. 创建辅助函数  app/helpers.php

   namespace App\Listeners;use App\Handlers\TransactionHandler;class TransactionListener{
       public function handle()
       {
           app(TransactionHandler::class)->run();
       }}

3. 创建监听  AppListenersTransactionListener

   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
           ]
       ];}

4. 绑定监听 AppProvidersEventServiceProvider

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

5. 更改调用方式  AppObserversUserObserver

   Verifizierung der Vermutung:
rrreee

Tatsächlich wird nach einer Wartezeit von drei Sekunden die Ausnahme in der Übermittlungswarteschlange zu 100 % ausgelöst.

3. Ursachenanalyse

$user->save() Wenn diese Methode erfolgreich Daten erstellt, wird auch der Scheduler ausgelöst . Führen Sie Modellereignisse einzeln aus. 🎜🎜

🎜Schieben Sie das Modell im Ereignis in die Warteschlange, und der Warteschlangenprozess verbraucht kontinuierlich Daten in der Warteschlange. 🎜🎜

🎜In den meisten Fällen läuft der Warteschlangenprozess wie gewohnt ab, wenn die Verarbeitungsgeschwindigkeit normal ist. 🎜🎜

🎜Wenn es während der Do-Etwas-Phase gelegentlich zu Verzögerungen kommt, wurde die Transaktion noch nicht festgeschrieben, aber die Warteschlange hat bereits begonnen, das neue Modell zu verbrauchen. Daher wird der obige Fehler verursacht. 🎜🎜🎜Als ich dann den Github-Issues-Datensatz durchsuchte, stellte ich fest, dass dieses Problem in einem Issue im Jahr 2015 angesprochen wurde und die Unterstützung für Transaktionsmodellereignisse endlich in Laravel 8.X hinzugefügt wurde; learnku.com /docs /laravel/8.x/eloqu..., ich scheine keine relevanten Anweisungen in der Community-Dokumentation zu finden~🎜🎜Da meine Version 6.x ist, kann ich diese neue Funktion nicht verwenden [heult]~~🎜 🎜🎜🎜 4. Beheben Sie die Ausnahme🎜

🎜🎜1. Ändern Sie die MySQL-Transaktionsisolationsstufe (nicht empfohlen)

🎜Dies betrifft die Transaktionsisolationsstufe von MySQL. Die Standardisolationsstufe der InnoDB-Engine ist REPEATABLE LESEN. Zu den Unterschieden zwischen den Levels kann man es in der offiziellen Dokumentation nachlesen. 🎜🎜Das Ändern der Isolationsstufe auf READ UNCOMMITTED kann dieses Problem lösen, aber um größere Probleme zu vermeiden, rate ich Ihnen, diese Methode nicht zu verwenden~🎜

🎜🎜2 Ereignisüberwachung hinzufügen

🎜Quellcode anzeigen Wir wissen, dass nach Abschluss der Transaktion das entsprechende Ereignis aufgerufen wird, sodass wir nur die Überwachung für das Ereignis hinzufügen müssen. 🎜🎜 🎜

1. 🎜Neue Klasse AppHandlersTransactionHandler🎜rrreee🎜
2. 🎜Hilfsfunktion erstellen app/helpers.php🎜rrreee🎜
3. 🎜Listener erstellen AppListenersTransactionListener 🎜rrreee🎜
4. 🎜Bind listenerAppProvidersEventServiceProvider🎜rrreee🎜
5. 🎜Ändern Sie die aufrufende Methode AppObserversUserObserver🎜🎜🎜rrreee🎜OK, ein elegantes The Die Lösung ist vollständig~~🎜🎜Verwandte Empfehlungen: 🎜Die neuesten fünf Laravel-Video-Tutorials🎜🎜

Das obige ist der detaillierte Inhalt vonDie Verwendung von Observer-Ereignissen in Laravel verursacht ein Redis-Warteschlangenausnahmeproblem. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!