Actuellement, mon installation Discourse utilise une base de données PostgreSQL gérée par DigitalOcean et une instance Redis gérée par DigitalOcean. Le serveur Redis géré est-il nécessaire ?
Discourse stocke-t-il quelque chose de permanent dans Redis, ou est-il uniquement utilisé pour la mise en cache et d’autres types de données temporaires ?
Ma configuration actuelle (définitivement excessive, mais elle facilitera la mise à l’échelle si nécessaire un jour) :
Serveur PostgreSQL géré par DigitalOcean
Instance Redis gérée par DigitalOcean
Équilibreur de charge DigitalOcean
Deux droplets DigitalOcean, chacun exécutant Discourse
Une configuration plus simple que j’envisageais serait :
Serveur PostgreSQL géré par DigitalOcean
Un seul serveur exécutant à la fois Redis et l’application Discourse, avec une adresse IP flottante pour basculer vers un serveur de sauvegarde si nécessaire.
Ma configuration actuelle permet de remplacer les serveurs web de manière transparente sans que l’utilisateur ne s’en aperçoive grâce au serveur Redis externe. Je pense que la configuration plus simple déconnectera les utilisateurs si le serveur de secours est nécessaire. Est-ce le principal inconvénient d’avoir Redis sur le même serveur que Discourse ?
Discourse utilise Sidekiq, un planificateur de tâches open source écrit en Ruby. Sidekiq exécute généralement (et par défaut) uniquement les tâches et ne gère pas leur planification, ou du moins c’est ce que disent les références (peut-être que les choses ont changé ?) ; cependant, à ma connaissance, la version entreprise de Sidekiq inclut la planification dès la sortie de boîte (OOTB).
Sidekiq utilise Redis comme magasin de structures de données en mémoire et est également écrit en Ruby. Sidekiq lit les tâches depuis une file d’attente Redis en utilisant le modèle Premier Entré, Premier Sorti (FIFO) pour les traiter. Le traitement des tâches est asynchrone et permet à un thread web de servir des requêtes en direct plutôt que d’exécuter des tâches lourdes qui peuvent être « planifiées » pour s’exécuter en arrière-plan.
Sidekiq est décrit comme un « logiciel de traitement de files d’attente bien connu » et est utilisé par Discourse pour des tâches conçues pour s’exécuter en arrière-plan et non directement dans les requêtes de l’application web.
Vous pouvez explorer les nombreux types de tâches exécutées par Discourse, sur la base de cet aperçu succinct, dans le dépôt Discourse :
Redis peut être utilisé par Discourse dans d’autres parties de l’architecture ; mais pour l’instant, l’utilisation principale de Redis est celle de « compagnon » de Sidekiq, le « gars des tâches ». Les membres de l’équipe Discourse plus compétents que moi sur l’architecture de haut niveau (HLA) de Discourse peuvent certainement fournir plus de détails sur la façon dont Redis est utilisé dans cette architecture.
C’est un peu un sujet un peu daté, mais j’ai pensé que je devrais étoffer cette réponse puisque je suis tombé là-dessus en cherchant d’autres informations sur Discourse et Redis.
Voici une réponse d’un membre de l’équipe à la question à quoi Discourse utilise-t-il Redis, hormis Sidekiq :
Salut @Francis, quelle était ta facturation estimée pour tous ces services DigitalOcean ? Je suis juste curieux car je prévois d’installer le même service sur Google Cloud (200 $ gratuits). Le prix du service Discourse SAS est hors de mon budget.
