浅谈 Redis

一、简单介绍一下Redis

用C语言开发的非关系型数据库，数据存储在内存中，所以读写速度非常快。
常用于作缓存，还可用作分布式锁、消息队列。
提供了5种数据类型。
还支持持久化、事务等。

二、数据结构及使用场景

1. String

1.1 概述

类似于Map类型的键值对存储

1.2 场景

常用于缓存，或者计数的作用，如用户访问次数、热点文章的点赞转发数等

2.List

2.1 概述

Redis的List是一个双向链表，即支持反向查找和遍历

2.2 场景

简易消息队列等

3. Hash

3.1 概述

类似于HashMap，是一个String类型的field-value的映射表，适合存储对象，如商品信息等

3.2 场景

对象数据的存储，如实现购物车

4. Set

4.1 概述

类似于HashSet，Redis的Set也是一种无序、不重复的集合，可以实现交集、并集、差集操作等

4.2 场景

需要存放数据不能重复，获取多个数据的交/并/差集时，如共同关注、共同粉丝等

5. ZSet（Sortest Set）

5.1 概述

相比于Set类型数据结构增加了一个权重参数score，使集合中的元素按照score有序排列，还可以通过score的范围获取元素列表等

5.2 场景

需要对数据进行排序时，如排行榜等

三、Redis为什么不使用多线程

在4.0之后加入了对多线程的支持；
在6.0之前主要还是使用单线程；原因如下：

• 单线程容易实现且维护
• Redis的性能瓶颈不在CPU，在内存和网络限制
• 多线程可能引发死锁、线程上下文切换等问题

四、Redis6.0为什么引入了多线程

主要为了提高网络IO读写性能，但执行命令仍然是单线程，所以不用担心线程安全问题；
6.0默认禁用，只使用主线程，如需开启修改配置为：

io-thread-do-reads yes

开启多线程后，还需要配置线程数，否则不生效：

io-threads 4

五、Redis为什么需要给缓存设置过期时间

因为内存有限，会导致OOM；除了缓解内存消耗，其它场景有：短信验证码只在1分钟内有效，设置token有效时间等

六、Redis过期删除策略

1. 惰性删除

在取出key时进行过期检查，对CPU最友好，但可能造成太多过期key没被删除

2. 定期删除

每隔一段时间抽取一批key执行删除过期key操作，对内存更加友好

以上两种方式各有千秋，但还是可能存在漏掉很多过期key的情况，仍然会导致OOM
那么怎么解决呢？--那就是Redis的内存淘汰机制了，请看下面

七、Redis内存淘汰机制（策略）

1. volatile-lru
   从已设置过期时间的数据集中挑选最近最少使用的淘汰
2. allkeys-lru
   当内存不足以写入新数据时，淘汰最近最少使用的key
3. volatile-random
   当内存不足以写入新数据时，从已设置过期时间的key中随机淘汰
4. allkeys-random
   当内存不足以写入新数据时，从所有key中随机淘汰
5. volatile-ttl
   从已设置过期时间的数据集中选择将要过期的淘汰
6. no-eviction
   禁止删除数据，内存不足时写入新数据会报错（一般不用）

八、Redis持久化

将内存中的数据写入磁盘，主要时为了重用数据，比如机器重启时恢复数据

1. RDB（快照持久化）

通过创建快照来获得存储在内存里的某个时间点上的副本，是Redis的默认持久化方式，配置如下：

save 900 1
save 300 10
save 60 10000

注：在1秒后，如果至少有900个key发生变化

2. AOF（追加文件持久化）

实时性更好，是目前主流方案，开启配置：

appendonly yes

开启AOF持久化后，每执行一条更改Redis中数据的命令，就将该命令写入磁盘中的AOF文件中，配置如下：

appendfsync always
appendfsync everysec
appendfsync no

always 每执行一条命令就持久化一次
everysec 每一秒进行一次持久化
no 由操作系统决定什么时候持久化

为了兼顾数据和写入性能，建议appendfsync everysec，让Redis每秒同步一次AOF文件，性能几乎无影响，即使崩溃，只丢失一秒内的数据

七、Redis事务

可以通过MULTI、EXEC、DISCARD、WATCH等命令来实现事务；
使用MULTI后可以输入多个命令，Redis不会立即执行这些命令，当调用EXEC命令时执行；
Redis不支持roll back

浅谈 Redis

原文：https://www.cnblogs.com/jinzlblog/p/15104547.html