Diseño y práctica de cosas distribuidas

Definición de coherencia de datos

alguien
cualquier momento
En cualquier lugar
Cualquier método de acceso
Cualquier servicio
Los datos son consistentes

Razones de los datos inconsistentes

Los datos están dispersos en muchos lugares

- Base de datos múltiple
- DB y caché

Caso de plataforma de negociación de segunda mano

- Usuario, transacción, mercancía y otras funciones

Razones para distribuir cosas

Comenzó como un solo proceso

Después de la evolución, los servicios monolíticos evolucionaron hacia microservicios y cada servicio es un proceso separado.

Cuando la cantidad de solicitudes de los usuarios es grande, para aliviar la presión sobre la base de datos, se agrega una caché distribuida

Caso de cosas distribuidas

Plataforma de comercio electrónico para comprar bienes.

Realizar un pedido -> reducir inventario -> pagar

Este es el problema de las cosas distribuidas, cuando una APP quiere comprar algo, esta operación implicará múltiples servicios, lo que significa que se deben operar múltiples bases de datos, de esta manera las cosas locales no pueden garantizar la consistencia de los datos, por lo que el problema de los distribuidos surgen las cosas.

Escena de cosas distribuidas

Escenario de pedido de comercio electrónico

- Hacer un pedido
- Enviar mensaje a MQ

Garantía de coherencia

- Cosas locales

- - Operación de pedidos
  - Enviar operación de mensaje MQ
  - Pon algo local

¿Qué hay de malo en el enfoque anterior?

Pregunta: Si se agota el tiempo de espera para enviar un mensaje, no sabe si el resultado de la devolución de MQ es correcto o no, y la operación de tiempo de espera no es atómica.

Clasificación de cosas distribuidas

Cosas distribuidas rígidas

- Consistencia fuerte
- Modelo XA
- GORRA

- - CP

Cosas distribuidas flexibles

- Consistencia final
- CAP, teoría BASE

- - AP

Cosas distribuidas rígidas

Satisfacer las características de las cosas tradicionales.

ACID (Atomicidad-atomicidad, Consistencia-consistencia, Aislamiento-aislamiento, Durabilidad-persistencia)

Modelo XA

XA se define en el modelo de especificación X / Open CAE (procesamiento de transacciones distribuidas), y la especificación XA se compone de AP, RM y TM
Entre ellos, el programa de aplicación (AP para abreviar), AP define el límite de las cosas (define el principio y el final de las cosas) y accede a los recursos dentro de los límites de las cosas.
Resource Manager (Resource Manager denominado RM), RM gestiona los recursos, los recursos y las bases de datos compartidos de la computadora, etc.
Transaction Manager (TM para abreviar) es responsable de administrar cosas globales, asignar identificadores únicos de cosas, monitorear el progreso de ejecución de las cosas y responsable del envío de cosas, reversiones, recuperación de fallas, etc.

2PC (implementación estándar de especificación XA de presentación en dos fases)

Caso de estudio

- Organizar montañismo

proceso

- La presentación de la segunda etapa es una implementación estándar de la especificación XA
- TM inicia preparar voto
- Después de que RM acepta, TM inicia Commit
- Hay una anomalía, como un tiempo de inactividad durante el proceso de confirmación. Una vez que se reinicia el servicio del nodo, la compensación de la confirmación se realizará de nuevo de acuerdo con la recuperación de XA.

Desventaja

- Modelo de bloqueo sincrónico
- El tiempo de bloqueo de los recursos de la base de datos es demasiado largo
- Bloqueo global (serialización de nivel de aislamiento), baja concurrencia
- No apto para cosas largas

Cosas distribuidas flexibles

GORRA

- P debe ser necesario en un entorno distribuido, compensaciones de CA

Teoría BASE

- Básicamente disponible
- Estado suave
- Consistencia eventual

Pensamiento arquitectónico

- Las cosas flexibles son un compromiso para el protocolo XA. Al reducir los estrictos requisitos de coherencia, reduce el tiempo de bloqueo de los recursos de la base de datos y mejora la disponibilidad.

Implementación clásica de arquitectura

- Modelo TCC
- Modelo de saga

Modelo TCC

Intentar-confirmar-cancelar
El modelo de TCC se entrega completamente a la empresa para lograrlo, y cada sub-negocio necesita implementar la interfaz Try-Confirm-cancel, que es una gran intrusión para el negocio.

- El bloqueo de recursos se transfiere al lado comercial

intentar

- Intente ejecutar el negocio, complete todas las inspecciones y reserve los recursos comerciales necesarios

confirmar

- Realmente ejecute el negocio y ya no realice inspecciones comerciales

Cancelar

- Liberar los recursos comerciales reservados en la fase de prueba

Caso de estudio

- Servicio de remesas, caso de servicio de cobranza

- - El usuario A envía 500 yuanes al usuario B

- Servicio de remesas

- - intentar

- - - Verifique la validez de la cuenta A y verifique si el estado de la cuenta A es "transfiriendo" o "congelado"
    - Compruebe si el saldo de la cuenta A es suficiente
    - Deduzca 500 yuanes de la cuenta A y establezca el estado para transferir
    - Reserve recursos de deducción, transfiera 500 yuanes de la cuenta A a la cuenta B y almacene el evento en el mensaje o registro

- - confirmar

- - - Hacer nada

- - cancelar

- - - Una cuenta aumentada en 500 yuanes.
    - Liberar recursos de deducción de registros o mensajes

- Servicio de cobranza

- - intentar

- - - Compruebe si la cuenta B es válida

- - confirmar

- - - Leer registros o mensajes, agregar 500 yuanes a la cuenta B
    - Liberar recursos de deducción de registros o mensajes

- - cancelar

- - - Hacer nada

Modelo de saga

Originado del papel Sagas publicado por Hector & Kenneth en 1987
El modelo Saga divide una cosa distribuida en varias cosas locales, y cada cosa local tiene un módulo de ejecución y un módulo de compensación correspondientes (correspondientes a confirmar y cancelar en TCC)
Cuando algo local en la cosa Saga sale mal, lo anterior se puede restaurar llamando al método de compensación correspondiente para alcanzar la consistencia final de la cosa.
Cuando cada sub-cosa de Saga T1, T2, ... TN tiene una definición de compensación correspondiente C1, C2, ... CN-1, entonces el sistema Saga puede garantizar

- Se completa la secuencia de subtransacción T1, T2, ... TN (mejor caso)
- O se puede completar la secuencia T1, T2, ... TJ, CJ-1, ..., C2, C1,0 <J <N

Aislamiento de la saga

- La capa empresarial controla la simultaneidad

- - Bloquear en la capa de aplicación
  - Congele previamente los recursos en la capa de aplicación, etc.

Método de recuperación de saga

- Recuperarse al revés, compensar todas las cosas completadas, si alguna de las cosas secundarias falla
- Recupere hacia adelante, vuelva a intentar cosas fallidas, asumiendo que cada sub-cosa tendrá éxito al final

Cosas distribuidas rígidas versus cosas distribuidas flexibles

	Cosas rígidas (XA)	Cosas suaves
Transformación del negocio	no	Tener
Retroceder	apoyar	Implementar interfaz de compensación
consistencia	Fuerte consenso (CP)	Consistencia eventual (AP)
Aislamiento	Soporte nativo	Implementar la interfaz de bloqueo de recursos
Rendimiento de simultaneidad	Recesión severa	Ligero declive
Adecuado para la escena	Cosas cortas, baja concurrencia	Cosas largas, alta concurrencia

Como practicamos

Ideas generales para la resolución de problemas

- Resuelve el problema en sí
- Deja que el problema se vaya

- - Solución de fuga de aceite de recarga de bolígrafo

La recarga del bolígrafo comienza a perder aceite después de escribir 2W veces. Si desea resolver el problema en sí mismo, debe agregar mejores materiales y tecnología de gama alta. Si desea que el problema desaparezca, es arreglar un número de veces para que solo pueda escribir. 1.5W veces, no hay aceite y comienzan a desecharse. Dos métodos como este
La primera opción es hacer desaparecer el problema, la segunda opción es resolver el problema en sí.
Opción 1: eliminar los elementos distribuidos de los escenarios empresariales

- Idea: el negocio principal se procesa primero y otros negocios se procesan de forma asincrónica

Opción 2: cosas distribuidas flexibles

Práctica de cosa distribuida flexible

Ideas generales de procesamiento

- Cosas locales -> cosas cortas
- Cosas distribuidas -> Cosas largas
- Conviértete en múltiples cosas cortas
- Caso de estudio

- - A [Pedido] -> B [Disminuir inventario] -> C [Pagar]

- - - A-> DB1
    - B-> DB2
    - C-> DB3
    - A / B / C son todos exitosos
    - A / B tiene éxito, C falla

- - - - inventar

Escena empresarial

- Escena asincrónica

- - Impulse elementos distribuidos basados en mensajes MQ

- Sincronizar escena

- - Basado en distribución de compensación asíncrona

Diseño de cosas distribuidas en escenarios asincrónicos

Escena asincrónica

comercio

Haz un pedido y paga

Opción 1: el lado comercial proporciona una función de devolución de cheques exitosa para las operaciones locales

- Mensaje de transacción: MQ proporciona funciones de transacción distribuidas similares a X / Open XA, y la consistencia final de las transacciones distribuidas se puede lograr a través de mensajes de transacción MQ
- Medio mensaje: un mensaje que no se entrega temporalmente. El remitente ha enviado correctamente el mensaje al servidor MQ, pero el servidor no ha recibido la segunda confirmación del mensaje del productor. En este momento, el mensaje se marca como "temporalmente "no se puede entregar", el mensaje en este estado es la mitad del mensaje
- Revisión de mensajes: debido al parpadeo de la red, el reinicio de la aplicación del productor y otras razones, se pierde la confirmación secundaria de un determinado mensaje de transacción. Cuando el servidor MQ escanea y encuentra que un mensaje es medio mensaje durante mucho tiempo, principalmente pregunta activamente al productor de mensajes. El estado final del mensaje (Confirmar o Revertir), es decir, revisión del mensaje

Esquema de diseño de cosa distribuida MQ

Diseño de mensajes de transacciones distribuidas de MQ

- El mensaje de diseño de mensaje de cosa MQ es una cosa garantizada asincrónica, y las ramas de dos cosas están desacopladas asincrónicamente a través de MQ. El proceso de diseño del mensaje de cosa MQ también se basa en la teoría de envío de dos etapas, y el proceso de interacción general es como se muestra en el figura de arriba.

1. El iniciador de la cosa envía primero un mensaje de preparación a MQ
2. Ejecute cosas locales después de enviar el mensaje de preparación con éxito
3. Devuelve la confirmación o la reversión de acuerdo con el resultado de la ejecución de las cosas locales
4. Si el mensaje es una reversión, MQ eliminará el mensaje de preparación sin enviarlo. Si es un mensaje de confirmación, MQ enviará el mensaje al consumidor.
5. Si el lado de ejecución se cuelga o se agota durante la ejecución de cosas locales, el lado del servidor MQ seguirá pidiendo al productor que obtenga el estado de la cosa.
6. El mecanismo de éxito del consumo por parte del consumidor está garantizado por MQ

costo:

- MQ debe admitir semi-mensaje
- MQ debe proporcionar un cruce de mensajes
- El lado empresarial debe proporcionar una interfaz de verificación

Pasos de acceso a la fiesta empresarial

ventaja

- Universal

Desventaja

- El lado comercial debe proporcionar una interfaz de verificación, que tiene una gran intrusión comercial
- Enviar un mensaje no es idempotente
- El consumidor necesita lidiar con la idempotencia

Solución 2: tabla de mensajes de transacciones locales

Operaciones locales y envío de mensajes a través de una fuerte coherencia de las transacciones locales.

- Tabla de transacciones locales
- Tabla de mensajes de transacciones locales

- - mqMessages (msgid, contenido, tema, estado)

El mensaje del remitente no es idempotente

- Al menos una vez (al menos una vez)
- Solo una vez (solo enviado una vez)
- Más una vez

Mensaje de procesamiento del consumidor idempotente

- Cerradura distribuida

A-> B-> C

- A / B tiene éxito, C falla

- - Registro de registro de errores
  - Llama a la policía
  - Intervención manual

ventaja

- Invasión de pequeñas empresas

En comparación con la provisión de una interfaz de verificación de mensajes (RockectMQ), el escenario asíncrono real se usa aún más en la tabla de transacciones de mensajes locales.

Diseño de cosa distribuida de escena síncrona.

Sincronizar escena

- Lista de productos recomendados en la página de inicio

- - Información sobre productos básicos
  - Información de usuario
  - Informacion social

- Comprar bienes

- - Realizar un pedido-> A
  - Reducir inventario-> B
  - Pago-> C

Impulsado por la capa de lógica empresarial

solución

- Cosas distribuidas basadas en compensación asincrónica
- Tres puntos clave del diseño arquitectónico

Comience a registrar los parámetros de la solicitud de llamada. Si la interfaz de compensación se basa en los parámetros después de la falla, la interfaz debe ser idempotente

Diseño de arquitectura general

Escenario: A realiza un pedido, B reduce el inventario y C paga. Al llamar a la interfaz, A primero usa el proxy para almacenar el ID de la transacción, el estado, los parámetros y otra información, y luego ejecuta la transacción local, luego B y C siguen el mismo proceso si todos tienen éxito, Entonces el estado de la cosa se cambia a 2, lo que significa éxito. Si puede tener más parámetros cuando C falla, la ID de la cosa compensará A y B.

Diseño de proxy de capa de lógica empresarial (basado en la implementación de AOP)

- Agregue anotaciones de cosas a la llamada de capa lógica @Around ("ejecución (** (..)) && @annotation (TX)")
- Antes de que se llame a la lógica empresarial real, el proxy genera un TXID único global para indicar el grupo de transacciones. El TXID se almacena en la variable ThreadLocal. Se escribe antes de que se inicie el método, se borra una vez finalizado y escribe el TXID en el base de datos remota e inicia el grupo de transacciones.
- Antes de que la capa de lógica empresarial llame a la capa de acceso a datos, registra a través del proxy RPCProxy, los parámetros de solicitud de llamada actual
- Si el negocio es normal, después de que se completa la llamada, el registro de llamadas del método actual se elimina o se archiva
- Si el negocio es anormal, consulte la cadena de llamadas para obtener una compensación inversa.

Diseño de capa de acceso a datos

- Interfaz atómica
- Interfaz de compensación

- - ¿Quién lo proporcionará?

- - - Proporcionado por la fiesta de negocios

- - Garantía de idempotencia

- - - Utilice el bloqueo de recursos locales para bloquear el único recurso

- Según el método de interfaz principal, agregue una anotación al nombre del método para marcar el nombre del método de compensación
- @Compensable (cancelMethod = "cancelRecord")

Servicio de compensación de transacciones distribuidas

- Tabla de grupo de cosas (tabla de base de datos TDB)

- - Registrar el estado del grupo de cosas
  - marca de tiempo del estado txid

- Tabla de grupo de llamadas de transacción (tabla de base de datos TDB)

- - Grabe cada llamada en el grupo de cosas y los parámetros relacionados
  - txid actionid callmethod pramatype params

- Estrategia de compensación

- - Error en la ejecución de la llamada, modificar el estado del grupo de transacciones
  - Servicio de compensación de transacciones distribuidas compensación de ejecución asíncrona

Casos exitosos de cosas distribuidas

El proceso normal de creación de un grupo de transacciones de pedidos para transacciones de segunda mano.

- Bloquear inventario -> Reducir sobre rojo -> Crear pedido

La capa de proxy registra de forma transparente los parámetros de solicitud de llamada.

- Registra el comienzo y el final del dominio de las cosas.
- Cuando todas las llamadas remotas son exitosas
- Sin intromisión en la lógica empresarial

Caso de error de transacción distribuida

El proceso anormal de crear un grupo de transacciones de pedidos para una transacción de segunda mano.

- La capa de acceso a datos de microservicio falló y el agente cambió el estado del grupo de transacciones
- Ejecución normal del negocio de microservicios
- El servicio de compensación de transacciones realiza la compensación de forma asincrónica

Ok, aquí está el final de las cosas distribuidas ... Tómate un descanso, oye, es hora de encontrar un trabajo nuevamente, puedes contactarme si lo necesitas