分布式系统唯一ID生成方案

订单编号生成规则 小型系统、单点系统:使用自增序列(数据库或 RedisINCR)即可,简单易实现,但需要注意系统扩展性和性能瓶颈。需要包含时间信息的订单号:可以使用时间戳 + 随机数,通过随机数降低重复风险,适合小型系统。订单类型明确的系统:可以使用订单类型 + 日期 + 序号,不仅保证唯一性,还能通过订单号获取有用信息,适合有不同订单类型的系统。高并发分布式系统:推荐使用分布式唯一ID生成器(如 Snowflake 算法),高效、唯一、支持分布式,是大型系统和高并发系统的首选。 阅读详情

系统唯一ID是我们在设计一个系统的时候常常会遇见的问题,也常常为这个问题而纠结。生成ID的方法有很多,适应不同的场景、需求以及性能要求。所以有些比较复杂的系统会有多个ID生成的策略。下面就介绍一些常见的ID生成策略。

1.数据库自增长序列或字段

最常见的方式。利用数据库,全数据库唯一。

优点:

1)简单,代码方便,性能可以接受。
2)数字ID天然排序,对分页或者需要排序的结果很有帮助。

缺点:

1)不同数据库语法和实现不同,数据库迁移的时候或多数据库版本支持的时候需要处理。
2)在单个数据库或读写分离或一主多从的情况下,只有一个主库可以生成。有单点故障的风险。
3)在性能达不到要求的情况下,比较难于扩展。
4)如果遇见多个系统需要合并或者涉及到数据迁移会相当痛苦。
5)分表分库的时候会有麻烦。

2.UUID

常见的方式。可以利用数据库也可以利用程序生成,一般来说全球唯一。

优点:

1)简单,代码方便。
2)生成ID性能非常好,基本不会有性能问题。
3)全球唯一,在遇见数据迁移,系统数据合并,或者数据库变更等情况下,可以从容应对。

缺点:

1)没有排序,无法保证趋势递增。
2)UUID往往是使用字符串存储,查询的效率比较低。
3)存储空间比较大,如果是海量数据库,就需要考虑存储量的问题。
4)传输数据量大
5)不可读。

3.Redis生成ID

当使用数据库来生成ID性能不够要求的时候,我们可以尝试使用Redis来生成ID。这主要依赖于Redis是单线程的,所以也可以用生成全局唯一的ID。可以用Redis的原子操作 INCR和INCRBY来实现。

可以使用Redis集群来获取更高的吞吐量。假如一个集群中有5台Redis。可以初始化每台Redis的值分别是1,2,3,4,5,然后步长都是5。各个Redis生成的ID为:

A:1,6,11,16,21
B:2,7,12,17,22
C:3,8,13,18,23
D:4,9,14,19,24
E:5,10,15,20,25

这个,随便负载到哪个机确定好,未来很难做修改。但是3-5台服务器基本能够满足器上,都可以获得不同的ID。但是步长和初始值一定需要事先需要了。使用Redis集群也可以方式单点故障的问题。

另外,比较适合使用Redis来生成每天从0开始的流水号。比如订单号=日期+当日自增长号。可以每天在Redis中生成一个Key,使用INCR进行累加。

优点:

1)不依赖于数据库,灵活方便,且性能优于数据库。
2)数字ID天然排序,对分页或者需要排序的结果很有帮助。

缺点:

1)如果系统中没有Redis,还需要引入新的组件,增加系统复杂度。
2)需要编码和配置的工作量比较大。

4.Twitter的snowflake算法

snowflake是Twitter开源的分布式ID生成算法,结果是一个long型的ID。其核心思想是:使用41bit作为毫秒数,10bit作为机器的ID(5个bit是数据中心,5个bit的机器ID),12bit作为毫秒内的流水号(意味着每个节点在每毫秒可以产生 4096 个 ID),最后还有一个符号位,永远是0。具体实现的代码可以参看https://github.com/twitter/snowflake。

package com.easygo.utils;

import java.lang.management.ManagementFactory;
import java.net.InetAddress;
import java.net.NetworkInterface;

/**
 * <p>名称:IdWorker.java</p>
 * <p>描述:分布式自增长ID</p>
 * <pre>
 *     Twitter的 Snowflake JAVA实现方案
 * </pre>
 * 核心代码为其IdWorker这个类实现,其原理结构如下,我分别用一个0表示一位,用—分割开部分的作用:
 * 1||0---0000000000 0000000000 0000000000 0000000000 0 --- 00000 ---00000 ---000000000000
 * 在上面的字符串中,第一位为未使用(实际上也可作为long的符号位),接下来的41位为毫秒级时间,
 * 然后5位datacenter标识位,5位机器ID(并不算标识符,实际是为线程标识),
 * 然后12位该毫秒内的当前毫秒内的计数,加起来刚好64位,为一个Long型。
 * 这样的好处是,整体上按照时间自增排序,并且整个分布式系统内不会产生ID碰撞(由datacenter和机器ID作区分),
 * 并且效率较高,经测试,snowflake每秒能够产生26万ID左右,完全满足需要。
 * <p>
 * 64位ID (42(毫秒)+5(机器ID)+5(业务编码)+12(重复累加))
 *
 * @author Polim
 */
public class IdWorker {
    // 时间起始标记点,作为基准,一般取系统的最近时间(一旦确定不能变动)
    private final static long twepoch = 1288834974657L;
    // 机器标识位数
    private final static long workerIdBits = 5L;
    // 数据中心标识位数
    private final static long datacenterIdBits = 5L;
    // 机器ID最大值
    private final static long maxWorkerId = -1L ^ (-1L << workerIdBits);
    // 数据中心ID最大值
    private final static long maxDatacenterId = -1L ^ (-1L << datacenterIdBits);
    // 毫秒内自增位
    private final static long sequenceBits = 12L;
    // 机器ID偏左移12位
    private final static long workerIdShift = sequenceBits;
    // 数据中心ID左移17位
    private final static long datacenterIdShift = sequenceBits + workerIdBits;
    // 时间毫秒左移22位
    private final static long timestampLeftShift = sequenceBits + workerIdBits + datacenterIdBits;

    private final static long sequenceMask = -1L ^ (-1L << sequenceBits);
    /* 上次生产id时间戳 */
    private static long lastTimestamp = -1L;
    // 0,并发控制
    private long sequence = 0L;

    private final long workerId;
    // 数据标识id部分
    private final long datacenterId;

    public IdWorker(){
        this.datacenterId = getDatacenterId(maxDatacenterId);
        this.workerId = getMaxWorkerId(datacenterId, maxWorkerId);
    }
    /**
     * @param workerId
     *            工作机器ID
     * @param datacenterId
     *            序列号
     */
    public IdWorker(long workerId, long datacenterId) {
        if (workerId > maxWorkerId || workerId < 0) {
            throw new IllegalArgumentException(String.format("worker Id can't be greater than %d or less than 0", maxWorkerId));
        }
        if (datacenterId > maxDatacenterId || datacenterId < 0) {
            throw new IllegalArgumentException(String.format("datacenter Id can't be greater than %d or less than 0", maxDatacenterId));
        }
        this.workerId = workerId;
        this.datacenterId = datacenterId;
    }
    /**
     * 获取下一个ID
     *
     * @return
     */
    public synchronized long nextId() {
        long timestamp = timeGen();
        if (timestamp < lastTimestamp) {
            throw new RuntimeException(String.format("Clock moved backwards.  Refusing to generate id for %d milliseconds", lastTimestamp - timestamp));
        }

        if (lastTimestamp == timestamp) {
            // 当前毫秒内,则+1
            sequence = (sequence + 1) & sequenceMask;
            if (sequence == 0) {
                // 当前毫秒内计数满了,则等待下一秒
                timestamp = tilNextMillis(lastTimestamp);
            }
        } else {
            sequence = 0L;
        }
        lastTimestamp = timestamp;
        // ID偏移组合生成最终的ID,并返回ID
        long nextId = ((timestamp - twepoch) << timestampLeftShift)
                | (datacenterId << datacenterIdShift)
                | (workerId << workerIdShift) | sequence;

        return nextId;
    }

    private long tilNextMillis(final long lastTimestamp) {
        long timestamp = this.timeGen();
        while (timestamp <= lastTimestamp) {
            timestamp = this.timeGen();
        }
        return timestamp;
    }

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

    /**
     * <p>
     * 获取 maxWorkerId
     * </p>
     */
    protected static long getMaxWorkerId(long datacenterId, long maxWorkerId) {
        StringBuffer mpid = new StringBuffer();
        mpid.append(datacenterId);
        String name = ManagementFactory.getRuntimeMXBean().getName();
        if (!name.isEmpty()) {
            /*
             * GET jvmPid
             */
            mpid.append(name.split("@")[0]);
        }
        /*
         * MAC + PID 的 hashcode 获取16个低位
         */
        return (mpid.toString().hashCode() & 0xffff) % (maxWorkerId + 1);
    }

    /**
     * <p>
     * 数据标识id部分
     * </p>
     */
    protected static long getDatacenterId(long maxDatacenterId) {
        long id = 0L;
        try {
            InetAddress ip = InetAddress.getLocalHost();
            NetworkInterface network = NetworkInterface.getByInetAddress(ip);
            if (network == null) {
                id = 1L;
            } else {
                byte[] mac = network.getHardwareAddress();
                id = ((0x000000FF & (long) mac[mac.length - 1])
                        | (0x0000FF00 & (((long) mac[mac.length - 2]) << 8))) >> 6;
                id = id % (maxDatacenterId + 1);
            }
        } catch (Exception e) {
            System.out.println(" getDatacenterId: " + e.getMessage());
        }
        return id;
    }

    public static void main(String[] args) {
        for (int i = 0; i <1000; i++) {
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            IdWorker worker=new IdWorker(0, i);
            long num = worker.nextId();
            System.out.println(num);
        }
    }
}

snowflake算法可以根据自身项目的需要进行一定的修改。比如估算未来的数据中心个数,每个数据中心的机器数以及统一毫秒可以能的并发数来调整在算法中所需要的bit数。

优点:

1)不依赖于数据库,灵活方便,且性能优于数据库。
2)ID按照时间在单机上是递增的。

缺点:

1)在单机上是递增的,但是由于涉及到分布式环境,每台机器上的时钟不可能完全同步,也许有时候也会出现不是全局递增的情况。

5.利用zookeeper生成唯一ID

zookeeper主要通过其znode数据版本来生成序列号,可以生成32位和64位的数据版本号,客户端可以使用这个版本号来作为唯一的序列号。
很少会使用zookeeper来生成唯一ID。主要是由于需要依赖zookeeper,并且是多步调用API,如果在竞争较大的情况下,需要考虑使用分布式锁。因此,性能在高并发的分布式环境下,也不甚理想。

6.MongoDB的ObjectId

MongoDB的ObjectId和snowflake算法类似。它设计成轻量型的,不同的机器都能用全局唯一的同种方法方便地生成它。MongoDB 从一开始就设计用来作为分布式数据库,处理多个节点是一个核心要求。使其在分片环境中要容易生成得多。

其格式如下:
在这里插入图片描述
前4 个字节是从标准纪元开始的时间戳,单位为秒。时间戳,与随后的5 个字节组合起来,提供了秒级别的唯一性。由于时间戳在前,这意味着ObjectId 大致会按照插入的顺序排列。这对于某些方面很有用,如将其作为索引提高效率。这4 个字节也隐含了文档创建的时间。绝大多数客户端类库都会公开一个方法从ObjectId 获取这个信息。
接下来的3 字节是所在主机的唯一标识符。通常是机器主机名的散列值。这样就可以确保不同主机生成不同的ObjectId,不产生冲突。
为了确保在同一台机器上并发的多个进程产生的ObjectId 是唯一的,接下来的两字节来自产生ObjectId 的进程标识符(PID)。
前9 字节保证了同一秒钟不同机器不同进程产生的ObjectId 是唯一的。后3 字节就是一个自动增加的计数器,确保相同进程同一秒产生的ObjectId 也是不一样的。同一秒钟最多允许每个进程拥有2563(16 777 216)个不同的ObjectId。

实现的源码可以到MongoDB官方网站下载。

分布式系统中生成全局唯一ID方案 本文主要介绍在一个分布式系统中, 如何去生成全局唯一的 ID 阅读详情

相关推荐

【支付系统】如何生成订单号

通常我们都会用数据库中的主键作为订单号,而id的生成方式又以自增,uuid,雪花id最为常见.但是这些并不适合作为订单号.订单号一般要体现出年月日等信息.方便快速定位是哪个时间的订单.如果我们直接使用时间作为id,会有重复的可能.这里就给大家介绍一种最为简单的一种方式.我们数据库中的id依旧是自增id,不过这里加了一个前缀,在使用时我们使用时采用的是拼接的方式.添加订单的时候会将当天的时间同时插入进去.时间+自增id , 这里借用了数据库的自增id,达到不会重复的效果.又能体现时间。

qq_39078783的博客 1690

[详解]Twitter开源分布式自增ID算法snowflake,附演算验证过程

详解Twitter开源分布式自增ID算法snowflake,附演算验证过程. snowflake简介,snowflake算法原理,snowflake算法源码(java版),snowflake算法推导和演算过程。 snowflake算法是一款本地生成的(ID生成过程不依赖任何中间件,无网络通信),保证ID全局唯一,并且ID总体有序递增,性能每秒生成300w+

Java高手真经 1万+

24V供电D1047/B817对管AB类音频功放设计与制作全解析

音频功率放大器是电子系统将微弱音频信号放大驱动扬声器的核心电路,其核心原理是通过晶体管或集成电路对信号进行电压和电流放大。从技术价值看,优秀的功放设计需兼顾效率、保真度与稳定性,AB类放大器便是经典折中方案,它在A类低失真与B类高效率间取得平衡。在应用场景上,这类电路广泛应用于家用音响、多媒体音箱、车载音频及DIY音频项目。本文聚焦于一个采用24V直流供电、以D1047和B817互补对管为核心输出级的AB类功放实例,深入剖析其**电路设计**与**元件选型**,涵盖从BC547小信号放大、偏置设置、PCB布

weixin_31355483的博客 415

简单介绍订单号或者流水号的生成方法

一般订单号或者流水号等可能在一些平台会用到,然后我就简单的介绍一个我自己生成订单号和流水号的一个方法吧,如果程序有问题或者你有更好的生成办法,欢迎留言,留下你的文章链接,我们一起学习和进步哈。 方法简介: 一般订单号或者流水号的生成,是时间戳+随机数(或者自己写的算法生成),或者是时间戳+订单类型+随机数 比如在A平台付款的,订单类型就是0001,B平台付款的就是0002,总之可以自己想怎么...

小小鱼儿小小林的博客 2万+

5分钟搞定:用Ollama在MacBook上本地运行Qwen3大模型(附避坑指南)

本文详细介绍了如何在MacBook上使用Ollama快速部署和运行Qwen3大模型,包括安装步骤、性能优化技巧及常见问题解决方案。Ollama作为一款轻量级工具,特别适合M系列芯片的Mac用户,支持多种量化版本,显著降低资源消耗,提升推理速度。

sql99的博客 824

【人工智能】RAG如何根据实际需求选择和进行文档解析(如 PDF、Word、TXT、网页等)?

文档解析的核心在于根据解析目标、文档类型和处理量选择合适工具。PDF、Word、TXT和网页各有特性:PDF需区分可编辑与扫描版,Word需处理结构化内容,TXT简单但需注意编码,网页需应对动态内容。解析场景包括提取纯文本、结构化数据、保留格式和批量处理。非技术用户可借助工具如Adobe Acrobat、WPS和在线OCR,技术用户可通过编程实现自动化。通用流程为:明确目标、分析文档属性、选择工具并测试优化。核心是“工具适配需求”,无需追求万能方案。

奶爸的编程之路,也就一周冷个三天 506

兑换券的实现(UUID,雪花算法,自增id)

基于BitMap:兑换或没兑换就是两个状态,对应0和1,而兑换码使用的是自增id.我们如果每一个自增id对应一个bit位,用每一个bit位的状态表示兑换状态,是不是完美解决问题。缺点:不适合要求可读性较高的情况,不容易防止刷暴(这里可以去了解雪花算法的组成,他由一位符号位,为0的符号位,然后41位的时间戳,10位工作机器id,12位序列号),数据较大的时候,可能存在性能问题。当然,这里我们不能采用MD5和RSA算法来生成签名,因为这些算法得到的签名都太长了,一般都是128位以上,超出了长度限制。

qq_62773260的博客 1384

《C#零基础入门之百识百例》(七)算数运算符 -- 圆的面积

运算符是一种告诉编译器执行特定的数学或逻辑操作的符号。C# 有丰富的内置运算符,本文带你学习C# 中算数运算符。

陈言必行 -- Unity游戏开发领域优质博主 3615

分布式系统中全局唯一ID的生成方案及对比分析

在分布式架构中,当我们将数据分库分表后,传统的自增主键机制面临着唯一性挑战。本文深入剖析了分布式系统中全局唯一ID生成的四种主流方案:UUID、单表自增、多表步长和雪花算法,从性能、存储空间、有序性和可用性等维度进行全面对比。你是否好奇为何Twitter选择了雪花算法?或者如何解决雪花算法中的时钟回拨问题?文章不仅提供了各方案的实现原理和代码示例,还分享了微博、美团等大厂的实践经验,帮助你在实际项目中做出最合适的技术选择。无论是小型应用还是高并发大型分布式系统,这里都有你需要的ID生成最佳实践。

猫步轻移,以学求知。余于此方寸之地,如猫观鼠,细察技艺所得,思维所悟。灵思如猫之警觉,日积月累,终成智海; 1368

【推荐100个unity插件】性能极高的逼真爆炸、火焰和烟雾效果——UNI VFX

这是一篇关于Unity中高性能GPU粒子特效插件UNI VFX的使用指南。文章介绍了该插件提供逼真的爆炸、火焰和烟雾效果,支持URP和HDRP渲染管线。主要内容包括:插件安装方法(需预先安装Visual Effect Graph和Shader Graph包)、事件系统使用方法(如create/loop/stop等事件控制)、特效分类(自动结束型和持续型特效)、检视面板配置技巧以及性能优化建议(特别提醒灯光特效对性能的影响较大)。文末还推荐了多个Unity开发相关的专栏内容。

向宇的博客,专注php/web全栈 unity游戏开发,欢迎大家评论纠错 1492

6、业务影响分析(BIA)的数据收集与关键指标评估

本文全面解析了业务影响分析(BIA)的核心内容,包括数据收集、业务流程分析、信息系统与资产清单、人员与供应商依赖、影响声明、关键指标评估(如MTD、RTO、RPO)、威胁建模与风险分析等。通过详细的介绍和图表展示,帮助组织系统性地制定灾难恢复计划,以应对各种潜在风险,确保关键业务流程在灾难发生后能够快速恢复并持续运营。

moss5的博客 376

分布式系统唯一ID生成方案汇总

分布式系统唯一ID生成方案汇总 系统唯一ID是我们在设计一个系统的时候常常会遇见的问题,也常常为这个问题而纠结。生成ID的方法有很多,适应不同的场景、需求以及性能要求。所以有些比较复杂的系统会有多个ID生成的策略。下面就介绍一些常见的ID生成策略。 数据库自增长序列或字段 最常见的方式。利用数据库,全数据库唯一。 优点: 1)简单,代码方便,性能可以接受。 2)数字ID天然排序,对分页或者需要排序的结果很有帮助。 缺点: 1)不同数据库语法和实现不同,数据库迁移的时候或多数据库版本支持的时候需要处理。

qq_44963130的博客 142

DCDC电路断电时放电波形发生震荡和电压跳变问题,如何解决?

DCDC电路断电时放电波形发生震荡和电压跳变问题: 做的一个项目需要用单片机ADC采集电压,要让单片机感应到电压降到3.1V开始往FLASH里存数据,单片机2.4V基本上就工作不了,(根据单片机手册的,擦写的时间在40mS在左右)所以3.1V降到2.4V的时间必须要大于40mS岁以上,在单片机VCC处加了一个100nF的电容,理论仿真下来150mS左右发现存不进去,用示波器抓了一下波形,发现放电时震荡很严重,实际3.1V到2.4V时间只有10ms左右,这个肯定存不进去; 请教师傅说是应该时前级DCDC开关电

**My Coding Family** 1972

四、分布式系统唯一ID生成方案汇总

系统唯一ID是我们在设计一个系统的时候常常会遇见的问题,也常常为这个问题而纠结。生成ID的方法有很多,适应不同的场景、需求以及性能要求。所以有些比较复杂的系统会有多个ID生成的策略。下面就介绍一些常见的ID生成策略。

Daniel的博客 888

C# WinForm 基于DirectShow.dll编写的程序,可边预览边保存视频,音频和图片

基于微软的DirectShow.dll的二次开发1.自动识别连接的摄像头跟麦克风且可以对其进行选择(默认选中第一个)2.可录制wmv和avi两种格式的视频并且都带有音频,avi可以录制的分辨率和帧数进行选择,wmv默认进行了淸晰度优化如不喜欢可去除代码中有相关提示3.可在预览点开之后进行拍照,也可边录制视频边拍照4.添加了视频和音频的压缩功能(酌情使用)这次二次开发发现C#对DirectShow的相关信息太少,这次做完也不敢藏私共享出来,还望大家指正

VB摄像头监控

该VB模块可对摄像头捕获的画面进行录像等,可在创建的窗口进行控制

八年实战:分布式系统全局唯一 ID 生成方案全解析​

作为一名经历过电商、金融、物流等多领域分布式系统设计的 Java 后端开发者,我深知全局唯一 ID 是分布式架构的基础磐石。它不仅是业务实体的身份标识,更承载着分库分表、事件溯源、审计追踪等核心功能。本文将结合实际项目经验,从方案对比、核心实现到工程实践,深度解析 7 种主流方案的适用场景与落地细节。

Minoz_wl的博客 688

lwip-2.0.3

lwip是瑞典计算机科学院(SICS)的Adam Dunkels 开发的一个小型开源的TCP/IP协议栈。实现的重点是在保持TCP协议主要功能的基础上减少对RAM 的占用。

android唯一机器码生成方案_分布式系统唯一ID生成方案汇总

系统唯一ID是我们在设计一个系统的时候常常会遇见的问题,也常常为这个问题而纠结。生成ID的方法有很多,适应不同的场景、需求以及性能要求。所以有些比较复杂的系统会有多个ID生成的策略。下面就介绍一些常见的ID生成策略。数据库自增长序列或字段最常见的方式。利用数据库,全数据库唯一。优点:1)简单,代码方便,性能可以接受。2)数字ID天然排序,对分页或者需要排序的结果很有帮助。缺点:1)不同数据库语法和...

weixin_36229293的博客 1281

Data-Structures-and-Algorithm-Analysis-in-Java.pdf

作者: Weiss, Mark A. 出版社: Addison Wesley Data Structures and Algorithm Analysis in Java is an “advanced algorithms” book that fits between traditional CS2 and Algorithms Analysis courses. In the old ACM Curriculum Guidelines, this course was known as CS7. This text is for readers who want to learn good programming and algorithm analysis skills simultaneously so that they can develop such programs with the maximum amo...

分布式系统唯一ID生成方案浅析

分布式系统唯一ID生成方案浅析 在复杂分布式系统中,往往需要对大量的数据和消息进行唯一标识。业务ID需要满足的要求如下 全局唯一性:不能出现重复的ID号,既然是唯一标识,这是最基本的要求。 趋势递增:在MySQL InnoDB引擎中使用的是聚集索引,由于多数RDBMS使用B-tree的数据结构来存储索引数据,在主键的选择上面我们应该尽量使用有序的主键保证写入性能。 单调递增:保证下一个ID一定大...

haxianhe的博客 590

分布式系统唯一ID的生成方案讨论

在分布式系统下唯一id问题,就是id咋生成?比如分表分库,因为要是一个表分成多个表之后,每个表的id都是从1开始累加自增长,那是不对的。举个例子,一个表拆分为了2张表,每个表的id都从1开始累加,这个肯定有问题了!你的系统就没办法根据表主键来查询了,比如id = 10这个记录,在两个表里都有!所以此时就需要分布式架构下的全局唯一id生成的方案了,保证每个表内的某个id,全局唯一。全局唯一id主要有...

weixin_30730053的博客 133

分布式系统(唯一) ID 生成器实现方案

分布式系统 ID 生成器实现方案

Jaemon 518
上一篇: 软件架构浅析-BASE理论
下一篇: Spring Data ElasticSearch使用
熊猫IT技术
熊猫IT技术 优质创作者: Java技术领域 优质创作者: Java技术领域 领域专家: 后端开发技术领域 领域专家: 后端开发技术领域
博客等级 码龄10年 6021粉丝 1312原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

打赏作者

熊猫IT技术

你的鼓励将是我创作的最大动力

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

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

打赏作者

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

抵扣说明:

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

余额充值