[Ruby on Rails] Arrêtez de "boucler jusqu'à ce que ..."

Pourquoi écrire

Cela fait un mois que j'ai commencé à travailler. En coopération avec la synchronisation, nous avons libéré une fonction et avons réussi à fonctionner normalement. Cependant, en fait, j'ai eu un problème une fois que le processus ne pouvait pas être terminé dans l'environnement de production. Je le publierai sous forme de mémorandum pour éviter que la même chose ne se reproduise.

Pourquoi c'est arrivé

En termes simples, c'est parce que vous êtes tombé dans une «boucle infinie». La mise en œuvre de cette heure consiste à surveiller les travaux exécutés sur Sidekiq, à détecter la duplication ou la perte de travaux et à alerter Slack.

La première chose que j'ai frappée était ・ Exécuter à partir du calendrier ・ Programmé à partir de l'exécution Si un travail est acquis et vérifié au moment des deux, il sera souvent détecté comme une erreur.

Il y avait un décalage de 1 seconde à 5 secondes dans la vitesse d'aller et de venir (vérifié dans l'environnement local). Si le nouveau travail de surveillance de fonction s'exécute à ce moment, il sera détecté comme une erreur même si le travail s'exécute normalement.

Les mesures que j'ai prises contre ça ** Faites une boucle lors de l'acquisition d'un travail, et si toutes les données sont identiques, prenez 5 secondes de «veille» tout en acquérant 10 fois, et passez-le au processus suivant ** C'était ça. Ce n'était pas bon ...

Comment ça s'est amélioré

Dans l'environnement de production, il s'exécute toutes les 30 secondes et termine le processus en environ 10 secondes, se déplaçant dans le calendrier et l'exécution à un rythme vertigineux, ce qui est un travail animé.

Il faut plus de 50 secondes pour l'obtenir en tournant la boucle (je le faisais exprès), donc la raison est que les données obtenues en 10 acquisitions ne seront pas les mêmes pour toujours. C'était une boucle infinie.

Lors des corrections, j'ai arrêté de dire ** en boucle jusqu'à ce que toutes les données soient identiques **. Mais je savais que si je ne filtrais pas l'acquisition correctement, je finirais par gâcher les alertes de Slack.

Par conséquent, nous avons décidé de la limite supérieure de la boucle et l'avons modifiée par la spécification qui transmet le plus de données obtenues au processus suivant **.

monitoring_sidekiq.rb

#réduction
def sidekiq_logs_arr_in
  consistency_check_sidekiq_logs = []
  #J'avais l'habitude d'utiliser l'instruction while et refaire, mais j'ai défini une limite supérieure claire
  50.times do
    queues = []
    #Évitez d'utiliser le sommeil en raison des variations dans le moment du rendez-vous à l'exécution et de l'exécution au rendez-vous
    sleep 2
    #Obtenez un emploi sur Sidekiq
    Sidekiq::Workers.new.each { |_process_id, _thread_id, job| queues << job["queue"] }
    Sidekiq::ScheduledSet.new.each { |job| queues << job["queue"] }
    queues = queues.sort
    consistency_check_sidekiq_logs << queues
  end
  #Renvoie enfin le plus de données de la boucle en comptant
  consistency_check_sidekiq_logs.max_by { |x| consistency_check_sidekiq_logs.count x }
end
#réduction

En faisant cela, il n'est plus nécessaire de lever une exception même pendant le traitement normal pendant le traitement suivant, et il est maintenant possible d'obtenir un journal cohérent même s'il existe un travail sain. ..

Que faire à l'avenir

Tout d'abord, si une condition spécifique n'est pas remplie, essayez de ne pas effectuer autant que possible le processus de refaire dans le processus de boucle. J'étais parfaitement conscient qu'il est extrêmement important de définir une limite supérieure et de former une boucle qui peut être évitée en toutes circonstances.

Je suis très prudent à l'avenir car cela peut causer de gros dommages à l'entreprise si une boucle infinie se produit dans un environnement de production.