2017-09-29 10 views
2

Je m'interroge sur la sémantique de l'atomicité dans Chronicle Map. Si j'ai une carte de chronique partagée sur 2 nœuds (serveurs) et que j'essaie d'insérer la même clé dans cette carte simultanément sur les deux nœuds, quelles sont les sémantiques transactionnelles?Chronicle Carte atomicité sémantique

Le premier put réussira-t-il et le second échouera-t-il?

Je suis curieux de savoir si Chronicle Map garantit la même sémantique transactionnelle que, Apache Zookeeper? Dans mon cas, je voudrais compter sur le fait que si node1 met une clé K1 dans la carte, ce node2 serait capable de vérifier l'existence de K1 et s'il n'y est pas il connaîtrait définitivement c'est le premier à ajouter K1.

En effet, demander si une mise sur ChronicleMap est une transaction distribuée, qui s'étend sur les 2 nœuds.

Un grand merci Clifford

Répondre

1

Chronique Map utilise la cohérence finale et le dernier gagne. Lorsque vous regardez les échelles de micro seconde fois, les nœuds sont dans un nœud de cerveau divisé car il n'y a aucun moyen de les synchroniser à cette vitesse. Ceci est par nature car Map est conçu pour prendre en charge des millions de mises à jour par seconde et par serveur. En général, il n'est pas difficile de s'assurer que deux serveurs ne mettent pas à jour la même clé en même temps en fonctionnement normal. Par exemple. vous pouvez passer toutes les mises à jour à un serveur en utilisant le moteur ou vous pouvez partitionner les clés pour la mise à jour. Alors que les transactions distribuées sonnent comme une excellente idée, vous devriez noter que; - ils sont de plusieurs ordres de grandeur plus lentement, - très difficile à récupérer à partir de quand vous avez une défaillance comme le cerveau divisé. - tester votre application fonctionne correctement dans différentes conditions d'échec est une vraie douleur. Mon avis nous il est préférable de concevoir un système qui n'a pas besoin de cette hypothèse et vous saurez comment il se comporte en cas de panne sans tests approfondis. Supposons que vous installiez zookeeper dans trois centres de données et que la défaillance d'un centre de données n'interrompe pas votre activité en vous assurant qu'aucun datacenter ne possède la moitié des nœuds ou plus (deux centres de données ne suffisent pas). cerveau causée par une interconnexion lente, cela influe sur les mises à jour, mais dans un transitoire d'une manière difficile à reproduire ou à tester. Avec la carte de chronologie, les centres de données peuvent être déconnectés pendant un certain temps et toutes leurs garanties sont honorées et vous n'avez aucun test supplémentaire à faire. En fait, vous pouvez perdre tous les nœuds sauf un et avoir encore un fonctionnement complet.

+1

Merci pour la réponse détaillée Peter. J'ai des commandes qui peuvent être routées vers l'une des 3 passerelles sortantes, pour une livraison finale vers un ECN (ceci afin d'assurer une haute disponibilité). J'essaie de garantir que la première passerelle pour recevoir un ordre est celle qui l'envoie à l'échange et l'autre 2 ne le devrait jamais. J'allais ajouter l'identifiant de commande unique à Chronicle et demander aux 3 passerelles de vérifier l'existence de cet identifiant de commande avant d'envoyer une commande. Sur la base de vos recommandations ci-dessus, avez-vous des suggestions sur la façon d'y parvenir? Chronicle Map est-il bien adapté? – cliff