2010-04-08 17 views
7

Estoy leyendo un artículo sobre el marco de fragmentación de Gizzard recientemente publicado por twitter (http://engineering.twitter.com/2010/04/introducing-gizzard-framework-for.html). Menciona que todas las operaciones de escritura deben ser idempotentes para garantizar una alta fiabilidad.¿Cómo hacer que la operación de escritura sea idempotente?

De acuerdo con wikipedia, "las operaciones de Idempotent son operaciones que se pueden aplicar varias veces sin cambiar el resultado". Pero, en mi humilde opinión, en el caso de Gizzard, las operaciones de escritura idempotentes deberían ser aquellas en las que la secuencia no importa.

Ahora, mi pregunta es: ¿cómo hacer que las operaciones de escritura sean idempotentes?

Lo único que puedo imaginar es tener un número de versión adjunto a cada escritura. Por ejemplo, en un sistema de blog, cada blog debe tener un $ blog_id y $ contenido. En el nivel de aplicación, siempre escribimos contenido de blog como este write ($ blog_id, $ content, $ version). El $ version se determina como único en el nivel de la aplicación. Por lo tanto, si una aplicación primero intenta establecer un blog en "Hola mundo" y segundo quiere que sea "Adiós", entonces escriba es idempotente. Tenemos esas dos operaciones de escritura:

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

Estas dos operaciones se supone que son cambiadas dos registros diferentes en la base de datos. Entonces, no importa cuántas veces y qué secuencia se ejecutan estas dos operaciones, los resultados son los mismos.

Esto es lo que yo entiendo. Por favor corrígeme si estoy equivocado.

Respuesta

3

Tiene toda la razón. Las operaciones ideopotentes por sí mismas pueden proporcionar solo un patrón de resolución de conflictos: "La última escritura gana". Es una posible solución si sus escrituras no se pueden reordenar a tiempo. Si pueden, debe proporcionar información adicional para que la resolución de conflictos sea automática. Y tu idea no es nueva En el caso general, se llama vector clocks.

Utilizamos la resolución de conflictos basada en versiones en uno de nuestros sistemas que recoge el historial de cambios de objetos en nuestro sistema. Los clientes envían el estado completo del objeto y la información de la versión a un módulo de historial (de forma asíncrona). El módulo de historial puede reordenar los estados del objeto de la manera correcta y guardar solo el delta en almacenamiento persistente. La única restricción es que el cliente debe usar algún tipo de control de concurrencia al realizar cambios en el objeto (optimistic locking es un método muy bueno si rastrea la versión del estado del objeto).

2

Tienes la idea correcta. Establecer un valor particular es idempotente, porque si lleva a cabo esa operación más de una vez, obtendrá el mismo resultado. La escritura clásica no idempotente es un apéndice, porque la repetición daría lugar a la adición de copias múltiples.

Además, consulte este previous stackoverflow question.

Cuestiones relacionadas