分布式系统全局唯一ID实现方案

已于 2024-09-25 15:05:40 修改
阅读量1k 收藏 20
点赞数 8
文章标签： java 分布式 微服务
于 2024-09-25 15:01:59 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/aRtHuR1207/article/details/142523929
版权

文章目录

实现分布式系统中的全局唯一标识符（GUID）

在构建一个分布式系统时，能够生成全局唯一标识符（GUID）是一个核心需求。本文档旨在综述当前市场上流行的分布式ID生成策略，并为本系统的实施提供一个推荐方案。分布式ID生成方法主要分为两大类：基于数据库的解决方案和基于算法的解决方案。

基于数据库的解决方案

基于数据库的方法依赖于传统的数据库系统，例如MySQL或Redis，来确保ID的唯一性和顺序性。通过数据库的原子性操作和内置功能，这些方案能够提供稳定和可靠的ID生成服务。

MySQL 实现【不推荐】

使用自增主键或其他数据库序列功能，MySQL可以提供简单且直接的方法来生成唯一ID。然而，它存在着单点故障和性能瓶颈的问题，且在水平扩展方面存在局限性。

以MySQL举例，利用给字段设置auto_increment_increment和auto_increment_offset来保证ID自增。

  • auto_increment_offset：表示自增长字段从那个数开始，他的取值范围是1 … 65535。
  • auto_increment_increment：表示自增长字段每次递增的量，其默认值是1，取值范围是1 … 65535。

总结：由于它强依赖DB，当DB异常时整个系统不可用。虽然配置主从复制可以尽可能的增加可用性，但是数据一致性在特殊情况下难以保证。主从切换时的不一致可能会导致重复发号。还有就是ID发号性能瓶颈限制在单台MySQL的读写性能。本系统不推荐此方案。

Redis 实现【不推荐】

Redis利用其原子操作来生成递增的数字作为唯一ID。它比传统数据库方案拥有更高的性能和吞吐量，但在分布式系统中需要处理复制和持久性的问题，以保证ID的唯一性和持久性。

  • INCR 和 INCRBY ：自增原子命令，实现分布式唯一ID。由于Redis自身的单线程的特点所以能保证生成的 ID 肯定是唯一有序的。
  • 单点故障：单机存在性能瓶颈，无法满足高并发的业务需求，所以可以采用集群的方式来实现。集群的方式又会涉及到和数据库集群同样的问题，所以也需要设置分段和步长来实现。

总结：一洽架构中使用此方案生成消息的mid，本系统使用分布式系统全局唯一ID，主要是用于在通信框架中给每条消息附上唯一编码，考虑到Redis解决方案可能存在的单点故障问题以及在高并发环境下的性能瓶颈以及对Redis服务的强依赖性等因素，不推荐此方案。

基于算法的解决方案

算法型方法通过数学计算来确保生成的ID全局唯一，其中最著名的是Snowflake算法。

UUID 算法【不推荐】

通用唯一识别码的缩写。UUID是由一组32位数的16进制数字所构成，所以UUID理论上的总数为 1632=2128，约等于 3.4 x 10^38。也就是说若每纳秒产生1兆个UUID，要花100亿年才会将所有UUID用完。

目前UUID的产生方式有5种版本，每个版本的算法不同，应用范围也不同。

  • 基于时间的UUID - 版本1： 这个一般是通过当前时间，随机数，和本地Mac地址来计算出来，可以通过 org.apache.logging.log4j.core.util包中的 UuidUtil.getTimeBasedUuid()来使用或者其他包中工具。由于使用了MAC地址，因此能够确保唯一性，但是同时也暴露了MAC地址，私密性不够好。
  • DCE安全的UUID - 版本2 DCE（Distributed Computing Environment）安全的UUID和基于时间的UUID算法相同，但会把时间戳的前4位置换为POSIX的UID或GID。这个版本的UUID在实际中较少用到。
  • 基于名字的UUID（MD5）- 版本3 基于名字的UUID通过计算名字和名字空间的MD5散列值得到。这个版本的UUID保证了：相同名字空间中不同名字生成的UUID的唯一性；不同名字空间中的UUID的唯一性；相同名字空间中相同名字的UUID重复生成是相同的。
  • 随机UUID - 版本4 根据随机数，或者伪随机数生成UUID。这种UUID产生重复的概率是可以计算出来的，但是重复的可能性可以忽略不计，因此该版本也是被经常使用的版本。JDK中使用的就是这个版本。
  • 基于名字的UUID（SHA1） - 版本5 和基于名字的UUID算法类似，只是散列值计算使用SHA1（Secure Hash Algorithm 1）算法。

虽然 UUID 生成方便，本地生成没有网络消耗，但是使用起来也有一些缺点

  • 不易于存储：UUID太长，16字节128位，通常以36长度的字符串表示，很多场景不适用。
  • 信息不安全：基于MAC地址生成UUID的算法可能会造成MAC地址泄露，暴露使用者的位置。
  • 对MySQL索引不利：如果作为数据库主键，在InnoDB引擎下，UUID的无序性可能会引起数据位置频繁变动，严重影响性能，可以查阅 Mysql 索引原理 B+树的知识。

总结：鉴于UUID的无序性，无法满足根据消息ID排序的需求，本系统不推荐此方案。

Snowflake 算法【考虑】

Twitter开发的Snowflake算法通过结合时间戳、工作机器ID和序列号生成唯一ID。它不依赖于外部存储系统，从而减少了系统依赖并提高了性能。尽管如此，它需要仔细管理时间同步和工作机器ID分配，以避免ID冲突。

  • 第1位占用1bit，其值始终是0，可看做是符号位不使用。
  • 第2位开始的41位是时间戳，41-bit位可表示2^41个数，每个数代表毫秒，那么雪花算法可用的时间年限是(1L<<41)/(1000L360024*365)=69 年的时间。
  • 中间的10-bit位可表示机器数，即2^10 = 1024台机器，但是一般情况下我们不会部署这么台机器。如果我们对IDC（互联网数据中心）有需求，还可以将 10-bit 分 5-bit 给 IDC，分5-bit给工作机器。这样就可以表示32个IDC，每个IDC下可以有32台机器，具体的划分可以根据自身需求定义。
  • 最后12-bit位是自增序列，可表示2^12 = 4096个数。

JAVA源码：

package com.rainbowred.commons.services.sequence;

import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.stereotype.Service;

import java.lang.management.ManagementFactory;
import java.net.InetAddress;
import java.net.NetworkInterface;
import java.util.Enumeration;
import java.util.concurrent.ThreadLocalRandom;
import java.util.regex.Pattern;

/**
 * 基于Twitter的Snowflake算法实现分布式高效有序ID生产黑科技(sequence)——升级版Snowflake
 *
 * <br>
 * SnowFlake的结构如下(每部分用-分开):<br>
 * <br>
 * 0 - 0000000000 0000000000 0000000000 0000000000 0 - 00000 - 00000 - 000000000000 <br>
 * <br>
 * 1位标识，由于long基本类型在Java中是带符号的，最高位是符号位，正数是0，负数是1，所以id一般是正数，最高位是0<br>
 * <br>
 * 41位时间截(毫秒级)，注意，41位时间截不是存储当前时间的时间截，而是存储时间截的差值（当前时间截 - 开始时间截)
 * 得到的值），这里的的开始时间截，一般是我们的id生成器开始使用的时间，由我们程序来指定的（如下START_TIME属性）。41位的时间截，可以使用69年，年T = (1L << 41) / (1000L * 60 * 60 * 24 * 365) = 69<br>
 * <br>
 * 10位的数据机器位，可以部署在1024个节点，包括5位dataCenterId和5位workerId<br>
 * <br>
 * 12位序列，毫秒内的计数，12位的计数顺序号支持每个节点每毫秒(同一机器，同一时间截)产生4096个ID序号<br>
 * <br>
 * <br>
 * 加起来刚好64位，为一个Long型。<br>
 * SnowFlake的优点是，整体上按照时间自增排序，并且整个分布式系统内不会产生ID碰撞(由数据中心ID和机器ID作区分)，并且效率较高，经测试，SnowFlake每秒能够产生26万ID左右。
 * <p>
 * <p>
 * 特性：
 * 1.支持自定义允许时间回拨的范围<p>
 * 2.解决跨毫秒起始值每次为0开始的情况（避免末尾必定为偶数，而不便于取余使用问题）<p>
 * 3.解决高并发场景中获取时间戳性能问题<p>
 * 4.支撑根据IP末尾数据作为workerId
 * 5.时间回拨方案思考：1024个节点中分配10个点作为时间回拨序号（连续10次时间回拨的概率较小）
 * <p>
 * 常见问题:
 * 1.时间回拨问题
 * 2.机器id的分配和回收问题
 * 3.机器id的上限问题
 *
 * @author wangyitao
 * @date 2024/1/2.
 */
@Service
@Slf4j
public class SequenceService {

    /**
     * 时间起始标记点，作为基准，一般取系统的最近时间（一旦确定不能变动）
     */
    private final long twepoch;

    /**
     * 5位的机房id
     */
    private final long datacenterIdBits;

    /**
     * 5位的机器id
     */
    private final long workerIdBits;

    /**
     * 每毫秒内产生的id数: 2的12次方个
     */
    private final long sequenceBits = 12L;

    protected final long maxDatacenterId;

    protected final long maxWorkerId;

    private final long workerIdShift;

    private final long datacenterIdShift;

    /**
     * 时间戳左移动位
     */
    private final long timestampLeftShift;

    private final long sequenceMask;

    /**
     * 所属机房id
     */
    private final long datacenterId;

    /**
     * 所属机器id
     */
    private final long workerId;

    /**
     * 并发控制序列
     */
    private long sequence = 0L;

    /**
     * 上次生产 ID 时间戳
     */
    private long lastTimestamp = -1L;

    private static volatile InetAddress LOCAL_ADDRESS = null;
    private static final Pattern IP_PATTERN = Pattern.compile("\\d{1,3}(\\.\\d{1,3}){3,5}$");

    public SequenceService(@Value("${sequence.datacenter-id-bits}") long datacenterIdBits,
                           @Value("${sequence.worker-id-bits}") long workerIdBits) {
        this.twepoch = SystemClock.INSTANCE.currentTimeMillis();

        this.datacenterIdBits = datacenterIdBits;
        this.workerIdBits = workerIdBits;

        this.maxDatacenterId = -1L ^ (-1L << this.datacenterIdBits);
        this.maxWorkerId = -1L ^ (-1L << this.workerIdBits);
        this.workerIdShift = this.sequenceBits;
        this.datacenterIdShift = this.sequenceBits + this.workerIdBits;
        this.timestampLeftShift = this.sequenceBits + this.workerIdBits + this.datacenterIdBits;
        this.sequenceMask = -1L ^ (-1L << this.sequenceBits);

        this.datacenterId = getDatacenterId();
        this.workerId = getMaxWorkerId(this.datacenterId);
    }

    /**
     * 基于网卡MAC地址计算余数作为数据中心
     * <p>
     * 可自定扩展
     */
    protected long getDatacenterId() {
        long id = 0L;
        try {
            NetworkInterface network = NetworkInterface.getByInetAddress(getLocalAddress());
            if (null == network) {
                id = 1L;
            } else {
                byte[] mac = network.getHardwareAddress();
                if (null != mac) {
                    id = ((0x000000FF & (long) mac[mac.length - 2]) | (0x0000FF00 & (((long) mac[mac.length - 1]) << 8))) >> 6;
                    id = id % (maxDatacenterId + 1);
                }
            }
        } catch (Exception e) {
            log.warn(" getDatacenterId: " + e.getMessage());
        }

        return id;
    }

    /**
     * 基于 MAC + PID 的 hashcode 获取16个低位
     * <p>
     * 可自定扩展
     */
    protected long getMaxWorkerId(long datacenterId) {
        StringBuilder mpId = new StringBuilder();
        mpId.append(datacenterId);
        String name = ManagementFactory.getRuntimeMXBean().getName();
        if (name != null && name.length() > 0) {
            // GET jvmPid
            mpId.append(name.split("@")[0]);
        }

        // MAC + PID 的 hashcode 获取16个低位
        return (mpId.toString().hashCode() & 0xffff) % (maxWorkerId + 1);
    }

    /**
     * 获取下一个 ID
     *
     * @return next id
     */
    public synchronized long nextId() {
        long timestamp = timeGen();
        // 闰秒
        if (timestamp < lastTimestamp) {
            long offset = lastTimestamp - timestamp;
            if (offset <= 5) {
                try {
                    // 休眠双倍差值后重新获取，再次校验
                    wait(offset << 1);
                    timestamp = timeGen();
                    if (timestamp < lastTimestamp) {
                        throw new RuntimeException(String.format("Clock moved backwards.  Refusing to generate id for %d milliseconds", offset));
                    }
                } catch (Exception e) {
                    throw new RuntimeException(e);
                }
            } else {
                throw new RuntimeException(String.format("Clock moved backwards.  Refusing to generate id for %d milliseconds", offset));
            }
        }

        if (lastTimestamp == timestamp) {
            // 相同毫秒内，序列号自增
            sequence = (sequence + 1) & sequenceMask;
            if (sequence == 0) {
                // 同一毫秒的序列数已经达到最大
                timestamp = tilNextMillis(lastTimestamp);
            }
        } else {
            // 不同毫秒内，序列号置为 1 - 3 随机数
            sequence = ThreadLocalRandom.current().nextLong(1, 3);
        }

        lastTimestamp = timestamp;

        // 时间戳部分 | 数据中心部分 | 机器标识部分 | 序列号部分
        return ((timestamp - twepoch) << timestampLeftShift)
                | (datacenterId << datacenterIdShift)
                | (workerId << workerIdShift)
                | sequence;
    }

    protected long tilNextMillis(long lastTimestamp) {
        long timestamp = timeGen();
        while (timestamp <= lastTimestamp) {
            timestamp = timeGen();
        }

        return timestamp;
    }

    protected long timeGen() {
        return SystemClock.INSTANCE.currentTimeMillis();
    }

    /**
     * Find first valid IP from local network card
     *
     * @return first valid local IP
     */
    public static InetAddress getLocalAddress() {
        if (LOCAL_ADDRESS != null) {
            return LOCAL_ADDRESS;
        }

        LOCAL_ADDRESS = getLocalAddress0();
        return LOCAL_ADDRESS;
    }

    private static InetAddress getLocalAddress0() {
        InetAddress localAddress = null;
        try {
            localAddress = InetAddress.getLocalHost();
            if (isValidAddress(localAddress)) {
                return localAddress;
            }
        } catch (Throwable e) {
            log.warn("Failed to retrieving ip address, " + e.getMessage(), e);
        }

        try {
            Enumeration<NetworkInterface> interfaces = NetworkInterface.getNetworkInterfaces();
            if (interfaces != null) {
                while (interfaces.hasMoreElements()) {
                    try {
                        NetworkInterface network = interfaces.nextElement();
                        Enumeration<InetAddress> addresses = network.getInetAddresses();
                        while (addresses.hasMoreElements()) {
                            try {
                                InetAddress address = addresses.nextElement();
                                if (isValidAddress(address)) {
                                    return address;
                                }
                            } catch (Throwable e) {
                                log.warn("Failed to retrieving ip address, " + e.getMessage(), e);
                            }
                        }
                    } catch (Throwable e) {
                        log.warn("Failed to retrieving ip address, " + e.getMessage(), e);
                    }
                }
            }
        } catch (Throwable e) {
            log.warn("Failed to retrieving ip address, " + e.getMessage(), e);
        }

        log.error("Could not get local host ip address, will use 127.0.0.1 instead.");
        return localAddress;
    }

    private static boolean isValidAddress(InetAddress address) {
        if (address == null || address.isLoopbackAddress()) {
            return false;
        }

        String name = address.getHostAddress();
        return (name != null && !"0.0.0.0".equals(name) && !"127.0.0.1".equals(name) && IP_PATTERN.matcher(name).matches());
    }
}

普通测试代码：

package com.rainbowred.websocket.service.sequence;

import lombok.extern.slf4j.Slf4j;
import org.junit.Test;

/**
 * @author wangyitao
 * @date 2024/1/2.
 */
@Slf4j
public class SequenceTest {

    SequenceService sequenceService = new SequenceService(1L, 1L);

    @Test
    public void snowflakeGeneratedId() {
        for (int i = 0; i < 100; i++) {
            long id = sequenceService.nextId();
            log.info("snowflake id:{}", id);
        }
    }

}

测试结果：

结果分析：id自增长

性能测试代码：

package com.rainbowred.websocket.service.sequence;

import lombok.extern.slf4j.Slf4j;
import org.databene.contiperf.PerfTest;
import org.databene.contiperf.junit.ContiPerfRule;
import org.junit.Rule;
import org.junit.Test;

/**
 * @author wangyitao
 * @date 2024/1/2.
 */
@Slf4j
public class SequenceTest {


    @Rule
    public ContiPerfRule rule = new ContiPerfRule();

    SequenceService sequenceService = new SequenceService(1L, 1L);

    @Test
    @PerfTest(invocations = 4000000, threads = 16)
    public void snowflakeBenchmark() {
        sequenceService.nextId();
    }
}

测试结果：

结果分析：16线程总共执行400w次，总耗时1.442秒，单次最大耗时15毫秒，平均每次耗时约0.003毫秒

总结：雪花算法强依赖机器时钟，如果机器上时钟回拨，会导致发号重复或者服务会处于不可用状态。如果恰巧回退前生成过一些ID，而时间回退后，生成的ID就有可能重复。官方对于此并没有给出解决方案，而是简单的抛错处理，这样会造成在时间被追回之前的这段时间服务不可用。本系统考虑使用此方案。

百度-UidGenerator【考虑】

官方地址：https://github.com/baidu/uid-generator

百度的 UidGenerator 是百度开源基于Java语言实现的唯一ID生成器，是在雪花算法 snowflake 的基础上做了一些改进。UidGenerator以组件形式工作在应用项目中, 支持自定义workerId位数和初始化策略，适用于docker等虚拟化环境下实例自动重启、漂移等场景。

在实现上，UidGenerator 提供了两种生成唯一ID方式，分别是 DefaultUidGenerator 和 CachedUidGenerator，官方建议如果有性能考虑的话使用 CachedUidGenerator 方式实现。UidGenerator 依然是以划分命名空间的方式将 64-bit位分割成多个部分，只不过它的默认划分方式有别于雪花算法 snowflake。它默认是由 1-28-22-13 的格式进行划分。可根据你的业务的情况和特点，自己调整各个字段占用的位数。

  • 第1位仍然占用1bit，其值始终是0。
  • 第2位开始的28位是时间戳，28-bit位可表示2^28个数，这里不再是以毫秒而是以秒为单位，每个数代表秒则可用（1L<<28）/ (360024365) ≈ 8.51 年的时间。
  • 中间的 workId （数据中心+工作机器，可以其他组成方式）则由 22-bit位组成，可表示 2^22 = 4194304个工作ID。
  • 最后由13-bit位构成自增序列，可表示2^13 = 8192个数。

其中 workId （机器 id），最多可支持约420w次机器启动。内置实现为在启动时由数据库分配（表名为 WORKER_NODE），默认分配策略为用后即弃，后续可提供复用策略。

总结：百度UidGenerator是对传统Snowflake算法的一种改进。与Snowflake算法相比，UidGenerator提供了更灵活的时间位和工作节点位配置，从而更好地适应不同的业务需求。UidGenerator的一个主要优点是它解决了Snowflake算法中系统时钟回拨问题。此外，UidGenerator还提供了可插拔的业务ID生成策略，使其更加灵活和适应多变的业务环境。但是目前官方文档中只有Spring + MyBatis的接入方式，新项目基于Spring Boot 3架构，会有兼容性的问题存在。本系统考虑使用此方案。

美团-Leaf【推荐】

官方地址：https://github.com/Meituan-Dianping/Leaf

Leaf 最早期需求是各个业务线的订单ID生成需求。在美团早期，有的业务直接通过DB自增的方式生成ID，有的业务通过redis缓存来生成ID，也有的业务直接用UUID这种方式来生成ID。以上的方式各自有各自的问题，因此我们决定实现一套分布式ID生成服务来满足需求。

目前Leaf覆盖了美团点评公司内部金融、餐饮、外卖、酒店旅游、猫眼电影等众多业务线。在4C8G VM基础上，通过公司RPC方式调用，QPS压测结果近5w/s，TP999 1ms。

Leaf 也提供了两种ID生成的方式，分别是 Leaf-segment 数据库方案和 Leaf-snowflake 方案

Leaf-segment 数据库方案：是在上文描述的在使用数据库的方案上，做了如下改变：

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

Leaf-snowflake方案：Leaf-snowflake方案完全沿用 snowflake 方案的bit位设计，对于workerID的分配引入了Zookeeper持久顺序节点的特性自动对snowflake节点配置 wokerID。避免了服务规模较大时，动手配置成本太高的问题。

解决时钟问题
因为这种方案依赖时间，如果机器的时钟发生了回拨，那么就会有可能生成重复的ID号，需要解决时钟回退的问题。

参见上图整个启动流程图，服务启动时首先检查自己是否写过ZooKeeper leaf_forever节点：

  1. 若写过，则用自身系统时间与leaf_forever/ s e l f 节点记录时间做比较，若小于 l e a f f o r e v e r / {self}节点记录时间做比较，若小于leaf_forever/ self节点记录时间做比较，若小于leaff​orever/{self}时间则认为机器时间发生了大步长回拨，服务启动失败并报警。
  2. 若未写过，证明是新服务节点，直接创建持久节点leaf_forever/${self}并写入自身系统时间，接下来综合对比其余Leaf节点的系统时间来判断自身系统时间是否准确，具体做法是取leaf_temporary下的所有临时节点(所有运行中的Leaf-snowflake节点)的服务IP：Port，然后通过RPC请求得到所有节点的系统时间，计算sum(time)/nodeSize。
  3. 若abs( 系统时间-sum(time)/nodeSize ) < 阈值，认为当前系统时间准确，正常启动服务，同时写临时节点leaf_temporary/${self} 维持租约。
  4. 否则认为本机系统时间发生大步长偏移，启动失败并报警。
  5. 每隔一段时间(3s)上报自身系统时间写入leaf_forever/${self}。

总结：美团的Leaf-snowflake是一个高性能的分布式ID生成系统，它基于Snowflake算法进行了优化和扩展。Leaf-snowflake特别注重解决分布式系统中的时钟回拨问题，它通过额外的状态机制确保ID的连续性和唯一性，即使在系统时间发生小幅回拨的情况下也能稳定运行。与传统的Snowflake算法相比，Leaf-snowflake更加健壮，能够更好地适应分布式环境中的各种挑战，包括时钟同步和节点故障。并且官方推荐Spring boot接入，本系统推荐使用此方案。

美团Leaf Quick Start

<dependency>
	<artifactId>leaf-boot-starter</artifactId>
    <groupId>com.sankuai.inf.leaf</groupId>
    <version>1.0.1-RELEASE</version>
</dependency>
  • 配置文件
#美团leaf
leaf:
  name: com.rainbowred.core.service
  snowflake:
    address: 10.255.251.1:2181
    enable: true
    port: 8899
  • 利用注解启动leaf @EnableLeafServer
@SpringBootApplication(scanBasePackages = {"com.rainbowred.core.service", "com.rainbowred.commons"})
@MapperScan("com.rainbowred.commons.mybatis.mapper")
@EnableDubbo
@EnableLeafServer
public class CoreServiceApplication {

    public static void main(String[] args) {
        SpringApplication.run(CoreServiceApplication.class, args);
    }

}
  • 直接使用 spring注入
    @Autowired
    private LeafSnowflakeService snowflakeService;


    @RequestMapping("/getUidTest")
    public HttpResult<Void, Void> getUidTest(@RequestParam("size") Integer size, @RequestParam("key") String key) {
        for (int i = 0; i < size; i++) {
            long id = snowflakeService.getId(key);
            log.info(i + ":" + id);
        }
        return HttpResult.success();
    }

优缺点

http://www.52im.net/thread-4378-1-1.html

洪河王大爷
关注
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值