存储+调优: 调优三-IO

存储+调优: 调优三-IO

I/O
影响I/O性能
1.mount  ro noatime
1。缓存: 使用日志
2。文件系统:日志文件系统和非日志文件系统
3。I/O大小:
4。RAID(带区卷 chunk size) 网络附加存储(cpu的iowait转移到存储服务器):

#!/bin/bash
for ((c=1;c<=24;c++))
do
  dd if=/dev/zero of=/mnt/file.$c bs=$((2**$c)) count=1
done

创建一个分区,分别使用async和sync挂载测试

创建一个ext2一个ext3,测试写入差别

man mount
  ◆data=journal日志模式

   日志中记录包括所有改变文件系统的数据和元数据。它是三种ext3日志模式中最慢的,但它将发生错误的可能性降至最小。使用“data= journal” 模式要求ext3将每个变化写入文件系统2次、写入日志1次,这将降低文件系统的总性能,但它的确是使用者最心爱的模式。由于记录了在ext3中元数据和数据更新情况,当一个系统重新启动的时候,这些日志将起作用。

  ◆data=ordered日志模式

   仅记录改变文件系统的元数据,且溢出文件数据要补充到磁盘中。这是缺省的ext3日志模式。这种模式降低了在写入文件系统和写入日志之间的冗余,因此速度较快,虽然文件数据的变化情况并不被记录在日志中,但它们必须做,而且由ext3的daemon程序在与之相关的文件系统元数据变化前执行,即在记录元数据前要修改文件系统数据,这将稍微降低系统的性能(速度),然而可确保文件系统中的文件数据与相应文件系统的元数据同步。

  ◆data=writeback日志模式

   仅记录改变文件系统的元数据,但根据标准文件系统,写程序仍要将文件数据的变化记录在磁盘上,以保持文件系统一致性。这是速度最快的ext3日志模式。因为它只记录元数据的变化,而不需等待与文件数据相关的更新如文件大小、目录信息等情况,对文件数据的更新与记录元数据变化可以不同步,即ext3是支持异步的日志。缺陷是当系统关闭时,更新的数据因不能被写入磁盘而出现矛盾,这一点目前尚不能很好解决。

[root@localhost ~]# mount -o data=journal /dev/sdb1 /mnt/


[root@localhost ~]# mke2fs -O journal_dev /dev/sdb5
[root@localhost ~]# mkfs.ext3 -J device=/dev/sdb5  /dev/sdb1
[root@localhost ~]# tune2fs -l /dev/sdb1 | grep Journal
Journal UUID:             2a8ae11d-e895-4fd9-9b44-aa2c5e1f4e13
Journal device:           0x0815

[root@localhost ~]# modinfo -F filename ext3
/lib/modules/2.6.18-194.el5/kernel/fs/ext3/ext3.ko
[root@localhost ~]# modinfo -F filename ext4
/lib/modules/2.6.18-194.el5/kernel/fs/ext4/ext4.ko


测试 xfs jfs reiserfs ext4

[root@localhost ~]# sar -d 1 100
Linux 2.6.18-194.el5 (localhost.localdomain)    04/04/2012

05:23:17 PM       DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util
05:23:18 PM    dev8-0     28.28      0.00    428.28     15.14      0.19      6.64      0.43      1.21
05:23:18 PM    dev8-1      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
05:23:18 PM    dev8-2      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
05:23:18 PM    dev8-3     28.28      0.00    428.28     15.14      0.19      6.64      0.43      1.21
05:23:18 PM   dev8-16      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
05:23:18 PM   dev8-17      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
05:23:18 PM   dev8-18      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
05:23:18 PM   dev8-19      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
05:23:18 PM   dev8-20      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
05:23:18 PM   dev8-21      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
05:23:18 PM   dev8-22      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
05:23:18 PM   dev8-23      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
05:23:18 PM   dev8-24      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
05:23:18 PM   dev8-25      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
05:23:18 PM   dev22-0      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
05:23:18 PM   dev8-32      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00


tps 每秒I/O读写请求数
rd_sec/s 每秒读的扇区数
avgrq-sz 每个请求的平均大小
avgqu-sz 平均队列长度
await I/O请求所消耗的平均时间
svctm I/O请求消耗的平均服务时间
%util 消耗CPU百分比

[root@localhost ~]# iostat  -k
Linux 2.6.18-194.el5 (localhost.localdomain)    04/04/2012

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           2.30    0.06    2.02    0.32    0.00   95.30

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda               1.65         6.83        24.54    1391447    4998914
sda1              0.00         0.46         0.00      92870        226
sda2              0.00         0.00         0.00        856        148
sda3              1.65         6.37        24.54    1296621    4998540
sdb               0.10         0.22        13.53      45056    2756266
sdb1              0.00         0.00         0.00        190          0
sdb2              0.00         0.00         0.00        189          0
sdb3              0.00         0.00         0.00        197          0
sdb4              0.00         0.00         0.00          1          0
sdb5              0.00         0.00         0.00        190          0
sdb6              0.01         0.00         2.67        328     544638
sdb7              0.01         0.00         2.55        368     519380
sdb8              0.01         0.16         2.68      33216     545980
sdb9              0.01         0.00         2.54        394     517256
hdc               0.00         0.07         0.00      13640          0
sdc               0.00         0.01         0.00       1537        123


[root@localhost ~]# sar -b 1 100
Linux 2.6.18-194.el5 (localhost.localdomain)    04/04/2012

05:57:06 PM       tps      rtps      wtps   bread/s   bwrtn/s
05:57:07 PM      0.00      0.00      0.00      0.00      0.00
05:57:08 PM      0.00      0.00      0.00      0.00      0.00
05:57:09 PM      3.96      0.00      3.96      0.00    174.26
05:57:10 PM      0.00      0.00      0.00      0.00      0.00
05:57:11 PM      0.00      0.00      0.00      0.00      0.00


Linux kernel 自 2.6.28 开始正式支持新的文件系统 Ext4。 Ext4 是 Ext3 的改进版,修改了 Ext3 中部分重要的数据结构,而不仅仅像 Ext3 对 Ext2 那样,
只是增加了一个日志功能而已。Ext4 可以提供更佳的性能和可靠性,还有更为丰富的功能:

1. 与 Ext3 兼容。 
执行若干条命令,就能从 Ext3 在线迁移到 Ext4,而无须重新格式化磁盘或重新安装系统。原有 Ext3 数据结构照样保留,Ext4 作用于新数据,当然,整个文件系统因此也就
获得了 Ext4 所支持的更大容量。

2. 更大的文件系统和更大的文件。 
较之 Ext3 目前所支持的最大 16TB 文件系统和最大 2TB 文件,Ext4 分别支持 1EB(1,048,576TB, 1EB=1024PB, 1PB=1024TB)的文件系统,以及 16TB 的文件。

3. 无限数量的子目录。 
Ext3 目前只支持 32,000 个子目录,而 Ext4 支持无限数量的子目录。

4. Extents。 
Ext3 采用间接块映射,当操作大文件时,效率极其低下。比如一个 100MB 大小的文件,在 Ext3 中要建立 25,600 个数据块(每个数据块大小为 4KB)的映射表。而 Ext4 
引入了现代文件系统中流行的 extents 概念,每个 extent 为一组连续的数据块,上述文件则表示为“该文件数据保存在接下来的 25,600 个数据块 中”,提高了不少效率。

5. 多块分配。 
当写入数据到 Ext3 文件系统中时,Ext3 的数据块分配器每次只能分配一个 4KB 的块,写一个 100MB 文件就要调用 25,600 次数据块分配器,而 Ext4 的多块分配器
“multiblock allocator”(mballoc) 支持一次调用分配多个数据块。

6. 延迟分配。 
Ext3 的数据块分配策略是尽快分配,而 Ext4 和其它现代文件操作系统的策略是尽可能地延迟分配,直到文件在 cache 中写完才开始分配数据块并写入磁盘,这样就能优化
整个文件的数据块分配,与前两种特性搭配起来可以显著提升性能。

7. 快速 fsck。 
以前执行 fsck 第一步就会很慢,因为它要检查所有的 inode,现在 Ext4 给每个组的 inode 表中都添加了一份未使用 inode 的列表,今后 fsck Ext4 文件系统就可以跳过
它们而只去检查那些在用的 inode 了。

8. 日志校验。 
日志是最常用的部分,也极易导致磁盘硬件故障,而从损坏的日志中恢复数据会导致更多的数据损坏。Ext4 的日志校验功能可以很方便地判断日志数据是否损坏,而且它将 
Ext3 的两阶段日志机制合并成一个阶段,在增加安全性的同时提高了性能。

9. “无日志”(No Journaling)模式。 
日志总归有一些开销,Ext4 允许关闭日志,以便某些有特殊需求的用户可以借此提升性能。

10. 在线碎片整理。 
尽管延迟分配、多块分配和 extents 能有效减少文件系统碎片,但碎片还是不可避免会产生。Ext4 支持在线碎片整理,并将提供 e4defrag 工具进行个别文件或整个文件系
统的碎片整理。

11. inode 相关特性。 
Ext4 支持更大的 inode,较之 Ext3 默认的 inode 大小 128 字节,Ext4 为了在 inode 中容纳更多的扩展属性(如纳秒时间戳或 inode 版本),默认inode 大小为 256 字节
。Ext4 还支持快速扩展属性(fast extended attributes)和 inode 保留(inodes reservation)。

12. 持久预分配(Persistent preallocation)。 
P2P 软件为了保证下载文件有足够的空间存放,常常会预先创建一个与所下载文件大小相同的空文件,以免未来的数小时或数天之内磁盘空间不足导致下载失败。 Ext4 在文件
系统层面实现了持久预分配并提供相应的 API(libc 中的 posix_fallocate()),比应用软件自己实现更有效率。

13. 默认启用 barrier。 
磁盘上配有内部缓存,以便重新调整批量数据的写操作顺序,优化写入性能,因此文件系统必须在日志数据写入磁盘之后才能写 commit 记录,若 commit 记录写入在先,
而日志有可能损坏,那么就会影响数据完整性。Ext4 默认启用 barrier,只有当 barrier 之前的数据全部写入磁盘,才能写 barrier 之后的数据。
(可通过 "mount -o barrier=0" 命令禁用该特性。)


reiserfs:号称最快的 FS。
            先进的日志机制 ReiserFS有先进的日志(Journaling/logging)功能 机制。日志机制保证了在每个实际数据修改之前,相应的日志已经写入硬盘。文件与数据的安全性
            有了很大提高。

        Reiserfs对一些小文件不分配inode。而是将这些文件打包,存放在同一个磁盘分块中。而其它文件系统则为每个小文件分别放置到一个磁盘分块中。
    
        ReiserFS基于快速平衡树(balanced tree)搜索,平衡树在性能上非常卓越,这是一种非常高效的算法。在实际运用中,ReiserFS 在处理小于 1k 的文件时,比ext2 
        快 8 到 15 倍
    
            ReiserFS是一个非常优秀的文件系统,可轻松管理上百G的文件系统,ReiserFS文件系统最大支持的文件系统尺寸为16TB。这非常适合企业级应用中。
            出现异常断电的时候,会出现大量的未写入完全的数据。ReiserFS会在恢复的时候进行rebuild-tree。而这个过程是非常慢的。在ReiserFS的升级版本Reiser4中有所
            改观。

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

jfs:由 IBM 所开发的 journal 型文件系統。 

    JFS( JOURNAL FILE SYSTEM),一种字节级日志文件系统,借鉴了数据库保护系统的技术,以日志的形式记录文件的变化。JFS通过记录文件结构而不是数据本身的变化
    来保证数据的完整性。这种方式可以确保在任何时刻都能维护数据的可访问性。该文件系统主要是为满足服务器(从单处理器系统到高级多处理器和群集系统)的高吞吐
    量和可靠性需求而设计、开发的。JFS文件系统是为面向事务的高性能系统而开发的。在IBM的AIX系统上,JFS已经过较长时间的测试,结果表明它是可靠、快速和容
    易使用的。
    
    与非日志文件系统相比,它的突出优点是快速重启能力,JFS能够在几秒或几分钟内就把文件系统恢复到一致状态。虽然JFS主要是为满足服务器(从单处理器系统到高级
    多处理器和群集系统)的高吞吐量和可靠性需求而设计的,但还可以用于想得到高性能和可靠性的客户机配置,因为在系统崩溃时JFS能提供快速文件系统重启时间,所以
    它是因特网文件服务器的关键技术。使用数据库日志处理技术,JFS能在几秒或几分钟之内把文件系统恢复到一致状态。而在非日志文件系统中,文件恢复可能花费几小时
    或几天。 

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

xfs:由 SGI 所开发的 journal 型文件系統。 

         采用XFS文件系统,当意想不到的宕机发生后,首先,由于文件系统开启了日志功能,所以你磁盘上的文件不再会意外宕机而遭到破坏了。不论目前文件系统上存储的
         文件与数据有多少,文件系统都可以根据所记录的日志在很短的时间内迅速恢复磁盘文件内容。

     XFS文件系统采用优化算法,日志记录对整体文件操作影响非常小。XFS查询与分配存储空间非常快。xfs文件系统能连续提供快速的反应时间。

        XFS 是一个全64-bit的文件系统,它可以支持上百万T字节的存储空间。对特大文件及小尺寸文件的支持都表现出众,支持特大数量的目录。

    XFS 能以接近裸设备I/O的性能存储数据。

LVM条带化
lvcreate -i 3 -I 64 -n lvtest -L 20G vgtest
mke2fs -j -E stride=16 /dev/vgtest/lvtest
    

RAID
mdadm -C /dev/md0 -l 0 -n 4 -c 16 /dev/sda{{7,8,9,10}
mdadm -D /dev/md0
    Chunk Size : 16K
mke2fs -j -E stride=16 -b 4096 /dev/vgtest/lvtest


mdadm -C /dev/md0 -l 5 -n 4 -c 32 /dev/sda{{7,8,9,10}
mke2fs -j -E stride=24 -b 4096 /dev/vgtest/lvtest


fdisk 最大支持分区2T
parted

怎样在磁盘上读取数据效率更快
I/O调度方式
电梯算法
[root@localhost jfsutils-1.1.14]# cat /sys/block/sda/queue/scheduler 
noop anticipatory deadline [cfq] 

cfq 平均分配I/O请求
A:  1 1 1 1
B:  2 2 2 2
C:  3 3 3 3


1)CFQ(完全公平排队I/O调度程序)

特点:
在最新的内核版本和发行版中,都选择CFQ做为默认的I/O调度器,对于通用的服务器也是最好的选择.CFQ试图均匀地分布对I/O带宽的访问,避免进程被饿死并实现较低的延迟,是deadline和as调度器的折中.CFQ对于多媒体应用(video,audio)和桌面系统是最好的选择.CFQ赋予I/O请求一个优先级,而I/O优先级请求独立于进程优先级,高优先级的进程的读写不能自动地继承高的I/O优先级.
工作原理:
CFQ为每个进程/线程,单独创建一个队列来管理该进程所产生的请求,也就是说每个进程一个队列,各队列之间的调度使用时间片来调度,
以此来保证每个进程都能被很好的分配到I/O带宽.I/O调度器每次执行一个进程的4次请求.


2)NOOP(电梯式调度程序)

特点:
在Linux2.4或更早的版本的调度程序,那时只有这一种I/O调度算法.
NOOP实现了一个简单的FIFO队列,它像电梯的工作主法一样对I/O请求进行组织,当有一个新的请求到来时,它将请求合并到最近的请求之后,以此来保证请求同一介质.NOOP倾向饿死读而利于写.NOOP对于闪存设备,RAM,嵌入式系统是最好的选择.

电梯算法饿死读请求的解释:
因为写请求比读请求更容易.写请求通过文件系统cache,不需要等一次写完成,就可以开始下一次写操作,写请求通过合并,堆积到I/O队列中.读请求需要等到它前面所有的读操作完成,才能进行下一次读操作.在读操作之间有几毫秒时间,而写请求在这之间就到来,饿死了后面的读请求.

3)Deadline(截止时间调度程序)

特点:
通过时间以及硬盘区域进行分类,这个分类和合并要求类似于noop的调度程序.Deadline确保了在一个截止时间内服务请求,这个截止时间是可调整的,而默认读期限短于写期限.这样就防止了写操作因为不能被读取而饿死的现象.Deadline对数据库环境(ORACLE RAC,MYSQL等)是最好的选择.


4)AS(预料I/O调度程序)

特点:
本质上与Deadline一样,但在最后一次读操作后,要等待6ms,才能继续进行对其它I/O请求进行调度.可以从应用程序中预订一个新的读请求,改进读操作的执行,但以一些写操作为代价.它会在每个6ms中插入新的I/O操作,而会将一些小写入流合并成一个大写入流,用写入延时换取最大的写入吞吐量.AS适合于写入较多的环境,比如文件服务器AS对数据库环境表现很差

了解当前的I/O情况
[root@localhost ~]# mpstat 
Linux 2.6.18-194.el5 (localhost.localdomain)    04/04/2012

05:15:59 PM  CPU   %user   %nice    %sys %iowait    %irq   %soft  %steal   %idle    intr/s
05:15:59 PM  all    2.27    0.06    1.87    0.32    0.07    0.07    0.00   95.33   1014.38

[root@localhost ~]# iostat 1 100
Linux 2.6.18-194.el5 (localhost.localdomain)    04/04/2012

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           2.27    0.06    2.01    0.32    0.00   95.34

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda               1.65        13.76        49.27    2779231    9952476
sda1              0.00         0.92         0.00     185740        452
sda2              0.00         0.01         0.00       1713        296
sda3              1.65        12.82        49.27    2589578    9951728
sdb               0.10         0.45        27.29      90112    5512532
sdb1              0.00         0.00         0.00        380          0
sdb2              0.00         0.00         0.00        378          0
sdb3              0.00         0.00         0.00        394          0
sdb4              0.00         0.00         0.00          2          0
sdb5              0.00         0.00         0.00        380          0
sdb6              0.01         0.00         5.39        656    1089276
sdb7              0.01         0.00         5.14        736    1038760
sdb8              0.01         0.33         5.41      66432    1091960
sdb9              0.01         0.00         5.12        788    1034512
hdc               0.00         0.14         0.00      27280          0
sdc               0.00         0.02         0.00       3074         80


tps每秒I/O请求个数

[root@localhost ~]# sar -d 1 100
Linux 2.6.18-194.el5 (localhost.localdomain)    04/04/2012

05:23:17 PM       DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util
05:23:18 PM    dev8-0     28.28      0.00    428.28     15.14      0.19      6.64      0.43      1.21
05:23:18 PM    dev8-1      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
05:23:18 PM    dev8-2      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
05:23:18 PM    dev8-3     28.28      0.00    428.28     15.14      0.19      6.64      0.43      1.21
05:23:18 PM   dev8-16      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
05:23:18 PM   dev8-17      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
05:23:18 PM   dev8-18      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
05:23:18 PM   dev8-19      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
05:23:18 PM   dev8-20      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
05:23:18 PM   dev8-21      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
05:23:18 PM   dev8-22      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
05:23:18 PM   dev8-23      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
05:23:18 PM   dev8-24      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
05:23:18 PM   dev8-25      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
05:23:18 PM   dev22-0      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
05:23:18 PM   dev8-32      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00


tps 每秒I/O读写请求数
rd_sec/s 每秒读的扇区数
avgrq-sz 每个请求的平均大小
avgqu-sz 平均队列长度
await I/O请求所消耗的平均时间
svctm I/O请求消耗的平均服务时间
%util 消耗CPU百分比


[root@localhost Documentation]# iostat -x 1
Linux 2.6.18-194.el5 (localhost.localdomain)    09/27/2012

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.47    0.14    0.36    0.81    0.00   98.22

Device:         rrqm/s   wrqm/s   r/s   w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.73     1.70  0.71  0.79    27.88    19.89    31.84     0.02   15.42   5.89   0.88
sda1              0.02     0.00  0.00  0.00     0.05     0.00    23.75     0.00    3.85   3.29   0.00
sda2              0.71     1.70  0.71  0.79    27.82    19.89    31.85     0.02   15.44   5.89   0.88
dm-0              0.00     0.00  1.41  2.49    27.79    19.89    12.24     0.07   17.17   2.27   0.88
dm-1              0.00     0.00  0.00  0.00     0.02     0.00     8.00     0.00    6.81   0.76   0.00
hdc               0.03     0.00  0.00  0.00     0.16     0.00    33.10     0.00    1.23   1.20   0.00
sdb               0.01     0.00  0.00  0.00     0.03     0.00    10.12     0.00    6.14   3.09   0.00
sdb1              0.01     0.00  0.00  0.00     0.03     0.00     9.81     0.00    6.23   3.11   0.00

rrqm/s 每秒合并的读请求个数


RAID条带化 chunk size
条带的大小,条带小意味这条带多,条带多大?(根据读写的数据量长度决定)avgrq-sz

系统io状态查看
1。观察iostat -x 1 10命令输出

2。cat /proc/partitions 并根据帮助解释文件作用

3。cat /proc/diskstats 并根据帮助解释文件作用

4。观察sar -b 1 10命令输出、

5。观察sar -d 1 10命令输出

6。观察sar -I ALL 1 10命令输出

7。使用lsof查看进程打开文件状态

   service httpd start
   lsof /usr/sbin/httpd
   lsof /
   lsof -p $$
   lsof -p 1

8.使用fuser查看进程打开文件状态

   fuser /
   fuser /sbin/init
   service httpd start
   fuser -k /usr/sbin/httpd

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

打赏作者

温柔-的-女汉子

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

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

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

打赏作者

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

抵扣说明:

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

余额充值