1-Redis架构设计到使用场景-四种部署运行模式（上）

专栏目录

1-Redis架构设计到使用场景-四种部署运行模式（上）
2-Redis架构设计到使用场景-四种部署运行模式（下）
3-Redis架构设计到使用场景-主从集群和分片集群
4-Redis架构设计到使用场景-string、list、set、zset、hash使用场景
4-Redis架构设计到使用场景-Redis数据结构与使用场景
5-Redis架构设计到使用场景-Redis请求执行过程
6-Redis架构设计到使用场景-存储原理-数据类型底层结构
7-Redis架构设计到使用场景-持久化机制、缓存失效策略、缓存命中率
8-Redis架构设计到使用场景-缓存穿透、缓存雪崩、缓存预热、缓存降级

Redis

简介

Redis 是完全开源免费的，是一个高性能的key-value类型的内存数据库。整个数据库系统加载在内存当中进行操作，定期通过异步操作把数据库数据flush到硬盘上进行保存。因为是纯内存操作，Redis的性能非常出色，每秒可以处理超过 10万次读写操作，是已知性能最快的Key-Value DB。

Redis的出色之处不仅仅是性能，Redis最大的魅力是支持保存多种数据结构，此外单个value的最大限制是1GB，因此Redis可以用来实现很多有用的功能，比方说用List来做FIFO双向链表，实现一个轻量级的高性能消息队列服务，用他的Set可以做高性能的tag系统等等。另外Redis也可以对存入的Key-Value设置expire时间。总结来说，使用Redis的好处如下：

1.速度快，因为数据存在内存中，读的速度是 110000 次 /s, 写的速度是 81000 次 /s；

2.支持丰富数据类型，支持string，list，set，sorted set，hash；

3.支持事务，操作都是原子性，对数据的更改要么全部执行，要么全部不执行，事务中任意命令执行失败，其余命令依然被执行。也就是说 Redis 事务不保证原子性，也不支持回滚；事务中的多条命令被一次性发送给服务器，服务器在执行命令期间，不会去执行其他客户端的命令请求。

4.丰富的特性：可用于缓存，消息（支持 publish/subscribe 通知），按key设置过期时间，过期后将会自动删除，具体淘汰策略有：

4.1.volatile-lru：从已经设置过期时间的数据集中，挑选最近最少使用的数据淘汰

4.2.volatile-ttl：从已经设置过期时间的数据集中，挑选即将要过期的数据淘汰

4.3.volatile-random：从已经设置过期时间的数据集中，随机挑选数据淘汰

4.4.allkeys-lru：从所有的数据集中，挑选最近最少使用的数据淘汰

4.5.allkeys-random：从所有的数据集中，随机挑选数据淘汰

4.6.no-enviction：禁止淘汰数据

具体过期键的策略有：定时删除（缓存过期时间到就删除，创建timer耗CPU），惰性删除（获取的时候检查，不获取一直留在内存，对内存不友好），定期删除（CPU和内存的折中方案）

5.支持数据持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用；

6.支持数据的备份，即 master - slave 模式的数据备份。

Redis的主要缺点是数据库容量受到物理内存的限制，不能用作海量数据的高性能读写，因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上。

常用架构

单机模式

单机模式顾名思义就是安装一个 Redis，启动起来，业务调用即可。例如一些简单的应用，并非必须保证高可用的情况下可以使用该模式。

优点

• 部署简单；
• 成本低，无备用节点；
• 高性能，单机不需要同步数据，数据天然一致性。

缺点

• 可靠性保证不是很好，单节点有宕机的风险。
• 单机高性能受限于 CPU 的处理能力，Redis 是单线程的。

​ 单机 Redis 能够承载的 QPS（每秒查询速率）大概在几万左右。取决于业务操作的复杂性，Lua 脚本复杂性就极高。假如是简单的 key value 查询那性能就会很高。

假设上千万、上亿用户同时访问 Redis，QPS 达到 10 万+。这些请求过来，单机 Redis 直接就挂了。系统的瓶颈就出现在 Redis 单机问题上，此时可以通过主从复制解决该问题，实现系统的高并发。

主从复制

​ Redis 的复制（Replication）功能允许用户根据一个 Redis 服务器来创建任意多个该服务器的复制品，其中被复制的服务器为主服务器（Master），而通过复制创建出来的复制品则为从服务器（Slave）。 只要主从服务器之间的网络连接正常，主服务器就会将写入自己的数据同步更新给从服务器，从而保证主从服务器的数据相同。

数据的复制是单向的，只能由主节点到从节点，简单理解就是从节点只支持读操作，不允许写操作。主要是读高并发的场景下用主从架构。主从模式需要考虑的问题是：当 Master 节点宕机，需要选举产生一个新的 Master 节点，从而保证服务的高可用性。

优点

• Master/Slave 角色方便水平扩展，QPS 增加，增加 Slave 即可；
• 降低 Master 读压力，转交给 Slave 节点；
• 主节点宕机，从节点作为主节点的备份可以随时顶上继续提供服务；

缺点

• 可靠性保证不是很好，主节点故障便无法提供写入服务；
• 没有解决主节点写的压力；
• 数据冗余（为了高并发、高可用和高性能，一般是允许有冗余存在的）；
• 一旦主节点宕机，从节点晋升成主节点，需要修改应用方的主节点地址，还需要命令所有从节点去复制新的主节点，整个过程需要人工干预；
• 主节点的写能力受到单机的限制；
• 主节点的存储能力受到单机的限制。

专栏目录

1-Redis架构设计到使用场景-四种部署运行模式（上）
2-Redis架构设计到使用场景-四种部署运行模式（下）
3-Redis架构设计到使用场景-主从集群和分片集群
4-Redis架构设计到使用场景-string、list、set、zset、hash使用场景
4-Redis架构设计到使用场景-Redis数据结构与使用场景
5-Redis架构设计到使用场景-Redis请求执行过程
6-Redis架构设计到使用场景-存储原理-数据类型底层结构
7-Redis架构设计到使用场景-持久化机制、缓存失效策略、缓存命中率
8-Redis架构设计到使用场景-缓存穿透、缓存雪崩、缓存预热、缓存降级