- 正确答案：设计一个分布式唯一ID生成器，可以采用Snowflake算法来生成全局唯一的64位整数ID。该ID由时间戳、机器标识和序列号组成，保证在分布式系统中高并发下也能高效生成不重复的ID。 - 解答思路： 1. 明确需求：请求ID需要满足唯一性、有序性（可选）、高性能、低延迟、支持分布式部署。 2. 分析常见方案：数据库自增主键（单点瓶颈）、UUID（无序、占用空间大、不易索引）、Redis自增（依赖中间件）等各有缺陷。 3. 选择Snowflake算法：Twitter开源的分布式ID生成算法，适合大规模分布式场景。 4. 设计ID结构：使用64位Long类型，按位划分不同含义字段。 5. 实现核心逻辑：确保线程安全、时钟回拨处理、避免ID冲突。 - 深度知识讲解： Snowflake ID是64位整数，典型结构如下： - 1位：符号位，始终为0（保证正数） - 41位：时间戳（毫秒级），以某个起始时间（如2023-01-01）为纪元 → 可用约69年（2^41 / 1000 / 3600 / 24 / 365 ≈ 69.7年） - 10位：机器标识（workerId + datacenterId） → 支持最多1024个节点（例如5位datacenter + 5位worker） - 12位：序列号（每毫秒内自增） → 每台机器每毫秒最多生成4096个ID（2^12）关键特性： - 全局唯一：组合了时间+机器+序列 - 趋势递增：时间戳主导，利于数据库索引 - 高性能：纯内存操作，无需外部依赖 - 分布式友好：去中心化设计核心挑战与解决方案： 1. 时钟回拨问题：系统时间被手动或NTP校准导致时间倒退 → 方案：短暂等待；记录上次时间；抛出异常或降级策略 2. 机器ID分配：需确保每个实例有唯一workerId → 可通过配置文件、ZooKeeper、K8s环境变量等方式注入 3. 并发安全：同一毫秒内多个线程请求 → 使用原子类控制序列号自增 - 扩展知识点： - 替代方案对比： - UUID v1：包含MAC地址+时间戳，长度128位，安全性差（暴露主机信息） - UUID v4：随机生成，碰撞概率极低但不可排序 - 数据库+步长：如设置auto_increment_increment=1000，多实例分段取值 - Leaf（美团）、TinyID（百度）：基于数据库的发号服务，提供REST接口 - 业务扩展性：可在ID中嵌入业务类型、租户信息等（需定制编码） - 存储优化：64位Long比字符串型UUID更节省存储和索引空间 - 解码能力：从生成的ID中反解析出时间、机器信息，用于排查问题 - Java伪代码实现： ``` public class SnowflakeIdGenerator { // 起始时间戳（自定义纪元，比如2023-01-01） private static final long EPOCH = 1672531200000L; // 各部分所占位数 private static final long TIMESTAMP_BITS = 41; private static final long DATA_CENTER_ID_BITS = 5; private static final long WORKER_ID_BITS = 5; private static final long SEQUENCE_BITS = 12; // 最大值掩码 private static final long MAX_DATA_CENTER_ID = ~(-1L << DATA_CENTER_ID_BITS); private static final long MAX_WORKER_ID = ~(-1L << WORKER_ID_BITS); private static final long MAX_SEQUENCE = ~(-1L << SEQUENCE_BITS); // 位移常量 private static final long WORKER_ID_SHIFT = SEQUENCE_BITS; private static final long DATA_CENTER_ID_SHIFT = SEQUENCE_BITS + WORKER_ID_BITS; private static final long TIMESTAMP_SHIFT = SEQUENCE_BITS + WORKER_ID_BITS + DATA_CENTER_ID_BITS; private long dataCenterId; private long workerId; private long sequence = 0L; private long lastTimestamp = -1L; public SnowflakeIdGenerator(long dataCenterId, long workerId) { if (dataCenterId > MAX_DATA_CENTER_ID || dataCenterId < 0) { throw new IllegalArgumentException("Data center ID can't be greater than " + MAX_DATA_CENTER_ID); } if (workerId > MAX_WORKER_ID || workerId < 0) { throw new IllegalArgumentException("Worker ID can't be greater than " + MAX_WORKER_ID); } this.dataCenterId = dataCenterId; this.workerId = workerId; } public synchronized long nextId() { long currentTimestamp = System.currentTimeMillis(); if (currentTimestamp < lastTimestamp) { // 时钟回拨处理：等待直到超过上一次时间戳 throw new RuntimeException("Clock moved backwards. Refusing to generate id"); } if (currentTimestamp == lastTimestamp) { // 同一毫秒内自增序列 sequence = (sequence + 1) & MAX_SEQUENCE; if (sequence == 0) { // 当前毫秒内序列耗尽，等待下一毫秒 while ((currentTimestamp = System.currentTimeMillis()) == lastTimestamp) { Thread.yield(); } } } else { // 进入下一毫秒，序列重置 sequence = 0L; } lastTimestamp = currentTimestamp; // 组装ID return ((currentTimestamp - EPOCH) << TIMESTAMP_SHIFT) | (dataCenterId << DATA_CENTER_ID_SHIFT) | (workerId << WORKER_ID_SHIFT) | sequence; } // 示例调用 public static void main(String[] args) { SnowflakeIdGenerator idGen = new SnowflakeIdGenerator(1, 1); for (int i = 0; i < 10; i++) { System.out.println(idGen.nextId()); } } } ``` - 注意事项： - 建议将EPOCH设为服务上线时间，延长可用年限 - workerId应作为配置项注入，避免硬编码 - 在容器化环境中可通过Pod名称/IP哈希等方式自动分配 - 若对时间精度要求更高，可改用微秒级时间戳（但需注意系统支持） - 生产环境建议封装成独立服务或SDK供多应用调用这个设计方案满足了校园招聘中对系统设计能力、并发编程、位运算、分布式基础知识的综合考察。

烽火通信offer逼签

全站热榜

创作者周榜