83 lines
2.7 KiB
Markdown
83 lines
2.7 KiB
Markdown
# Ordre d'arrivée des notes depuis les relais
|
|
|
|
## Comment fonctionne la récupération avec rotation de relais
|
|
|
|
### 1. Sélection du relai
|
|
|
|
Avec `tryWithRelayRotation`, le système :
|
|
|
|
1. **Essaie les relais un par un** dans l'ordre de priorité configuré
|
|
2. **Crée une subscription** avec **un seul relai à la fois**
|
|
3. Si le premier relai échoue (timeout ou erreur de connexion), passe au suivant
|
|
4. Continue jusqu'à trouver un relai qui répond
|
|
|
|
### 2. Arrivée des événements
|
|
|
|
Une fois qu'une subscription est établie avec un relai qui fonctionne :
|
|
|
|
```
|
|
Subscription créée → Relai commence à envoyer les événements
|
|
```
|
|
|
|
Les événements arrivent **de manière asynchrone** via le callback `sub.on('event')` :
|
|
|
|
```
|
|
Event 1 reçu
|
|
Event 2 reçu
|
|
Event 3 reçu
|
|
...
|
|
Event N reçu
|
|
EOSE (End of Stored Events) → Le relai a fini d'envoyer
|
|
```
|
|
|
|
### 3. Ordre des événements
|
|
|
|
L'ordre d'arrivée des événements **n'est pas garanti** :
|
|
|
|
- ❌ **Pas nécessairement chronologique** : Le relai peut envoyer dans n'importe quel ordre
|
|
- ❌ **Pas nécessairement par ID** : Les événements peuvent arriver dans un ordre aléatoire
|
|
- ✅ **Déduplication automatique** : Les événements avec le même ID ne sont traités qu'une seule fois
|
|
|
|
### 4. Exemple concret
|
|
|
|
Si vous avez 3 relais configurés : `relay1`, `relay2`, `relay3`
|
|
|
|
**Scénario 1 : Relay1 fonctionne**
|
|
```
|
|
1. Essaie relay1 → ✅ Connexion réussie
|
|
2. Reçoit événements depuis relay1 uniquement
|
|
3. Tous les événements viennent de relay1
|
|
```
|
|
|
|
**Scénario 2 : Relay1 échoue, relay2 fonctionne**
|
|
```
|
|
1. Essaie relay1 → ❌ Timeout après 5 secondes
|
|
2. Essaie relay2 → ✅ Connexion réussie
|
|
3. Reçoit événements depuis relay2 uniquement
|
|
4. Tous les événements viennent de relay2
|
|
```
|
|
|
|
**Scénario 3 : Tous les relais fonctionnent**
|
|
```
|
|
1. Essaie relay1 → ✅ Connexion réussie (premier qui répond)
|
|
2. Reçoit événements depuis relay1 uniquement
|
|
3. relay2 et relay3 ne sont pas utilisés pour cette subscription
|
|
```
|
|
|
|
### 5. Pourquoi un seul relai à la fois ?
|
|
|
|
- **Efficacité** : Un seul relai suffit pour récupérer les événements
|
|
- **Simplicité** : Plus facile de gérer une seule source
|
|
- **Pas de doublons** : Les événements viennent d'une seule source, pas besoin de dédupliquer
|
|
|
|
### 6. Problèmes de rotation pendant la réception
|
|
|
|
⚠️ **Important** : Si un relai échoue **pendant** la réception des événements :
|
|
- La subscription est interrompue
|
|
- Les événements déjà reçus sont traités
|
|
- Un nouveau relai est essayé pour une nouvelle subscription
|
|
|
|
## Conclusion
|
|
|
|
Les notes arrivent **d'un seul relai à la fois**, dans un **ordre non garanti** (pas forcément chronologique), et sont traitées au fur et à mesure de leur arrivée jusqu'à recevoir EOSE (End of Stored Events).
|