关于分布式唯一ID的思考-雪花算法及美团Leaf方案详解

news2024/11/16 13:43:32

引言

首先，我们看一下日常开发中常见的雪花算法工具类：

  1. 引入hutool
<dependency>
    <groupId>cn.hutool</groupId>
    <artifactId>hutool-all</artifactId>
    <version>5.7.20</version>
</dependency>
  1. 工具类
import cn.hutool.core.lang.Singleton;
/**
 * 雪花算法工具类
 */
public class SnowFlakeUtil {
    private static final long START_STMP = 1420041600000L;
    private static final long SEQUENCE_BIT = 9L;
    private static final long MACHINE_BIT = 2L;
    private static final long DATACENTER_BIT = 2L;
    private static final long MAX_SEQUENCE = 511L;
    private static final long MAX_MACHINE_NUM = 3L;
    private static final long MAX_DATACENTER_NUM = 3L;
    private static final long MACHINE_LEFT = 9L;
    private static final long DATACENTER_LEFT = 11L;
    private static final long TIMESTMP_LEFT = 13L;
    private long datacenterId;
    private long machineId;
    private long sequence = 0L;
    private long lastStmp = -1L;

    public SnowFlakeUtil(long datacenterId, long machineId) {
        if (datacenterId <= 3L && datacenterId >= 0L) {
            if (machineId <= 3L && machineId >= 0L) {
                this.datacenterId = datacenterId;
                this.machineId = machineId;
            } else {
                throw new IllegalArgumentException("machineId can't be greater than MAX_MACHINE_NUM or less than 0");
            }
        } else {
            throw new IllegalArgumentException("datacenterId can't be greater than MAX_DATACENTER_NUM or less than 0");
        }
    }

    public synchronized long nextId() {
        long currStmp = this.getNewstmp();
        if (currStmp < this.lastStmp) {
            throw new RuntimeException("Clock moved backwards.  Refusing to generate id");
        } else {
            if (currStmp == this.lastStmp) {
                this.sequence = this.sequence + 1L & 511L;
                if (this.sequence == 0L) {
                    currStmp = this.getNextMill();
                }
            } else {
                this.sequence = 0L;
            }

            this.lastStmp = currStmp;
            return currStmp - 1420041600000L << 13 | this.datacenterId << 11 | this.machineId << 9 | this.sequence;
        }
    }

    private long getNextMill() {
        long mill;
        for(mill = this.getNewstmp(); mill <= this.lastStmp; mill = this.getNewstmp()) {
        }

        return mill;
    }

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

    public static Long getDefaultSnowFlakeId() {
        return ((SnowFlakeUtil)Singleton.get(SnowFlakeUtil.class, new Object[]{1L, 1L})).nextId();
    }

    public static void main(String[] args) {
        for(int i = 0; i < 10; ++i) {
            System.out.println(getDefaultSnowFlakeId());
            System.out.println(getDefaultSnowFlakeId().toString().length());
        }

    }
}

代码所涉及的具体含义，会在下文中逐一分析，那么这么一个看似复杂的雪花算法背后，是否还有着鲜为人知的问题呢，为什么美团会基于最基础的雪花算法开发自己的Leaf解决方案呢，那让我们带着疑惑继续往下看。

背景

日常开发中，我们需要对系统中的各种数据使用 ID 唯一表示，比如用户 ID 对应且仅对应一个人，商品 ID 对应且仅对应一件商品，订单 ID 对应且仅对应一个订单。我们现实生活中也有各种 ID，比如身份证 ID 对应且仅对应一个人，简单来说，ID 就是数据的唯一标识。
一般情况下，会使用数据库的自增主键作为数据ID，但是在大数量的情况下，我们往往会引入分布式、分库分表等手段来应对，很明显对数据分库分表后我们依然需要有一个唯一ID来标识一条数据或消息，数据库的自增ID已经无法满足需求。此时一个能够生成全局唯一ID的系统是非常必要的。概括下来，那业务系统对ID号的要求有哪些呢？

  • 全局唯一性：不能出现重复的ID号，既然是唯一标识，这是最基本的要求。
  • 趋势递增、单调递增：保证下一个ID一定大于上一个ID。
  • 信息安全：如果ID是连续的，恶意用户的扒取工作就非常容易做了，直接按照顺序下载指定URL即可；如果是订单号就更危险了，竞对可以直接知道我们一天的单量。所以在一些应用场景下，会需要ID无规则、不规则。

同时除了对ID号码自身的要求，业务还对ID号生成系统的可用性要求极高，想象一下，如果ID生成系统不稳定，大量依赖ID生成系统，比如订单生成等关键动作都无法执行。所以一个ID生成系统还需要做到平均延迟和TP999延迟都要尽可能低；可用性5个9；高QPS。

常见方法介绍

UUID

UUID(Universally Unique Identifier)的标准型式包含32个16进制数字，以连字号分为五段，形式为8-4-4-4-12的36个字符，示例：550e8400-e29b-41d4-a716-446655440000，到目前为止业界一共有5种方式生成UUID，详情见IETF发布的UUID规范 A Universally Unique IDentifier (UUID) URN Namespace。

  • 优点：性能非常高：本地生成，没有网络消耗。
  • 缺点：
    • 不易于存储：UUID太长，16字节128位，通常以36长度的字符串表示，很多场景不适用。
    • 信息不安全：基于MAC地址生成UUID的算法可能会造成MAC地址泄露，这个漏洞曾被用于寻找梅丽莎病毒的制作者位置。

ID作为主键时在特定的环境会存在一些问题，比如做DB主键的场景下，UUID就非常不适用：

  • MySQL官方有明确的建议主键要尽量越短越好[4]，36个字符长度的UUID不符合要求。
  • 对MySQL索引不利：如果作为数据库主键，在InnoDB引擎下，UUID的无序性可能会引起数据位置频繁变动，严重影响性能。在MySQL InnoDB引擎中使用的是聚集索引，由于多数RDBMS使用B-tree的数据结构来存储索引数据，在主键的选择上面我们应该尽量使用有序的主键保证写入性能。

可以直接使用jdk自带的UUID，原始生成的是带中划线的，如果不需要，可自行去除
在这里插入图片描述

雪花算法及其衍生

这种方案大致来说是一种以划分命名空间（UUID也算，由于比较常见，所以单独分析）来生成ID的一种算法，Snowflake 是 Twitter 开源的分布式 ID 生成算法。Snowflake 把64-bit分别划分成多段，分开来标示机器、时间等，比如在snowflake中的64-bit分别表示如下图所示：
在这里插入图片描述

第 0 位： 符号位（标识正负），始终为 0，没有用，不用管。
第 1~41 位 ：一共 41 位，用来表示时间戳，单位是毫秒，可以支撑 2 ^41 毫秒（约 69 年）
第 42~52 位 ：一共 10 位，一般来说，前 5 位表示机房 ID，后 5 位表示机器 ID（实际项目中可以根据实际情况调整），这样就可以区分不同集群/机房的节点，这样就可以表示32个IDC，每个IDC下可以有32台机器。
第 53~64 位 ：一共 12 位，用来表示序列号。 序列号为自增值，代表单台机器每毫秒能够产生的最大 ID 数(2^12 = 4096),也就是说单台机器每毫秒最多可以生成 4096 个 唯一 ID。
理论上snowflake方案的QPS约为409.6w/s，这种分配方式可以保证在任何一个IDC的任何一台机器在任意毫秒内生成的ID都是不同的。
有很多基于 Snowflake 算法的开源实现比如美团的 Leaf、百度的 UidGenerator(自 18 年后，UidGenerator 就基本没有再维护了，https://github.com/baidu/uid-generator/blob/master/README.zh_cn.md)，并且这些开源实现对原有的 Snowflake 算法进行了优化。在实际项目中，我们一般也会对 Snowflake 算法进行改造，最常见的就是在算法生成的 ID 中加入业务类型信息。

Snowflake 优缺点是：

  • 优点：
    • 毫秒数在高位，自增序列在低位，整个ID都是趋势递增的。
    • 不依赖数据库等第三方系统，以服务的方式部署，稳定性更高，生成ID的性能也是非常高的。
      可以根据自身业务特性分配bit位，非常灵活。
  • 缺点：
    • 强依赖机器时钟，如果机器上时钟回拨，会导致发号重复或者服务会处于不可用状态。

当然，在我们自己的项目如果不想自行实现唯一性ID，还可以利用外部中间件，比如Mongdb objectID，它也可以算作是和snowflake类似方法，通过“时间+机器码+pid+inc”共12个字节，通过4+3+2+3的方式最终标识成一个24长度的十六进制字符。
其次Seata内置了一个分布式UUID生成器，用于辅助生成全局事务ID和分支事务ID，我们同样可以拿来使用，完整类名为： io.seata.common.util.IdWorker

数据库生成

MYSQL

以MySQL举例

  1. 创建一个数据库表。
CREATE TABLE `sequence_id` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `stub` char(10) NOT NULL DEFAULT '',
  PRIMARY KEY (`id`),
  UNIQUE KEY `stub` (`stub`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

stub 字段无意义，只是为了占位，便于我们插入或者修改数据。并且，给 stub 字段创建了唯一索引，保证其唯一性。

  1. 通过 replace into 来插入数据。
BEGIN;
REPLACE INTO sequence_id (stub) VALUES ('stub');
SELECT LAST_INSERT_ID();
COMMIT;

插入数据这里，我们没有使用 insert into 而是使用 replace into 来插入数据。replace是insert的增强版，replace into 首先尝试插入数据到表中，

  • 如果发现表中已经有此行数据（根据主键或者唯一索引判断）则先删除此行数据，然后插入新的数据。
  • 否则，直接插入新数据。

数据库方案的优缺点如下：

  • 优点：
    • 非常简单，利用现有数据库系统的功能实现，成本小，有DBA专业维护。ID号单调自增，存储消耗空间小。
  • 缺点：
    • 支持的并发量不大、存在数据库单点问题（可以使用数据库集群解决，不过增加了复杂度）、ID 没有具体业务含义、安全问题（比如根据订单 ID 的递增规律就能推算出每天的订单量 ）、每次获取 ID 都要访问一次数据库（增加了对数据库的压力，获取速度也慢）

对于MySQL性能问题，可用如下方案解决：在分布式系统中我们可以多部署几台机器，每台机器设置不同的初始值，且步长和机器数相等。比如有两台机器。设置步长step为2，TicketServer1的初始值为1（1，3，5，7，9，11…）、TicketServer2的初始值为2（2，4，6，8，10…）。这是Flickr（雅虎旗下图片分享网站）团队在2010年撰文介绍的一种主键生成策略（Ticket Servers: Distributed Unique Primary Keys on the Cheap ）。为了实现上述方案分别设置两台机器对应的参数，TicketServer1从1开始发号，TicketServer2从2开始发号，两台机器每次发号之后都递增2。
假设我们要部署N台机器，步长需设置为N，每台的初始值依次为0,1,2…N-1。
这种架构貌似能够满足性能的需求，但有以下几个缺点：
系统水平扩展比较困难，比如定义好了步长和机器台数之后，如果要添加机器该怎么做？假设现在只有一台机器发号是1,2,3,4,5（步长是1），这个时候需要扩容机器一台。可以这样做：把第二台机器的初始值设置得比第一台超过很多，比如140（假设在扩容时间之内第一台不可能发到140），同时设置步长为2，那么这台机器下发的号码都是140以后的偶数。然后摘掉第一台，把ID值保留为奇数，比如7，然后修改第一台的步长为2。让它符合我们定义的号段标准，对于这个例子来说就是让第一台以后只能产生奇数。扩容方案看起来复杂吗？貌似还好，现在想象一下如果我们线上有100台机器，这个时候要扩容该怎么做？简直是噩梦。所以系统水平扩展方案复杂难以实现。
ID没有了单调递增的特性，只能趋势递增，这个缺点对于一般业务需求不是很重要，可以容忍。
数据库压力还是很大，每次获取ID都得读写一次数据库，只能靠堆机器来提高性能。

Redis

通过 Redis 的 incr 命令即可实现对 id 原子顺序递增，例如：

127.0.0.1:6379> incr sequence_id_biz_type
(integer) 2

为了提高可用性和并发，我们可以使用 Redis Cluster。
除了高可用和并发之外，我们知道 Redis 基于内存，我们需要持久化数据，避免重启机器或者机器故障后数据丢失。很明显，Redis方案性能很好并且生成的 ID 是有序递增的。
不过，我们也知道，即使Redis 开启了持久化，不管是快照（snapshotting，RDB）、只追加文件（append-only file, AOF）还是 RDB 和 AOF 的混合持久化依然存在着丢失数据的可能，那就意味着产生的ID存在着重复的概率。

分布式ID微服务

从上面的分析可以看出，每种方案都各有优劣，在我们的商城系统中则基于美团的Leaf实现了自己的分布式ID微服务。我们先来看看美团Leaf方案。

美团Leaf方案实现

Leaf这个名字是来自德国哲学家、数学家莱布尼茨的一句话： There are no two identical leaves in the world（“世界上没有两片相同的树叶”）
Leaf分别在MySQL和雪花上做了相应的优化，实现了Leaf-segment和Leaf-snowflake方案。

Leaf-segment数据库方案

Leaf-segment方案，在使用数据库的方案上，做了如下改变：
原MySQL方案每次获取ID都得读写一次数据库，造成数据库压力大。改为批量获取，每次获取一个segment(step决定大小)号段的值。用完之后再去数据库获取新的号段，可以大大的减轻数据库的压力。
各个业务不同的发号需求用biz_tag字段来区分，每个biz-tag的ID获取相互隔离，互不影响。如果以后有性能需求需要对数据库扩容，不需要上述描述的复杂的扩容操作，只需要对biz_tag分库分表就行。
数据库表设计如下：
在这里插入图片描述

重要字段说明：biz_tag用来区分业务，max_id表示该biz_tag目前所被分配的ID号段的最大值，step表示每次分配的号段长度。原来获取ID每次都需要写数据库，现在只需要把step设置得足够大，比如1000。那么只有当1000个号被消耗完了之后才会去重新读写一次数据库。读写数据库的频率从1减小到了1/step。
例如现在有3台机器，每台机器各取1000个，很明显在第一台Leaf机器上是11000的号段，当这个号段用完时，会去加载另一个长度为step=1000的号段，假设另外两台号段都没有更新，这个时候第一台机器新加载的号段就应该是30014000。同时数据库对应的biz_tag这条数据的max_id会从3000被更新成4000，更新号段的SQL语句如下：

Begin
UPDATE table SET max_id=max_id+step WHERE biz_tag=xxx
SELECT tag, max_id, step FROM table WHERE biz_tag=xxx
Commit

这种模式有以下优缺点：

  • 优点：
    • Leaf服务可以很方便的线性扩展，性能完全能够支撑大多数业务场景。
    • ID号码是趋势递增的8byte的64位数字，满足上述数据库存储的主键要求。
    • 容灾性高：Leaf服务内部有号段缓存，即使DB宕机，短时间内Leaf仍能正常对外提供服务。
    • 可以自定义max_id的大小，非常方便业务从原有的ID方式上迁移过来。
  • 缺点：
    • ID号码不够随机，能够泄露发号数量的信息，不太安全。
    • TP999数据波动大，当号段使用完之后还是会在获取新号段时在更新数据库的I/O依然会存在着等待，tg999数据会出现偶尔的尖刺。
    • DB宕机会造成整个系统不可用。

双buffer优化

对于第二个缺点，Leaf-segment做了一些优化，简单的说就是：
Leaf 取号段的时机是在号段消耗完的时候进行的，也就意味着号段临界点的ID下发时间取决于下一次从DB取回号段的时间，并且在这期间进来的请求也会因为DB号段没有取回来，导致线程阻塞。如果请求DB的网络和DB的性能稳定，这种情况对系统的影响是不大的，但是假如取DB的时候网络发生抖动，或者DB发生慢查询就会导致整个系统的响应时间变慢。
为此，希望DB取号段的过程能够做到无阻塞，不需要在DB取号段的时候阻塞请求线程，即当号段消费到某个点时就异步的把下一个号段加载到内存中。而不需要等到号段用尽的时候才去更新号段。这样做就可以很大程度上的降低系统的TP999指标。
采用双buffer的方式，Leaf服务内部有两个号段缓存区segment。当前号段已下发10%时，如果下一个号段未更新，则另启一个更新线程去更新下一个号段。当前号段全部下发完后，如果下个号段准备好了则切换到下个号段为当前segment接着下发，循环往复。
通常推荐segment长度设置为服务高峰期发号QPS的600倍（10分钟），这样即使DB宕机，Leaf仍能持续发号10-20分钟不受影响。
每次请求来临时都会判断下个号段的状态，从而更新此号段，所以偶尔的网络抖动不会影响下个号段的更新。

Leaf高可用容灾

对于第三点“DB可用性”问题，可以采用一主两从的方式，同时分机房部署，Master和Slave之间采用半同步方式同步数据。美团内部使用了奇虎360的Atlas数据库中间件（已开源，改名为DBProxy）做主从切换。当然这种方案在一些情况会退化成异步模式，甚至在非常极端情况下仍然会造成数据不一致的情况，但是出现的概率非常小。如果要保证100%的数据强一致，可以选择使用“类Paxos算法”实现的强一致MySQL方案，如MySQL 5.7中的MySQL Group Replication。但是运维成本和精力都会相应的增加，根据实际情况选型即可。
Leaf-snowflake方案
Leaf-segment方案可以生成趋势递增的ID，同时ID号是可计算的，不适用于订单ID生成场景，比如竞对在两天中午12点分别下单，通过订单id号相减就能大致计算出公司一天的订单量，这个是不能忍受的。面对这一问题，美团提供了 Leaf-snowflake方案。
Leaf-snowflake方案完全沿用snowflake方案的bit位设计，即是“1+41+10+12”的方式组装ID号。对于workerID的分配，当服务集群数量较小的情况下，完全可以手动配置。Leaf服务规模较大，动手配置成本太高。所以使用Zookeeper持久顺序节点的特性自动对snowflake节点配置wokerID。Leaf-snowflake是按照下面几个步骤启动的：
启动Leaf-snowflake服务，连接Zookeeper，在leaf_forever父节点下检查自己是否已经注册过（是否有该顺序子节点）。
如果有注册过直接取回自己的workerID（zk顺序节点生成的int类型ID号），启动服务。
如果没有注册过，就在该父节点下面创建一个持久顺序节点，创建成功后取回顺序号当做自己的workerID号，启动服务。

弱依赖ZooKeeper

除了每次会去ZK拿数据以外，也会在本机文件系统上缓存一个workerID文件。当ZooKeeper出现问题，恰好机器出现问题需要重启时，能保证服务能够正常启动。这样做到了对三方组件的弱依赖。

解决时钟问题

因为这种方案依赖时间，如果机器的时钟发生了回拨，那么就会有可能生成重复的ID号，需要解决时钟回退的问题。
首先在启动时，服务会进行检查：

  1. 新节点通过检查综合对比其余Leaf节点的系统时间来判断自身系统时间是否准确，具体做法是取所有运行中的Leaf-snowflake节点的服务IP：Port，然后通过RPC请求得到所有节点的系统时间，计算sum(time)/nodeSize，然后看本机时间与这个平均值是否在阈值之内来确定当前系统时间是否准确，准确正常启动服务，不准确认为本机系统时间发生大步长偏移，启动失败并报警。
  2. 在ZooKeeper 中登记过的老节点，同样会比较自身系统时间和ZooKeeper 上本节点曾经的记录时间以及所有运行中的Leaf-snowflake节点的时间，不准确同样启动失败并报警。

另外，在运行过程中，每隔一段时间节点都会上报自身系统时间写入ZooKeeper 。

在服务运行过程中，机器的NTP同步也会造成秒级别的回退，由于强依赖时钟，对时间的要求比较敏感，美团建议有三种解决方案，一是可以直接关闭NTP同步；二是在时钟回拨的时候直接不提供服务直接返回ERROR_CODE，等时钟追上即可，三是做一层重试，然后上报报警系统，更或者是发现有时钟回拨之后自动摘除本身节点并报警，代码如下：
在这里插入图片描述

从美团的实际运行情况来看，在2017年闰秒出现那一次出现过部分机器回拨，由于Leaf-snowflake的策略保证，成功避免了对业务造成的影响。

美团Leaf现状

Leaf在美团点评公司内部服务包含金融、支付交易、餐饮、外卖、酒店旅游、猫眼电影等众多业务线。目前Leaf的性能在4C8G的机器上QPS能压测到近5万/s，TP999 1ms，已经能够满足大部分的业务的需求。每天提供亿数量级的调用量。

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.coloradmin.cn/o/420042.html

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈，一经查实，立即删除！

相关文章

推荐10个AI学习、工作用的有趣网站

推荐10个AI学习、工作用的有趣网站

来源&#xff1a;towardsai 作者&#xff1a;学姐 编辑&#xff1a;学姐 1.VERSE BY VERSE 帮你写诗 https://sites.research.google/versebyverse/ 2.Let’s Enhance 照片放大增强 https://letsenhance.io/ 让扭曲和模糊的照片变得漂亮&#xff0c;用这个网站实现增强&am…
阅读更多...
A01-固件库开发模板

A01-固件库开发模板

&#x1f9d1;‍&#x1f393; 个人主页&#xff1a;Silence Lamb &#x1f4d6; 本章内容&#xff1a;【固件库开发模板】 Silence-STM v1.0.0 基于固件库开发模板 一、前提准备 &#x1f680;从ST官网获取stm32f103标准例程固件库&#x1f680; 参考文档 1.1&#x1f333;…
阅读更多...
[HAOI2011]Problem b（莫比乌斯反演）

[HAOI2011]Problem b（莫比乌斯反演）

[HAOI2011]Problem b 题目链接&#xff1a;https://www.luogu.com.cn/problem/P2522 题目描述 对于给出的 nnn 个询问&#xff0c;每次求有多少个数对 (x,y)(x,y)(x,y)&#xff0c;满足 a≤x≤ba \le x \le ba≤x≤b&#xff0c;c≤y≤dc \le y \le dc≤y≤d&#xff0c;且 …
阅读更多...
【CE】Mac下的CE教程Tutorial：进阶篇（第7关：代码注入）

【CE】Mac下的CE教程Tutorial：进阶篇（第7关：代码注入）

▒ 目录 ▒&#x1f6eb; 导读开发环境1️⃣ 第7关&#xff1a;代码注入翻译非代码注入完成任务代码注入完成任务&#x1f6ec; 文章小结&#x1f4d6; 参考资料&#x1f6eb; 导读 开发环境 版本号描述文章日期2023-03-操作系统MacOS Big Sur 11.5Cheat Engine7.4.3 1️⃣ 第…
阅读更多...
PADS生成SMT坐标文件

PADS生成SMT坐标文件

做SMT时&#xff0c;除了“gerber文件”外&#xff0c;还要提供 “BOM文件” 和 “坐标文件”。 “gerber文件” 和 “BOM文件”&#xff0c;前面都有介绍过了&#xff0c;现在详细说一下生成“坐标文件”的方法。 贴片厂家提供了操作教程&#xff0c;如下&#xff1a; 所以&a…
阅读更多...
Leetcode力扣秋招刷题路-0289

Leetcode力扣秋招刷题路-0289

从0开始的秋招刷题路&#xff0c;记录下所刷每道题的题解&#xff0c;帮助自己回顾总结 289. 生命游戏 根据 百度百科 &#xff0c; 生命游戏 &#xff0c;简称为 生命 &#xff0c;是英国数学家约翰何顿康威在 1970 年发明的细胞自动机。 给定一个包含 m n 个格子的面板&a…
阅读更多...
应届生，实力已超6年，太卷了！

应届生，实力已超6年，太卷了！

你好&#xff0c;我是田哥今晚上&#xff0c;给一位朋友做模拟面试&#xff0c;原本说好的90分钟左右&#xff0c;结果整了2个多小时。很多人估计也很好奇&#xff0c;我们这两个多小时聊聊什么&#xff0c;下面我给大致总结一下&#xff1a;面试技巧面试中&#xff0c;我们回答…
阅读更多...
企业招采系统实现方案（SRM系统）

企业招采系统实现方案（SRM系统）

企事业数字化转型专家&#xff0c;提供各类应用解决方案。您身边的赋能小助手&#xff01; 文章目录前言一、当下采购的痛点二、解决方案-供应商管理1.供应商管理三、解决方案-企业询价、供应商报价管理四、解决方案-采购订单五、送货、到货、订单管理总结前言 随着各类产业链…
阅读更多...
JS实用技巧断点调试详解

JS实用技巧断点调试详解

调试能力是一个程序员的生存根本&#xff0c;可是很多初学者却忽视调试。今天我们就来讨究一下JS的调试技巧。本文章将会详细列举JS相关的各种实用调试技巧。 如果您是JS的初学者&#xff0c;那么这篇文章将对您有很大的帮助。为什么要调试&#xff1f;程序就是函数堆砌起来的…
阅读更多...
智驾升级！ADB+AFS「起势」

智驾升级！ADB+AFS「起势」

目前&#xff0c;乘用车前大灯已经完成从传统卤素、氙气到LED的转型升级&#xff0c;高工智能汽车研究院监测数据显示&#xff0c;2022年中国市场&#xff08;不含进出口&#xff09;乘用车前装标配LED前大灯搭载率达到75.99%&#xff0c;同比2021年提高约7个百分点。 而相比而…
阅读更多...
2023.4.16 第四十九次周报-2

2023.4.16 第四十九次周报-2

目录 前言 文献阅读 :基于动态分类的长短期记忆网络模型&#xff0c;用于不同气候区日流量预报 背景 主要贡献 思路 动态分类 &#xff08;DC&#xff09; 方法 DC-LSTM 和 DC-B-LSTM 模型 Box -Cox数据转换 模型性能评估指标 克里金插值源码总结 第一部分 第二部分…
阅读更多...
网络连通性测试-防甩锅套路

网络连通性测试-防甩锅套路

一、前言 为什么要写这个东西呢&#xff1f;怎么涉及到甩锅呢&#xff1f;说白了就是在各种对接过程中&#xff0c;总会遇到一些喜欢甩锅的人&#xff0c;说是你的问题&#xff0c;什么网络没毛病&#xff0c;是你的接口什么的不对&#xff0c;总之就是你的问题~ 这时候什么最…
阅读更多...
游戏解密之常见网络游戏同步方式分析

游戏解密之常见网络游戏同步方式分析

一、为什么需要有同步呢&#xff1f; 同步机制是用来维护游戏的一致性&#xff0c;通俗的说就是虚拟世界中的事实&#xff1b;比如在CF中&#xff0c;大家的PING都很高&#xff0c;A和B两个玩家同时发现了对方&#xff0c;并向对方开火&#xff0c;如果没有很好的同步机制&…
阅读更多...
50 Projects 50 Days - Rotating Navigation Animation 学习记录

50 Projects 50 Days - Rotating Navigation Animation 学习记录

项目地址 Rotating Navigation Animation 展示效果 Rotating Navigation Animation 实现思路 结构主要分为两部分&#xff0c;绕左上角旋转的部分&#xff1a;包括按钮圆盘和内容区&#xff0c;以及左下角移出的导航栏部分。 整个界面只在左上角圆盘的按钮点击时发生改变…
阅读更多...
Sarsa VS Q-Learning

Sarsa VS Q-Learning

前言 1.如何计算价值函数&#xff1f; 为了使模型训练的最好&#xff0c;学习到更多有用的知识即完成任务的最好策略。对策略好坏的评价标准自然是得到最多最好的奖励&#xff0c;那么如何找到最好的最好的奖励&#xff0c;即如何得到最好的价值函数&#xff1f; 首先对于在状…
阅读更多...
Leetcode.2280 表示一个折线图的最少线段数

Leetcode.2280 表示一个折线图的最少线段数

题目链接 Leetcode.2280 表示一个折线图的最少线段数 Rating &#xff1a; 1681 题目描述 给你一个二维整数数组 stockPrices&#xff0c;其中 stockPrices[i] [dayi, pricei]表示股票在 dayi的价格为 pricei 。折线图 是一个二维平面上的若干个点组成的图&#xff0c;横坐标…
阅读更多...
ROS学习——艰辛的环境安装之路一Ubuntu

ROS学习——艰辛的环境安装之路一Ubuntu

文章目录Ubuntu安装和下载页面设置安装Vmware Tools安装VSCODE用几个常用命令简单熟悉下UbuntuUbuntu 安装和下载 Ubuntu的安装和下载 看这个链接 Ubuntu安装和下载1 或者这个链接 Ubuntu安装和下载2 页面设置 安装Vmware Tools 看这个链接 VMware Tools的介绍和安装 安装…
阅读更多...
算法训练第五十五天 | 392.判断子序列、115.不同的子序列

算法训练第五十五天 | 392.判断子序列、115.不同的子序列

动态规划part15392.判断子序列题目描述思路总结115.不同的子序列题目描述思路392.判断子序列 题目链接&#xff1a;392.判断子序列 参考&#xff1a;https://programmercarl.com/0392.%E5%88%A4%E6%96%AD%E5%AD%90%E5%BA%8F%E5%88%97.html 题目描述 给定字符串 s 和 t &…
阅读更多...
RabbitMQ 基础篇 | 黑马

RabbitMQ 基础篇 | 黑马

目录 一、RabbitMQ简介 1、AMQP 2、基本概念 3、工作模式 4、JMS 5、小结 二、快速入门 简单模式 生产者 消费者 三、工作模式 1、Work queues 工作队列模式 2、Pub/Sub 订阅模式 3、Routing 路由模式 4、Topics 通配符模式 四、SpringBoot整合RabbitMQ 1、生产…
阅读更多...
ESP32设备驱动-BME680环境传感器驱动

ESP32设备驱动-BME680环境传感器驱动

BME680环境传感器驱动 文章目录 BME680环境传感器驱动1、BME680介绍2、硬件准备3、软件准备4、驱动实现1、BME680介绍 BME680 是一款集成环境传感器，专为尺寸和低功耗是关键要求的移动应用和可穿戴设备而开发。 BME680 扩展了 Bosch Sensortec 现有的环境传感器系列，首次集成…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023