kafka事务详细讲解,示例代码,概念讲解

于 2023-02-07 10:30:18 发布
阅读量431 收藏 1
点赞数
分类专栏： kafka 文章标签： kafka java 分布式
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_37335180/article/details/128914299
版权

01 场景

(1)  producer发多条消息组成一个事务这些消息需要对consumer同时消费或不消费
(2)  producer可能会给多个topic多个分区发消息，这些消息需要放在一个事务里面，典型的分布式事务。
(3)  应用先消费一个topic的消息，再发消息到另一个topic，这个consume-transform-produce过程需放到一个事务里面
(4)  producer或producer所在应用可能会挂掉，新的producer启动后需要知道怎么处理之前未完成的事务 。

只有consumer消费消息，加事务没意义，跟使用手动提交效果一样，且也不是事务属性引入的目的，一般不使用这种情况

02 概念和推导

  (1) 因为producer发送消息可能是分布式事务，引入了2PC事务协调者(Transaction Coordinator)。Transaction Coordinator和之前为了解决脑裂和惊群问题引入的Group Coordinator在选举上类似。

  (2)  事务管理中事务日志是必不可少的，kafka用内部topic(名字是__transaction_state)保存事务日志，事务日志是Transaction Coordinator管理的状态的持久化，因为不需要回溯事务的历史状态，所以事务日志只用保存最近的事务状态。

  (3)  因为事务存在commit和abort两种操作，而客户端又有read committed(提交了消费者才能看到)和read uncommitted(比提交消费者也能看到)两种隔离级别，所以消息队列必须能标识事务状态，这个被称作Control Message。

  (4) producer挂掉重启或漂移到其它机器需要能关联之前未完成事务所以需有个唯一标识符进行关联，就是TransactionalId，一个producer挂了，另一个有相同TransactionalId的producer能够接着处理这个事务未完成的状态。kafka目前没有引入全局序，所以也没有transactionId，这个TransactionalId是用户提前配置的。
 (5) TransactionalId能关联producer，也需要避免两个使用相同TransactionalId的producer同时存在，所以引入了producer epoch来保证对应一个TransactionalId只有一个活跃的producer

03 粉碎“僵尸实例”

  为每个事务Producer分配一个称为transactional.id的唯一标识符来解决僵尸实例问题。在进程重新启动时能够识别相同的Producer实例。
 API要求事务性Producer的第一个操作应该是在Kafka集群中显示注册transactional.id。 注册时Kafka broker用给定的transactional.id检查打开的事务且完成处理。 Kafka也增加了一个与transactional.id相关的epoch。Epoch存储每个transactional.id内部元数据。
  一旦epoch被触发，任何具有相同的transactional.id和旧的epoch的生产者被视为僵尸，Kafka拒绝来自这些生产者的后续事务性写入。
  Kafka可以保证Consumer最终只能消费非事务性消息或已提交事务性消息。它将保留来自未完成事务的消息，并过滤掉已中止事务的消息。

05 事务消息定义

生产者可以显式地发起事务会话，在这些会话中发送(事务)消息，并提交或中止事务。有如下要求：

  1. 原子性：消费者的应用程序不应暴露于未提交事务的消息中。
  2. 持久性：Broker不能丢失任何已提交的事务。
  3. 排序：事务消费者应在每个分区中以原始顺序查看事务消息。
  4. 交织：每个分区都应该能够接收来自事务性生产者和非事务生产者的消息
  5. 事务中不应有重复的消息。

不管是事务消息还是非事务消息,都以最后的提交时间为准来决定顺序

01 事务配置

(1 )创建消费者代码，需要：
将配置中的自动提交属性(auto.commit)进行关闭
而且在代码里面也不能使用手动提交commitSync( )或者commitAsync( )
设置isolation.level：READ_COMMITTED或READ_UNCOMMITTED
(2) 创建生成者，代码如下,需要：
配置transactional.id属性
配置enable.idempotence(幂等)属性

02 事务概览

  生产者将表示事务开始/结束/中止状态的事务控制消息发送给使用多阶段协议管理事务的高可用事务协调器。生产者将事务控制记录(开始/结束/中止)发送到事务协调器，并将事务的消息直接发送到目标数据分区。消费者需要了解事务并缓冲每个待处理的事务，直到它们到达其相应的结束(提交/中止)记录为止。

  事务组: 事务组中的生产者有相同的transactionId
  事务组中的生产者
  事务组的事务协调器
  Leader brokers(事务数据所在分区的Broker)
  事务的消费者

03 事务组

  用于映射到特定的事务协调器(基于日志分区数字的哈希)。该组中的生产者需要配置为该组事务生产者。由于来自这些生产者的所有事务都通过此协调器进行，因此我们可以在这些事务生产者之间实现严格的有序。
  事务协调器就是一个broker

04 生产者ID和事务组状态

  生产者Id唯一标识一个生产者
  事务生产者需要两个新参数：生产者ID和生产组。需将生产者的输入状态与上一个已提交的事务相关联。这使事务生产者能够重试事务(通过为该事务重新创建输入状态；在我们的用例中通常是偏移量的向量)。
  可以使用消费者偏移量管理机制来管理这些状态。消费者偏移量管理器将每个键(consumergroup-topic-partition)与该分区的最后一个检查点偏移量和元数据相关联。在事务生产者中，我们保存消费者的偏移量，该偏移量与事务的提交点关联。此偏移提交记录(在__consumer_offsets主题中)应作为事务的一部分写入。即，存储消费组偏移量的__consumer_offsets 主题分区将需要参与事务。因此，假定生产者在事务中间失败(事务协调器随后到期)；当生产者恢复时，它可以发出偏移量获取请求，以恢复与最后提交的事务相关联的输入偏移量，并从该点恢复事务处理。

  为了支持此功能，我们需要对偏移量管理器和压缩的 __consumer_offsets 主题进行一些增强。首先，压缩的主题现在还将包含事务控制记录。我们将需要为这些控制记录提出剔除策略。其次，偏移量管理器需要具有事务意识；特别是，如果组与待处理的事务相关联，则偏移量提取请求应返回错误。

05 事务协调器

 事务协调器是 __transaction_state主题特定分区的Leader副本所在的Broker。它负责初始化/提交/回滚事务。事务协调器在内存管理如下的状态：
   对应正在处理的事务的第一个消息的HW。事务协调器周期性地将HW写到ZK。
  事务控制日志中存储对应于日志HW的所有正在处理的事务：
  事务消息主题分区的列表。 
     事务的超时时间。
    与事务关联的Producer ID。

需要确保无论是什么样的保留策略(日志分区的删除还是压缩)，都不能删除包含事务HW的日志分段。

06 事务流程

初始阶段

  1. Producer：计算哪个Broker作为事务协调器。
  2. Producer：向事务协调器发送BeginTransaction(producerId, generation, partitions… )请求，当然也可以发送另一个包含事务过期时间的。如果生产者需要将消费者状态作为事务的一部分提交事务，则需要在BeginTransaction中包含对应的 __consumer_offsets 主题分区信息。
  3. Broker：生成事务ID
  4. Coordinator：向事务协调主题追加BEGIN(TxId, producerId, generation, partitions…)消息，然后发送响应给生产者。
  5. Producer：读取响应（包含了事务ID：TxId）
  6. Coordinator (and followers)：在内存更新当前事务的待确认事务状态和数据分区信息。

发送阶段
Producer：发送事务消息给主题Leader分区所在的Broker。每个消息需要包含TxId和TxCtl字段。TxCtl仅用于标记事务的最终状态(提交还是中止)。生产者请求也封装了生产者ID，但是不追加到日志中。

结束阶段(生产者准备提交事务)

  1. Producer：发送OffsetCommitRequest请求提交与事务结束状态关联的输入状态(如下一个事务输入从哪儿开始)
  2. Producer：发送CommitTransaction(TxId, producerId, generation)请求给事务协调器并等待响应。(如果响应中没有错误信息，表示将提交事务)
  3. Coordinator：向事务控制主题追加PREPARE_COMMIT(TxId)请求并向生产者发送响应。
  4. Coordinator：向事务涉及到的每个Leader分区(事务的业务数据的目标主题)的Broker发送一个CommitTransaction(TxId, partitions…)请求。
  5. 事务业务数据的目标主题相关Leader分区Broker：
    1. 如果是非 __consumer_offsets 主题的Leader分区：一收到CommitTransaction(TxId, partition1, partition2, …)请求就会向对应的分区Broker发送空(null)消息(没有key/value)并给该消息设置TxId和TxCtl(设置为COMMITTED)字段。Leader分区的Broker给协调器发送响应。
    2. 如果是 __consumer_offsets 主题的Leader分区：追加消息，该消息的key是 GLAST-COMMIT ，value就是 TxId 的值。同时也应该给该消息设置TxId和TxCtl字段。Broker向协调器发送响应。
  6. Coordinator：向事务控制主题发送COMMITTED(TxId)请求。 __transaction_state
  7. Coordinator (and followers)：尝试更新HW。

07 事务的中止

当事务生产者发送业务消息的时候如果发生异常，可以中止该事务。如果事务提交超时，事务协调器也会中止当前事务。
Producer：向事务协调器发送AbortTransaction(TxId)请求并等待响应。(一个没有异常的响应表示事务将会中止)
Coordinator：向事务控制主题追加PREPARE_ABORT(TxId)消息，然后向生产者发送响应。
Coordinator：向事务业务数据的目标主题的每个涉及到的Leader分区Broker发送AbortTransaction(TxId, partitions…)请求。(收到Leader分区Broker响应后，事务协调器中止动作跟上面的提交类似)

08 基本事务流程的失败

生产者发送BeginTransaction(TxId):的时候超时或响应中包含异常，生产者使用相同的TxId重试。
生产者发送数据时的Broker错误：生产者应中止（然后重做）事务（使用新的TxId）。如果生产者没有中止事务，则协调器将在事务超时后中止事务。仅在可能已将请求数据附加并复制到Follower的错误的情况下才需要重做事务。例如，生产者请求超时将需要重做，而NotLeaderForPartitionException不需要重做。
生产者发送CommitTransaction(TxId)请求超时或响应中包含异常，生产者使用相同的TxId重试事务。此时需要幂等性。

09 主题的压缩

  压缩主题在压缩过程中会丢弃具有相同键的早期记录。如果这些记录是事务的一部分，这合法吗？这可能有点怪异，但可能不会太有害，因为在主题中使用压缩策略的理由是保留关键数据的最新更新。
  如果该应用程序正在(例如)更新某些表，并且事务中的消息对应于不同的键，则这种情况可能导致数据库视图不一致。

10 相关配置
Broker configs

Producer configs

Consumer configs
--------------------------------------------------------------------------------这这以发送多条消息为例

public static void main(String[] args) {
    Map<String, Object> configs = new HashMap<>();
    configs.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, "120.77.206.207:9092");
    configs.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class);
    configs.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class);

    // 提供生产者client.id
    configs.put(ProducerConfig.CLIENT_ID_CONFIG, "tx_producer");
    // 设置事务ID
    configs.put(ProducerConfig.TRANSACTIONAL_ID_CONFIG, "my_tx_id_1");
    // 需要ISR全体确认消息
    configs.put(ProducerConfig.ACKS_CONFIG, "all");

    KafkaProducer<String, String> producer = new KafkaProducer<String, String>(configs);
    // 初始化事务
    producer.initTransactions();

    try {
        // 开启事务
        producer.beginTransaction();
        // 发送事务消息
        producer.send(new ProducerRecord<>("topicName", "key1", "message1"));
        producer.send(new ProducerRecord<>("topicName", "key2", "message2"));
        producer.send(new ProducerRecord<>("topicName", "key3", "message3"));

        int i = 1 / 0;

        // 提交事务
        producer.commitTransaction();
    } catch (Exception e) {
        e.printStackTrace();
        // 事务回滚
        producer.abortTransaction();
    } finally {
        // 关闭生产者
        producer.close();
    }
}

先介绍消息，再发送消息，整体是一个事务

public class MyTransactional {

    public static KafkaProducer<String, String> getProducer() {
        Map<String, Object> configs = new HashMap<>();
        configs.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, "120.77.206.207:9092");
        configs.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class);
        configs.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class);

        // 设置client.id
        configs.put(ProducerConfig.CLIENT_ID_CONFIG, "tx_producer_01");
        // 设置事务id
        configs.put(ProducerConfig.TRANSACTIONAL_ID_CONFIG, "tx_id_02");
        // 需要所有的ISR副本确认
        configs.put(ProducerConfig.ACKS_CONFIG, "all");
        // 启用幂等性
        configs.put(ProducerConfig.ENABLE_IDEMPOTENCE_CONFIG, true);

        KafkaProducer<String, String> producer = new KafkaProducer<String, String>(configs);

        return producer;
    }

    public static KafkaConsumer<String, String> getConsumer(String consumerGroupId) {
        Map<String, Object> configs = new HashMap<>();
        configs.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, "120.77.206.207:9092");
        configs.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class);
        configs.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class);

        // 设置消费组ID
        configs.put(ConsumerConfig.GROUP_ID_CONFIG, "consumer_grp_02");
        // 不启用消费者偏移量的自动确认，也不要手动确认
        configs.put(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG, false);
        configs.put(ConsumerConfig.CLIENT_ID_CONFIG, "consumer_client_02");
        configs.put(ConsumerConfig.AUTO_OFFSET_RESET_CONFIG, "earliest");

        // 只读取已提交的消息
//        configs.put(ConsumerConfig.ISOLATION_LEVEL_CONFIG, "read_committed");

        KafkaConsumer<String, String> consumer = new KafkaConsumer<String, String>(configs);
        return consumer;
    }

public static void main(String[] args) {

    String consumerGroupId = "consumer_grp_id_101";
    KafkaProducer<String, String> producer = getProducer();
    KafkaConsumer<String, String> consumer = getConsumer(consumerGroupId);

    // 事务的初始化,设置事务id
    producer.initTransactions();
    // 订阅主题
    consumer.subscribe(Collections.singleton("topicName"));
    // 先消费
    final ConsumerRecords<String, String> records = consumer.poll(1_000);

    // 开启事务
    producer.beginTransaction();
    try {
        Map<TopicPartition, OffsetAndMetadata> offsets = new HashMap<>();

        for (ConsumerRecord<String, String> record : records) {
            System.out.println(record);
            // 发送消息
            producer.send(new ProducerRecord<String, String>("topicName1", record.key(), record.value()));
            // value是下一条消费消息的偏移量
            offsets.put(new TopicPartition(record.topic(), record.partition()), new OffsetAndMetadata(record.offset() + 1));
        }

        // 将该消息的偏移量提交作为事务的一部分，事务提交就提交偏移量,事务回滚就不提交偏移量
        producer.sendOffsetsToTransaction(offsets, consumerGroupId);

        // 如果有一样,发送到topicName1的消息将会失败
       // int i = 1 / 0;

        // 提交事务
        producer.commitTransaction();
    } catch (Exception e) {
        e.printStackTrace();
        // 回滚事务
        producer.abortTransaction();
    } finally {
        // 关闭资源
        producer.close();
        consumer.close();
    }
}

}

用下面的命令监听topicName1主题的消息，这里要加事务的选项表示只接收已经提交的消息
kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic topicName1 --isolation-level read_committed --from-beginning

java架构师-太阳
关注
  • 0
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
【Kafka】Kafka事务是怎么实现的
九师兄
09-20 3273
如果采用这种方案，那么一般是按照不同的延时等级来划分的，比如设定5s、10s、30s、1min、2min、5min、10min、20min、30min、45min、1hour、2hour这些按延时时间递增的延时等级，延时的消息按照延时时间投递到不同等级的主题中，投递到同一主题中的消息的延时时间会被强转为与此主题延时等级一致的延时时间，这样延时误差控制在两个延时等级的时间差范围之内（比如延时时间为17s的消息投递到30s的延时主题中，之后按照延时时间为30s进行计算，延时误差为13s）。
关于Kafka事务处理的详细讲解
lukystarlgq的博客
01-02 1366
producer可能给多个topic，多个partition发送消息，这些消息组成一个事务，这些消息需要对consumer同时可见或者同时不可见。Kafka事务需要在producer端处理，consumer端不需要做特殊处理，跟普通消息消费一样。
Kafka
weisanju
05-18 268
Kafka是如何保证数据的可靠性? 副本机制 单个topic可以有多个 分区, 每个分区 都可以设置 副本数量,只有一个leader副本进行外部数据的写入,然后由leader将数据转发给各个副本,保证集群间数据的一致. acks参数 三种选项 不等待答复|等待leader答复|等待所有节点答复 ISR机制 ISR机制保证了leader写入数据成功并且至少有一个follower同步完成leader的数据，才会认为消息发送成功 每个partition中会维护着一个ISR列表包含leader，还有与它同步的fol
kafka高可用集群搭建
憧憬个人博客
07-16 1232
kafka高可用集群搭建 说明 这篇博文主要是为了后面的 elk 做准备，我们这里搭建一个 kafka 集群，使用2个节点，还是前面的节点。主要是为了后面做数据缓冲。 这里不对 mq 的详细进行介绍，必要会对 kafka 相关配置进行描述。 节点说明 节点 hostname 192.168.179.123 node-5 192.168.179...
Kafka（六）生产者事务
qq_41982570的博客
04-02 902
Kafka 生产者事务
kafka事务性实现
热门推荐
蝉之洞
06-11 2万+
转自：http://matt33.com/2018/11/04/kafka-transaction/侵删 这篇文章是 Kafka Exactly-Once 实现系列的第二篇，主要讲述 Kafka 事务性的实现，这部分的实现要比幂等性的实现复杂一些，幂等性实现是事务性实现的基础，幂等性提供了单会话单 Partition Exactly-Once 语义的实现，正是因为 Idempotent Pro...
spring boot操作kafka例子
10-21
在这个`train-kafka`压缩包中，可能包含了一些示例代码或教程，帮助你更好地理解和实践这些知识点。如果你遇到任何问题，可以查阅这些资源，或者参考Apache Kafka和Spring Boot的官方文档，以获取更详细的指导。在...
designing-distributed-systems:《设计分布式系统》一书中的示例代码和配置文件
03-11
提供的压缩包"designing-distributed-systems-master"包含了书中示例代码和配置文件，这对于读者理解和实践分布式系统的设计理念至关重要。 在分布式系统设计中，我们关注以下几个核心知识点： 1. **一致性模型**...
大型电商分布式系统实践（视频+源码）代码.zip
最新发布
02-03
例如，课时1可能是介绍分布式系统的基本概念，课时2可能涉及负载均衡和集群，课时6可能讲解缓存机制，如Redis的使用，而课时12可能是关于数据一致性与事务管理的深入讨论。 3. "课时10" - 通常在课程的后期，可能会...
《Java开发典型模块大全》光盘
11-14
这个光盘提供的源代码是学习和参考的重要资料，涵盖了广泛的Java编程概念和实践。 首先，我们来探讨Java模块化开发的重要性。在Java中，模块化是组织代码的一种高效方式，它允许将大型项目分解为小而独立的部分，每...
spring4.x-chapter9:精通Spring4.x企业应用开发实战Chapter9
03-23
本章会详细解释AOP的概念、通知类型（前置、后置、环绕、异常和最终通知）以及如何定义和使用切点表达式。 2. **Spring事务管理**：Spring提供了编程式和声明式两种事务管理方式。编程式事务管理通过...
Kafka的幂等性与事务性理解
淡定一生2333的博客
09-08 6431
最近在深入理解Flink的Exactly-Once，发现Flink Checkpoint只能保障Flink程序内部的一致性，无法保证Sink到外部系统的Exactly-Once语义。但是Sink到外部如果实现了TwoPhaseCommitSinkFunction这个抽象类就能实现端到端的Exactly-Once语义，而Kafka刚好也实现了这个这个类，所以先来研究下Kafka的Exactly-Once是怎么实现的。 在Producer向Kafka发送消息的时候，如果消息成功被写入到日志文件...
Kafka 事务
程序猿进阶
04-24 1533
在了解 Kafka的事务之前，先说一下 Kafka中幂等和事务（Kafka 0.11.0.0版本引入的两个特性）以此来实现 Exactly once（精确一次）了解更多链接。 幂等：生产者在进行重试的时候有可能会重复写入消息，而使用 Kafka的幂等性功能之后就可以避免这种情况。 生产者事务相关配置 开启幂等性功能的方式很简单，只需显式地将生产者客户端参数 enable.idempotence=true（默认值为false）Kafka的幂等只能保证单个生产者会话（session）中单分区的幂等。幂
Kafka事务消息详解
wanger61的博客
10-08 4546
如果消费者先处理消息后提交位移，那么如果在消息处理之后在位移提交之前消费者宕机了，那么重新上线后，会从上一次位移提交的位置拉取，这就导致了重复消息，对应 at least once。反过来，如果先提交位移后处理消息，就有可能会造成消息的丢失，对应 at most once。设置为 true即可（默认为false），开启后生产者就会幂等的发送消息。Kafka提供了幂等机制，只需显式地将生产者客户端参数。注意：序列号实现幂等只是针对每一对，即。Kafka消费者消息保障主要。
Kafka for java 简单使用（二）
口袋里的小龙的专栏
11-22 1466
本文简单的介绍 kafka在java 环境下的 连接和使用方法
大数据开发：Kafka事务实现流程
shuimuzh123的博客
06-11 435
在Kafka框架当中，一个重要的概念，就是事务，在流处理场景下，Kafka事务应用广泛，搞懂Kafka事务这一块，也是学习当中的重要任务。今天的大数据开发学习分享，我们就主要来讲讲Kafka事务的具体实现流程。 Kafka事务听起来比较空洞，举个简单的例子，比如原子性的读取消息，立即处理和发送，如果中途出现错误，支持回滚操作。Kafka事务处理流程 Kafka的整个事务处理流程如下图： 上图中的Transaction Coordinator运行在Kafka服务端，下面简称TC服务。 __tran.
Kafka事务提交位点失败
qq422243639的博客
11-01 2524
记一次kafka事务提交失败 线上业务报错： 2019-10-29/20:27:48.621|l-fin-ycb-sync-server1.toc.pre.ali.dm|-|-|^_^|[org.springframework.kafka.KafkaListenerEndpointContainer#1-1-C-1] ERROR o.s.k.l.KafkaMessageListenerContai...
MQ 解决分布式事务的一些思路
ShootCode
04-03 1万+
不同于单一架构应用(Monolith), 分布式环境下, 进行事务操作将变得困难, 因为分布式环境通常会有多个数据源, 只用本地数据库事务难以保证多个数据源数据的一致性. 这种情况下, 可以使用两阶段或者三阶段提交协议来完成分布式事务.但是使用这种方式一般来说性能较差, 因为事务管理器需要在多个数据源之间进行多次等待. 有一种方法同样可以解决分布式事务问题, 并且性能较好, 这就是我这篇文章要介绍的
kafka事务
liang0000zai的专栏
02-24 765
官方网址 用户提供一个事务id，用于初始化生产者。 一、额外的概念 Transaction Coordinator 类似于consumer group coordinator，管理事务日志和生产者的pid。 Transaction Log 类似于 Consumer Offsets topic，事务日志是事务的持久化存储，存储着每个活动的事务状态。已经完成的事务，其实事务日志就没有意义了。 Con...
"深入理解kafka重要概念及示例
总的来说，本文详细介绍了Kafka的重要概念及使用示例，涵盖了概念、幂等性和事务性、分区的leader和follower、消息的可靠性和限速机制等方面的内容。对于想要了解Kafka的人来说，本文是一份很好的参考资料。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值