Architecture: une base de données utilisée par deux serveurs distincts

Question

Avis de non-responsabilité: L'auteur de ce message n'a que des connaissances théoriques et pratiquement aucune connaissance pratique de l'architecture logicielle pour les applications Web.

Disons que je veux construire une application web avec le contour de l'architecture suivante:

1. Un frontend web typique, qui permet aux utilisateurs de créer/modifier/supprimer un compte et crée/mises à jour/supprime le compte enregistrements dans ...
2. ... la base de données, qui stocke tous les comptes des utilisateurs;
3. et un bot Jabber (un service distinct, peut-être sur une machine physique distincte) qui parle aux utilisateurs, mais qui doit rechercher et mettre à jour des informations sur les utilisateurs dans la même base de données (2).

Donc, essentiellement j'ai deux applications qui utilisent la même base de données. Je ne suis pas sûr que ce soit une bonne solution en raison de l'intégrité des données, des conditions de course et d'autres problèmes. Un cas d'utilisation typique pourrait être: User1 interagit avec le bot Jabber (3) et le bot doit rechercher et mettre à jour les données dans la base de données, et exactement au même moment, User2 crée un compte via (1), ce qui nécessite une certaine interaction avec la base de données (2). Comment éviter ce type d'architecture tout en gardant la fonctionnalité requise?

Ou comment puis-je concevoir l'architecture d'une manière qui élimine la nécessité d'interroger une base de données à partir de deux services distincts? (Malheureusement, le «business model» de cette application ne permet pas d'avoir la gestion des comptes (1) et la logique «Jabber bot» (2) dans un service Web).

P.S. L'exigence la plus importante du système en question est la haute disponibilité (peut-être que cela affecterait la réponse d'une manière ou d'une autre).

Answer 1

Il n'y a aucun problème avec l'interrogation ou la mise à jour de la base de données à partir de deux services distincts. Les bases de données sont conçues pour prendre en charge plusieurs demandes différentes simultanément et il est indifférent pour la base de données si ces demandes simultanées proviennent de la même application ou d'applications différentes.

Même si nous supprimons le service Jabber (3), vous pouvez toujours traiter plusieurs demandes Web simultanées par l'application Web (1) et créer des requêtes de base de données parallèles.

Il n'y a aucun problème avec cela, jusqu'à ce que vous atteigniez une certaine limite. Une fois que vous aurez dépassé une certaine limite (disons 1000 demandes simultanées, mais que le nombre réel dépend de circonstances différentes), vous devrez peut-être mettre en cluster votre base de données. Mais avant d'atteindre cela, vous devrez faire face à d'autres goulots d'étranglement pour la performance. Par exemple. La mise en cache correctement vous permettra de servir plus d'utilisateurs avec une seule instance du serveur de base de données.