Redis知识点总结及常见面试题

写在文前，本篇文章是在学习过程抄录的笔记，需要更详细的内容可以在微信搜索javaguide公众号获取。

1、概述：

Redis 是一个开源的高性能基于内存运行的键值对NoSQL数据库。

1.支持数据的持久化。

2.支持多种数据类型，除 key-value 外还支持 list、set、hash。

3.支持 master-slave（主从同步）模式的数据备份。

2、Nosql

2.1 Nosql特点

1. 方便扩展
2. 大数据量高性能
3. 数据类型多样
4. 高性能、高可用、高扩展

3v和3高：

1.海量 Velume、多样 Variety、实时 Velocity。

2.高并发、高扩展、高性能。

2.2 RDBMS和Nosql比较

传统的 RDBMS(关系型数据库)
- 结构化组织
- SQL
- 数据和关系都存在单独的表中 row col
- 操作，数据定义语言
- 严格的一致性
- 基础的事务

Nosql
- 不仅仅是数据
- 没有固定的查询语言
- 键值对存储，列存储，文档存储，图形数据库（社交关系）
- 最终一致性
- CAP 定理和 BASE
- 高性能，高可用，高扩展

2.3 应用场景：

1.热点数据加速查询，如热点商品、热点信息等访问量较高的数据。

2.即时信息查询，如公交到站信息、在线人数信息。

3.时效性信息控制，如验证码、投票控制。

4.分布式数据共享，如分布式集群架构中的 session 分离消息队列。

2.4 特征

1. 多样的数据类型
2. 持久化
3. 集群
4. 事务

2.5 Nosql四大类

• KV键值对
  1. 阿里、百度：Redis + Memcache。
• 文档型数据库（bson数据格式）**：**MongoDB(掌握)
  1. 基于分布式文件存储的数据库，C++编写，用于处理大量文档。
  2. MongoDB是RDBMS和Nosql的中间产物。
• 列存储数据库
  1. HBase
  2. 分布式文件系统
• 图关系数据库
  1. Neo4j、InfoGrid
     

3、Redis知识点

3.1 Redis指令

redis默认有16个数据库。

127.0.0.1:6379> config get databases # 命令行查看数据库数量databases
1) "databases"
2) "16"

127.0.0.1:6379> select 8 # 切换数据库 DB 8
OK
127.0.0.1:6379[8]> dbsize # 查看数据库大小
(integer) 0

# 不同数据库之间 数据是不能互通的，并且dbsize 是根据库中key的个数。
127.0.0.1:6379> set name sakura 
OK
127.0.0.1:6379> SELECT 8
OK
127.0.0.1:6379[8]> get name # db8中并不能获取db0中的键值对。
(nil)
127.0.0.1:6379[8]> DBSIZE
(integer) 0
127.0.0.1:6379[8]> SELECT 0
OK
127.0.0.1:6379> keys *
1) "counter:__rand_int__"
2) "mylist"
3) "name"
4) "key:__rand_int__"
5) "myset:__rand_int__"
127.0.0.1:6379> DBSIZE # size和key个数相关
(integer) 5

keys * ：查看当前数据库中所有的key。

flushdb：清空当前数据库中的键值对。 rt

flushall：清空所有数据库的键值对。

• exists key：判断键是否存在
• del key：删除键值对
• move key db：将键值对移动到指定数据库
• expire key second：设置键值对的过期时间
• type key：查看value的数据类型

127.0.0.1:6379> keys * # 查看当前数据库所有key
(empty list or set)
127.0.0.1:6379> set name qinjiang # set key
OK
127.0.0.1:6379> set age 20
OK
127.0.0.1:6379> keys *
1) "age"
2) "name"
127.0.0.1:6379> move age 1 # 将键值对移动到指定数据库
(integer) 1
127.0.0.1:6379> EXISTS age # 判断键是否存在
(integer) 0 # 不存在
127.0.0.1:6379> EXISTS name
(integer) 1 # 存在
127.0.0.1:6379> SELECT 1
OK
127.0.0.1:6379[1]> keys *
1) "age"
127.0.0.1:6379[1]> del age # 删除键值对
(integer) 1 # 删除个数


127.0.0.1:6379> set age 20
OK
127.0.0.1:6379> EXPIRE age 15 # 设置键值对的过期时间

(integer) 1 # 设置成功 开始计数
127.0.0.1:6379> ttl age # 查看key的过期剩余时间
(integer) 13
127.0.0.1:6379> ttl age
(integer) 11
127.0.0.1:6379> ttl age
(integer) 9
127.0.0.1:6379> ttl age
(integer) -2 # -2 表示key过期，-1表示key未设置过期时间

127.0.0.1:6379> get age # 过期的key 会被自动delete
(nil)
127.0.0.1:6379> keys *
1) "name"

127.0.0.1:6379> type name # 查看value的数据类型
string

3.2 五大数据类型

字符串String、哈希表hash，列表list、集合set、有序集合zset。

在redis中无论什么数据类型，在数据库中都是以key-value形式保存，通过进行对Redis-key的操作，来完成对数据库中数据的操作。

3.2.1 String

String 数据结构是简单的 key-value 类型。

String 类似的使用场景：value 除了是字符串还可以是数字，用途举例：

• 计数器
• 统计多单位的数量：uid:123666：follow 0
• 粉丝数
• 对象存储缓存

3.2.2 List

Redis 列表是简单的字符串列表，按照插入顺序排序。你可以添加一个元素到列表的头部（左边）或者尾部（右边）。

Redis的list实现为一个双向链表，支持反向查询和遍历，方便操作，不过带来了额外的内存开销。

一个列表最多可以包含 2^32 - 1 个元素 (4294967295, 每个列表超过40亿个元素)。

命令

1. rpush/lpop实现队列。
2. rpush/rpop实现栈。
3. 使用lrange命令基于list实现分页查询。
4. llen查看表长度。

• list实际上是一个链表，before Node after , left, right 都可以插入值
• 如果key不存在，则创建新的链表
• 如果key存在，新增内容
• 如果移除了所有值，空链表，也代表不存在
• 在两边插入或者改动值，效率最高！修改中间元素，效率相对较低

应用：

发布与订阅或者消息队列、慢查询。

消息排队！消息队列（Lpush Rpop）,栈（Lpush Lpop）

3.2.3 Set

Redis 的 Set 是 string 类型的无序集合。集合成员是唯一的，这就意味着集合中不能出现重复的数据。

Redis 中集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是O(1)。

集合中最大的成员数为 2^32 - 1 (4294967295, 每个集合可存储40多亿个成员)。

应用场景：需要存放的数据不能重复以及需要获取多个数据源交集和并集的场景。

3.2.4 Hash

Redis hash 是一个 string 类型的 field 和 value 的映射表，hash 特别适合用于存储对象。

Set就是一种简化的 Hash，只变动key,而 value 使用默认值填充。可以将一个 Hash 表作为一个对象进行存储，表中存放对象的信息。

Hash 更适合于对象的存储，Sring 更加适合字符串存储！

应用场景：系统中对象数据的存储。

3.2.5 Zset(有序集合，sorted set)

不同的是每个元素都会关联一个 double 类型的分数（score）。redis 正是通过分数来为集合中的成员进行从小到大的排序。

score 相同：按字典顺序排序

有序集合的成员是唯一的,但分数(score)却可以重复。

应用案例：

• set 排序 存储班级成绩表 工资表排序！
• 普通消息，1.重要消息 2.带权重进行判断
• 排行榜应用实现，取 Top N 测试

3.3 三种特殊数据类型

3.3.1 Geospatial(地理位置)

通过 georadius 就可以完成 附近的人功能。

withcoord: 带上坐标

withdist: 带上距离，单位与半径单位相同

COUNT n : 只显示前n个(按距离递增排序)

3.3.2 Hyperloglog(基数统计)

Redis HyperLogLog 是用来做基数统计的算法。

HyperLogLog 的优点是，在输入元素的数量或者体积非常非常大时，计算基数所需的空间总是固定的、并且是很小的。

花费 12 KB 内存，就可以计算接近 2^64 个不同元素的基数。

因为 HyperLogLog 只会根据输入元素来计算基数，而不会储存输入元素本身，所以 HyperLogLog 不能像集合那样，返回输入的各个元素。

其底层使用string数据类型。

基数：数据集中不重复的元素的个数。

应用场景：

网页的访问量（UV）：一个用户多次访问，也只能算作一个人。

3.3.3 BitMaps(位图)

**bitmap存储使用连续的二进制数字。**使用位存储，信息状态只有 0 和 1。

Bitmap是一串连续的2进制数字（0或1），每一位所在的位置为偏移(offset)，在bitmap上可执行AND,OR,XOR,NOT以及其它位操作。

应用场景：需要保存状态信息并对信息进行分析的场景

• 签到统计、状态统计

3.4 Redis事务

Redis的单条命令是保证原子性的，但是redis事务不能保证原子性。

• 一次性
• 顺序性
• 排他性

1. Redis 事务没有隔离级别的概念。
2. Redis 单条命令是保证原子性的，但是事务不保证原子性！

事务操作

• 开启事务（multi）
• 命令入队
• 执行事务（exec）
• 取消事务（discard）
• 命令监听（watch）

代码语法错误（编译时异常）所有的命令都不执行，代码逻辑错误 (运行时异常) **其他命令可以正常执行 **。

注意：每次提交执行exec后都会自动释放锁，不管是否成功。

3.5 Jedis

使用 Java 来操作 Redis ，Jedis 是 Redis 官方推荐使用的 Java 连接 redis 的客户端。

<!--导入jredis的包-->
<dependency>
    <groupId>redis.clients</groupId>
    <artifactId>jedis</artifactId>
    <version>3.2.0</version>
</dependency>
<!--fastjson-->
<dependency>
    <groupId>com.alibaba</groupId>
    <artifactId>fastjson</artifactId>
    <version>1.2.70</version>
</dependency>

编码测试:

连接数据库

vim /usr/local/bin/myconfig/redis.conf

开放端口6379

firewall-cmd --zone=public --add-port=6379/tcp --permanet

重启防火墙服务

systemctl restart firewalld.service

重启redis-server

[root@AlibabaECS bin]# redis-server myconfig/redis.conf 

3.6 SpringBoot整合

1. 导入依赖

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>

jedis：采用的直连，多个线程操作的话，是不安全的。如果要避免不安全，使用 jedis pool 连接池！更像 BIO 模式。

lettuce：采用 netty，实例可以在多个线程中共享，不存在线程不安全的情况！可以减少线程数据了，更像 NIO 模式。

3.7 Redis持久化

由于 Redis 是基于内存的数据库，需要将数据由内存持久化到文件中。

持久化方式：

• RDB
• AOF

**3.7.1 RDB:**快照持久化

RDB：Redis Databases

在指定时间间隔后，将内存中的数据集快照写入数据库 ；在恢复时候，直接读取快照文件，进行数据的恢复 ；

默认情况下， Redis 将数据库快照保存在名字为 dump.rdb 的二进制文件中。文件名可以在配置文件中进行自定义。

工作原理：

在进行 RDB 的时候，redis 的主线程是不会做 io 操作的，主线程会 fork 一个子线程来完成该操作；

1. Redis 调用 forks。同时拥有父进程和子进程。
2. 子进程将数据集写入到一个临时 RDB 文件中。
3. 当子进程完成对新 RDB 文件的写入时，Redis 用新 RDB 文件替换原来的 RDB 文件，并删除旧的 RDB 文件。

这种工作方式使得 Redis 可以从写时复制（copy-on-write）机制中获益(因为是使用子进程进行写操作，而父进程依然可以接收来自客户端的请求。)

持久化触发条件：

1. save 的规则满足的情况下，会自动触发 rdb 原则
2. 执行 flushall 命令，也会触发我们的 rdb 原则
3. 退出 redis，也会自动产生 rdb 文件

3.7.2 AOF:Append Only File

将我们所有的命令都记录下来，history，恢复的时候就把这个文件全部再执行一遍。

redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

从 1.1 版本开始， Redis 增加了一种完全耐久的持久化方式： AOF 持久化。启用设置：appendonly yes。

优点：

1. 每一次修改都会同步，文件的完整性会更加好。
2. 每秒同步一次，可能会丢失一秒的数据。
3. 从不同步，效率最高。

缺点：

1. 相对于数据文件来说，aof 远远大于 rdb，修复速度比 rdb 慢！
2. aof 运行效率也要比 rdb 慢，所以我们 redis 默认的配置就是rdb持久化。

	RDB	AOF
启动优先级	低	高
体积	小	大
恢复速度	快	慢
数据安全性	丢数据	根据策略决定

3.8 Redis发布与订阅

消息通信模式：发送者(pub)发送消息，订阅者(sub)接收消息。

3.8.1 原理

每个 Redis 服务器进程都维持着一个表示服务器状态的 redis.h/redisServer 结构， 结构的 pubsub_channels 属性是一个字典， 这个字典就用于保存订阅频道的信息，其中，字典的键为正在被订阅的频道， 而字典的值则是一个链表， 链表中保存了所有订阅这个频道的客户端。

缺点：

1. 如果一个客户端订阅了频道，但自己读取消息的速度却不够快的话，那么不断积压的消息会使 redis 输出缓冲区的体积变得越来越大，这可能使得 redis 本身的速度变慢，甚至直接崩溃。
2. 这和数据传输可靠性有关，如果在订阅方断线，那么他将会丢失所有在短线期间发布者发布的消息。

3.8.2 应用

1. 消息订阅：公众号订阅，微博关注等等（起始更多是使用消息队列来进行实现）
2. 多人在线聊天室。

3.9 Redis主从复制

主从复制，是指将一台Redis服务器的数据，复制到其他的 Redis 服务器。前者称为主节点（Master/Leader）,后者称为从节点（Slave/Follower）， 数据的复制是单向的！只能由主节点复制到从节点（主节点以写为主、从节点以读为主）。

默认情况下，每台Redis服务器都是主节点，一个主节点可以有0个或者多个从节点，但每个从节点只能有一个主节点。

作用：

**1.数据冗余：**主从复制实现了数据的热备份，是持久化之外的一种数据冗余的方式。
**2.故障恢复：**当主节点故障时，从节点可以暂时替代主节点提供服务，是一种服务冗余的方式。
**3.负载均衡：**在主从复制的基础上，配合读写分离，由主节点进行写操作，从节点进行读操作，分担服务器的负载；尤其是在多读少写的场景下，通过多个从节点分担负载，提高并发量。
**4.高可用基石：**主从复制还是哨兵和集群能够实施的基础。

为什么使用集群：

1. 单台服务器难以负载大量的请求。
2. 单台服务器故障率高，系统崩坏概率大。
3. 单台服务器内存容量有限。。

3.10 哨兵模式

**主从切换技术的方法是：**当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑哨兵模式。

哨兵的作用：

• 通过发送命令，让 Redis 服务器返回监控其运行状态，包括主服务器和从服务器。
• 当哨兵监测到 master 宕机，会自动将 slave 切换成 master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。

优点：

1. 哨兵集群，基于主从复制模式，所有主从复制的优点，它都有。
2. 主从可以切换，故障可以转移，系统的可用性更好。
3. 哨兵模式是主从模式的升级，手动到自动，更加健壮。

缺点：

1. Redis不好在线扩容，集群容量一旦达到上限，在线扩容就十分麻烦。
2. 实现哨兵模式的配置其实是很麻烦的，里面有很多配置项。

3.11 缓存穿透（查不到）

在默认情况下，用户请求数据时，会先在缓存(Redis)中查找，若没找到即缓存未命中，再在数据库中进行查找，数量少可能问题不大，可是一旦大量的请求数据（例如秒杀场景）缓存都没有命中的话，就会全部转移到数据库上，造成数据库极大的压力，就有可能导致数据库崩溃。网络安全中也有人恶意使用这种手段进行攻击被称为洪水攻击。

解决方案：布隆过滤器

对所有可能查询的参数以Hash的形式存储，以便快速确定是否存在这个值，在控制层先进行拦截校验，校验不通过直接打回，减轻了存储系统的压力。

缓存空对象

存储空对象也需要空间，大量的空对象会耗费一定的空间，存储效率并不高。解决这个缺陷的方式就是设置较短过期时间。

3.12 缓存击穿（量太大，缓存过期）

相较于缓存穿透，缓存击穿的目的性更强，一个存在的 key，在缓存过期的一刻，同时有大量的请求，这些请求都会击穿到DB，造成瞬时DB请求量大、压力骤增。这就是缓存被击穿，只是针对其中某个 key 的缓存不可用而导致击穿，但是其他的key依然可以使用缓存响应。

解决方案：

1.设置热点数据永不过期

这样就不会出现热点数据过期的情况，但是当 Redis 内存空间满的时候也会清理部分数据，而且此种方案会占用空间，一旦热点数据多了起来，就会占用部分空间。

2.加互斥锁(分布式锁)

在访问 key 之前，采用 SETNX（set if not exists）来设置另一个短期 key 来锁住当前 key 的访问，访问结束再删除该短期 key。保证同时刻只有一个线程访问。这样对锁的要求就十分高。

3.13 缓存雪崩

大量的 key 设置了相同的过期时间，导致在缓存在同一时刻全部失效，造成瞬时 DB 请求量大、压力骤增，引起雪崩。

解决方案：

• redis高可用

  这个思想的含义是，既然redis有可能挂掉，那我多增设几台 redis，这样一台挂掉之后其他的还可以继续工作，其实就是搭建的集群。

• 限流降级

  这个解决方案的思想是，在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个 key 只允许一个线程查询数据和写缓存，其他线程等待。

• 数据预热

  数据加热的含义就是在正式部署之前，我先把可能的数据先预先访问一遍，这样部分可能大量访问的数据就会加载到缓存中。在即将发生大并发访问前手动触发加载缓存不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀。

4、面试

4.1 分布式缓存常见的技术选型有哪些

分布式缓存是为了解决单机缓存的容量受服务器控制无法保存通用信息问题。

1. Memcached
2. Redis

共同点

1. 都是基于内存的数据库，都可用作缓存使用。
2. 都有过期策略。
3. 性能都非常高。

区别

1. Redis 和 Memcached
   • Redis 的数据类型更丰富，也就是应用场景。redis 支持 k/v，还有 list、set、zset、hash；Memcached 只支持 k/v。
   • Redis 支持数据的持久化，将数据保存到磁盘上，重启时加载使用；Memcached 把所有数据存放在内存中。
   • Redis 灾难恢复机制，可以把缓存中的数据持久化到磁盘中。
   • Redis 在服务器内存用完之后，可以将不用的数据存放到磁盘中，而 Memcached 会直接报异常。
   • Memcached 没有原生的集群模式，需要依靠客户端实现往集群中分片写入数据，而 Redis 原生支持cluster 模式。
   • Memcached 是多线程，非阻塞I/O复用网络模型；Redis 使用单线程的多路I/O复用模型。（Redis6.0引入了多线程I/O）。
   • Redis 支持订阅、lua脚本、事务，而 Memcached 不支持。Redis 支持更多的编程语言。
   • Memcached 的过期数据删除策略只用了惰性删除，而 Redis 同时使用了惰性删除和定期删除。

4.2 缓存数据处理流程

1. 用户请求的数据在缓存中就直接返回。
2. 缓存中不存在就查看数据库中是否存在。
3. 数据库中存在就更新到缓存。
4. 数据库中不在就返回空数据。

4.3 Redis除了做缓存还能做什么

1. 分布式锁
   • 基于 Redisson 来实现分布式锁。
2. 限流
   • 通过 Redis + Lua 脚本实现限流。
3. 消息队列
   • Redis 自带的 list 数据结构可以作为一个简单的队列使用，Redis5.0 中增加的 Stream 类型数据结构更适合用来做消息队列。因为它有主题和消费组概念，支持消息持久化以及 ACK 机制。
4. 复杂业务场景
   • 通过 Redis 以及 Redis 扩展提供的数据结构，如 bitmap 签到统计，通过 sorted set 维护排行榜。

4.4 Redis常见数据结构以及使用场景

上文已有详细叙述，此处不再累赘。

4.5 Redis单线程模型

1. Redis基于 Reactor 模式设计开发自己的一套高效的事件处理模型，对应的是文件事件处理器。文件事件处理器是单线程运行的，所以所 Redis 是单线程模型。
2. Redis 通过多路I/O复用程序监听来自客户端的大量连接，将感兴趣的事件及类型注册到内核中并监听每个事件是否发生。
3. 这样的好处是：不用 Redis 额外创建多余的线程监听客户端的大量连接，降低了资源的消耗。
4. Redis 服务器是一个事件驱动程序，服务器要处理的两类事件文件事件、时间事件。
   • 文件事件处理器
   • 多个 socket（客户端连接）
   • IO 多路复用程序
   • 文件事件分派器（将 socket 关联到相应的事件处理器）
   • 文件处理器（连接应答处理器、命令请求处理器、命令回复处理器）

4.6 Redis为什么单线程还这么快？

核心：Redis 是将所有的数据放在内存中的，所以说使用单线程去操作效率就是最高的，多线程（CPU上下文会切换：耗时的操作！），对于内存系统来说，如果没有上下文切换效率就是最高的，多次读写都是在一个CPU上的，在内存存储数据情况下，单线程就是最佳的方案。

• 单线程编程容易而且容易维护。
• Redis的瓶颈不是CPU，主要在内存和网络。
• 多线程存在死锁，上下文切换等问题，甚至影响性能。

4.7 为何Redis6.0引入多线程

1. 引入多线程主要为了提升网络IO读写性能。

2. 执行命令仍然是单线程顺序执行，不需要担心线程安全的问题。

3. Redis6.0 的多线程默认是禁止的，只使用主线程，需要通过修改 redis 配置文件开启。redis.conf：

   io-threads-do-read yes
   
   #开启多线程后还需要设置线程数，否则不会生效。
   io-threads 4
   

4.8 过期时间除了缓解内存消耗，还有什么作用

比如设置验证码一分钟内有效。

4.9 Redis如何判断数据是否过期

1. Redis 通过过期字典保存数据的过期时间。
2. 过期字典的键指向数据库中的某个key，它的 value 是一个 long long 类型的整数，这个整数保存键指向的数据库 key 的过期时间。

4.10 过期数据的删除策略

常用的过期删除策略

1. 惰性删除
   • 只会在取出key的时候对数据过期检查
   • 对CPU友好，但可能会造成太多过期key没有删除
2. 定期删除
   • 每隔一段时间抽取一批key执行删除过期key操作。
   • Redis底层可以通过控制删除操作的执行时常和频率来减少删除操作对CPU时间的影响。
3. 定期删除对内存更友好，惰性删除对CPU更友好，Redis 采用的是 定期删除+惰性/懒汉删除。
4. Redis通过内存淘汰机制清除定期删除和惰性删除漏掉的内存中的过期 key 。

4.11 Redis内存淘汰机制

Redis提供6种淘汰策略

1. volatile-lru（least recently used）：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰。
2. volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰。
3. volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰。
4. allkeys-lru（least recently used）：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的 key（这个是最常用的）。
5. allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰。
6. no-eviction：禁止驱逐数据，也就是说当内存不足以容纳新写入数据时，新写入操作会报错。这个基本没人使用。

4.0后增加两种

1. volatile-lfu（least frequently used）：从已设置过期时间的数据集（server.db[i].expires）中挑选最不经常使用的数据淘汰。
2. allkeys-lfu（least frequently used）：当内存不足以容纳新写入数据时，在键空间中，移除最不经常使用的 key。

4.12 Redis持久化机制

上文已有详细叙述，此处不再累赘。（RDB+AOF）

4.13 Redis事务

上文已有详细叙述，此处不再累赘。

4.14 缓存穿透，缓存击穿，缓存雪崩

上文已有详细叙述，此处不再累赘。

文末，欢迎来讨论与指出问题。本文图片来自网络，如有侵权请联系。转发请标明出处。