L'utilisation d'événements Observer dans Laravel provoque un problème d'exception de file d'attente Redis

La colonne tutoriel de Laravel partagera avec vous l'enregistrement de l'exception de file d'attente Redis causée par Laravel Observer. J'espère que cela sera utile à tout le monde !

                                                                                                           

1. Logique métier

Après avoir créé un nouveau modèle, utilisez l'événement de modèle Observer créé pour le pousser dans la file d'attente d'envoi de SMS asynchrone

AppHttpControllersUsersControllerAppHttpControllersUsersController

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

    }

AppObserversUserObserver

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

2、发现异常

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

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

验证猜想：

    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、原因分析

• $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

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

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. 创建监听  AppListenersTransactionListener

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

4. 绑定监听 AppProvidersEventServiceProvider

   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. 更改调用方式  AppObserversUserObserver

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

   AppObserversUserObserver
rrreee

2. Des anomalies ont été trouvées

Le service commercial a signalé que les utilisateurs ne pouvaient parfois pas recevoir de notifications par SMS. J'ai donc vérifié les journaux et constaté qu'il y avait des exceptions d'erreur occasionnelles : aucun résultat de requête pour le modèle [AppModelsUser It]. signifie que le modèle correspondant est introuvable

Moi Cela ne devrait pas être correct. J'ai fait l'appel de file d'attente après avoir créé le modèle... Ensuite, j'ai soigneusement vérifié le code commercial et j'ai deviné qu'il était affecté par la transaction. 🎜🎜Vérification de la conjecture :🎜rrreee🎜 Effectivement, après avoir attendu trois secondes, l'exception de la file d'attente de soumission est déclenchée à 100 %. 🎜🎜🎜🎜3. Analyse des causes🎜

• 🎜$user->save() Si cette méthode réussit à créer des données, le planificateur sera également déclenché. . Exécutez les événements du modèle un par un. 🎜🎜
• 🎜Poussez le modèle vers la file d'attente lors de l'événement, et le processus de file d'attente consomme continuellement les données de la file d'attente. 🎜🎜
• 🎜Dans la plupart des cas, si la vitesse de traitement des tâches est normale, le processus de file d'attente se déroulera comme d'habitude. 🎜🎜
• 🎜S'il y a un retard occasionnel pendant la phase d'action, la transaction n'a pas encore été validée mais la file d'attente a commencé à consommer de nouveaux modèles, l'erreur ci-dessus est donc provoquée ; 🎜🎜

🎜Ensuite, lorsque j'ai effectué une recherche dans l'enregistrement des problèmes Github, j'ai découvert que ce problème avait été soulevé dans un problème en 2015 et que la prise en charge des événements de modèle de transaction a finalement été ajoutée dans Laravel 8.X ; learnku.com /docs ; /laravel/8.x/eloqu..., je ne trouve pas d'instructions pertinentes dans la documentation de la communauté~🎜🎜Comme ma version est 6.x, je ne peux pas utiliser cette nouvelle fonctionnalité [pleurer]~~🎜 🎜🎜🎜 4. Résolvez l'exception🎜

🎜🎜1. Modifier le niveau d'isolation des transactions MySQL (non recommandé)

🎜Cela implique le niveau d'isolation des transactions de MySQL. Le niveau d'isolation par défaut du moteur InnoDB est RÉPÉTABLE. LIRE. Concernant les différences entre les niveaux, cela peut être trouvé dans la documentation officielle. 🎜🎜Changer le niveau d'isolement sur READ UNCOMMITTED peut résoudre ce problème, mais afin d'éviter des problèmes plus importants, je vous conseille de ne pas utiliser cette méthode~🎜

🎜🎜2 Ajouter une surveillance des événements

🎜Voir le code source. Nous savons qu'une fois la transaction terminée, l'événement correspondant sera appelé, il suffit donc d'ajouter une surveillance pour l'événement. " />🎜

1. 🎜Nouvelle classe AppHandlersTransactionHandler🎜rrreee🎜
2. 🎜Créer une fonction d'assistance app/helpers.php🎜rrreee🎜
3. 🎜Créer un écouteur AppListenersTransactionListener 🎜rrreee🎜
4. 🎜Lier l'écouteurAppProvidersEventServiceProvider🎜rrreee🎜
5. 🎜Changer la méthode d'appel AppObserversUserObserver🎜🎜🎜rrreee🎜OK, un élégant The la solution est complète~~🎜🎜Recommandations associées : 🎜Les cinq derniers didacticiels vidéo Laravel🎜🎜

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!