Nginx

nginx

20191112

14:32

    1. nginx安装

将文件解压到没有中文没有空格的路径即可安装完毕

    1. 目录结构

conf: 启动加载的核心配置文件nginx.conf,需要手动编辑,其他的副本.back都是nginx.conf的测试版本文件

logs:

error.log : 输出启动停止运行的各种错误信息,定位问题的首先要观察的文件

access.log: 运行的访问日志,通过什么浏览器,http协议访问的nginx,nginx转发了哪些内容

    1. 启动和停止

start.bat: 双击启动

观察任务管理器是否存在两个nginx进程

master: 主进程,管理nginx其他工作的唯一

workers: 工作进程,树妖负责并发的处理,默认配置workers的数量是1

stop.bat: 双击停止

重启nginx需要先运行stop.bat,必须确认是否正确停止,观察任务管理器nginx进程是否全部消失,如果不能正确停止,就不能运行start.bat

    1. 入门案例
      1. 实现功能

通过浏览器http://www.os.com/user/query/points?userId=1能够访问到一个后台服务器(在8090端口启动的Tomcat)

    1. nginx配置文件的编写(注意{}内的结构)

http

http{

默认配置了当前nginx的http服务器的各种属性

虚拟服务器端server

server {} //虚拟服务器,可以接收http请求,定义接收域名,监听的端口,接收请求地址等等

server {}

server {}

}

server {

#三个关键字 listen 多个server监听同一个端口

#一旦nginx监听了80端口,其他软件tomcat不能占用80了

listen 80;

#server_name 请求域名 request HOST的头中的域名

#当前server虚拟服务器在满足80端口访问监听

#后判断的域名是否满足条件,不同的server

#不同同时监听一个端口一个域名

server_name www.os.com;

#locatoin 定义处理请求的具体过程

#将当前请求转发给 127.0.0.1:8090的tomcat容器

#"/" locatoin 匹配域名端口后的url地址字符串

#/ 的意思是任何字符串都能匹配上

#http://www.os.com/user/query/points?userId=1

location / {

#定义转发和负载均衡逻辑

proxy_pass http://127.0.0.1:8090/;

}

}

 

server {

listen 80;

server_name www.os.com;

location /{

proxy_pass http://127.0.0.1:8090/;

}

}

 

确定: http://www.os.com/ 先要访问到nginx才有server的作用

配置host文件

验证:

    1. 验证配置是否正确,启动nginx,停止nginx是否能正常
    2. 8090的服务器启动

http://localhost:8090/user/query/point?userId=1

直接访问后端tomcat进程,并获取返回结果

http://www.os.com/user/query/point?userId=1

通过nginx实现的代理转发逻辑请求地址

 

    1. 流转逻辑
      1. 浏览器发起请求 http://www.os.com/user/query/point?userId=1
      2. 域名解析,通过host文件: www.os.com--->127.0.0.1

http://127.0.0.1:80/user/query/point?userId=1

    1. nginx接收到请求,server判断监听逻辑
    2. 实现了监听80端口监听域名www.os.com的server处理这个请求
    3. 进入server的逻辑,匹配location

location /    匹配到 user/query/point?userId=1

匹配成功进入location

    1. proxy_pass生效,拼接匹配后的剩余字符串

user/query/point?userId=1

http://127.0.0.1:8090/user/query/point?userId=1

    1. tomcat处理请求返回数据到nginx
    2. nginx返回数据给客户端

    1. location的匹配原则
      1. 原则和优先级关系

从上到下的优先级是由高到低的,多个location不同的匹配规则在同一个server下需要通过优先级的原则实现处理请求的决定

精确匹配 =/image:url除了域名和端口完全等于这里/image

由修饰的前缀字符串匹配(支持匹配多级)

^~/image

^~/image/test

以前缀匹配的字符串开始的url地址

没有修饰的前缀字符串匹配(不支持多级)

/image

满足前缀开始的所有url都匹配成功

正则匹配

~正则表达式

~.png$ 以png结尾的所有请求url

~.(png|jpg|gif)$

 

包含关系的优先级

    • 有修饰的字符串匹配:以最大匹配长度的优先最高原则判断多个包含的前缀字符串修改
    • 配置在上的location的正则表达式优先级更高

 

    1. 测试案例

listen 80;

server_name locahost;

location =/image              { return 200;}

location ^~/image             { return 201;}

location /image               { return 202;}

location ^~/image/test        { return 203;}

location ~.png$               { return 204;}

locatoin ~.(png|jpg|gif)$     { return 205;}

location /                    { return 206;}

 

http://localhost/             返回206;

http://localhost/image       返回200;

http://localhost/image/tes   返回201

http://localhost/image/test/haha.png 返回203

http://localhost/haha/kaka.png 返回204

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Nginx的负载均衡

20191112

15:36

    1. 负载均衡的结构

2.准备后端服务器

使用标示内容显示当前请求nginx转发给哪个后端服务器,启动多个后端服务器,多个服务器启动端口不同,被访问的页面带有不同的标识可以显示出访问到了不同的服务器

2.1SSM-DEMO02拷贝成多个

2.2修改maventomcat插件的端口号

8090 8091 8092

2.3index.html

分别编写一些标识字符串

3.负载均衡配置

    1. 轮询方式(轮着访问)

在配置文件中添加一个关键字,与server同级

upstream orderuserserver{

#根据后端服务器的访问地址编辑元素内容

server 127.0.0.1:8090;

server 127.0.0.1:8091;

server 127.0.0.1:8092;

}

相同于一个对象,List<Server>

Server对象作为元素记录的时候服务器的ip:port,orderserver的变量指向了一个内存中包含了三个服务器信息的list对象

 

server中修改proxy_pass

负载均衡的流转逻辑

    1. 浏览器发起请求 http://www.os.com/index.html
    2. host文件找映射127.0.0.1

http://127.0.0.1:80/index.html

    1. server监听80端口,域名www.os.com满足
    2. location/ /index.html  匹配/
    3. proxy_pass  http://orderuserserver/index.html
    4. 拦截请求发送:  判断orderuserserver的对象是否存在
    5. upstream orderuserserver
      1. 127.0.0.1:8090
      2. 127.0.0.1:8091
      3. 127.0.0.1:8092
    6. 拦截规则: 获取orderuserserver中真正的ip:port
      1. http://127.0.0.1:8090/index.html
      2. http://127.0.0.1:8091/index.html
      3. http://127.0.0.1:8092/index.html
    7. 权重(权衡比重)

权重的意义: 根据服务器的性能按照比例分配所有的并发请求到不同的服务器,性能低的处理的并发少,反之亦然

 

轮询配置中的upstream的基础上添加两个关键字: weight=权重整数值或者down

upstream orderuserserver{

#根据后端服务器的访问地址编辑元素内容

server 127.0.0.1:8090 weight=1;

server 127.0.0.1:8091 weight=20;

server 127.0.0.1:8092 down;

}

上述配置造成了8091所在服务器承担了绝大部分的负载均衡的请求,同时nginx不会讲任何请求发送到8092中

再集群中容易出现故障,对于长时间不能恢复的集群节点可以采用down的处理方式

    1. ip黏着

session的集群共享问题(用户登录状态访问)

ip黏着解决的问题: session无法在集群中共享

session共享的问题描述:

如果在集群中使用session存储域属性(以登录逻辑为例)会造成登录时访问一个负载均衡的后端服务器,跳转首页是访问一个负载均衡的后端服务器,跳转首页显示xxx,欢迎回来从session访问负载均衡的另外节点导致服务器间的session不能共享

nginx提供的ip_hash黏着问题解决session共享问题

原理: 客户端ip地址不变(10.9.115.116)判断是否是同一个客户端,将会对ip做hash处理(hash取余),IP地址不变,绑定的后端负载均衡的服务器就不会变,使用ip_hash黏着,无法体验到集群的高可用效果,配置如下

 

upstream orderuserserver{

#根据后端服务器的访问地址编辑元素内容

ip_hash;

server 127.0.0.1:8090 ;

server 127.0.0.1:8091 ;

server 127.0.0.1:8092 ;

}

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

nginx动静分离

20191112

16:29

    1. nginx访问静态文件的server配置

http://www.image.com/1.jpg 访问nginx管理的一张静态图片资源

    1. server监听80端口 www.image,com

nginx服务器的磁盘 存放在一个静态文件夹中1.jpg的图片

server {

listen 80;

server_name www.image.com;

#/1.jpg

location /{

#需要引入一个关键字指定静态文件的根目录

#c://根目录

root c://;

#c://1.jpg

流转逻辑:

    1. hosts文件找域名映射
    2. 127.0.0.1:80/1.jpg
    3. server监听端口 监听端口域名成功
    4. location匹配  /1.jpg 匹配 / 剩余1.jpg
    5. 拼接location root c://
    6. c://1.jpg
    7. host文件配置ip和域名映射关系

127.0.0.1      www.image.com

    1. easymall图片资源的静态资源配置

访问方式

http://image.jt.com/upload/1/0/c/f/1/d/1/6/4ff2cce6-a722-4408-ba94-0af91e61467d_c987f2c1-4123-4d87-83bd-fe2fb221e272.jpg

    1. hosts映射地址 127.0.0.1 image.jt.com
    2. location /{

root  c://;

}

    1. 在c盘中准备upload/1/0/c/f/1/d/1/6/图片文件名称的数据

2.动静分离处理订单用户demo中所有的静态文件

2.1动静分离的实际应用

由于nginx可以处理静态文件,后端服务器可以不再做静态资源的维护工作了,相同的静态文件,提取到nginx来处理

easymall就有 在nginx的根目录的easymall的文件夹有静态文件

 

    • 修改nginx配置

http://www.ssm.com/index.html; 访问静态资源

http://www.ssm.com/user/query/point?userId=1;

server {

            listen 80;

     server_name www.ssm.com;

location /user {

proxy_pass http://orderuserserver/user;

add_header 'Access-Control-Allow-Origin' '*';

            add_header 'Access-Control-Allow-Credentials' 'true';

}

location /order {

proxy_pass http://orderuserserver/order;

add_header 'Access-Control-Allow-Origin' '*';

            add_header 'Access-Control-Allow-Credentials' 'true';

}

location /{

root easymall;

index index.html;

} }  

    • 添加hosts配置

nginx

20191112

14:32

    1. nginx安装

将文件解压到没有中文没有空格的路径即可安装完毕

    1. 目录结构

conf: 启动加载的核心配置文件nginx.conf,需要手动编辑,其他的副本.back都是nginx.conf的测试版本文件

logs:

error.log : 输出启动停止运行的各种错误信息,定位问题的首先要观察的文件

access.log: 运行的访问日志,通过什么浏览器,http协议访问的nginx,nginx转发了哪些内容

    1. 启动和停止

start.bat: 双击启动

观察任务管理器是否存在两个nginx进程

master: 主进程,管理nginx其他工作的唯一

workers: 工作进程,树妖负责并发的处理,默认配置workers的数量是1

stop.bat: 双击停止

重启nginx需要先运行stop.bat,必须确认是否正确停止,观察任务管理器nginx进程是否全部消失,如果不能正确停止,就不能运行start.bat

    1. 入门案例
      1. 实现功能

通过浏览器http://www.os.com/user/query/points?userId=1能够访问到一个后台服务器(在8090端口启动的Tomcat)

    1. nginx配置文件的编写(注意{}内的结构)

http

http{

默认配置了当前nginx的http服务器的各种属性

虚拟服务器端server

server {} //虚拟服务器,可以接收http请求,定义接收域名,监听的端口,接收请求地址等等

server {}

server {}

}

server {

#三个关键字 listen 多个server监听同一个端口

#一旦nginx监听了80端口,其他软件tomcat不能占用80了

listen 80;

#server_name 请求域名 request HOST的头中的域名

#当前server虚拟服务器在满足80端口访问监听

#后判断的域名是否满足条件,不同的server

#不同同时监听一个端口一个域名

server_name www.os.com;

#locatoin 定义处理请求的具体过程

#将当前请求转发给 127.0.0.1:8090的tomcat容器

#"/" locatoin 匹配域名端口后的url地址字符串

#/ 的意思是任何字符串都能匹配上

#http://www.os.com/user/query/points?userId=1

location / {

#定义转发和负载均衡逻辑

proxy_pass http://127.0.0.1:8090/;

}

}

 

server {

listen 80;

server_name www.os.com;

location /{

proxy_pass http://127.0.0.1:8090/;

}

}

 

确定: http://www.os.com/ 先要访问到nginx才有server的作用

配置host文件

验证:

    1. 验证配置是否正确,启动nginx,停止nginx是否能正常
    2. 8090的服务器启动

http://localhost:8090/user/query/point?userId=1

直接访问后端tomcat进程,并获取返回结果

http://www.os.com/user/query/point?userId=1

通过nginx实现的代理转发逻辑请求地址

 

    1. 流转逻辑
      1. 浏览器发起请求 http://www.os.com/user/query/point?userId=1
      2. 域名解析,通过host文件: www.os.com--->127.0.0.1

http://127.0.0.1:80/user/query/point?userId=1

    1. nginx接收到请求,server判断监听逻辑
    2. 实现了监听80端口监听域名www.os.com的server处理这个请求
    3. 进入server的逻辑,匹配location

location /    匹配到 user/query/point?userId=1

匹配成功进入location

    1. proxy_pass生效,拼接匹配后的剩余字符串

user/query/point?userId=1

http://127.0.0.1:8090/user/query/point?userId=1

    1. tomcat处理请求返回数据到nginx
    2. nginx返回数据给客户端

    1. location的匹配原则
      1. 原则和优先级关系

从上到下的优先级是由高到低的,多个location不同的匹配规则在同一个server下需要通过优先级的原则实现处理请求的决定

精确匹配 =/image:url除了域名和端口完全等于这里/image

由修饰的前缀字符串匹配(支持匹配多级)

^~/image

^~/image/test

以前缀匹配的字符串开始的url地址

没有修饰的前缀字符串匹配(不支持多级)

/image

满足前缀开始的所有url都匹配成功

正则匹配

~正则表达式

~.png$ 以png结尾的所有请求url

~.(png|jpg|gif)$

 

包含关系的优先级

    • 有修饰的字符串匹配:以最大匹配长度的优先最高原则判断多个包含的前缀字符串修改
    • 配置在上的location的正则表达式优先级更高

 

    1. 测试案例

listen 80;

server_name locahost;

location =/image              { return 200;}

location ^~/image             { return 201;}

location /image               { return 202;}

location ^~/image/test        { return 203;}

location ~.png$               { return 204;}

locatoin ~.(png|jpg|gif)$     { return 205;}

location /                    { return 206;}

 

http://localhost/             返回206;

http://localhost/image       返回200;

http://localhost/image/tes   返回201

http://localhost/image/test/haha.png 返回203

http://localhost/haha/kaka.png 返回204

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Nginx的负载均衡

20191112

15:36

    1. 负载均衡的结构

2.准备后端服务器

使用标示内容显示当前请求nginx转发给哪个后端服务器,启动多个后端服务器,多个服务器启动端口不同,被访问的页面带有不同的标识可以显示出访问到了不同的服务器

2.1SSM-DEMO02拷贝成多个

2.2修改maventomcat插件的端口号

8090 8091 8092

2.3index.html

分别编写一些标识字符串

3.负载均衡配置

    1. 轮询方式(轮着访问)

在配置文件中添加一个关键字,与server同级

upstream orderuserserver{

#根据后端服务器的访问地址编辑元素内容

server 127.0.0.1:8090;

server 127.0.0.1:8091;

server 127.0.0.1:8092;

}

相同于一个对象,List<Server>

Server对象作为元素记录的时候服务器的ip:port,orderserver的变量指向了一个内存中包含了三个服务器信息的list对象

 

server中修改proxy_pass

负载均衡的流转逻辑

    1. 浏览器发起请求 http://www.os.com/index.html
    2. host文件找映射127.0.0.1

http://127.0.0.1:80/index.html

    1. server监听80端口,域名www.os.com满足
    2. location/ /index.html  匹配/
    3. proxy_pass  http://orderuserserver/index.html
    4. 拦截请求发送:  判断orderuserserver的对象是否存在
    5. upstream orderuserserver
      1. 127.0.0.1:8090
      2. 127.0.0.1:8091
      3. 127.0.0.1:8092
    6. 拦截规则: 获取orderuserserver中真正的ip:port
      1. http://127.0.0.1:8090/index.html
      2. http://127.0.0.1:8091/index.html
      3. http://127.0.0.1:8092/index.html
    7. 权重(权衡比重)

权重的意义: 根据服务器的性能按照比例分配所有的并发请求到不同的服务器,性能低的处理的并发少,反之亦然

 

轮询配置中的upstream的基础上添加两个关键字: weight=权重整数值或者down

upstream orderuserserver{

#根据后端服务器的访问地址编辑元素内容

server 127.0.0.1:8090 weight=1;

server 127.0.0.1:8091 weight=20;

server 127.0.0.1:8092 down;

}

上述配置造成了8091所在服务器承担了绝大部分的负载均衡的请求,同时nginx不会讲任何请求发送到8092中

再集群中容易出现故障,对于长时间不能恢复的集群节点可以采用down的处理方式

    1. ip黏着

session的集群共享问题(用户登录状态访问)

ip黏着解决的问题: session无法在集群中共享

session共享的问题描述:

如果在集群中使用session存储域属性(以登录逻辑为例)会造成登录时访问一个负载均衡的后端服务器,跳转首页是访问一个负载均衡的后端服务器,跳转首页显示xxx,欢迎回来从session访问负载均衡的另外节点导致服务器间的session不能共享

nginx提供的ip_hash黏着问题解决session共享问题

原理: 客户端ip地址不变(10.9.115.116)判断是否是同一个客户端,将会对ip做hash处理(hash取余),IP地址不变,绑定的后端负载均衡的服务器就不会变,使用ip_hash黏着,无法体验到集群的高可用效果,配置如下

 

upstream orderuserserver{

#根据后端服务器的访问地址编辑元素内容

ip_hash;

server 127.0.0.1:8090 ;

server 127.0.0.1:8091 ;

server 127.0.0.1:8092 ;

}

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

nginx动静分离

20191112

16:29

    1. nginx访问静态文件的server配置

http://www.image.com/1.jpg 访问nginx管理的一张静态图片资源

    1. server监听80端口 www.image,com

nginx服务器的磁盘 存放在一个静态文件夹中1.jpg的图片

server {

listen 80;

server_name www.image.com;

#/1.jpg

location /{

#需要引入一个关键字指定静态文件的根目录

#c://根目录

root c://;

#c://1.jpg

流转逻辑:

    1. hosts文件找域名映射
    2. 127.0.0.1:80/1.jpg
    3. server监听端口 监听端口域名成功
    4. location匹配  /1.jpg 匹配 / 剩余1.jpg
    5. 拼接location root c://
    6. c://1.jpg
    7. host文件配置ip和域名映射关系

127.0.0.1      www.image.com

    1. easymall图片资源的静态资源配置

访问方式

http://image.jt.com/upload/1/0/c/f/1/d/1/6/4ff2cce6-a722-4408-ba94-0af91e61467d_c987f2c1-4123-4d87-83bd-fe2fb221e272.jpg

    1. hosts映射地址 127.0.0.1 image.jt.com
    2. location /{

root  c://;

}

    1. 在c盘中准备upload/1/0/c/f/1/d/1/6/图片文件名称的数据

2.动静分离处理订单用户demo中所有的静态文件

2.1动静分离的实际应用

由于nginx可以处理静态文件,后端服务器可以不再做静态资源的维护工作了,相同的静态文件,提取到nginx来处理

easymall就有 在nginx的根目录的easymall的文件夹有静态文件

 

    • 修改nginx配置

http://www.ssm.com/index.html; 访问静态资源

http://www.ssm.com/user/query/point?userId=1;

server {

            listen 80;

     server_name www.ssm.com;

location /user {

proxy_pass http://orderuserserver/user;

add_header 'Access-Control-Allow-Origin' '*';

            add_header 'Access-Control-Allow-Credentials' 'true';

}

location /order {

proxy_pass http://orderuserserver/order;

add_header 'Access-Control-Allow-Origin' '*';

            add_header 'Access-Control-Allow-Credentials' 'true';

}

location /{

root easymall;

index index.html;

} }  

    • 添加hosts配置

127.0.0.1

www.ssm.com

 

    • user查询为例看流转逻辑

http://www.ssm.com/user/query/point

    • hosts找到ip映射地址
    • nginx接收请求server监听80 www.ssm.com
    • locatoin /user 匹配
    • 从浏览器看到的js发起的请求url地址未必是后端接收的地址
    • nginx向后端发起的请求地址

http://127.0.0.1:8090/user/query/point;

3.nginx的总结

掌握:

server的配置,可以根据请求的url路径,匹配自定义的server中的location

 

nginx引入到当前结构中后,访问流转逻辑

hosts映射

nginx监听

location匹配过滤

拼接location中的逻辑

知识点:

负载均衡的方式

轮询

权重

iphash黏着

session在集群中的无法共享数据的问题

动静分离

实现测试案例中order user系统所有的静态文件访问nginx

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

单体项目的拆分

2019912

15:29

 

1.回顾单体项目问题

1.1单机tomcat并发不高

nginx 负载均衡

1.2单体项目功能强耦合并发集中

功能强耦合导致开发学习更广范围的业务逻辑

并发集中导致系统大部分功能受限制于一个或2个具体功能

2.项目拆分

2.1横向拆分

根据开发的不同模块将一个项目横向拆分给多个人员并发开发,提升项目的开发速度,最终都会整合到一起实现单体项目的运行(横向拆分并没有解决单体项目的功能强耦合和并发集中的问题)

2.2纵向拆分

不拆分controller-server-mapper,根据不同的功能和不同的业务逻辑(购物车,订单,用户,商品,秒杀,微服务序列号,搜索等等),对项目的功能进行拆分--纵向拆分

纵向拆分的结果,就是将一个运行的系统,最终保持多个独立运行的系统的同时使用.

 

纵向拆分后解决2个问题

  • 系统间的通信问题(代码解决)

做纵向拆分的结果,是实现了一个小的微服务集群

  • SSM框架会导致纵向拆分的功能系统越多,重复配置就越多--独立的配置环境(框架解决--springboot)
 

 

    • user查询为例看流转逻辑

http://www.ssm.com/user/query/point

    • hosts找到ip映射地址
    • nginx接收请求server监听80 www.ssm.com
    • locatoin /user 匹配
    • 从浏览器看到的js发起的请求url地址未必是后端接收的地址
    • nginx向后端发起的请求地址

http://127.0.0.1:8090/user/query/point;

3.nginx的总结

掌握:

server的配置,可以根据请求的url路径,匹配自定义的server中的location

 

nginx引入到当前结构中后,访问流转逻辑

hosts映射

nginx监听

location匹配过滤

拼接location中的逻辑

知识点:

负载均衡的方式

轮询

权重

iphash黏着

session在集群中的无法共享数据的问题

动静分离

实现测试案例中order user系统所有的静态文件访问nginx

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

单体项目的拆分

2019912

15:29

 

1.回顾单体项目问题

1.1单机tomcat并发不高

nginx 负载均衡

1.2单体项目功能强耦合并发集中

功能强耦合导致开发学习更广范围的业务逻辑

并发集中导致系统大部分功能受限制于一个或2个具体功能

2.项目拆分

2.1横向拆分

根据开发的不同模块将一个项目横向拆分给多个人员并发开发,提升项目的开发速度,最终都会整合到一起实现单体项目的运行(横向拆分并没有解决单体项目的功能强耦合和并发集中的问题)

2.2纵向拆分

不拆分controller-server-mapper,根据不同的功能和不同的业务逻辑(购物车,订单,用户,商品,秒杀,微服务序列号,搜索等等),对项目的功能进行拆分--纵向拆分

纵向拆分的结果,就是将一个运行的系统,最终保持多个独立运行的系统的同时使用.

 

纵向拆分后解决2个问题

  • 系统间的通信问题(代码解决)

做纵向拆分的结果,是实现了一个小的微服务集群

  • SSM框架会导致纵向拆分的功能系统越多,重复配置就越多--独立的配置环境(框架解决--springboot)
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值