一、当订单号撞衫时会发生什么？

去年双十一，某电商平台因为订单号重复导致发货混乱。传统的数据库自增ID在分布式环境下就像多人共用的流水号本，UUID虽然唯一却像乱码无法排序，雪花算法需要维护机器ID就像管理身份证号码。这时Redis举着它的单线程大旗站了出来："让我试试？"

二、Redis的原子计数魔法

// Spring Boot + Redis技术栈示例
@Service
public class DistributedIdGenerator {
    @Autowired
    private RedisTemplate<String, String> redisTemplate;

    /**
     * 生成分布式ID
     * @param bizType 业务类型（如：order）
     * @return 形如：20231102123456_000001
     */
    public String generateId(String bizType) {
        // 获取当前时间戳（精确到秒）
        String timestamp = new SimpleDateFormat("yyyyMMddHHmmss").format(new Date());
        
        // 构造Redis键（业务隔离）
        String redisKey = "id:" + bizType + ":" + timestamp;
        
        // 原子操作：序列号自增
        Long sequence = redisTemplate.opsForValue().increment(redisKey);
        
        // 设置24小时过期（自动清理历史数据）
        redisTemplate.expire(redisKey, 1, TimeUnit.DAYS);

        // 组合最终ID：时间戳+6位序列号
        return String.format("%s_%06d", timestamp, sequence);
    }
}

这段代码就像银行叫号机的工作原理：每个时间窗口（秒级）对应一个独立的号码池，Redis的INCR命令确保叫号不重复，24小时后自动重置号码本。

三、适合使用Redis生成ID的场景

  1. 电商订单系统：每秒生成数万订单号，需要严格递增便于分库分表
  2. 日志追踪体系：为每条日志打上有序标记，方便问题排查
  3. 秒杀活动系统：瞬时高并发场景下生成唯一凭证
  4. 物联网设备注册：为百万级设备分配唯一身份标识

四、技术方案的AB面

优势亮点：

  1. 性能王者：单机Redis可支撑10万+/秒的ID生成
  2. 天然分布式：无需维护机器ID等状态信息
  3. 灵活扩展：通过key设计支持多业务隔离
  4. 自带过期：自动清理历史数据避免内存膨胀

潜在风险：

  1. 单点故障：Redis宕机会导致服务不可用（可通过集群解决）
  2. 时钟回拨：服务器时间异常调整会导致ID重复（需增加时间校验）
  3. 序列溢出：单秒超过999999时需要特殊处理（可增加位数）

五、使用时的四大注意事项

  1. 键命名规范：建议采用id:业务类型:时间戳的三段式结构
  2. 时间同步机制：所有节点必须使用NTP时间同步服务
  3. 异常处理策略：网络超时重试、降级方案设计
  4. 容量预评估：按每秒峰值计算内存消耗，例如：
    • 每秒1万请求
    • 每个key存储数值约6字节
    • 每日新增key数量：86400秒 = 84MB/天

六、进阶优化方案

对于更高要求的场景，可以采用混合方案增强系统可靠性：

// 改进版ID生成器（带时间校验）
public String generateIdEnhanced(String bizType) throws Exception {
    String timestamp = new SimpleDateFormat("yyyyMMddHHmmss").format(new Date());
    String lastTimestamp = (String) redisTemplate.opsForValue().get("lastTimestamp");
    
    // 防止时间回拨
    if (lastTimestamp != null && timestamp.compareTo(lastTimestamp) < 0) {
        throw new Exception("系统时钟异常！");
    }
    
    redisTemplate.opsForValue().set("lastTimestamp", timestamp);
    // 后续生成逻辑与基础版相同
}

七、总结与选择建议

Redis生成的ID就像超市的购物小票：抬头是精确到秒的结账时间，末尾是当秒内的流水编号。这种方案特别适合需要有序性、高并发的业务场景。但就像不能指望收银员同时服务多个顾客，我们也需要接受Redis单线程模型的特性限制。对于中小型系统，这无异于一把瑞士军刀；但在超大规模场景下，可能需要结合数据库号段等方案构建复合体系。