Antecedentes
En las aplicaciones, a menudo se requiere una identificación global única como clave principal de la base de datos.
¿Qué tipo de generador de ID necesitamos?
- Alto rendimiento-> 1. Alto rendimiento de generación 2. Alto rendimiento de inserción 3. Alto rendimiento de índice
- Alta disponibilidad-> 1. Menos dependiente del middleware 2. Evite problemas de un solo nodo
- No repita-> 1. No repita globalmente en el clúster
- Fácil de usar-> 1. Acceso simple 2. Costo de aprendizaje cero
- Semántica-> 1. La ID contiene alguna otra información
Cómo cumplir con estos requisitos
- Rendimiento de alta generación-> la mayor parte del tiempo para la asignación de memoria, reducir E / S, reducir bloqueos
- Alto rendimiento de inserción-> incremento global para evitar división de página
- Alto índice de rendimiento-> tipo numérico
- No repita globalmente-> consistencia distribuida
- Alta disponibilidad de servicios-> reduce la dependencia del middleware y reduce el tiempo de interacción del middleware
Resumen de características
- Incremento global
- Tipo de número
- Globalmente único
- Concurrencia sin bloqueo
- Asignación de memoria
- Generación independiente (la mayor parte del tiempo)
Copo de nieve
Twitter migró el sistema de almacenamiento de MySQL a Cassandra. Debido a que Cassandra no tiene un mecanismo de generación de ID secuencial, desarrolló un conjunto de servicios de generación de ID únicos a nivel mundial. La idea básica de Ray proviene de SnowFlake, que resuelve algunos problemas en SnowFlake
Cómo garantizar que no se repitan los incrementos de máquinas individuales
La idea más simple: marca de tiempo + pseudocódigo de número de serie:
If 当前时间 > 上次ID生成时间 -> 当前时间+序列号0
If 当前时间 = 上次ID生成时间 -> 当前时间 + 上次序列号+1
If 当前时间 < 上次ID生成时间 -> 是否存在这种情况
复制代码Cómo garantizar que no se repita el todo
¿Cómo juzgar que dos ID son duplicados? Creemos que cada una de las dos ID está duplicada y las dos ID están duplicadas.
Si dos valores repetidos se empalman con valores diferentes, los dos valores serán diferentes, tales como:
1111 y 1111, hechizo 1 y 2 respectivamente
Entonces 1111-1 y 1111-2 no son lo mismo
Antes, usábamos marca de tiempo + número de serie para no duplicar en una sola máquina
Entonces solo necesitamos asegurar la ID única en la máquina individual + la ID de instancia única (workId) para asegurar que la ID final generada no esté duplicada
Cómo garantizar que workId no esté duplicado
Este es un problema de consistencia distribuida
Esto puede usar bloqueos distribuidos para lograr un workId exclusivo para cada instancia
Y esto solo depende del middleware en el inicio y la renovación
Incluso si el middleware dependiente no está disponible temporalmente, solo el nuevo servicio no se puede usar, el antiguo es normal
Resumen por etapas
- Incremento global (la marca de tiempo viene con incremento global) -> Insertar, indexar alto rendimiento
- Asignación de memoria (sin E / S durante la asignación) -> Generar alto rendimiento
- Generación de una sola máquina (solo depende en gran medida del middleware al inicio) -> alta disponibilidad
Problemas con el copo de nieve
Reloj sesgado
Las computadoras modernas tienen al menos dos relojes diferentes: relojes y relojes monótonos. Aunque ambos miden el tiempo, es importante distinguir entre los dos porque tienen propósitos diferentes.
Reloj
Devuelve la fecha y hora actuales de acuerdo con un calendario determinado. Por ejemplo: System.currentTimeMillis () en Java devuelve el número de segundos (o milisegundos) desde la época (medianoche UTC del 1 de enero de 1970, calendario gregoriano), de acuerdo con el calendario gregoriano, excluyendo los segundos bisiestos.
Reloj monótono
Adecuado para medir la duración (intervalo de tiempo), por ejemplo, System.nanoTime () en Java es un reloj monótono. El nombre proviene del hecho de que prometen avanzar siempre.
El problema
El problema con los relojes es que, aunque parecen simples y fáciles de usar, tienen fallas sorprendentes: un día puede no tener 86,400 segundos precisos, el reloj puede saltar de un lado a otro y la hora en un nodo puede ser El tiempo es completamente diferente. Si se adelanta el tiempo, no podemos garantizar que la ID generada por la marca de tiempo + número de serie sea única en una sola máquina.
Número máximo de generaciones en unidades de milisegundos.
El número de ID generados en unidades de SnowFlake en milisegundos no puede exceder los bits de secuencia de 12 bits
Resumen del problema
En otras palabras, SnowFlake se basa en gran medida en la marca de tiempo actual, y solo puede manejar casos donde la marca de tiempo actual es mayor o igual que la última marca de tiempo, y no puede manejar casos donde la marca de tiempo actual es menor que la última marca de tiempo.
Resolver sesgo de reloj
If 当前时间 > 上次ID生成时间 -> 当前时间+序列号0
If 当前时间 = 上次ID生成时间 -> 当前时间 + 上次序列号+1
If 当前时间 < 上次ID生成时间 ->上次ID生成时间 + 上次序列号 +1
复制代码El reloj está sesgado, y saltar antes de tiempo es en realidad equivalente al tiempo actual <tiempo de última generación de ID
Cómo registrar el último tiempo de generación de ID
Primero, el último tiempo de generación de ID se registra en la memoria de la instancia actual. Si se produce la devolución de llamada del reloj durante el reinicio, se perderá el último registro de tiempo de generación de ID. En este momento, la nueva instancia obtiene su workId, y la marca de tiempo de la nueva máquina aparecerá antes. En el caso de ID duplicados, es necesario sincronizar periódicamente la marca de tiempo máxima global con el middleware en segundo plano, y sincronizar la marca de tiempo antes de que la instancia salga y comience
Número de serie sin fin
¿Por qué SnowFlake tiene un número de serie de solo 4096 bits? 1. Hay tantos dígitos que puede asignar desde los bits de la máquina 2. No hay espacio de transporte, solo admite la marca de tiempo actual> = Última marca de tiempo Ray admite la hora actual <La última hora significa que se pueden usar 4096 bits hasta el momento Empuje para resolver el tráfico estallido
Rayo
Rayo de referencia del copo de nieve diseñado para resolver el número de serie de problemas y deficiencias de reloj de devolución de llamada, y proporciona un mejor rendimiento concurrente Github Dirección: github.com/KeshawnVan / ...