分散式ID設計方案

oktokeep發表於2024-11-27
分散式

分散式ID設計方案

package com.example.core.mydemo.thread;

import java.util.UUID;

public class IDTest {
    public static void main(String[] args) {
        String uuid = UUID.randomUUID().toString();
        //6c1d27a1-6a1c-458e-bc66-3cfb76999733
        //在分散式日誌系統或者分散式鏈路跟蹤系統中，可以使用UUID生成唯一標識，用於串聯請求的日誌。
        //缺點：UUID生成的字串太長，透過索引查詢資料的效率比較低。此外，UUID生成的字串，順序沒有保證，不是遞增的，不滿足工作中的有些業務場景。
        System.out.println("uuid=" + uuid);

        /**
         * MySQL中的auto_increment。
         * Oracle中sequence。
         * 在一些老系統或者公司的內部管理系統中，可能會用資料庫遞增ID作為分散式ID的方案，這些系統的使用者併發量一般比較小，資料量也不多。
         * 缺點：只能保證單表的資料唯一性，如果跨表或者跨資料庫，ID可能會重複。ID是自增的，生成規則很容易被猜透，有安全風險。ID是基於資料庫生成的，在高併發下，可能會有效能問題。
         */

        /**
         *  資料庫號段模式
         *  一次生成一定步長的ID，比如：步長是1000，每次資料庫自增1000，ID值從100001變成了101001
         *  這時需要重新從資料庫中獲取一次新號段的ID，快取到伺服器的記憶體中，這樣下次又能直接從記憶體中獲取ID了。
         *  缺點：ID是自增的，生成規則很容易被猜透，有安全風險。如果資料庫是單節點的，有巖機的風險。
         */

        /**
         * 資料庫的多主模式
         * 為了保證在不同的master例項下ID的唯一性，我們需要事先規定好每個master下的大的區間，比如：master1的資料是10開頭的，master2的資料是11開頭的，master3的資料是12開頭的。
         * 缺點：跨多個master例項下生成的ID，可能不是遞增的。
         */

        /**
         * Redis生成ID
         * SET ID_VALUE 1000
         * INCR ID_VALUE
         * GET ID_VALUE
         * DEL ID_VALUE  刪除
         * 缺點：ID是自增的，生成規則很容易被猜透，有安全風險。並且Redis可能也存在單節點，巖機的風險。
         */

        /**
         * Zookeeper生成ID
         * Zookeeper主要透過其znode資料版本來生成序列號，可以生成32位和64位的資料版本號，客戶端可以使用這個版本號來作為唯一的序列號。
         */

        /**
         * Snowflake(雪花演算法)是Twitter開源的分散式ID演算法。
         * 缺點：依賴伺服器時間，伺服器時鐘回撥時可能會生成重複ID。
         */

        /**
         * Leaf是美團開源的分散式ID生成系統，它提供了兩種生成ID的方式：
         * Leaf-segment號段模式
         * Leaf-snowflake雪花演算法
         * https://github.com/Meituan-Dianping/Leaf
         */

        /**
         * Tinyid是滴滴用Java開發的一款分散式id生成系統，基於資料庫號段演算法實現。
         * https://github.com/didi/tinyid
         */

        /**
         * 百度 UID-Generator 使用 Java 語言，基於雪花演算法實現。
         */
    }
}

相關文章