Algoritmo de copo de nieve de solución de identificación única distribuida

阅读大概需要3分钟

Con código fuente

[grifo]

Prefacio

Atrás quedaron los días de los servicios monolíticos.

La complejidad del almacenamiento de datos y negocios del sistema actual está aumentando, y los sistemas distribuidos son actualmente una solución muy común.

Las identificaciones únicas a nivel mundial se encuentran en casi todos los sistemas de diseño. Las identificaciones únicas a nivel mundial desempeñan un papel vital en el almacenamiento y la recuperación.

Generador de ID

En las aplicaciones, a menudo se requiere una identificación única global como clave principal de la base de datos. ¿Cómo generar una identificación única a nivel mundial?

Primero, ¿necesita determinar si el ID único global es un número entero o una cadena? Si es una cadena, el UUID existente satisface completamente la demanda y no se requiere trabajo adicional. La desventaja es que la cadena ocupa mucho espacio como ID y la eficiencia de indexación es menor que la de un número entero.

Si se utiliza un número entero como ID, primero se excluye el tipo int de 32 bits, porque el rango es demasiado pequeño y se debe utilizar el tipo largo de 64 bits.

采用整型作为ID时，如何生成自增、全局唯一且不重复的ID？

Autoincremento de la base de datos

El ID de incremento automático de la base de datos se usa a menudo en sistemas con una pequeña cantidad de datos. Usando el ID de incremento automático de la base de datos, comenzando desde 1, básicamente puede lograr un incremento continuo. Se puede usar Oracle SEQUENCE, MySQL puede usar la clave principal AUTO_INCREMENT, aunque la unicidad global no está garantizada, pero cada tabla es única, lo que básicamente satisface las necesidades.

La desventaja del ID de autoincremento de la base de datos es que no se puede obtener el ID antes de insertar los datos. Después de insertar los datos, aunque la identificación obtenida es única, debe esperar hasta que se envíe la transacción antes de que la identificación sea válida. Algunos datos bidireccionales deben actualizarse después de la inserción, lo cual es problemático.

Durante nuestro proceso de desarrollo, nos encontramos con un escenario en el que la base de datos principal y la principal se sincronizaron (se puede entender simplemente que el mismo SQL se ejecuta de nuevo en otra base de datos). Si usa el ID de incremento automático de la base de datos, habrá claves primarias inconsistentes o claves primarias Problemas de conflicto.

Generador de ID distribuido

Opción 1: UUID

No recomendado para entornos distribuidos

uuid es el método que pensamos primero, y hay un método correspondiente en el paquete java.util; Este es un uuid con estándar rfc: https://www.ietf.org/rfc/rfc4122.txt

uuid tiene muy buen rendimiento (llamada local), sin consumo de red.

Sin embargo, uuid no es fácil de almacenar (se genera una cadena, el almacenamiento es demasiado largo y muchos escenarios no son aplicables); la información es insegura (según la generación de direcciones MAC, lo que puede causar fugas. Esta vulnerabilidad se ha utilizado para encontrar la ubicación del productor del virus Melissa .
); no se puede garantizar el incremento (o incrementos de tendencia); los comentarios de otros bloggers, la intercepción de los 20 principales hacen una identificación única, habrá duplicación en grandes cantidades (solo alrededor de 220w).

UUID.randomUUID().toString()

Solución 2: copo de nieve (algoritmo de copo de nieve)

Actualmente se utilizan soluciones de identificación más distribuidas, recomendado

Antecedentes Twitter Yunyun no lo presentará, es el Twitter el que bloqueó la cuenta de comprensión de Wang hace algún tiempo.

Introducción al algoritmo

El resultado del ID de generación del algoritmo SnowFlake es un entero de 64 bits, y su estructura es la siguiente:

• 1 bit, sin uso. En el sistema binario, el bit más alto de 1 es un número negativo, pero la identificación que generamos generalmente usa un número entero, por lo que el bit más alto se fija en 0

• 41 bits, utilizados para registrar la marca de tiempo (milisegundos).

  • 41 bits pueden representar 2 ^ {41} -1 números,
  • Si solo se usa para representar un número entero positivo (un número positivo en la computadora contiene 0), el rango de valores que se puede representar es: 0 a 2 ^ {41} -1, menos 1 porque el rango de valores que se puede representar comienza desde 0, no 1.
  • En otras palabras, 41 bits pueden representar un valor de 2 ^ {41} -1 milisegundos, y convertirse en una unidad de año es (2 ^ {41} -1) / (1000 60 60 24 365) = 69 años

• 10 bits, utilizados para registrar la identificación de la máquina en funcionamiento.

  • Se puede implementar en 2 ^ {10} = 1024 nodos, incluidos 5 datacenterId y 5 workerId
  • El entero positivo más grande que se puede representar con 5 bits es 2 ^ {5} -1 = 31, es decir, los 32 números 0, 1, 2, 3, ... 31 se pueden usar para representar diferentes datecenterId o workerId
• 12 dígitos, número de serie, que se utiliza para registrar diferentes ID generados en el mismo milisegundo.
  • El entero positivo más grande que se puede representar con 12 bits es 2 ^ {12} -1 = 4095, es decir, 4095 números como 0, 1, 2, 3, ... 4094 se pueden usar para representar la misma máquina al mismo tiempo. 4095 Números de serie de ID generados en (milisegundos).

Dado que los enteros de 64 bits en Java son de tipo long, la identificación generada por el algoritmo SnowFlake en Java se almacena en long.

SnowFlake puede garantizar :

1. Todos los identificadores generados por el mismo servidor aumentan en la tendencia temporal
2. No habrá ID duplicados en todo el sistema distribuido (porque hay datacenterId y workerId para distinguir)

Problemas existentes:

1. La configuración de la ID de la máquina (5 dígitos) y la ID del centro de datos (5 dígitos) no se resuelve. Se utilizará la misma configuración en la implementación distribuida y aún existe el riesgo de duplicación de la ID.
2. Los objetos deben crearse una instancia cuando se usan, y no hay una clase de herramienta lista para usar.
3. Fuerte dependencia del reloj de la máquina, si el reloj de la máquina se retrasa, provocará llamadas repetidas o el servicio no estará disponible. (Esto no sucedería en circunstancias normales)

Para resolver el problema anterior, aquí hay una solución. El workId se genera usando el servidor hostName y el dataCenterId se genera usando la IP. Esto puede evitar la duplicación del código de máquina de 10 dígitos en la mayor medida posible, pero como ambos ID no pueden exceder los 32, solo se puede tomar el resto, lo cual es inevitable. Repito, pero en el uso real, la configuración de hostName e IP son generalmente continuas o similares. Siempre que no estén exactamente separados por 32 bits, no habrá ningún problema. Además, es casi imposible que hostName e IP estén separados por 32 al mismo tiempo. Para la implementación distribuida, generalmente no más de 10 contenedores.

La configuración de la ventana acoplable utilizada en producción generalmente se compila una vez y luego se distribuye a diferentes contenedores, no habrá configuraciones diferentes. En este caso, existe incertidumbre sobre la situación mencionada anteriormente, y habrá otro artículo de referencia en los comentarios.

Código fuente

Algoritmo de generación de ID de copo de nieve de la versión Java

package com.my.blog.website.utils;

import org.apache.commons.lang3.RandomUtils;
import org.apache.commons.lang3.StringUtils;
import org.apache.commons.lang3.SystemUtils;

import java.net.Inet4Address;
import java.net.UnknownHostException;

/**
 * Twitter_Snowflake<br>
 * SnowFlake的结构如下(每部分用-分开):<br>
 * 0 - 0000000000 0000000000 0000000000 0000000000 0 - 00000 - 00000 - 000000000000 <br>
 * 1位标识，由于long基本类型在Java中是带符号的，最高位是符号位，正数是0，负数是1，所以id一般是正数，最高位是0<br>
 * 41位时间截(毫秒级)，注意，41位时间截不是存储当前时间的时间截，而是存储时间截的差值（当前时间截 - 开始时间截)
 * 得到的值），这里的的开始时间截，一般是我们的id生成器开始使用的时间，由我们程序来指定的（如下下面程序IdWorker类的startTime属性）。41位的时间截，可以使用69年，年T = (1L << 41) / (1000L * 60 * 60 * 24 * 365) = 69<br>
 * 10位的数据机器位，可以部署在1024个节点，包括5位datacenterId和5位workerId<br>
 * 12位序列，毫秒内的计数，12位的计数顺序号支持每个节点每毫秒(同一机器，同一时间截)产生4096个ID序号<br>
 * 加起来刚好64位，为一个Long型。<br>
 * SnowFlake的优点是，整体上按照时间自增排序，并且整个分布式系统内不会产生ID碰撞(由数据中心ID和机器ID作区分)，并且效率较高，经测试，SnowFlake每秒能够产生26万ID左右。
 */
public class SnowflakeIdWorker {

    // ==============================Fields===========================================
    /** 开始时间截 (2015-01-01) */
    private final long twepoch = 1489111610226L;

    /** 机器id所占的位数 */
    private final long workerIdBits = 5L;

    /** 数据标识id所占的位数 */
    private final long dataCenterIdBits = 5L;

    /** 支持的最大机器id，结果是31 (这个移位算法可以很快的计算出几位二进制数所能表示的最大十进制数) */
    private final long maxWorkerId = -1L ^ (-1L << workerIdBits);

    /** 支持的最大数据标识id，结果是31 */
    private final long maxDataCenterId = -1L ^ (-1L << dataCenterIdBits);

    /** 序列在id中占的位数 */
    private final long sequenceBits = 12L;

    /** 机器ID向左移12位 */
    private final long workerIdShift = sequenceBits;

    /** 数据标识id向左移17位(12+5) */
    private final long dataCenterIdShift = sequenceBits + workerIdBits;

    /** 时间截向左移22位(5+5+12) */
    private final long timestampLeftShift = sequenceBits + workerIdBits + dataCenterIdBits;

    /** 生成序列的掩码，这里为4095 (0b111111111111=0xfff=4095) */
    private final long sequenceMask = -1L ^ (-1L << sequenceBits);

    /** 工作机器ID(0~31) */
    private long workerId;

    /** 数据中心ID(0~31) */
    private long dataCenterId;

    /** 毫秒内序列(0~4095) */
    private long sequence = 0L;

    /** 上次生成ID的时间截 */
    private long lastTimestamp = -1L;

    private static SnowflakeIdWorker idWorker;

    static {
        idWorker = new SnowflakeIdWorker(getWorkId(),getDataCenterId());
    }

    //==============================Constructors=====================================
    /**
     * 构造函数
     * @param workerId 工作ID (0~31)
     * @param dataCenterId 数据中心ID (0~31)
     */
    public SnowflakeIdWorker(long workerId, long dataCenterId) {
        if (workerId > maxWorkerId || workerId < 0) {
            throw new IllegalArgumentException(String.format("workerId can't be greater than %d or less than 0", maxWorkerId));
        }
        if (dataCenterId > maxDataCenterId || dataCenterId < 0) {
            throw new IllegalArgumentException(String.format("dataCenterId can't be greater than %d or less than 0", maxDataCenterId));
        }
        this.workerId = workerId;
        this.dataCenterId = dataCenterId;
    }

    // ==============================Methods==========================================
    /**
     * 获得下一个ID (该方法是线程安全的)
     * @return SnowflakeId
     */
    public synchronized long nextId() {
        long timestamp = timeGen();

        //如果当前时间小于上一次ID生成的时间戳，说明系统时钟回退过这个时候应当抛出异常
        if (timestamp < lastTimestamp) {
            throw new RuntimeException(
                    String.format("Clock moved backwards.  Refusing to generate id for %d milliseconds", lastTimestamp - timestamp));
        }

        //如果是同一时间生成的，则进行毫秒内序列
        if (lastTimestamp == timestamp) {
            sequence = (sequence + 1) & sequenceMask;
            //毫秒内序列溢出
            if (sequence == 0) {
                //阻塞到下一个毫秒,获得新的时间戳
                timestamp = tilNextMillis(lastTimestamp);
            }
        }
        //时间戳改变，毫秒内序列重置
        else {
            sequence = 0L;
        }

        //上次生成ID的时间截
        lastTimestamp = timestamp;

        //移位并通过或运算拼到一起组成64位的ID
        return ((timestamp - twepoch) << timestampLeftShift)
                | (dataCenterId << dataCenterIdShift)
                | (workerId << workerIdShift)
                | sequence;
    }

    /**
     * 阻塞到下一个毫秒，直到获得新的时间戳
     * @param lastTimestamp 上次生成ID的时间截
     * @return 当前时间戳
     */
    protected long tilNextMillis(long lastTimestamp) {
        long timestamp = timeGen();
        while (timestamp <= lastTimestamp) {
            timestamp = timeGen();
        }
        return timestamp;
    }

    /**
     * 返回以毫秒为单位的当前时间
     * @return 当前时间(毫秒)
     */
    protected long timeGen() {
        return System.currentTimeMillis();
    }

    private static Long getWorkId(){
        try {
            String hostAddress = Inet4Address.getLocalHost().getHostAddress();
            int[] ints = StringUtils.toCodePoints(hostAddress);
            int sums = 0;
            for(int b : ints){
                sums += b;
            }
            return (long)(sums % 32);
        } catch (UnknownHostException e) {
            // 如果获取失败，则使用随机数备用
            return RandomUtils.nextLong(0,31);
        }
    }

    private static Long getDataCenterId(){
        int[] ints = StringUtils.toCodePoints(SystemUtils.getHostName());
        int sums = 0;
        for (int i: ints) {
            sums += i;
        }
        return (long)(sums % 32);
    }

    /**
     * 静态工具类
     *
     * @return
     */
    public static synchronized Long generateId(){
        long id = idWorker.nextId();
        return id;
    }

    //==============================Test=============================================
    /** 测试 */
    public static void main(String[] args) {
        System.out.println(System.currentTimeMillis());
        long startTime = System.nanoTime();
        for (int i = 0; i < 50000; i++) {
            long id = SnowflakeIdWorker.generateId();
            System.out.println(id);
        }
        System.out.println((System.nanoTime()-startTime)/1000000+"ms");
    }
}

Referencia del texto original: https://blog.csdn.net/xiaopeng9275/article/details/72123709

Compartir y mirar son mi mayor estímulo. Soy un pub, ¡nos vemos la próxima!