Elasticsearch Index Monitoring(索引监控)之Index Stats API详解

本文详细介绍了Elasticsearch Index Monitoring监控命令之Index Stats API。阐述了该API默认返回的各类统计信息,如docs、store、indexing等方面。还说明了返回结果在索引级别的聚合维度,最后给出了在JAVA中使用该API的示例。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

本文将详细介绍Elasticsearch Index Monitoring监控命令之Index Stats API。
索引状态统计。默认情况下,该API会返回所有类型的统计信息,Indices Stats返回如下类型的统计信息:

1、docs
文档总数量(包含已删除的文档),调用文档删除API后并不会立即将文档物理删除,会保留一段时间,受refreshing the index的影响。其返回示例如下:

"docs" : {
         "count" : 1286,
          "deleted" : 0
  }

2、store
索引存储的总大小,其返回示例如下:

"store" : {
       "size_in_bytes" : 459254 
}

其返回字段说明如下:

  • size_in_bytes
    索引大小,单位为字节。

3、indexing
新增、更新、删除索引操作的统计信息,其返回示例如下:

"indexing" : {
         	 "index_total" : 0,     
          	"index_time_in_millis" : 0, 
          	"index_current" : 0,            
         	 "index_failed" : 0,              
          	"delete_total" : 0,                
          	"delete_time_in_millis" : 0, 
         	 "delete_current" : 0,           
          	"noop_update_total" : 0,     
          	"is_throttled" : false,            
          	"throttle_time_in_millis" : 0  
        }

其返回字段说明如下:

  • index_total
    索引操作总次数。
  • index_time_in_millis
    索引操作总耗时。
  • index_current
    当前正在执行索引操作的个数。
  • index_failed
    失败的索引操作次数。
  • delete_total
    执行删除索引操作的次数。
  • delete_time_in_millis
    删除索引操作总耗时。
  • delete_current
    当前正在执行删除索引操作的个数。
  • noop_update_total
    空更新总次数(检测到空更新的次数)。
  • is_throttled
    索引是否处在merge throttling control(合并节流控制状态)。
  • throttle_time_in_millis
    索引处在merge throttling control(合并节流状态)的时间开销。

4、get
get api 统计信息,其返回示例如下:

"get" : {
          "total" : 0,                             
          "time_in_millis" : 0,              
          "exists_total" : 0,                  
          "exists_time_in_millis" : 0,    
          "missing_total" : 0,                
          "missing_time_in_millis" : 0,  
          "current" : 0                            
}

其返回字段说明如下:

  • total
    get api总调用次数。
  • time_in_millis
    get api总耗时。
  • exists_total
    命中的次数。
  • exists_time_in_millis
    命中的操作总耗时。
  • missing_total
    未命中的总次数。
  • missing_time_in_millis
    未命中的操作的总耗时。
  • current
    当前正在执行的个数。

5、search
查询API的统计信息,其返回示例如下:

       "search" : {
          "open_contexts" : 0,                      
          "query_total" : 0,                            
          "query_time_in_millis" : 0,             
          "query_current" : 0,                       
          "fetch_total" : 0,                             
          "fetch_time_in_millis" : 0,              
          "fetch_current" : 0,                        
          "scroll_total" : 0,                            
          "scroll_time_in_millis" : 0,             
          "scroll_current" : 0,                       
          "suggest_total" : 0,                       
          "suggest_time_in_millis" : 0,        
          "suggest_current" : 0                    
        },

其返回字段说明如下:

  • open_contexts
    正在打开的查询上下文个数。
  • query_total
    查询出来的总数据条数。
  • query_time_in_millis
    查询阶段所耗费的时间。
  • query_current
    当前正在查询个数。
  • fetch_total
    Fetch操作的次数。
  • fetch_time_in_millis
    Fetch阶段总耗时时间。
  • fetch_current
    正在fetch的次数。
  • scroll_total
    通过scroll api查询数据总条数。
  • scroll_time_in_millis
    通过scroll api总耗时时间。
  • scroll_current
    当前滚动API调用次数。
  • suggest_total
    通过suggest api获取的推荐总数量。
  • suggest_time_in_millis
    suggest总耗费时间。
  • suggest_current
    正在执行suggest api的个数。

6、merges
合并相关的统计信息,其输出示例如下:

   "merges" : {
        "current" : 0,                                                        
        "current_docs" : 0,                                        
        "current_size_in_bytes" : 0,                                
        "total" : 0,                                                            
        "total_time_in_millis" : 0,                               
        "total_docs" : 0,                                                 
        "total_size_in_bytes" : 0,                                    
        "total_stopped_time_in_millis" : 0,                     
        "total_throttled_time_in_millis" : 0,                     
        "total_auto_throttle_in_bytes" : 104857600       
      }

其返回字段说明如下:

  • current
    总发生的合并次数。
  • current_docs
    当前正在发生合并的文档数。
  • current_size_in_bytes
    当前合并参与的文档总大小,单位字节。
  • total
    总发生的合并次数。
  • total_time_in_millis
    合并的总耗时(单位毫秒)。
  • total_docs
    merge(合并)时总处理的文档个数。
  • total_size_in_bytes
    merge(合并)时总处理的文档总大小(字节)。
  • total_stopped_time_in_millis
    merge(合并)时总停止时间(吞吐率为0)。
  • total_throttled_time_in_millis
    超过指定吞吐率而暂停的时间(节流)。
  • total_auto_throttle_in_bytes
    自动进行流控的阔值,默认速率20m/s。

7、refresh
刷新索引相关的统计。

       "refresh" : {
        "total" : 15,                                                               
        "total_time_in_millis" : 0,                                         
        "listeners" : 0                                                          
      }

其返回字段说明如下:

  • total
    执行刷新的总次数。
  • total_time_in_millis
    执行刷新总耗时。
  • listeners
    等待刷新侦听器的数量。

8、flush
刷盘的统计信息。

"flush" : {
        "total" : 5,                                                        
        "periodic" : 0,                                                  
        "total_time_in_millis" : 0                                 
      }

其返回字段说明如下:

  • total
    执行刷盘操作的次数。
  • periodic
    当translog超过刷新阈值时周期性触发的刷新次数。
  • total_time_in_millis
    刷盘操作总耗时时间。

9、warmer
索引分片(shard)预热统计信息,分片预热是指为索引创建一个分片节点时,是否对该索引预热(为索引创建一bitSet位图)。其统计示例如下:

"warmer" : {
        "current" : 0,    
        "total" : 5,        
        "total_time_in_millis" : 0   
      }

其返回字段说明如下:

  • current
    当前正在预热的个数。
  • total
    总共发生的预热次数。
  • total_time_in_millis
    分片预热总耗时。

10、query_cache
查询缓存统计信息,其示例如下:

"query_cache" : {
        "memory_size_in_bytes" : 0,   
        "total_count" : 0,                     
        "hit_count" : 0,                        
        "miss_count" : 0,                   
        "cache_size" : 0,                    
        "cache_count" : 0,                 
        "evictions" : 0                        
      }

其返回字段说明如下:

  • memory_size_in_bytes
    查询缓存占用的内存空间,单位为字节。
  • total_count
    缓存中查询的总次数,等于hit_count + miss_count。
  • hit_count
    查询缓存命中的次数。
  • miss_count
    查询缓存未命中的次数。
  • cache_size
    当前查询缓存中缓存文档的个数。
  • cache_count
    查询缓存总缓存文档个数(包含已经被换出evictions的文档个数)。
  • evictions
    查询缓存被逐出的总数。

11、fielddata
fielddata统计信息,fielddata主要用加快text字段排序与聚合的性能,存储词根与文档的映射关系存储在在内存,在内存中进行排序与聚合。

"fielddata" : {
          "memory_size_in_bytes" : 0,         
          "evictions" : 0                                 
        }

其返回字段说明如下:

  • memory_size_in_bytes
    当前占用内存的大小。
  • evictions
    被逐出词根的个数。

12、completion
completion(自动填充)相关统计,其输出示例为:

"completion" : {
          "size_in_bytes" : 0                 
 },

其返回字段说明如下:

  • size_in_bytes
    自动提示占用字节数。

13、segments
检索打开段的内存使用情况。可选地,设置include_segment_file_size=true(默认为false),将输出每个Lucene索引文件的聚合磁盘使用情况,其返回示例如下:

"segments" : {
          "count" : 32,                                                         
          "memory_in_bytes" : 38078,                                
          "terms_memory_in_bytes" : 23838,                     
          "stored_fields_memory_in_bytes" : 9984,            
          "term_vectors_memory_in_bytes" : 0,                  
          "norms_memory_in_bytes" : 2048,                       
          "points_memory_in_bytes" : 32,                           
          "doc_values_memory_in_bytes" : 2176,               
          "index_writer_memory_in_bytes" : 0,                   
          "version_map_memory_in_bytes" : 0,                  
          "fixed_bit_set_memory_in_bytes" : 0,                  
          "max_unsafe_auto_id_timestamp" : -1,              
          "file_sizes" : { }                                                  
   },

其返回字段说明如下:

  • count
    该索引目前拥有的总段数。
  • memory_in_bytes
    该索引缓存在内存中字节数。
  • terms_memory_in_bytes
    倒排索引(term)缓存在内中所占字节数。
  • stored_fields_memory_in_bytes
    该索引定义为stored_fields字段在内存中缓存的字节数。
  • term_vectors_memory_in_bytes
    该索引term_vectors(词向量)在内存中所占字节数量。
  • norms_memory_in_bytes
    该索引存储对应norms=true的字段当前在内存中缓存字节数。
  • points_memory_in_bytes
    与地理位置相关的缓存数据。
  • doc_values_memory_in_bytes
    设置为doc_values缓存在内存中的字节数(doc_values,列式存储)。
  • index_writer_memory_in_bytes
    用于优化索引写的缓存(减少写磁盘的频率)。
  • version_map_memory_in_bytes
    关于文档的版本映射所占内存大小。
  • fixed_bit_set_memory_in_bytes
    fixed_bit_set内存,专门用来做nested查询的。
  • max_unsafe_auto_id_timestamp
    es内部当前的自增ID。
  • file_sizes
    其中如果设置为true,则file_sizes主要包含如下统计信息:
    在这里插入图片描述

14、translog
translog统计信息(有点类似于Innodb的redo日志),其输出示例如下:

"translog" : {
          "operations" : 0,                                               
          "size_in_bytes" : 1100,                                    
          "uncommitted_operations" : 0,                        
          "uncommitted_size_in_bytes" : 1100,             
          "earliest_last_modified_age" : 0                     
        }

其返回字段说明如下:

  • operations
    写translog的次数(索引文档、更新文档、删除文档的总操作数量)。
  • size_in_bytes
    translog实例管理的translog文件总大小。(一个索引引擎(InternalEngine)示例包含一个Translog实例)。
  • uncommitted_operations
    当前还未提交到lucene中的操作次数(索引文档、更新文档、删除文档的操作数量)。
  • uncommitted_size_in_bytes
    translog中未提交到Lucene中的字节数。
  • earliest_last_modified_age
    以秒为单位返回translog文件中最老条目的年龄。

15、request_cache
请求缓存的统计信息,其输出示例如下:

"request_cache" : {
          "memory_size_in_bytes" : 0,                         
          "evictions" : 0,                                               
          "hit_count" : 0,                                               
          "miss_count" : 0                                            
},

其返回字段说明如下:

  • memory_size_in_bytes
    请求缓存占用内存总大小。
  • evictions
    请求缓存被剔除出次数。
  • hit_count
    请求缓存被命中次数。
  • miss_count
    请求缓存未命中次数。

16、recovery
recovery(恢复)相关的统计信息,其输出示例:

"recovery" : {
          "current_as_source" : 0,                                                  
          "current_as_target" : 0,                                
          "throttle_time_in_millis" : 0                          
}

其返回字段说明如下:

  • current_as_source
    作为源分片,正在执行恢复的分片数量 。
  • current_as_target
    作为目标分片,正在执行恢复的分片数量。
  • throttle_time_in_millis
    恢复过程总等待时间。

Indices Stats返回的结果是在索引级别的聚合,包含三个维度:primaries(所有主节点进行聚合)、total(所有主节点、副本节点进行聚合)、indices(索引级别)。

下面给出在JAVA中使用Index Stats示例来结束本篇的讲解。

ElasticSearch Index Stats JAVA示例如下:(当前elasticsearch6.4.0 High Rest Client未提供对应API的封装)

public static final void test_Indices_StatsIndex() {
      TransportClient client = EsClient.getTransportClient();
      try {
         IndicesStatsRequest request = new IndicesStatsRequest();
//       request.indices("aggregations_index02");
//       request.indices("logs_write");
//       request.includeSegmentFileSizes(true);
         ActionFuture<IndicesStatsResponse> responseFuture = client.admin().indices().stats(request);
         IndicesStatsResponse response = responseFuture.get();
         System.out.println(response);
//       System.out.println(result);
      } catch (Throwable e) {
         e.printStackTrace();
      } finally {
         EsClient.close(client);
      }
   }

其返回的结果:

{
  "_shards" : {
    "total" : 172,
    "successful" : 86,
    "failed" : 0
  },
  "_all" : {
    "primaries" : {
      "docs" : {
        "count" : 4166,
        "deleted" : 0
      },
      "store" : {
        "size_in_bytes" : 929840
      },
      // ... 省略部分选项
    },
    "total" : {
      "docs" : {
        "count" : 4166,
        "deleted" : 0
      },
      "store" : {
        "size_in_bytes" : 929840
      },
      // ... 省略部分选项
    }
  },
  "indices" : {
    "aggregations_index04" : {
      "uuid" : "2_6WutahTHa6iK52E7CwZQ",
      "primaries" : {
        // ... 省略部分选项
      },
      "total" : {
        // ... 省略部分选项
      }
    },
    "alias_demo" : {
      "uuid" : "EltFD6Y6TA-lpfntx00naw",
      "primaries" : {
        
      },
      "total" : {
        
      }
      
    } // 省略其他索引
  }
}

本文详细介绍了Index Stats API的使用,特别在结合源码的基础上给出该API响应结果中各个字段含义的解读,包含docs、store、indexing、get、search、merges、refresh、flush、warmer、query_cache、fielddata、completion、segments、translog、request_cache、recovery。


见文如面,我是威哥,热衷于成体系剖析JAVA主流中间件,关注公众号『中间件兴趣圈』,回复专栏可获取成体系专栏导航,回复资料可以获取笔者的学习思维导图。
在这里插入图片描述

ey Features Understand common performance and reliability pitfalls in ElasticSearch Use popular monitoring tools such as ElasticSearch-head, BigDesk, Marvel, Kibana, and more This is a step-by-step guide with lots of case studies on solving real-world ElasticSearch cluster issues Book Description ElasticSearch is a distributed search server similar to Apache Solr with a focus on large datasets, a schema-less setup, and high availability. This schema-free architecture allows ElasticSearch to index and search unstructured content, making it perfectly suited for both small projects and large big data warehouses with petabytes of unstructured data. This book is your toolkit to teach you how to keep your cluster in good health, and show you how to diagnose and treat unexpected issues along the way. You will start by getting introduced to ElasticSearch, and look at some common performance issues that pop up when using the system. You will then see how to install and configure ElasticSearch and the ElasticSearch monitoring plugins. Then, you will proceed to install and use the Marvel dashboard to monitor ElasticSearch. You will find out how to troubleshoot some of the common performance and reliability issues that come up when using ElasticSearch. Finally, you will analyze your cluster's historical performance, and get to know how to get to the bottom of and recover from system failures. This book will guide you through several monitoring tools, and utilizes real-world cases and dilemmas faced when using ElasticSearch, showing you how to solve them simply, quickly, and cleanly. What you will learn Explore your cluster with ElasticSearch-head and BigDesk Access the underlying data of the ElasticSearch monitoring plugins using the ElasticSearch API Analyze your cluster's performance with Marvel Troubleshoot some of the common performance and reliability issues that come up when using ElasticSearch Analyze a cluster's historical performance, and get to the bottom of and recover from system failures Use and install various other tools and plugins such as Kibana and Kopf, which is helpful to monitor ElasticSearch About the Author Dan Noble is a software engineer with a passion for writing secure, clean, and articulate code. He enjoys working with a variety of programming languages and software frameworks, particularly Python, Elasticsearch, and frontend technologies. Dan currently works on geospatial web applications and data processing systems. Dan has been a user and advocate of Elasticsearch since 2011. He has given talks about Elasticsearch at various meetup groups, and is the author of the Python Elasticsearch client rawes. Dan was also a technical reviewer for the Elasticsearch Cookbook, Second Edition, by Alberto Paro. Table of Contents Chapter 1. Introduction to Monitoring Elasticsearch Chapter 2. Installation and the Requirements for Elasticsearch Chapter 3. Elasticsearch-head and Bigdesk Chapter 4. Marvel Dashboard Chapter 5. System Monitoring Chapter 6. Troubleshooting Performance and Reliability Issues Chapter 7. Node Failure and Post-Mortem Analysis Chapter 8. Looking Forward
<think>好的,我现在需要帮助用户了解Elasticsearch(ES)的运行状态数据。首先,用户之前询问过EQL,所以可能对ES有一定的了解,现在转向运行状态数据,可能是想监控或优化他们的ES集群。接下来,我需要明确用户的需求:他们可能想知道如何获取这些数据,关键指标有哪些,以及如何解读这些数据来确保集群健康。 首先,我应该回忆ES的运行状态数据包括哪些方面。通常包括集群健康状态、节点指标、索引相关数据、分片状态、资源使用情况(如CPU、内存、磁盘)、缓存和线程池等。这些都是监控ES性能的重要指标。 然后,用户可能需要知道如何获取这些数据。常见的方法是通过API,比如`_cluster/health`,`_nodes/stats`,`_cat` API等。还要考虑工具如Kibana、Prometheus等,这些工具可以提供可视化监控。 接下来需要分步骤详细解释每个部分。比如集群健康状态的green、yellow、red分别代表什么,节点级别的指标包括JVM内存、CPU使用率,磁盘I/O等。索引层面的文档数、存储大小、查询性能等。 同时,用户可能关心如何根据这些数据诊断问题。例如,如果集群状态是red,说明有主分片未分配,这时候需要检查节点是否宕机或者磁盘空间不足。如果JVM内存使用率高,可能需要调整堆大小或优化查询。 还要注意用户可能的深层需求,比如他们可能在实际运维中遇到了性能问题,需要快速定位原因。因此,除了列出指标,还需要给出实际应用中的例子,比如如何分析慢查询,如何识别热点分片等。 需要确保语言清晰,结构合理,分点列出,方便用户理解。同时,避免使用过于专业的术语,或者在使用时进行解释。例如,解释什么是分片,为什么分片分配失败会影响集群健康。 最后,总结部分要强调监控的重要性,并推荐常用工具和最佳实践,帮助用户建立长期的监控策略。可能还需要提醒用户定期检查这些指标,预防潜在问题,而不仅仅是出现问题后才查看。 检查是否有遗漏的重要指标,比如线程池拒绝次数、缓存命中率等,这些也是诊断性能问题的关键。同时,确保每个部分的描述准确,比如JVM内存中的老年代和年轻代的区别,以及它们如何影响GC频率。 现在组织内容,先概述运行状态数据的作用,然后分模块详细讲解,每个模块包括获取方式、关键指标和实际应用示例。最后给出总结和工具推荐,确保用户能够全面理解并应用这些信息。</think>### Elasticsearch(ES)运行状态数据详解 #### 1. **概述** Elasticsearch 的运行状态数据是监控集群性能、诊断问题、优化资源的关键依据,主要包括**集群健康**、**节点资源使用**、**索引性能**、**分片状态**等核心指标。通过分析这些数据,可快速定位故障(如节点宕机、磁盘满、查询阻塞等)并保障服务稳定性。 --- #### 2. **核心数据分类与获取方式** ##### **2.1 集群健康状态** - **API**:`GET /_cluster/health` - **关键字段**: - `status`:集群状态(`green`/`yellow`/`red`)。 - `green`:所有主/副本分片正常。 - `yellow`:主分片正常,副本分片未完全分配。 - `red`:至少一个主分片未分配(严重故障)。 - `number_of_nodes`:存活节点数。 - `active_shards`:活跃分片数。 **示例**: ```json { "cluster_name": "my-cluster", "status": "yellow", "number_of_nodes": 3, "active_shards": 95, "unassigned_shards": 2 // 未分配分片数(需排查原因) } ``` --- ##### **2.2 节点状态** - **API**:`GET /_nodes/stats` - **关键指标**: - **资源使用**: - `jvm.mem.heap_used_percent`:JVM堆内存使用率(>75%需警惕)。 - `os.cpu.percent`:CPU使用率。 - `fs.total.available`:磁盘剩余空间。 - **线程池**: - `thread_pool.{search,write}.rejected`:拒绝的任务数(队列满时触发,需扩容节点或优化负载)。 - **网络与I/O**: - `transport.rx_size`/`tx_size`:网络吞吐量。 **示例**(节点级JVM状态): ```json "jvm": { "mem": { "heap_used_percent": 68, "heap_max_in_bytes": 2147483648 }, "gc": { "collectors": { "young": { "collection_count": 120, "collection_time_in_millis": 4500 }, "old": { "collection_count": 3, "collection_time_in_millis": 200 } } } } ``` --- ##### **2.3 索引性能** - **API**:`GET /_stats` 或 `GET /my-index/_stats` - **关键指标**: - `docs.count`:文档总数。 - `store.size_in_bytes`:索引存储大小。 - `search.query_total`/`query_time_in_millis`:查询次数与耗时。 - `indexing.index_total`/`index_time_in_millis`:写入次数与耗时。 **示例**(索引查询性能): ```json "search": { "query_total": 15000, "query_time_in_millis": 12000, // 平均每次查询耗时约 0.8ms "query_current": 0 // 当前正在执行的查询数 } ``` --- ##### **2.4 分片状态** - **API**:`GET /_cat/shards?v` - **关键信息**: - 分片分布(`prirep`:主分片 `p` 或副本 `r`)。 - 分片状态(`STARTED`/`UNASSIGNED`/`RELOCATING`)。 - 节点归属(`node` 字段)。 **示例**: ``` index shard prirep state docs node logs-2023 0 p STARTED 100k node-1 logs-2023 0 r UNASSIGNED - - // 副本分片未分配 ``` --- #### 3. **典型问题诊断** ##### **3.1 集群变“红”(Red Status)** - **原因**:主分片未分配(如节点宕机、磁盘满、分片损坏)。 - **排查步骤**: 1. 检查未分配分片:`GET /_cluster/allocation/explain`。 2. 查看节点存活状态:`GET /_cat/nodes?v`。 3. 检查磁盘空间:`GET /_nodes/stats/fs`。 ##### **3.2 查询延迟高** - **可能原因**: - 资源瓶颈(CPU、内存、磁盘I/O)。 - 复杂查询(如通配符搜索、脚本排序)。 - 分片不均(热点分片)。 - **优化方向**: - 优化查询语句(避免`wildcard`,使用`keyword`类型字段)。 - 扩容节点或调整分片策略。 --- #### 4. **监控工具推荐** - **Kibana**:内置 [Monitoring] 模块,可视化展示集群健康、资源使用等。 - **Prometheus + Grafana**:通过`elasticsearch-exporter`采集指标,自定义仪表盘。 - **ElasticHQ**:第三方轻量级管理工具,适合基础监控。 --- #### 5. **最佳实践** 1. **定期监控**:设置阈值告警(如JVM堆内存 >80%)。 2. **分片规划**:单分片大小建议在10-50GB,避免过大或过多。 3. **日志保留策略**:按时间滚动删除旧索引(如`ILM`生命周期管理)。 --- #### 6. **示例:快速诊断命令** ```bash # 查看集群健康 curl -XGET "localhost:9200/_cluster/health?pretty" # 检查热点线程(定位CPU瓶颈) curl -XGET "localhost:9200/_nodes/hot_threads" # 统计索引写入/查询延迟 curl -XGET "localhost:9200/_stats/indexing,search?pretty" ``` --- 通过运行状态数据,可精准掌握ES集群的实时健康状况,提前规避风险并快速响应故障,是运维Elasticsearch的核心能力之一。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

打赏作者

中间件兴趣圈

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

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

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

打赏作者

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

抵扣说明:

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

余额充值