Fuente: https://www.yuque.com/renyong-jmovm/kb/lgz2xv#5m84f
ID es un identificador único de los datos, el enfoque tradicional es utilizar las compañías de Internet y base de datos UUID incremento automático de identificación, la mayor parte de las empresas están utilizando Mysql, y debido a la necesidad de apoyar la transacción, a menudo se utiliza el motor de almacenamiento InnoDB, UUID demasiado largo y desordenado, que no es adecuado como clave principal en InnoDB, el incremento del ID es apropiado, pero como la empresa desarrollo de negocios, la cantidad de datos aumenta, la necesidad de una tabla de puntos de datos, mientras que las sub-tablas, cada tabla de datos se incrementará a su propio ritmo, es probable que surjan conflictos de ID. Luego hay que ser responsable de un mecanismo separado para generar un identificador único, generado fuera de la ID también se puede llamar una identificación distribuida o una identificación global. Para analizar los siguientes mecanismos de generación respectivo ID del distribuida.
En este artículo no se detalla el análisis particular, sobre todo para hacer un poco de resumen, un artículo posterior se detalla una serie de programas.
1. Base de datos incremento ID
En todavía una primera realización basada en la base de datos ID auto-energizante, una base de datos requiere una instancia independiente, en este ejemplo una nueva tabla separada, estructura de tabla como sigue:
CREATE DATABASE `SEQID`;
CREATE TABLE SEQID.SEQUENCE_ID (
id bigint(20) unsigned NOT NULL auto_increment,
stub char(10) NOT NULL default '',
PRIMARY KEY (id),
UNIQUE KEY stub (stub)
) ENGINE=MyISAM;
La siguiente declaración se puede utilizar para generar y obtener un identificador de auto-energizante
begin;
replace into SEQUENCE_ID (stub) VALUES ('anyword');
select last_insert_id();
commit;
campo talón de aquí y no hay un significado especial, sólo para fácil de insertar datos, sólo se pueden insertar los datos para producir Identificación del incremento. Para la inserción utilizamos sustituir, reemplazar el mismo código auxiliar mirar si hay un valor especificado de los datos, si es que existe elimine primero y luego insertar, si no existe, no inserte directamente.
Este ID se distribuye mecanismo de generación requiere un ejemplo de MySQL por separado, mientras sea posible, pero si se basan en el rendimiento y la fiabilidad suficiente para considerar, cuando cada servicio requiere un ID del sistema, las necesidades de base de datos a petición de adquisición, de bajo rendimiento, y Si la instancia de base de datos está abajo, que afectará a todos los sistemas de negocio.
Para hacer frente a los problemas de fiabilidad de base de datos, podemos utilizar la segunda generación del programa de identificación distribuido.
2. La base de datos multi-master
Si tenemos dos clúster de base de datos compuesta de un modo maestro-esclavo, en circunstancias normales, la base de datos puede resolver los problemas de fiabilidad, pero si la biblioteca principal cuelgue, los datos no están sincronizados en el tiempo de la biblioteca, esta vez no habrá duplicación de ID. Podemos utilizar cúmulo modo maestro dual, es decir, dos instancias MySQL puede separar ID incremento de producción, esto puede mejorar la eficiencia, pero si no pasan por otra transformación, entonces MySQL probable que genere el mismo ID de dos instancias son. Mysql requiere una instancia independiente para cada configuración diferente del valor de inicio y tamaño de paso de incremento.
El primer ejemplo de configuración de MySQL:
set @@auto_increment_offset = 1; -- 起始值
set @@auto_increment_increment = 2; -- 步长
Un segundo ejemplo de configuración de MySQL:
set @@auto_increment_offset = 2; -- 起始值
set @@auto_increment_increment = 2; -- 步长
Después de la configuración anterior, la secuencia de dos casos de id Mysql generado es como sigue:
mysql1, valor inicial de 1, paso 2, la secuencia de ID resultante: 1,3,5,7,9, ...
mysql2, un valor inicial de 2, etapa 2, la secuencia de ID resultante: 2 , 4,6,8,10, ...
Para la generación de tales Identificación un programa distribuido, una necesidad para añadir un separadas aplicaciones distribuidas de generación de ID, como DistributIdService, la aplicación proporciona una interfaz para la obtención de ID de aplicación de servicio, una aplicación de negocio necesita ID, solicitud DistributIdService, DistributIdService a modo RPC mysql asignados al azar a dos ejemplos anteriores para obtener ID.
Después de la aplicación de la presente realización, incluso si una estación en la que instancia de MySQL abajo, que no afectará a DistributIdService, DistributIdService todavía ser utilizada además para generar una Mysql ID.
Pero la extensión del esquema no es muy buena, Mysql ejemplo, si dos no es suficiente, tenemos que añadir instancia de MySQL para mejorar el rendimiento, entonces tendrá problemas.
Ahora bien, si desea agregar un MySQL3 ejemplo, a cómo funciona?
En primer lugar, mysql1, mysql2 tamaño de paso, sin duda, ser revisado a 3, y sólo puede ser artificial para modificar, se necesita tiempo.
En segundo lugar, porque mysql1 y mysql2 se mantienen en auto-incrementales para el valor inicial MySQL3 que puede tener que ajustar un poco demasiado grande, con el fin de dar tiempo suficiente para modificar mysql1, tamaño de paso mysql2.
En tercer lugar, puede aparecer en la etapa de modificación de identificación cuando se repite, para resolver este problema, es posible que tenga que cerrar el trabajo.
Con el fin de resolver los problemas anteriores, y la capacidad para mejorar aún más el rendimiento DistributIdService, distribuidos mecanismo ID Si la tercera generación.
3. Modo de segmento Resolución
Podemos utilizar la sección de estilo para conseguir el incremento del ID, número de segmentos puede ser entendida como la adquisición por lotes, tales como DistributIdService de la base de datos para obtener el identificador, si pueden conseguir mayor múltiples ID y almacena en caché localmente, a continuación, que proporcionará gran medida de aplicaciones de negocio para obtener ID eficiencia.
Por ejemplo DistributIdService cada base de datos adquiridos de la ID, para obtener un número de segmentos, tales como (1, 1000], esta gama indica la ID 1000, al solicitar la aplicación de servicio proporciona DistributIdService ID, DistributIdService solamente incrementa a partir de un local y volver sin tener que pedir cada vez que la base de datos hasta el local de auto-energizar a 1000, cuando el número de segmento actual se ha agotado, antes de ir a la base de datos para volver a adquirir el número más bajo.
por lo tanto, tenemos que la base de datos tabla cambia como sigue:
la id_generator mesa (Crear
int ID (10) el NO NULL,
current_max_id BIGINT (20 es) el NO NULL el comentario 'corriente máxima ID',
(10) 'número longitud de segmento' la NOT NULL el int COMENTARIO increment_step,
una PRIMARY KEY ( id)
) = MOTOR la InnoDB la DEFAULT el CHARSET = UTF8;
tabla de base de datos utilizado para registrar la longitud actual de la etapa de auto-energizante, y el ID de máximo incremento (es decir, la corriente se ha aplicado al último segmento de un valor de número), ya que se desplaza la lógica auto-energizar DistributIdService a ir, por lo que parte de la lógica de la base de datos no lo hace.
esta solución no depende en gran medida de la base de datos, incluso si la base de datos no está disponible Así DistributIdService también seguir apoyando a un período de tiempo. Pero si DistributIdService reinicio, perdió algo de identidad, lo que resulta en ID vaciar.
Con el fin de mejorar la disponibilidad DistributIdService, que necesita para hacer un clúster, el servicio de clúster a petición DistributIdService get ID, seleccionará aleatoriamente un nodo para obtener un DistributIdService, cada nodo DistributIdService, la base de datos es la misma conexión de base de datos, es posible generar una pluralidad de nodos soliciten simultáneamente sección de número de acceso de base de datos DistributIdService, a continuación, el tiempo necesario para controlar el uso de bloqueo positivo, tal como la adición de un campo de versión en una tabla de base de datos utilizando la siguiente SQL en número de segmento adquisición:
actualización id_generator current_max_id SET = {# newMaxId}, version = versión + 1 donde version = # {version}
porque el oldMaxId + DistributIdService newMaxId se calcula tamaño de paso, siempre que el anterior para actualizar la actualización se ha realizado correctamente adquirido de acuerdo con el número de párrafo indica éxito.
Con el fin de proporcionar una alta disponibilidad capa de base de datos, es necesario usar la distribución de la base de datos multi-maestro para cada base de datos es asegurarse de que el número de segmentos generados no se repiten, lo que requiere el uso de la idea del principio, y luego aumentar la tabla de base de datos por si valor inicial y el tamaño del paso, como si somos dos MySQL, y luego
La sección mysql1 resultante número (1, 1001], la secuencia de incremento de tiempo ... 1,3,4,5,7
mysql1 sección número generado (2,1002], secuencia de incremento de tiempo 2,4,6, 8,10 ...
Una referencia más detallada se puede piezas de código abierto TinyId: https://github.com/didi/tinyid/wiki
en TinyId también añade una etapa para mejorar la eficiencia, las implementaciones anteriores, el ID de lógica está en el incremento de la DistributIdService lograr, y de hecho puede incrementar la lógica en las aplicaciones empresariales a nivel local, por lo que para aplicaciones de negocios sólo tienen que obtener el párrafo, ya no hay necesidad de solicitar una llamada DistributIdService cada incremento de tiempo.
4. algoritmo de nieve
Lo anterior tres métodos en general se basa en la idea de auto-crecimiento, y el siguiente será introducir más famoso algoritmo de copo de nieve -snowflake.
Podemos pensar en ID distribuido desde otro ángulo, siempre y cuando haga responsable de la generación distribuida Generación de identificación de cada máquina no es la misma en todos los ID de milisegundos en la línea.
copo de nieve se distribuye ID gorjeo algoritmo de generación de abierto es un algoritmo, y que genera la anteriormente tres tipos de distribuido ID mecanismo no es el mismo, no se basa en la base de datos.
La idea central es: un ID de tipo distribuido largo es un número fijo, un tipo de 8 bytes de largo, que es de 64 bits, el algoritmo de copo de nieve original para asignación de bits como se muestra a continuación:
• la identificación de una primera porción está un bit , debido a la más alta java bit es el bit de signo de largo, un número positivo es 0, un número negativo es 1, genera de identificación para el general positiva, se fija a 0.
• parte marca de tiempo representa 41bit, esto es a nivel de milisegundos, la marca de tiempo actual no se almacenan en la aplicación general, pero el valor de la diferencia de fecha y hora (hora - hora de inicio fija), esto podría hacer que el identificador generado en más arranques de valor pequeño; 41 marcas de tiempo se pueden utilizar 69 años, (1L << 41) / ( 1000L * 60 * 60 * 24 * 365) = 69 años
• Manejo de la ID de la máquina representó el 10 bits, más flexible que aquí, por ejemplo, se puede utilizar 5 como antes de la sala del centro de datos de identificación, la habitación 5 como una identificación de la máquina independiente, el nodo 1024 pueden ser desplegados.
• parte de 12 bits representa el número de serie, el mismo soporte en el mismo nodo milisegundo puede generar ID 4096
de acuerdo con este algoritmo de lógica, el algoritmo solamente necesita salir en el lenguaje Java, un método de paquete de la herramienta, entonces cada uno de la aplicación de servicio puede ser utilizado directamente herramientas distribuidas método para obtener ID, sólo para asegurarse de que cada negocio tiene su propio ID de aplicación puede funcionar máquinas, sin necesidad de una solicitud por separado para construir un distribuyeron obtener la ID.
algoritmo de copo de nieve no es difícil, siempre y cuando la realización de java con un github:https://github.com/beyondfengyu/SnowFlake
gran fábrica, de hecho, no utilizar directamente el copo de nieve, pero se ha transformado, porque algoritmo de copo de nieve es la más difícil de practicar el trabajo ID de la máquina, copo de nieve algoritmos originales tienen que ir manualmente a cada máquina para especificar un ID de la máquina, y en algún lugar configure de manera que copo de obtener el ID de la máquina de aquí.
Pero en la gran fábrica, la máquina es una gran cantidad de mano de obra cuesta demasiado propenso a errores, por lo que los fabricantes de copo de nieve se ha transformado.
5. Baidu (uid-generador)
github Dirección: https://github.com/baidu/uid-generator
uso UID-generador es el copo de nieve, pero el ID de la máquina de producción, el tiempo también es diferente que se llama workId.
Cuando se inicia la aplicación: uid-generador en workId se genera automáticamente por UID-generador, y teniendo en cuenta el caso de las aplicaciones desplegadas en estibador, los propios usuarios pueden definir la estrategia de generación workId en UID-generador, la política proporcionada por defecto es asignado por la base de datos. Dijo que el punto es sencilla: los datos se devuelven después de su uso cuando comienza a las tablas de bases de datos (necesidad WORKER_NODE UID-generador para añadir una tabla) para insertar una inserción de datos datos de incremento del éxito correspondiente es el identificador único de la máquina workId y los datos desde el host, composición puerto.
Por uid-generador en WorkId, ocupa bits de 22 bits, 28 tiempo de bit ocupado los bits, una secuencia de 13 bits ocupa poco, debe observarse que, copo de nieve y no el mismo que el original, la segunda unidad de tiempo en lugar de milisegundos, workId no es lo mismo, la misma aplicación se reinicia cada vez que un consumidor workId.
Referencia específica: https://github.com/baidu/uid-generator/blob/master/README.zh_cn.md
6. Misión de Estados Unidos (hoja)
Dirección github: https://github.com/Meituan-Dianping/Leaf
Hoja de EE.UU. ID de grupo es también un marco de generación distribuida. Es muy amplia, que es al apoyo número de modelo segmento, también soportes del copo de nieve patrón. No hay modo de ráfaga no se presenta aquí, y un análisis similar al anterior.
patrón de copo de nieve es diferente del algoritmo original de la hoja del copo de nieve, principalmente en la generación workId, Hoja workId base con el fin de generar el Id ZooKeeper, cada aplicación cuando se utiliza la hoja-copo de nieve, en el inicio estará en Zookeeper generar una secuencia de Id, una máquina equivalente a una secuencia correspondiente al nodo, es decir un workId.
En términos generales, los dos anteriores se generan automáticamente workId, con el fin de hacer el sistema más estable y reducir el éxito laboral.
7.Redis
Una vez más introducir el uso adicional Redis para generar distribuido ID, y en uso hecho de MySQL similares Identificación de la subasta, puede utilizar Redis al mando incr para lograr la subasta y el retorno atómica, tales como:
127.0.0.1:6379> set seq_id 1 // 初始化自增ID为1
OK
127.0.0.1:6379> incr seq_id // 增加1，并返回
(integer) 2
127.0.0.1:6379> incr seq_id // 增加1，并返回
(integer) 3
Redis eficiencia de uso es muy alto, pero a tener en cuenta la persistencia del problema. Redis es compatible con dos tipos de AOF RDB y de manera persistente.
RDB equivalente persistente de jugar un temporizada instantánea persistente, si una instantánea está terminado, continuos incrementos en varias ocasiones, una instantánea persistencia no han tenido tiempo de hacerlo en este momento Redis colgó, no se repetirá después de la reanudación Redis ID .
AOF persistente equivalente a cada comando de escritura para la persistencia, si Redis cuelgue, no será la duplicación de ID, pero debido a Incr moscas de mando, lo que el tiempo de recuperación de datos reinicio es demasiado largo.
