【面试】考官问我MySQL如何实现高并发电商订单ID

【Mysql】雪花算法(Snowflake)

一、电商订单的系统要求

  1. 全局唯一:如果订单ID重复了,肯定要完蛋。
  2. 高性能:要做到高并发、低延迟。生成订单ID都成为瓶颈了,那还得了。
  3. 高可用:至少要做到4个9,别动不动就宕机了。
  4. 易用性:如果为了满足上述要求,搞了几百台服务器,复杂且难以维护,也不行。
  5. 数值且有序递增:数值占用的空间更小,有序递增能保证插入MySQL的时候更高性能。
  6. 嵌入业务含义:如果订单ID里面能嵌入业务含义,就能通过订单ID知道是哪个业务线生成的,便于排查问题。

二、传统实现方式无法满足

  1. 数据库主键顺序自增,每天有多少订单量被竞争对手看的一清二楚,商业机密都暴露了。
  2. 单机MySQL只能支持几百量级的并发,我们公司每天千万订单量,hold不住啊。
  3. 使用数据库集群,自增ID起始值按机器编号,步长等于机器数量。 实现百万级的并发,大概就需要2000台机器,不可取。(比如有两台机器,第一台机器生成的ID是1、3、5、7,第二台机器生成的ID是2、4、6、8。性能不行就加机器)。
  4. 使用号段模式。虽然并发量是上去了,但是自增ID还是不能作为订单ID。(提前获取数据库的号段,加载到内存中)

三、雪花算法生成ID

雪花算法生成ID是Long类型,长度64位。适合分布式、高性能、高可用的订单ID生成算法。

第 1 位: 符号位,暂时不用。

第 2~42 位:共41位,时间戳,单位是毫秒,可以支撑大约69年。

第 43~52 位:共10位,机器ID,最多可容纳1024台机器 

第 53~64 位:共12位,序列号,是自增值,表示同一毫秒内产生的ID,单台机器每毫秒最多可生成4096个订单ID 。

代码实现:

/**
 * @apiNote 雪花算法
 **/
public class SnowFlake {
​
    /**
     * 起始时间戳,从2021-12-01开始生成
     */
    private final static long START_STAMP = 1638288000000L;
​
    /**
     * 序列号占用的位数 12
     */
    private final static long SEQUENCE_BIT = 12;
​
    /**
     * 机器标识占用的位数
     */
    private final static long MACHINE_BIT = 10;
​
    /**
     * 机器数量最大值
     */
    private final static long MAX_MACHINE_NUM = ~(-1L << MACHINE_BIT);
​
    /**
     * 序列号最大值
     */
    private final static long MAX_SEQUENCE = ~(-1L << SEQUENCE_BIT);
​
    /**
     * 每一部分向左的位移
     */
    private final static long MACHINE_LEFT = SEQUENCE_BIT;
    private final static long TIMESTAMP_LEFT = SEQUENCE_BIT + MACHINE_BIT;
​
    /**
     * 机器标识
     */
    private long machineId;
    /**
     * 序列号
     */
    private long sequence = 0L;
    /**
     * 上一次时间戳
     */
    private long lastStamp = -1L;
​
    /**
     * 构造方法
     * @param machineId 机器ID
     */
    public SnowFlake(long machineId) {
        if (machineId > MAX_MACHINE_NUM || machineId < 0) {
            throw new RuntimeException("机器超过最大数量");
        }
        this.machineId = machineId;
    }
​
    /**
     * 产生下一个ID
     */
    public synchronized long nextId() {
        long currStamp = getNewStamp();
        if (currStamp < lastStamp) {
            throw new RuntimeException("时钟后移,拒绝生成ID!");
        }
​
        if (currStamp == lastStamp) {
            // 相同毫秒内,序列号自增
            sequence = (sequence + 1) & MAX_SEQUENCE;
            // 同一毫秒的序列数已经达到最大
            if (sequence == 0L) {
                currStamp = getNextMill();
            }
        } else {
            // 不同毫秒内,序列号置为0
            sequence = 0L;
        }
​
        lastStamp = currStamp;
​
        return (currStamp - START_STAMP) << TIMESTAMP_LEFT // 时间戳部分
                | machineId << MACHINE_LEFT             // 机器标识部分
                | sequence;                             // 序列号部分
    }
​
    private long getNextMill() {
        long mill = getNewStamp();
        while (mill <= lastStamp) {
            mill = getNewStamp();
        }
        return mill;
    }
​
    private long getNewStamp() {
        return System.currentTimeMillis();
    }
​
    public static void main(String[] args) {
        // 订单ID生成测试,机器ID指定第0台
        SnowFlake snowFlake = new SnowFlake(0);
        System.out.println(snowFlake.nextId());
    }
}
输出结果:6836348333850624

接入非常简单,不需要搭建服务集群,。代码逻辑非常简单,,同一毫秒内,订单ID的序列号自增。同步锁只作用于本机,机器之间互不影响,每毫秒可以生成4百万个订单ID,非常强悍。

生成规则不是固定的,可以根据自身的业务需求调整。如果你不需要那么大的并发量,可以把机器标识位拆出一部分,当作业务标识位,标识是哪个业务线生成的订单ID。

四、雪花算法还有改进的空间吗?

 雪花算法严重依赖系统时钟。如果时钟回拨,就会生成重复ID。

解决办法

比如美团的Leaf(美团自研一种分布式ID生成系统),为了解决时钟回拨,引入了zookeeper,原理也很简单,就是比较当前系统时间跟生成节点的时间。

有的对并发要求更高的系统,比如双十一秒杀,每毫秒4百万并发还不能满足要求,就可以使用雪花算法和号段模式相结合,比如百度的UidGenerator、滴滴的TinyId。想想也是,号段模式的预先生成ID肯定是高性能分布式订单ID的最终解决方案。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

常生果

喜欢我,请支持我

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值