Teoría distribuida (5) Cosas distribuidas: TCC

1. Introducción

En 2007, Pat Helland publicó un artículo titulado "La vida más allá de las transacciones distribuidas: la opinión de un apóstata" (http://adrianmarriott.net/logosroot/papers/LifeBeyondTxns.pdf) y propuso el concepto TCC (Try-Confirm-Cancel) .

La confirmación en dos fases (2PC) y la confirmación en tres fases (3PC) no se aplican a escenarios de grandes empresas simultáneas. En comparación con 2PC y 3PC, el mecanismo de transacción de TCC no bloquea todo el recurso, pero al introducir un mecanismo de compensación , el recurso se convierte en una forma lógica empresarial y la granularidad del bloqueo se reduce.

La idea central de TCC es: para cada operación, se debe registrar una operación de confirmación y compensación (revocación) correspondiente , la cual se divide en tres etapas:

• ** Pruebe: ** En esta etapa, los recursos de cada servicio se prueban y los recursos se bloquean o reservan;
• ** Confirmar: ** Realice operaciones comerciales reales sin ningún control comercial, y solo use los recursos comerciales reservados en la fase de Prueba. La operación Confirmar requiere un diseño idempotente, y se requiere un reintento después de que la Confirmación falla;
• ** Cancelar: ** Si el método comercial de cualquier servicio se ejecuta incorrectamente, entonces se requiere una compensación aquí, es decir, se realiza una operación de reversión y se liberan los recursos comerciales reservados en la fase de Prueba. La operación Cancelar requiere un idempotente diseño, y se requiere después de que la cancelación falla. Vuelva a intentarlo.

Por ejemplo, existen dos servicios en el sistema de comercio electrónico: servicio de pedido A, servicio de inventario B: al brindar servicios externamente, se debe aceptar cierta incertidumbre, es decir, una llamada al servicio A / B es solo una operación temporal, y el servicio El consumidor se reserva el derecho de cancelación posterior. Si el consumidor cree que la transacción global debe ser revertida, solicitará la cancelación de la operación temporal anterior; si el consumidor cree que la transacción global debe estar comprometida, realizará una operación de confirmación.

En segundo lugar, la implementación de TCC

TCC divide una operación de transacción en tres etapas: Probar, Confirmar y Cancelar. Lo entendemos a través de un ejemplo de pedido / inventario. Suponga que nuestro sistema distribuido contiene un total de 4 servicios: servicio de pedidos, servicio de inventario, servicio puntual, servicio de almacenamiento, cada servicio tiene su propia base de datos

2.1 Prueba

La etapa de prueba se usa generalmente para bloquear un determinado recurso, establecer un estado listo o congelar parte de los datos. Para cada servicio del ejemplo, el trabajo realizado en la fase de prueba es el siguiente:

• Servicio de pedido: primero establezca un estado intermedio "ACTUALIZACIÓN" en lugar de establecer directamente el estado "pago exitoso";
• Servicio de inventario: primero use un campo de inventario congelado para guardar el número de inventario congelado, en lugar de deducir directamente el inventario;
• Servicio de puntos: pre-aumento de puntos para miembros;
• Servicio de almacenaje: cree una orden de salida de ventas, pero el estado es DESCONOCIDO.

2.2 Confirmar

Según la ejecución de la fase Try, Confirm se divide en dos situaciones:

1. Idealmente, si todos los intentos se ejecutan con éxito, se ejecutará la lógica Confirmar de cada servicio;
2. Si la ejecución de Try de algunos servicios falla, se ejecuta la tercera etapa: Cancelar.

La fase de confirmación generalmente requiere que cada servicio implemente la lógica de confirmación por sí mismo:

• Servicio de pedido: La lógica de confirmación puede ser cambiar el estado intermedio del pedido a PAGADO: el pago se ha realizado correctamente;
• Servicio de inventario: borre el inventario congelado y deduzca el inventario real al mismo tiempo;
• Servicio de puntos: borre los puntos previamente aumentados y aumente los puntos de miembros reales al mismo tiempo;
• Servicio de almacenaje: Modifique el estado de la orden de salida de ventas a CREADO-CREADO.

Los diversos servicios en la fase Confirmar pueden tener problemas. En este momento, el marco TCC (como ByteTCC, tcc-transaction, himly) generalmente se requiere. El marco de transacciones TCC generalmente registra el registro de actividad de algunas transacciones distribuidas y guarda el varias etapas de la operación de la transacción Estado, a fin de garantizar la consistencia final de toda la transacción distribuida.

2.3 Cancelar

Si la fase de prueba se ejecuta de forma anormal, se ejecutará la fase de cancelación. Por ejemplo, para el servicio de pedidos, una lógica de cancelación que se puede implementar es: establecer el estado del pedido en "CANCELADO"; para el servicio de inventario, la lógica de cancelación es: deducir el inventario congelado y agregarlo nuevamente al inventario vendible.

Para simplificar el uso de TCC, muchas empresas suelen dividir una determinada interfaz central de un servicio en dos, como la interfaz de deducción de inventario del servicio de inventario, en dos subinterfaces: ① interfaz de deducción ② interfaz de inventario de deducción de reversión, el El marco TCC asegura que cuando una interfaz no se ejecuta, se ejecuta la interfaz de reversión correspondiente.

Tres, resumen

Desde el proceso normal, TCC sigue siendo un acuerdo de presentación de dos fases. Sin embargo, cuando hay un problema en la ejecución, existe un cierto grado de capacidad de autorreparación. Si algún participante de la transacción tiene un problema, el coordinador puede cancelar la operación anterior realizando la operación inversa para lograr el estado consistente final (tal como transacción de reversión, transacción de consulta).

También se puede ver en el proceso de ejecución de TCC que el proveedor de servicios debe proporcionar una lógica de compensación adicional , por lo que es posible que la interfaz de servicio original deba transformarse en tres lógicas después de la introducción de TCC:

• Try: Primero, el enlace de llamada de servicio ejecuta la lógica Try a su vez;
• Confirmar: si todo es normal, el marco de transacciones distribuidas de TCC avanza la ejecución de la lógica Confirmar para completar toda la transacción;
• Cancelar: si hay un problema con la lógica de prueba de un servicio, el marco de transacciones distribuidas de TCC avanzará la ejecución de la lógica de cancelación de cada servicio después de detectarlo y cancelará las diversas operaciones realizadas antes.

Nota: Al diseñar transacciones TCC, tanto las operaciones Cancelar como Confirmar de la interfaz deben satisfacer el diseño idempotente.

3.1 Selección de fotogramas

Hay relativamente pocas opciones para el marco TCC. En la actualidad, el marco de transacciones distribuidas de código abierto de Ali, seata (https://github.com/seata/seata), es relativamente maduro. Este marco ha experimentado muchas pruebas en el entorno de producción de Ali. También es compatible con dubbo y spring cloud.

3.2 Ventajas

En comparación con 2PC, la implementación y el proceso son relativamente simples, pero la consistencia de los datos es peor que la de 2PC. Por supuesto, el rendimiento también se puede mejorar.

3.3 Desventajas

El modelo de TCC es demasiado intrusivo para el negocio. La reversión de transacciones consiste en escribir el código de negocio usted mismo para la reversión y compensación. La transformación es difícil. En términos generales, en escenarios comerciales centrales, como pagos y transacciones, la TCC se puede utilizar para garantizar estrictamente la coherencia de las transacciones distribuidas, y todas tienen éxito o todas se revierten automáticamente. Estos escenarios comerciales son el negocio principal de toda la empresa, como el sistema de contabilidad del servidor principal del banco, y no se permiten márgenes.

Sin embargo, en escenarios comerciales generales, intente no usar TCC como una solución para transacciones distribuidas, porque usted mismo escribe la lógica de reversión / compensación, lo que hará que el código comercial se infle y sea difícil de mantener.