彻底搞懂snowflake算法及百度美团的最佳实践

写在前面的话

一提到分布式ID自动生成方案，大家肯定都非常熟悉，并且立即能说出自家拿手的几种方案，确实，ID作为系统数据的重要标识，重要性不言而喻，而各种方案也是历经多代优化，请允许我用这个视角对分布式ID自动生成方案进行分类：

实现方式

  • 完全依赖数据源方式

ID的生成规则，读取控制完全由数据源控制，常见的如数据库的自增长ID，序列号等，或Redis的INCR/INCRBY原子操作产生顺序号等。

  • 半依赖数据源方式

ID的生成规则，有部分生成因子需要由数据源（或配置信息）控制，如snowflake算法。

  • 不依赖数据源方式

ID的生成规则完全由机器信息独立计算，不依赖任何配置信息和数据记录，如常见的UUID，GUID等

实践方案

实践方案适用于以上提及的三种实现方式，可作为这三种实现方式的一种补充，旨在提升系统吞吐量，但原有实现方式的局限性依然存在。

  • 实时获取方案

顾名思义，每次要获取ID时，实时生成。
简单快捷，ID都是连续不间断的，但吞吐量可能不是最高。

  • 预生成方案

预先生成一批ID放在数据池里，可简单自增长生成，也可以设置步长，分批生成，需要将这些预先生成的数据，放在存储容器里（JVM内存，Redis，数据库表均可）。
可以较大幅度地提升吞吐量，但需要开辟临时存储空间，断电宕机后可能会丢失已有ID，ID可能有间断。

方案简介

以下对目前流行的分布式ID方案做简单介绍

  1. 数据库自增长ID

属于完全依赖数据源的方式，所有的ID存储在数据库里，是最常用的ID生成办法，在单体应用时期得到了最广泛的使用，建立数据表时利用数据库自带的auto_increment作主键，或是使用序列完成其他场景的一些自增长ID的需求。

  • 优点：非常简单，有序递增，方便分页和排序。
  • 缺点：分库分表后，同一数据表的自增ID容易重复，无法直接使用（可以设置步长，但局限性很明显）；性能吞吐量整个较低，如果设计一个单独的数据库来实现 分布式应用的数据唯一性，即使使用预生成方案，也会因为事务锁的问题，高并发场景容易出现单点瓶颈。
  • 适用场景：单数据库实例的表ID（包含主从同步场景），部分按天计数的流水号等；分库分表场景、全系统唯一性ID场景不适用。
  1. Redis生成ID

也属于完全依赖数据源的方式，通过Redis的INCR/INCRBY自增原子操作命令，能保证生成的ID肯定是唯一有序的，本质上实现方式与数据库一致。

  • 优点：整体吞吐量比数据库要高。
  • 缺点：Redis实例或集群宕机后，找回最新的ID值有点困难。
  • 适用场景：比较适合计数场景，如用户访问量，订单流水号（日期+流水号）等。
  1. UUID、GUID生成ID

UUID：按照OSF制定的标准计算，用到了以太网卡地址、纳秒级时间、芯片ID码和许多可能的数字。由以下几部分的组合：当前日期和时间(UUID的第一个部分与时间有关，如果你在生成一个UUID之后，过几秒又生成一个UUID，则第一个部分不同，其余相同)，时钟序列，全局唯一的IEEE机器识别号（如果有网卡，从网卡获得，没有网卡以其他方式获得）

GUID：微软对UUID这个标准的实现。UUID还有其它各种实现，不止GUID一种，不一一列举了。

这两种属于不依赖数据源方式，真正的全球唯一性ID

  • 优点：不依赖任何数据源，自行计算，没有网络ID，速度超快，并且全球唯一。
  • 缺点：没有顺序性，并且比较长（128bit），作为数据库主键、索引会导致索引效率下降，空间占用较多。
  • 适用场景：只要对存储空间没有苛刻要求的都能够适用，比如各种链路追踪、日志存储等。

4、snowflake算法（雪花算法）生成ID

属于半依赖数据源方式，原理是使用Long类型（64位），按照一定的规则进行填充：时间（毫秒级）+集群ID+机器ID+序列号，每部分占用的位数可以根据实际需要分配，其中集群ID和机器ID这两部分，在实际应用场景中要依赖外部参数配置或数据库记录。

  • 优点：高性能、低延迟、去中心化、按时间有序
  • 缺点：要求机器时钟同步（到秒级即可）
  • 适用场景：分布式应用环境的数据主键

雪花ID算法听起来是不是特别适用分布式架构场景？照目前来看是的，接下来我们重点讲解它的原理和最佳实践。

snowflake算法实现原理

snowflake算法来源于Twitter，使用scala语言实现，利用Thrift框架实现RPC接口调用，最初的项目起因是数据库从mysql迁移到Cassandra，Cassandra没有现成可用 的ID生成机制，就催生了这个项目，现有的github源码有兴趣可以去看看。

snowflake算法的特性是有序、唯一，并且要求高性能，低延迟（每台机器每秒至少生成10k条数据，并且响应时间在2ms以内），要在分布式环境（多集群，跨机房）下使用，因此snowflake算法得到的ID是分段组成的：

  • 与指定日期的时间差（毫秒级），41位，够用69年
  • 集群ID + 机器ID， 10位，最多支持1024台机器
  • 序列，12位，每台机器每毫秒内最多产生4096个序列号

如图所示：

  • 1bit：符号位，固定是0，表示全部ID都是正整数
  • 41bit：毫秒数时间差，从指定的日期算起，够用69年，我们知道用Long类型表示的时间戳是从1970-01-01 00:00:00开始算起的，咱们这里的时间戳可以指定日期，如2019-10-23 00:00:00
  • 10bit：机器ID，有异地部署，多集群的也可以配置，需要线下规划好各地机房，各集群，各实例ID的编号
  • 12bit：序列ID，前面都相同的话，最多可以支持到4096个

以上的位数分配只是官方建议的，我们可以根据实际需要自行分配，比如说我们的应用机器数量最多也就几十台，但并发数很大，我们就可以将10bit减少到8bit，序列部分从12bit增加到14bit等等

当然每部分的含义也可以自由替换，如中间部分的机器ID，如果是云计算、容器化的部署环境，随时有扩容，缩减机器的操作，通过线下规划去配置实例的ID不太现实，就可以替换为实例每重启一次，拿一次自增长的ID作为该部分的内容，下文会讲解。

github上也有大神用Java做了snowflake最基本的实现，这里直接查看源码：
snowflake java版源码

/**
 * twitter的snowflake算法 -- java实现
 *
 * @author beyond
 * @date 2016/11/26
 */
public class SnowFlake {

    /**
     * 起始的时间戳
     */
    private final static long START_STMP = 1480166465631L;

    /**
     * 每一部分占用的位数
     */
    private final static long SEQUENCE_BIT = 12; //序列号占用的位数
    private final static long MACHINE_BIT = 5;   //机器标识占用的位数
    private final static long DATACENTER_BIT = 5;//数据中心占用的位数

    /**
     * 每一部分的最大值
     */
    private final static long MAX_DATACENTER_NUM = -1L ^ (-1L << DATACENTER_BIT);
    private final static long MAX_MACHINE_NUM = -1L ^ (-1L << MACHINE_BIT);
    private final static long MAX_SEQUENCE = -1L ^ (-1L << SEQUENCE_BIT);

    /**
     * 每一部分向左的位移
     */
    private final static long MACHINE_LEFT = SEQUENCE_BIT;
    private final static long DATACENTER_LEFT = SEQUENCE_BIT + MACHINE_BIT;
    private final static long TIMESTMP_LEFT = DATACENTER_LEFT + DATACENTER_BIT;

    private long datacenterId;  //数据中心
    private long machineId;     //机器标识
    private long sequence = 0L; //序列号
    private long lastStmp = -1L;//上一次时间戳

    public SnowFlake(long datacenterId, long machineId) {
        if (datacenterId > MAX_DATACENTER_NUM || datacenterId < 0) {
            throw new IllegalArgumentException("datacenterId can‘t be greater than MAX_DATACENTER_NUM or less than 0");
        }
        if (machineId > MAX_MACHINE_NUM || machineId < 0) {
            throw new IllegalArgumentException("machineId can‘t be greater than MAX_MACHINE_NUM or less than 0");
        }
        this.datacenterId = datacenterId;
        this.machineId = machineId;
    }

    /**
     * 产生下一个ID
     *
     * @return
     */
    public synchronized long nextId() {
        long currStmp = getNewstmp();
        if (currStmp < lastStmp) {
            throw new RuntimeException("Clock moved backwards.  Refusing to generate id");
        }

        if (currStmp == lastStmp) {
            //相同毫秒内，序列号自增
            sequence = (sequence + 1) & MAX_SEQUENCE;
            //同一毫秒的序列数已经达到最大
            if (sequence == 0L) {
                currStmp = getNextMill();
            }
        } else {
            //不同毫秒内，序列号置为0
            sequence = 0L;
        }

        lastStmp = currStmp;

        return (currStmp - START_STMP) << TIMESTMP_LEFT //时间戳部分
                | datacenterId << DATACENTER_LEFT       //数据中心部分
                | machineId << MACHINE_LEFT             //机器标识部分
                | sequence;                             //序列号部分
    }

    private long getNextMill() {
        long mill = getNewstmp();
        while (mill <= lastStmp) {
            mill = getNewstmp();
        }
        return mill;
    }

    private long getNewstmp() {
        return System.currentTimeMillis();
    }

    public static void main(String[] args) {
        SnowFlake snowFlake = new SnowFlake(2, 3);

        for (int i = 0; i < (1 << 12); i++) {
            System.out.println(snowFlake.nextId());
        }

    }
}

基本上通过位移操作，将每段含义的数值，移到相应的位置上，如机器ID这里由数据中心+机器标识组成，所以，机器标识向左移12位，就是它的位置，数据中心的编号向左移17位，时间戳的值向左移22位，每部分占据自己的位置，各不干涉，由此组成一个完整的ID值。

这里就是snowflake最基础的实现原理，如果有些java基础知识不记得了建议查一下资料，如二进制-1的表示是0xffff(里面全是1)，<<表示左移操作，-1<<5等于-32，异或操作-1 ^ (-1 << 5)为31等等。

了解snowflake的基本实现原理，可以通过提前规划好机器标识来实现，但目前的分布式生产环境，借用了多种云计算、容器化技术，实例的个数随时有变化，还需要处理服务器实例时钟回拨的问题，固定规划ID然后通过配置来使用snowflake的场景可行性不高，一般是自动启停，增减机器，这样就需要对snowflake进行一些改造才能更好地应用到生产环境中。

百度uid-generator项目

UidGenerator项目基于snowflake原理实现，只是修改了机器ID部分的定义（实例重启的次数），并且64位bit的分配支持配置，官方提供的默认分配方式如下图：

Snowflake算法描述：指定机器 & 同一时刻 & 某一并发序列，是唯一的。据此可生成一个64 bits的唯一ID（long）。

  • sign(1bit) 固定1bit符号标识，即生成的UID为正数。
  • delta seconds (28 bits)
    当前时间，相对于时间基点"2016-05-20"的增量值，单位：秒，最多可支持约8.7年
  • worker id (22 bits) 机器id，最多可支持约420w次机器启动。内置实现为在启动时由数据库分配，默认分配策略为用后即弃，后续可提供复用策略。
  • sequence (13 bits) 每秒下的并发序列，13 bits可支持每秒8192个并发。

具体的实现有两种，一种是实时生成ID，另一种是预先生成ID方式

  1. DefaultUidGenerator
  • 启动时向数据库WORKER_NODE表插入当前实例的IP，Port等信息，再获取该数据的自增长ID作为机器ID部分。
    简易流程图如下：

  • 提供获取ID的方法，并且检测是否有时钟回拨，有回拨现象直接抛出异常，当前版本不支持时钟顺拨后漂移操作。简易流程图如下：

核心代码如下：

    /**
     * Get UID
     *
     * @return UID
     * @throws UidGenerateException in the case: Clock moved backwards; Exceeds the max timestamp
     */
    protected synchronized long nextId() {
        long currentSecond = getCurrentSecond();

        // Clock moved backwards, refuse to generate uid
        if (currentSecond < lastSecond) {
            long refusedSeconds = lastSecond - currentSecond;
            throw new UidGenerateException("Clock moved backwards. Refusing for %d seconds", refusedSeconds);
        }

        // At the same second, increase sequence
        if (currentSecond == lastSecond) {
            sequence = (sequence + 1) & bitsAllocator.getMaxSequence();
            // Exceed the max sequence, we wait the next second to generate uid
            if (sequence == 0) {
                currentSecond = getNextSecond(lastSecond);
            }

        // At the different second, sequence restart from zero
        } else {
            sequence = 0L;
        }

        lastSecond = currentSecond;

        // Allocate bits for UID
        return bitsAllocator.allocate(currentSecond - epochSeconds, workerId, sequence);
    }
  1. CachedUidGenerator

机器ID的获取方法与上一种相同，这种是预先生成一批ID，放在一个RingBuffer环形数组里，供客户端使用，当可用数据低于阀值时，再次调用批量生成方法，属于用空间换时间的做法，可以提高整个ID的吞吐量。

  • 与DefaultUidGenerator相比较，初始化时多了填充RingBuffer环形数组的逻辑，简单流程图如下：

核心代码：

/**
     * Initialize RingBuffer & RingBufferPaddingExecutor
     */
    private void initRingBuffer() {
        // initialize RingBuffer
        int bufferSize = ((int) bitsAllocator.getMaxSequence() + 1) << boostPower;
        this.ringBuffer = new RingBuffer(bufferSize, paddingFactor);
        LOGGER.info("Initialized ring buffer size:{}, paddingFactor:{}", bufferSize, paddingFactor);

        // initialize RingBufferPaddingExecutor
        boolean usingSchedule = (scheduleInterval != null);
        this.bufferPaddingExecutor = new BufferPaddingExecutor(ringBuffer, this::nextIdsForOneSecond, usingSchedule);
        if (usingSchedule) {
            bufferPaddingExecutor.setScheduleInterval(scheduleInterval);
        }

        LOGGER.info("Initialized BufferPaddingExecutor. Using schdule:{}, interval:{}", usingSchedule, scheduleInterval);

        // set rejected put/take handle policy
        this.ringBuffer.setBufferPaddingExecutor(bufferPaddingExecutor);
        if (rejectedPutBufferHandler != null) {
            this.ringBuffer.setRejectedPutHandler(rejectedPutBufferHandler);
        }
        if (rejectedTakeBufferHandler != null) {
            this.ringBuffer.setRejectedTakeHandler(rejectedTakeBufferHandler);
        }

        // fill in all slots of the RingBuffer
        bufferPaddingExecutor.paddingBuffer();

        // start buffer padding threads
        bufferPaddingExecutor.start();
    }
public synchronized boolean put(long uid) {
        long currentTail = tail.get();
        long currentCursor = cursor.get();

        // tail catches the cursor, means that you can‘t put any cause of RingBuffer is full
        long distance = currentTail - (currentCursor == START_POINT ? 0 : currentCursor);
        if (distance == bufferSize - 1) {
            rejectedPutHandler.rejectPutBuffer(this, uid);
            return false;
        }

        // 1. pre-check whether the flag is CAN_PUT_FLAG
        int nextTailIndex = calSlotIndex(currentTail + 1);
        if (flags[nextTailIndex].get() != CAN_PUT_FLAG) {
            rejectedPutHandler.rejectPutBuffer(this, uid);
            return false;
        }

        // 2. put UID in the next slot
        // 3. update next slot‘ flag to CAN_TAKE_FLAG
        // 4. publish tail with sequence increase by one
        slots[nextTailIndex] = uid;
        flags[nextTailIndex].set(CAN_TAKE_FLAG);
        tail.incrementAndGet();

        // The atomicity of operations above, guarantees by ‘synchronized‘. In another word,
        // the take operation can‘t consume the UID we just put, until the tail is published(tail.incrementAndGet())
        return true;
    }
  • ID获取逻辑，由于有RingBuffer这个缓冲数组存在，获取ID直接从RingBuffer取出即可，同时RingBuffer自身校验何时再触发重新批量生成即可，这里获取的ID值与DefaultUidGenerator的明显区别是，DefaultUidGenerator获取的ID，时间戳部分就是当前时间的，CachedUidGenerator里获取的是填充时的时间戳，并不是获取时的时间，不过关系不大，都是不重复的，一样用。简易流程图如下：

核心代码：

public long take() {
        // spin get next available cursor
        long currentCursor = cursor.get();
        long nextCursor = cursor.updateAndGet(old -> old == tail.get() ? old : old + 1);

        // check for safety consideration, it never occurs
        Assert.isTrue(nextCursor >= currentCursor, "Curosr can‘t move back");

        // trigger padding in an async-mode if reach the threshold
        long currentTail = tail.get();
        if (currentTail - nextCursor < paddingThreshold) {
            LOGGER.info("Reach the padding threshold:{}. tail:{}, cursor:{}, rest:{}", paddingThreshold, currentTail,
                    nextCursor, currentTail - nextCursor);
            bufferPaddingExecutor.asyncPadding();
        }

        // cursor catch the tail, means that there is no more available UID to take
        if (nextCursor == currentCursor) {
            rejectedTakeHandler.rejectTakeBuffer(this);
        }

        // 1. check next slot flag is CAN_TAKE_FLAG
        int nextCursorIndex = calSlotIndex(nextCursor);
        Assert.isTrue(flags[nextCursorIndex].get() == CAN_TAKE_FLAG, "Curosr not in can take status");

        // 2. get UID from next slot
        // 3. set next slot flag as CAN_PUT_FLAG.
        long uid = slots[nextCursorIndex];
        flags[nextCursorIndex].set(CAN_PUT_FLAG);

        // Note that: Step 2,3 can not swap. If we set flag before get value of slot, the producer may overwrite the
        // slot with a new UID, and this may cause the consumer take the UID twice after walk a round the ring
        return uid;
    }

另外有个细节可以了解一下，RingBuffer的数据都是使用数组来存储的，考虑CPU Cache的结构，tail和cursor变量如果直接用原生的AtomicLong类型，tail和cursor可能会缓存在同一个cacheLine中，多个线程读取该变量可能会引发CacheLine的RFO请求，反而影响性能,为了防止伪共享问题，特意填充了6个long类型的成员变量，加上long类型的value成员变量，刚好占满一个Cache Line（Java对象还有8byte的对象头），这个叫CacheLine补齐，有兴趣可以了解一下，源码如下：

public class PaddedAtomicLong extends AtomicLong {
    private static final long serialVersionUID = -3415778863941386253L;

    /** Padded 6 long (48 bytes) */
    public volatile long p1, p2, p3, p4, p5, p6 = 7L;

    /**
     * Constructors from {@link AtomicLong}
     */
    public PaddedAtomicLong() {
        super();
    }

    public PaddedAtomicLong(long initialValue) {
        super(initialValue);
    }

    /**
     * To prevent GC optimizations for cleaning unused padded references
     */
    public long sumPaddingToPreventOptimization() {
        return p1 + p2 + p3 + p4 + p5 + p6;
    }

}

以上是百度uid-generator项目的主要描述，我们可以发现，snowflake算法在落地时有一些变化，主要体现在机器ID的获取上，尤其是分布式集群环境下面，实例自动伸缩，docker容器化的一些技术，使得静态配置项目ID，实例ID可行性不高，所以这些转换为按启动次数来标识。

美团ecp-uid项目

在uidGenerator方面，美团的项目源码直接集成百度的源码，略微将一些Lambda表达式换成原生的java语法，例如：

// com.myzmds.ecp.core.uid.baidu.impl.CachedUidGenerator类的initRingBuffer()方法
// 百度源码
this.bufferPaddingExecutor = new BufferPaddingExecutor(ringBuffer, this::nextIdsForOneSecond, usingSchedule);

// 美团源码
this.bufferPaddingExecutor = new BufferPaddingExecutor(ringBuffer, new BufferedUidProvider() {
    @Override
    public List<Long> provide(long momentInSecond) {
        return nextIdsForOneSecond(momentInSecond);
    }
}, usingSchedule);

并且在机器ID生成方面，引入了Zookeeper，Redis这些组件，丰富了机器ID的生成和获取方式，实例编号可以存储起来反复使用，不再是数据库单调增长这一种了。

结束语

本篇简单介绍了snowflake算法的原理及落地过程中的改造，在此学习了优秀的开源代码，并挑出部分进行了简单的示例，美团的ecp-uid项目不但集成了百度现有的UidGenerator算法，原生的snowflake算法，还包含优秀的leaf segment算法，鉴于篇幅没有详尽描述。文章内有任何不正确或不详尽之处请留言指出，谢谢。

原文地址：https://www.cnblogs.com/cider/p/11776088.html

时间： 2024-10-21 11:31:15

彻底搞懂snowflake算法及百度美团的最佳实践的相关文章

一篇文章彻底搞懂snowflake算法及百度美团的最佳实践

写在前面的话 一提到分布式ID自动生成方案,大家肯定都非常熟悉,并且立即能说出自家拿手的几种方案,确实,ID作为系统数据的重要标识,重要性不言而喻,而各种方案也是历经多代优化,请允许我用这个视角对分布式ID自动生成方案进行分类: 实现方式 完全依赖数据源方式 ID的生成规则,读取控制完全由数据源控制,常见的如数据库的自增长ID,序列号等,或Redis的INCR/INCRBY原子操作产生顺序号等. 半依赖数据源方式 ID的生成规则,有部分生成因子需要由数据源(或配置信息)控制,如snowflake

一文搞懂 RSA 算法

一文搞懂 RSA 算法 地球上最重要的算法 如果没有 RSA 算法,现在的网络世界毫无安全可言,也不可能有现在的网上交易.上一篇文章 ssh 协议为什么安全 中的 ssh 协议也是基于 RSA 加密算法才能确保通讯是加密的,可靠的. 1976年以前,所有的加密方法都使用对称加密算法:加密和解密使用同一套规则.例如:甲使用密钥 A 加密,将密文传递给乙,乙仍使用密钥 A 解密.如果密钥 A 在甲传递给乙的过程中泄露,或者根据已知的几次密文和明文推导出密钥 A,则甲乙之间的通讯将毫无秘密. 1976

hiho一下 第二十九周 最小生成树三&#183;堆优化的Prim算法【14年寒假弄了好长时间没搞懂的prim优化：prim算法+堆优化 】

题目1 : 最小生成树三·堆优化的Prim算法 时间限制:10000ms 单点时限:1000ms 内存限制:256MB 描述 回到两个星期之前,在成功的使用Kruscal算法解决了问题之后,小Ho产生了一个疑问,究竟这样的算法在稀疏图上比Prim优化之处在哪里呢? 提示:没有无缘无故的优化! 输入 每个测试点(输入文件)有且仅有一组测试数据. 在一组测试数据中: 第1行为2个整数N.M,表示小Hi拥有的城市数量和小Hi筛选出路线的条数. 接下来的M行,每行描述一条路线,其中第i行为3个整数N1_

彻底搞懂最短路算法

转载自:戳 彻底弄懂最短路径问题 只想说:温故而知新,可以为师矣.我大二的<数据结构>是由申老师讲的,那时候不怎么明白,估计太理论化了(ps:或许是因为我睡觉了):今天把老王的2011年课件又看了一遍,给大二的孩子们又讲了一遍,随手谷歌了N多资料,算是彻底搞懂了最短路径问题.请读者尽情享用…… 我坚信:没有不好的学生,只有垃圾的教育.不过没有人理所当然的对你好,所以要学会感恩. 一.问题引入 问题:从某顶点出发,沿图的边到达另一顶点所经过的路径中,各边上权值之和最小的一条路径——最短路径.解决

搞懂分布式技术2：分布式一致性协议与Paxos，Raft算法

搞懂分布式技术2:分布式一致性协议与Paxos,Raft算法 2PC 由于BASE理论需要在一致性和可用性方面做出权衡,因此涌现了很多关于一致性的算法和协议.其中比较著名的有二阶提交协议(2 Phase Commitment Protocol),三阶提交协议(3 Phase Commitment Protocol)和Paxos算法. 本文要介绍的2PC协议,分为两个阶段提交一个事务.并通过协调者和各个参与者的配合,实现分布式一致性. 两个阶段事务提交协议,由协调者和参与者共同完成. 角色 XA概

彻底搞懂字符编码(unicode,mbcs,utf-8,utf-16,utf-32,big endian,little endian...)[转]

最近有一些朋友常问我一些乱码的问题,和他们交流过程中,发现这个编码的相关知识还真是杂乱不堪,不少人对一些知识理解似乎也有些偏差,网上百度, google的内容,也有不少以讹传讹,根本就是错误的(例如说 unicode编码是两个字节),各种软件让你选择编码的时候,常常是很长的一个选单,让用户不知道该如何选.基于这样的问题,我就写下我的理解吧,一方面帮助一些需要帮助的人纠正认识,一方面作为自己以后备查的资料. 1. ASCII(American Standard Code for Informati

准零基础搞懂FFT快速傅里叶变换及其实现程序（二）

上一篇文章我们了解了DFT的原理,FFT是基于DFT的更适合计算机运算的算法,本文我们就正式开始学习FFT的原理. 首先我么先来宏观的看一下FFT.如果我们把整个FFT的算法看成一个黑盒子的话,那么它的输入就是时间波形信号,比如声音波形(横轴为时间,纵轴为振幅).外什么FFT要比DFT速度更快呢?下面(图1)解释了FFT和DFT的(对于计算机的)算法复杂度 图1 从上面的数学表达式可以看出,一个1024采样点的FFT比DFT块了102.4倍.如果傅里叶变换的数量级更大,FFT的速度优势会更明显.

分布式唯一id：snowflake算法思考

匠心零度 转载请注明原创出处,谢谢! 缘起 为什么会突然谈到分布式唯一id呢?原因是最近在准备使用RocketMQ,看看官网介绍: 一句话,消息可能会重复,所以消费端需要做幂等.为什么消息会重复后续RocketMQ章节进行详细介绍,本节重点不在这里. 为了达到业务的幂等,必须要有这样一个id存在,需要满足下面几个条件: 同一业务场景要全局唯一. 该id必须是在消息的发送方进行产生发送到MQ. 消费端根据该id进行判断是否重复,确保幂等. 在那里产生,和消费端进行判断等和这个id没有关系,这个id

搞懂分布式技术13：缓存的那些事

搞懂分布式技术13:缓存的那些事 缓存和它的那些淘汰算法们 为什么我们需要缓存? 很久很久以前,在还没有缓存的时候--用户经常是去请求一个对象,而这个对象是从数据库去取,然后,这个对象变得越来越大,这个用户每次的请求时间也越来越长了,这也把数据库弄得很痛苦,他无时不刻不在工作.所以,这个事情就把用户和数据库弄得很生气,接着就有可能发生下面两件事情: 1.用户很烦,在抱怨,甚至不去用这个应用了(这是大多数情况下都会发生的) 2.数据库为打包回家,离开这个应用,然后,就出现了大麻烦(没地方去存储数据