【ES专题】ElasticSearch集群架构剖析_es集群(1)

于 2024-04-27 05:39:39 发布
阅读量1.1k 收藏 21
点赞数 7
文章标签： elasticsearch 架构 大数据
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/2401_84166236/article/details/138237480
版权
  1. 每个节点各有一个主副分片

高可用之——故障转移

  1. 主副分片之间交叉存储（node1的副本放在node3，node2放在node1，node3放在node2）

使用【cat API查看集群信息】

  • GET /_cat/nodes?v #查看节点信息
  • GET /_cat/health?v #查看集群当前状态：红、黄、绿
  • GET /_cat/shards?v #查看各shard的详细情况
  • GET /_cat/shards/{index}?v #查看指定分片的详细情况
  • GET /_cat/master?v #查看master节点信息
  • GET /_cat/indices?v #查看集群中所有index的详细信息
  • GET /_cat/indices/{index}?v #查看集群中指定index的详细信息 `
1.3 搭建三节点ES集群
1.3.1 ES集群搭建步骤

下面是在Linux环境，centos7下面的集群搭建步骤：
1）系统环境准备
首先创建用户，因为es不允许root账号启动

adduser es
passwd es

安装版本：elasticsearch-7.17.3。接着切换到root用户，修改/etc/hosts：

vim  /etc/hosts
192.168.66.150 es-node1  
192.168.66.151 es-node2  
192.168.66.152 es-node3

2）修改elasticsearch.yml
注意配置里面的注释，里面有一些细节。比如：

  1. 注意集群的名字，3个节点的集群名称必须一直
  2. 给每个节点指定名字，比如这里是node1/2/3
  3. 是否要开启外网访问，跟redis的配置差不多
# 指定集群名称3个节点必须一致
cluster.name: es-cluster
#指定节点名称，每个节点名字唯一
node.name: node-1
#是否有资格为master节点，默认为true
node.master: true
#是否为data节点，默认为true
node.data: true
# 绑定ip,开启远程访问,可以配置0.0.0.0
network.host: 0.0.0.0
#用于节点发现
discovery.seed_hosts: ["es-node1", "es-node2", "es-node3"]
#7.0新引入的配置项,初始仲裁，仅在整个集群首次启动时才需要初始仲裁。
#该选项配置为node.name的值，指定可以初始化集群节点的名称
cluster.initial_master_nodes: ["node-1","node-2","node-3"]
#解决跨域问题
http.cors.enabled: true
http.cors.allow-origin: "\*"

三个节点配置很简单，按照上面的模板，依次修改node.name就行了

3) 启动每个节点的ES服务

# 注意：如果运行过单节点模式，需要删除data目录， 否则会导致无法加入集群
rm -rf data
# 启动ES服务
bin/elasticsearch -d

4）验证集群
正常来说，如果我们先启动了192.168.66.150，那么它就是这个集群当中的主节点，所以我们验证集群的话，只需要访问http://192.168.66.150:9200即可看到如下界面：
在这里插入图片描述

1.3.2 安装客户端

介绍完了ES的集群部署，我们再来看看ES客户端的部署。这里有两个可选方案，它们分别是Cerebro和Kibana，它们的区别与联系如下：

Cerebro和Kibana都是用于Elasticsearch的开源工具，但它们在功能和使用场景上存在一些区别。

功能：

  • Cerebro：Cerebro是Elasticsearch的图形管理工具，可以查看分片分配和执行常见的索引操作，功能集中管理alias和index template，十分快捷。此外，Cerebro还具有实时监控数据的功能。
  • Kibana：Kibana是一个强大的可视化工具，可以用于Elasticsearch数据的探索、分析和展示。它提供了丰富的图表类型，包括折线图、直方图、饼图等，可以方便地展示基于时间序列的数据。此外，Kibana还提供了日志管理、分析和展示的功能

使用场景：

  • Cerebro：Cerebro适合用于生产和测试环境的Elasticsearch集群管理，尤其适用于需要快速查看和执行索引操作的情况。由于Cerebro轻量且适用于实时监控，它可能更适用于较小的集群和实时监控的场景。
  • Kibana：Kibana适合对Elasticsearch数据进行深入的分析和探索，以及对日志进行管理和分析。它提供了丰富的可视化功能和灵活的数据展示方式，适用于各种规模的数据分析和监控场景。

Cerebro安装
Cerebro 可以查看分片分配和通过图形界面执行常见的索引操作，完全开源，并且它允许添加用户，密码或 LDAP 身份验证问网络界面。Cerebro 基于 Scala 的Play 框架编写，用于后端 REST 和 Elasticsearch 通信。 它使用通过 AngularJS 编写的单页应用程序（SPA）前端。
安装包下载地址如下：https://github.com/lmenezes/cerebro/releases/download/v0.9.4/cerebro-0.9.4.zip

下载安装之后，用以下命令启动即可：

cerebro-0.9.4/bin/cerebro

#后台启动
nohup bin/cerebro > cerebro.log &

访问：http://192.168.66.150:9000/
在这里插入图片描述
输入ES集群节点：http://192.168.66.150:9200，建立连接。然后会出现以下界面：
在这里插入图片描述
kibana安装
1）修改kibana配置

vim config/kibana.yml

server.port: 5601
server.host: "192.168.66.150" 
elasticsearch.hosts: ["http://192.168.66.150:9200","http://192.168.66.151:9200","http://192.168.66.152:9200"]  
i18n.locale: "zh-CN"

2）运行Kibana

#后台启动
nohup  bin/kibana &

3）访问
访问http://192.168.66.150:5601/验证

二、生产环境最佳实践

2.1 一个节点只承担一个角色的配置

我们在上面的介绍中知道，节点有多种不同的类型（角色），有：Master eligible / Data / Ingest / Coordinating /Machine Learning等。不过跟之前学习的各种集群架构不同的是，ES一个节点可承担多种角色。
不过，在生产环境中尽量还是一个节点一种角色比较好，优点是：极致的高可用；缺点是：可能有点费钱
想要一个节点只承担一个角色，只需要修改如下配置：

#Master节点
node.master: true
node.ingest: false
node.data: false

#data节点
node.master: false
node.ingest: false
node.data: true

#ingest 节点
node.master: false
node.ingest: true
node.data: false

#coordinate节点
node.master: false
node.ingest: false
node.data: false
2.2 增加节点水平扩展场景

在实际生产中，我们可能会遇到需要水平扩展容量的场景，通常来说，以下是几个常见的场景：

  • 当磁盘容量无法满足需求时，可以增加数据节点
  • 磁盘读写压力大时，增加数据节点
  • 当系统中有大量的复杂查询及聚合时候，增加Coordinating节点，增加查询的性能
2.3 异地多活架构

下面是一个多集群架构。集群处在三个数据中心，数据三写，使用GTM分发读请求
在这里插入图片描述

全局流量管理（GTM）和负载均衡（SLB）的区别：
GTM 是通过DNS将域名解析到多个IP地址，不同用户访问不同的IP地址，来实现应用服务流量的分配。同时通过健康检查动态更新DNS解析IP列表，实现故障隔离以及故障切换。最终用户的访问直接连接服务的IP地址，并不通过GTM。
而 SLB 是通过代理用户访问请求的形式将用户访问请求实时分发到不同的服务器，最终用户的访问流量必须要经过SLB。 一般来说，相同Region使用SLB进行负载均衡，不同region的多个SLB地址时，则可以使用GTM进行负载均衡。

2.4 Hot & Warm 架构

热节点存放用户最关心的热数据；温节点或者冷节点存放用户不太关心或者关心优先级低的冷数据或者暖数据。
它的典型的应用场景如下：
在成本有限的前提下，让客户关注的实时数据和历史数据硬件隔离，最大化解决客户反应的响应时间慢的问题。业务场景描述：每日增量6TB日志数据，高峰时段写入及查询频率都较高，集群压力较大，查询ES时，常出现查询缓慢问题。

  • ES集群的索引写入及查询速度主要依赖于磁盘的IO速度，冷热数据分离的关键为使用SSD磁盘存储热数据，提升查询效率。
  • 若全部使用SSD，成本过高，且存放冷数据较为浪费，因而使用普通SATA磁盘与SSD磁盘混搭，可做到资源充分利用，性能大幅提升的目标。

ES为什么要设计Hot & Warm 架构呢？

  • ES数据通常不会有 Update操作;
  • 适用于Time based索引数据，同时数据量比较大的场景。
  • 引入 Warm节点，低配置大容量的机器存放老数据，以降低部署成本

两类数据节点，不同的硬件配置：

  • Hot节点(通常使用SSD)︰索引不断有新文档写入。
  • Warm 节点（通常使用HDD)︰索引不存在新数据的写入，同时也不存在大量的数据查询

Hot Nodes：用于数据的写入

  • lndexing 对 CPU和IO都有很高的要求，所以需要使用高配置的机器
  • 存储的性能要好，建议使用SSD
    在这里插入图片描述

Warm Nodes
用于保存只读的索引，比较旧的数据。通常使用大容量的磁盘
在这里插入图片描述

配置Hot & Warm 架构
使用Shard Filtering实现Hot&Warm node间的数据迁移

  • node.attr来指定node属性：hot或是warm。
  • 在index的settings里通过index.routing.allocation来指定索引（index)到一个满足要求的node
    在这里插入图片描述
    使用 Shard Filtering，步骤分为以下几步：
  • 标记节点(Tagging)
  • 配置索引到Hot Node
  • 配置索引到 Warm节点

1）标记节点
需要通过“node.attr”来标记一个节点

  • 节点的attribute可以是任何的key/value
  • 可以通过elasticsearch.yml 或者通过-E命令指定
# 标记一个 Hot 节点
elasticsearch.bat  -E node.name=hotnode -E cluster.name=tulingESCluster -E http.port=9200 -E path.data=hot_data -E node.attr.my\_node\_type=hot

# 标记一个 warm 节点
elasticsearch.bat  -E node.name=warmnode -E cluster.name=tulingESCluster -E http.port=9201 -E path.data=warm_data -E node.attr.my\_node\_type=warm

# 查看节点
GET /_cat/nodeattrs?v

2）配置Hot数据
创建索引时候，指定将其创建在hot节点上

# 配置到 Hot节点
PUT /index-2022-05
{
  "settings":{
    "number\_of\_shards":2,
    "number\_of\_replicas":0,
    "index.routing.allocation.require.my\_node\_type":"hot"
  }
}

POST /index-2022-05/_doc
{
  "create\_time":"2022-05-27"
}

#查看索引文档的分布
GET _cat/shards/index-2022-05?v

3）旧数据移动到Warm节点
Index.routing.allocation是一个索引级的dynamic setting，可以通过API在后期进行设定

# 配置到 warm 节点
PUT /index-2022-05/_settings
{  
  "index.routing.allocation.require.my\_node\_type":"warm"
}
GET _cat/shards/index-2022-05?v
2.5 如何对集群的容量进行规划

一个集群总共需要多少个节点?一个索引需要设置几个分片？规划上需要保持一定的余量，当负载出现波动，节点出现丢失时，还能正常运行。做容量规划时，一些需要考虑的因素：

  • 机器的软硬件配置
  • 单条文档的大小│文档的总数据量│索引的总数据量（(Time base数据保留的时间)|副本分片数
  • 文档是如何写入的(Bulk的大小)
  • 文档的复杂度，文档是如何进行读取的(怎么样的查询和聚合)

评估业务的性能需求：

  • 数据吞吐及性能需求
    • 数据写入的吞吐量，每秒要求写入多少数据?
    • 查询的吞吐量?
  • 单条查询可接受的最大返回时间?
    • 了解你的数据
    • 数据的格式和数据的Mapping
    • 实际的查询和聚合长的是什么样的

ES集群常见应用场景：

  • 搜索: 固定大小的数据集
    • 搜索的数据集增长相对比较缓慢
  • 日志: 基于时间序列的数据
    • 使用ES存放日志与性能指标。数据每天不断写入，增长速度较快
    • 结合Warm Node 做数据的老化处理

硬件配置：

  • 选择合理的硬件，数据节点尽可能使用SSD
  • 搜索等性能要求高的场景，建议SSD
    • 按照1∶10-20的比例配置内存和硬盘
  • 日志类和查询并发低的场景，可以考虑使用机械硬盘存储
    • 按照1:50的比例配置内存和硬盘
  • 单节点数据建议控制在2TB以内，最大不建议超过5TB
  • JVM配置机器内存的一半，JVM内存配置不建议超过32G
  • 不建议在一台服务器上运行多个节点

内存大小要根据Node 需要存储的数据来进行估算

  • 搜索类的比例建议: 1:16
  • 日志类: 1:48——1:96之间

假设总数据量1T，设置一个副本就是2T总数据量

  • 如果搜索类的项目，每个节点31*16 = 496 G，加上预留空间。所以每个节点最多400G数据，至少需要5个数据节点
  • 如果是日志类项目，每个节点31*50= 1550 GB，2个数据节点即可

部署方式：

  • 按需选择合理的部署方式
  • 如果需要考虑可靠性高可用，建议部署3台单一的Master节点
  • 如果有复杂的查询和聚合，建议设置Coordinating节点

集群扩容：

  • 增加Coordinating / Ingest Node
  • 解决CPU和内存开销的问题
  • 增加数据节点
  • 解决存储的容量的问题
  • 为避免分片分布不均的问题，要提前监控磁盘空间，提前清理数据或增加节点
2.6 如何设计和管理分片

单个分片

  • 7.0开始，新创建一个索引时，默认只有一个主分片。单个分片，查询算分，聚合不准的问题都可以得以避免
  • 单个索引，单个分片时候，集群无法实现水平扩展。即使增加新的节点，无法实现水平扩展

两个分片
集群增加一个节点后，Elasticsearch 会自动进行分片的移动，也叫 Shard Rebalancing
在这里插入图片描述

算分不准的原因
相关性算分在分片之间是相互独立的，每个分片都基于自己的分片上的数据进行相关度计算。这会导致打分偏离的情况，特别是数据量很少时。当文档总数很少的情况下，如果主分片大于1，主分片数越多，相关性算分会越不准
一个示例如下：

PUT /blogs
{
  "settings":{
    "number\_of\_shards" : "3"
  }
}

POST /blogs/_doc/1?routing=fox
{
 "content":"Cross Cluster elasticsearch Search"
}

POST /blogs/_doc/2?routing=fox2
{
 "content":"elasticsearch Search"
}

POST /blogs/_doc/3?routing=fox3
{
 "content":"elasticsearch"
}

GET /blogs/_search
{
  "query": {
    "match": {
      "content": "elasticsearch"
    }
  }
}

#解决算分不准的问题
GET /blogs/_search?search_type=dfs_query_then_fetch
{
  "query": {
    "match": {
      "content": "elasticsearch"
    }
  }
}

解决算分不准的方法：

  • 数据量不大的时候，可以将主分片数设置为1。当数据量足够大时候，只要保证文档均匀分散在各个分片上，结果一般就不会出现偏差
  • 使用DFS Query Then Fetch
    • 搜索的URL中指定参数“_search?search_type=dfs_query_then_fetch"
    • 到每个分片把各分片的词频和文档频率进行搜集，然后完整的进行一次相关性算分

但是这样耗费更加多的CPU和内存，执行性能低下，一般不建议使用

如何设计分片数
当分片数>节点数时

  • 一旦集群中有新的数据节点加入，分片就可以自动进行分配
  • 分片在重新分配时，系统不会有downtime

多分片的好处: 一个索引如果分布在不同的节点，多个节点可以并行执行

  • 查询可以并行执行
  • 数据写入可以分散到多个机器

分片过多所带来的副作用
Shard是Elasticsearch 实现集群水平扩展的最小单位。过多设置分片数会带来一些潜在的问题：

  • 每个分片是一个Lucene的索引，会使用机器的资源。过多的分片会导致额外的性能开销。
  • 每次搜索的请求,需要从每个分片上获取数据
  • 分片的Meta 信息由Master节点维护。过多，会增加管理的负担。经验值，控制分片总数在10W以内

如何确定主分片数
从存储的物理角度看：

  • 搜索类应用，单个分片不要超过20 GB
  • 日志类应用，单个分片不要大于50 GB

为什么要控制分片存储大小：

  • 提高Update 的性能
  • 进行Merge 时，减少所需的资源
  • 丢失节点后，具备更快的恢复速度
  • 便于分片在集群内 Rebalancing

如何确定副本分片数
副本是主分片的拷贝：

  • 提高系统可用性︰响应查询请求，防止数据丢失
  • 需要占用和主分片一样的资源

img
img
img

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化资料的朋友，可以戳这里获取

储的物理角度看：

  • 搜索类应用，单个分片不要超过20 GB
  • 日志类应用，单个分片不要大于50 GB

为什么要控制分片存储大小：

  • 提高Update 的性能
  • 进行Merge 时，减少所需的资源
  • 丢失节点后，具备更快的恢复速度
  • 便于分片在集群内 Rebalancing

如何确定副本分片数
副本是主分片的拷贝：

  • 提高系统可用性︰响应查询请求，防止数据丢失
  • 需要占用和主分片一样的资源

[外链图片转存中…(img-RVRJ3CYZ-1714167560233)]
[外链图片转存中…(img-VaEIMcct-1714167560233)]
[外链图片转存中…(img-evJ0my5l-1714167560234)]

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化资料的朋友，可以戳这里获取

2401_84166236
关注
  • 7
    点赞
  • 踩
  • 21
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
【ES专题】ElasticSearch集群架构剖析_es集群(2)
2401_84166258的博客
04-30 745
诸如。
2024年最新【ES专题】ElasticSearch集群架构剖析_es集群，系列篇
最新发布
2301_79098963的博客
05-05 791
诸如。
【ES专题】ElasticSearch集群架构剖析
qq_32681589的博客
11-05 3499
使用何种通信协议去同步数据，互相通信采用何种策略同步数据（异步还是同步）如何保证一致性，保证到什么程度（【最终一致性】 or【实时一致性 / 强一致性】）使用何种算法去选举主次节点（感觉这个比较随意，通常为了快速恢复服务，选举流程是怎么快怎么来，但是不能出现【脑裂问题】）
Elasticsearch的基本概念及架构剖析
meser88的博客
06-09 2657
Elaticsearch，简称为ES， ES是一个开源的高扩展的分布式全文检索引擎，它可以近乎实时的存储、检索数据;本身扩展性很好，可以扩展到上百台服务器，处理PB级别的数据。ES也使用Java开发并使用Lucene作为其核心来实现所有索引和搜索的功能，但是它的目的是通过简单的RESTful API来隐藏Lucene的复杂性，从而让全文搜索变得简单。
ES—集群架构详解
热门推荐
不是很懂
03-19 2万+
ES集群节点介绍 master node：整个集群的管理者，索引管理，分片管理，以及整个集群的状态的管理，master节点是从master候选节点中选出的，成为master候选节点的方式： node.master:true 默认（true） data node：数据节点，存储主要数据，负责索引的数据的检索和聚合等操作，成为data node的方式： node.data:true 默认（true） coordinating node：协调节点，所有节点都可以接受来自客户端的请求进行转发，因为每个节点都知道
ElasticSearch（七）：集群架构
Men-DD
07-27 3418
搭建三节点ES集群;安装Cerebro客户端;安装kibana ES安全认证;集群内部安全通信;开启并配置X-Pack的认证 生产环境常见集群部署方式;增加节点水平扩展场景;读写分离架构;异地多活架构;Hot & Warm 架构 ES跨集群搜索 分片的设计和管理;如何设计分片数;如何确定主分片数;如何确定副本分片数 ES底层读写工作原理;ES写入数据的过程;ES读取数据的过程;写数据底层原理 如何提升集群的读写性能;提升集群读取性能的方法;提升写入性能的方法......
三十、elasticsearch集群
icbbm的博客
11-28 1946
Elasticsearch是一个开源的分布式搜索引擎，能够快速地进行全文检索、结构化搜索、分析等操作。为了增加其可靠性和容错性，Elasticsearch支持多节点之间的集群，并采用了Shard（分片）和Replica（副本）机制来分摊负载、提高可用性。下面我们来详细讲解一下Elasticsearch集群的概念、架构和部署方式。
滴滴Elasticsearch多集群架构实践
02-24
Elasticsearch是基于Lucene实现的分布式搜索引擎，提供了海量数据实时检索和分析能力。Elastic公司开源的一系列产品组成的ElasticStack，可以为日志服务、搜索引擎、系统监控等提供简单、易用的解决方案。滴滴2016年...
CentOS7下搭建多节点Elasticsearch集群.docx
10-26
知识点 1：Elasticsearch 集群架构 Elasticsearch 集群架构主要包括三个部分：生产服务器、应用服务器和 Elasticsearch 集群。生产服务器（kafka1 和 kafka2）负责采集数据，应用服务器（kafka3）负责对数据进行...
Elasticsearch集群部署.docx
07-30
### Elasticsearch集群部署与配置详解 #### 一、概述 Elasticsearch是一款基于Lucene的分布式搜索和分析引擎，适用于各种大规模的数据应用场景。本篇文档旨在详细介绍如何在CentOS 7.6环境下部署并配置Elastic...
ES(ElasticSearch)快速入门和集群搭建
m0_55794726的博客
12-02 3155
ES作为一个索引及搜索服务，对外提供丰富的REST接口，快速入门部分的实例使用kibana来测试，目的是对ES的使用方法及流程有个初步的认识。
ElasticSearch入门
文盲青年的博客
02-21 548
https://blog.csdn.net/achuo/article/details/87865141
ES架构及原理
LinYaoGai的博客
08-25 2691
Elasticsearch 是一个兼有搜索引擎和NoSQL数据库功能的开源系统，基于Java/Lucene构建，可以用于全文搜索，结构化搜索以及近实时分析。可以说Lucene是当今最先进，最高效的全功能开源搜索引擎框架。 说明： Lucene：只是一个框架，要充分利用它的功能，需要使用JAVA，并且在程序中集成Lucene，学习成本高，Lucene确实非常复杂。 Elasticsearch 是 面向文档型数据库，这意味着它存储的是整个对象或者 文档，它不但会存储它们，还会为他们建立索引，这样你就可以搜索他们
ElasticSearch架构介绍及原理解析
不积跬步无以致千里 不积小流无以成江海
03-02 4991
目录 简介 架构原理 基本概念与MySQL的对比 分片机制 document路由原理 集群发现机制 shard&replica规则 避免脑裂 负载均衡 相关配置 容错过程与选举机制 扩容机制 容错机制 Lucene 结构原理 ​ Lucene索引实现 DocValues 关于ES索引与检索分片 运行原理解析 倒排索引说明 检索倒排索引 分词器Analyzer 建立索引和类型 分片内文档写入流程场景 多个分片的文档写入场景 确定文档存储位置 同步
ElasticSearch集群架构及底层原理
zxc_user的博客
01-14 2354
elasticsearch集群架构和底层原理
ES的集群部署
weixin_42666548的博客
05-26 5697
ES的集群部署
ElasticSearch 集群
凉茶铺的博客
04-24 2477
介绍了ElasticSearch 集群
互联网大厂技术-elasticsearch(es)原理-ES架构、elasticsearch架构原理、ES数据写入、数据删除、数据读取、搜索过程、检索原理、节点协调过程、搜索引擎、索引原理
码者人生的技术博客
07-20 5311
Elasticsearch 是由Lucene提供支持的搜索引擎。 它为 “搜索部分” 提供了强大的动力，而 Elasticsearch 为你提供了可扩展性，可用性，REST API，专门的数据结构等（从广义上来说）。 Elasticsearch 架构的概略示意图 从图中可以看出，Elasticsearch 在可用节点上对每个 Lucene 索引进行了分片。 分片可以是主分片或副本分片。 每个分片都是一个 Lucene 索引，这些索引中的每个索引都可以具有多个 segment，每个 segem...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值