Hablar de idempotencia
idempotencia
1. El concepto matemático de idempotencia
Si en una operación unaria, x es cualquier número en un determinado conjunto, si se cumple f(x) = f(f(x)), entonces la operación f es idempotente.
La operación de valor absoluto abs(a) = abs(abs(a)) es una función idempotente
Si en una operación binaria, x es cualquier número en un determinado conjunto, si se cumple f(x,x) = x, siempre que los dos parámetros de la operación f sean ambos x, entonces llamamos a la operación f también idempotente.
Encontrar una función de valor grande max(x,x) = x es una función idempotente
2. Visión general de la idempotencia
2.1 Análisis de escenarios empresariales idempotentes
¿El entorno de producción suele tener datos duplicados? Al solucionar el problema, los datos vuelven a ser normales. ¿Cuál es la explicación para esto? ¿Cómo puede suceder esto, y es difícil de solucionar?
Motivo: se producen datos duplicados o inconsistencias en los datos (suponiendo que el código comercial del programa esté bien), la mayoría de los cuales son solicitudes duplicadas. Las solicitudes duplicadas se refieren a la misma solicitud que se envía varias veces por algún motivo. Hay varios escenarios que conducen a esta situación: (esencialmente: solicitudes múltiples)
1) En el escenario de microservicio, llamar a la interfaz en nuestra arquitectura de aplicación tradicional tendrá éxito o fallará. Pero bajo la arquitectura de microservicios, habrá una tercera situación [desconocida], que es el tiempo de espera. Si se agota el tiempo de espera, el marco de microservicio volverá a intentarlo.
2) Múltiples clics durante la interacción del usuario. Por ejemplo: haga clic en el botón varias veces rápidamente.
3) Middleware de mensajes MQ, consumo de mensajes repetidos.
4) La interfaz de la plataforma de terceros (como: interfaz de devolución de llamada exitosa de pago), porque la excepción también dará lugar a múltiples devoluciones de llamada asincrónicas.
5) Otros servicios de middleware/aplicación también pueden reintentar según sus propias características.
2.2 Idempotencia de interfaz
La idempotencia de la interfaz en realidad significa que la interfaz se puede llamar repetidamente. En el caso de múltiples llamadas por parte de la persona que llama, el resultado final de la interfaz es consistente . Para ser más precisos: varias llamadas tienen el mismo impacto en el sistema, es decir, el efecto en los recursos es el mismo, pero se permite que el valor de retorno sea diferente.
2.3 Ejemplos de escenarios empresariales idempotentes
Escenario 1: Escenario de pago
1. Una interfaz de creación de pedidos, la primera llamada se agotó y luego la persona que llamó volvió a intentarlo una vez.
2. Cuando se creó el pedido, necesitábamos deducir el inventario. En este momento, la interfaz se agotó y la persona que llamó volvió a intentarlo una vez.
3. Cuando el pedido comienza a pagarse, después de enviar la solicitud de pago, se produce una operación de deducción en el servidor, la respuesta de la interfaz se agota y la persona que llama vuelve a intentarlo una vez. 4. Una interfaz de actualización del estado del pedido, la persona que llama envía
dos mensajes, uno se crea y otro se paga. Pero primero recibe el pago y luego recibe el creado
5. Después de completar el pago, se debe enviar un mensaje de texto.Cuando una máquina recibe el mensaje enviado por el mensaje de texto, el procesamiento es lento. El middleware de mensajes entrega el mensaje a otra máquina para su procesamiento.
Escenario 2: conexión triple con un clic
Xiaopozhan tiene una función de tres enlaces con un clic. Una pulsación prolongada puede motivar al maestro superior. Todos tienen solo una oportunidad de tres enlaces con un clic para cada video. Incluso si le gusta un determinado video y lo opera varias veces, solo puede usar un botón y tres veces consecutivas.
Escenario 3: Estadísticas DAU/MAU
DAU/MAU, también conocido como actividad diaria/actividad mensual, es un indicador estadístico utilizado para reflejar el funcionamiento de sitios web, aplicaciones de Internet o juegos en línea. Por lo tanto, un usuario que inicia sesión varias veces en un día o mes (o alcanza un cierto mecanismo de juicio de usuario activo varias veces) solo puede considerarse como un usuario activo y no puede contarse repetidamente.
2.4 CRUD e idempotencia
Algunas interfaces pueden lograr naturalmente la idempotencia, como la interfaz de consulta. Para la consulta, una o varias consultas no tienen impacto en el sistema, y los resultados son los mismos. Otras funciones, como: agregar, actualizar, eliminar deben garantizar la idempotencia .
Tome la tabla de usuario como ejemplo.
1. Consulta, seleccione * del usuario donde xxx, no realizará ningún cambio en los datos y es idempotente
2、新增，insertar en valores de usuario (ID de usuario, nombre) (1, 'a')
Si userid es la única clave principal, es decir, si se repite el negocio anterior, solo se insertará un dato de usuario, que es idempotente
Si el ID de usuario no es una clave principal y se puede repetir, el negocio anterior se operará varias veces y se agregarán múltiples datos, lo que no es idempotente.
3. Modificar y distinguir entre asignación directa y asignación calculada
Asignación directa, actualizar punto de ajuste de usuario = 20 donde id de usuario = 1, no importa cuántas veces se ejecute, el punto es el mismo, con idempotencia
Cálculo y asignación, actualización del punto de ajuste del usuario = punto + 20 donde ID de usuario = 1, los datos de cada punto de operación son diferentes, no idempotentes
4. Eliminar, eliminar del usuario donde ID de usuario = 1, operaciones múltiples, el resultado es el mismo, con idempotencia
Por lo tanto, podemos concluir que los datos sin restricciones de clave primaria única y las operaciones que modifican los datos de asignación de cálculo no son idempotentes .
Lo mismo se extiende a los tipos de solicitud get, put, post y delete
1. get: solo consulta, seguro e idempotente. Al igual que la operación de selección de base de datos, no hay efectos secundarios. Repetidamente el resultado es el mismo.
2. poner: enviar datos para cambiar el contenido, idempotente. Al igual que la actualización, pero no incrementada.
3.post: enviar datos, cambiar el tipo, al igual que insertar, también puede solicitar recursos (no idempotentes)
4.delete: eliminar un recurso es como eliminar una base de datos, idempotente.
3. Soluciones
3.1 token + mecanismo redis
El esquema idempotente de token + redis es adecuado para la mayoría de los escenarios. La idea principal:
token作为请求的唯一性标示
redis作为存储token的数据库
每次请求先去redis查看token是否存在
不存在，将返回结果缓存到redis
存在，直接返回缓存结果
设置缓存有效期
服务端提供发送token的接口，业务调用接口前先获取token,然后调用业务接口请求时，把token携带过去,服务器判断token是否存在redis中，存在表示第一次请求，可以继续执行业务，执行业务完成后，最后需要把redis中的token删除。
3.2 Mecanismo de bloqueo optimista
El bloqueo optimista aquí resuelve el escenario de modificación del tipo de asignación de cálculo
update user set point = #{point}+ 20, version = #{version}+ 1 where userid=#{userid} and version=#{version}
Después de agregar el número de versión, el negocio de cálculo y asignación se vuelve idempotente
Desventaja: antes de operar el negocio, debe verificar la versión actual. El ejemplo de la versión es el siguiente:
- Control de versiones múltiples
Este método es adecuado para escenarios de actualización, por ejemplo, si queremos actualizar el nombre de un producto, podemos agregar un número de versión a la interfaz de actualización para que sea idempotente.
boolean updateGoodsName(int id,String newName,int version);
Se puede implementar de la siguiente manera
update goods set name=#{newName},version=#{version} where id=#{id} and version<${version}
- control de la máquina de estado
Este método es adecuado para el caso del flujo de la máquina de estado, como la creación y el pago de pedidos, y el pago de los pedidos debe ser antes.En este momento, podemos usar el tipo int al diseñar el campo de estado y pasar el valor type El tamaño se utiliza para ser idempotente, por ejemplo, la creación de un pedido es 0, el pago exitoso es 10 y el pago fallido es -1.
Al hacer actualizaciones de la máquina de estado, podemos controlarlo así
update `order` set status=#{status} where id=#{id} and status<#{status}
3.3 Mecanismo de clave primaria única
El mecanismo de clave principal única es generar una ID de clave principal única a nivel mundial en función de la operación y el contenido del negocio. Antes de ejecutar la operación, se juzga si la operación se ha ejecutado de acuerdo con si existe la ID de clave principal única a nivel mundial. Si no existe, almacene la ID global en el sistema de almacenamiento, como base de datos, redis, etc. Si existe, significa que el método ha sido ejecutado.
Desde el punto de vista de la ingeniería, el uso de ID globales para ser idempotentes puede existir como un microservicio básico para las empresas. Dichos servicios se utilizan en muchos microservicios. Para completar dichas funciones en cada microservicio, habrá una duplicación de la carga de trabajo. Además, para crear un servicio idempotente altamente confiable, se deben considerar muchas cuestiones. Por ejemplo, aunque una máquina primero escribe la ID de clave primaria globalmente única en el almacenamiento, cuelga después de escribir, lo que requiere la introducción de la ID de clave principal globalmente única. Id. de clave principal mecanismo de tiempo de espera. El uso de una identificación global única es una solución general que puede admitir operaciones comerciales de inserción, actualización y eliminación. Pero este esquema se ve hermoso pero es más problemático de implementar.
Con todo, este mecanismo aprovecha la restricción única de la clave principal de la base de datos para resolver el problema de la idempotencia en los escenarios de inserción. Sin embargo, el requisito para la clave principal no es una clave principal de incremento automático, por lo que la empresa debe generar una ID de clave principal única a nivel mundial para resolverlo.
En el escenario de la subbase de datos y la subtabla, las reglas de enrutamiento deben garantizar que la misma solicitud se coloque en la misma base de datos y en la misma tabla; de lo contrario, la restricción de la clave principal de la base de datos no funcionará, porque las claves principales de diferentes bases de datos y Las tablas son irrelevantes.
Debido a que existen ciertos requisitos para la clave principal, esta solución está un poco acoplada con el negocio y no se puede usar la clave principal de incremento automático.
3.4 Mecanismo para eliminar tablas duplicadas
Este método es adecuado para escenarios en los que se inserta una marca única en el negocio. Por ejemplo, en el escenario de pago anterior, si un pedido solo se pagará una vez, la ID del pedido se puede usar como un identificador único. En este momento, podemos construir una tabla de deduplicación y usar el identificador único como un índice único. Cuando lo implementamos, colocamos la creación de documentos de pago y la escritura en la tabla de deduplicación en una sola transacción. Si se crea repetidamente, la base de datos Se lanza una excepción de restricción única y la operación se retrotrae.
En pocas palabras, es insertar la clave principal única en la tabla de deduplicación y luego realizar operaciones comerciales, y están en la misma transacción. Esto asegura que cuando se repite la solicitud, la solicitud falla porque la tabla de deduplicación tiene una restricción única, lo que evita el problema de la idempotencia.
Cabe señalar aquí que la tabla de deduplicación y la tabla de negocios deben estar en la misma biblioteca, para garantizar que en la misma transacción, incluso si falla la operación comercial, los datos en la tabla de deduplicación se revertirán . Esta es una buena garantía de consistencia de los datos.
Esta solución también se usa comúnmente. La tabla de deduplicación no tiene nada que ver con el negocio. Muchas empresas pueden compartir la misma tabla de deduplicación, siempre que se planifique la clave principal única.
3.5 Mecanismo de boletos
Escenario de pago: Una sola solicitud de pago, es decir, pago directo, no se requieren operaciones de base de datos adicionales. En este momento, se inicia una solicitud asíncrona para crear un ticketId único, que es un ticket. Este ticket solo se puede usar una vez y luego se vuelve inválido.
Pasos específicos:
1.异步请求获取门票
2.调用支付，传入门票
3.根据门票ID查询此次操作是否存在，如果存在则表示该操作已经执行过，直接返回结果；如果不存在，支付扣款，保存结果
4.返回结果到客户端
如果步骤4通信失败，用户再次发起请求，那么最终结果还是一样的.