Comment rendre l'opération d'écriture idempotent?

Question

Je suis en train de lire un article sur le framework Gizzard sharding récemment publié par twitter (http://engineering.twitter.com/2010/04/introducing-gizzard-framework-for.html). Il mentionne que toutes les opérations d'écriture doivent être idempotentes pour assurer une grande fiabilité.

Selon wikipedia, "Les opérations Idempotent sont des opérations qui peuvent être appliquées plusieurs fois sans modifier le résultat." Mais, à mon humble avis, dans l'affaire Gizzard, les opérations d'écriture idempotentes devraient être celles dans lesquelles la séquence n'a pas d'importance. Maintenant, ma question est: Comment faire pour rendre les opérations d'écriture idempotentes?

La seule chose que je peux imaginer est d'avoir un numéro de version attaché à chaque écriture. Par exemple, dans un système de blog, chaque blog doit avoir un $ blog_id et $ content. Au niveau de l'application, nous écrivons toujours un contenu de blog tel que write ($ blog_id, $ content, $ version). Il est déterminé que la version $ est unique au niveau de l'application. Ainsi, si une application tente d'abord de définir un blog sur "Bonjour tout le monde" et que la deuxième veut que ce soit "Au revoir", alors écrit est idempotent. Nous avons deux telles opérations d'écriture:

write($blog_id, "Hello world", 1); 
write($blog_id, "Goodbye", 2); 

Ces deux opérations sont censées modifier deux enregistrements différents dans le DB. Donc, peu importe combien de fois et quelle séquence ces deux opérations sont exécutées, les résultats sont les mêmes.

C'est juste ma compréhension. Corrigez-moi si j'ai tort, s'il-vous plait.

Answer 1

Vous avez absolument raison. Les opérations idempotentes en elles-mêmes ne peuvent fournir qu'un seul modèle de résolution de conflit - "La dernière écriture gagne". C'est une solution possible si vos écritures ne peuvent pas être réorganisées à temps. Dans la mesure du possible, vous devez fournir des informations supplémentaires pour automatiser la résolution des conflits. Et votre idée n'est pas nouvelle. Dans le cas général, il est appelé vector clocks.

Nous utilisons la résolution de conflit basée sur la version dans l'un de nos systèmes qui collectent l'historique des modifications des objets dans notre système. Les clients envoient l'état de l'objet complet et les informations de version à un module d'historique (de manière asynchrone). Le module d'historique peut alors réorganiser les états de l'objet de manière correcte et enregistrer uniquement le delta dans le stockage persistant. La seule restriction est que le client doit utiliser une sorte de contrôle de concurrence lors de la modification de l'objet (optimistic locking est une très bonne méthode si vous suivez la version de l'état de l'objet).

Answer 2

Vous avez la bonne idée. La définition d'une valeur particulière est idempotente, car si vous effectuez cette opération plus d'une fois, vous obtenez le même résultat. L'écriture classique non-idempotente est un append, car la répétition entraînerait l'ajout de plusieurs copies.

Voir aussi previous stackoverflow question.