redis是什么
Redis（Remote Dictionary Server )，即远程字典服务，是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value，并提供多种语言的API。
redis 可以干什么
缓存
将热点数据放到内存中进行缓存，降低数据库的查询压力,提高响应速度，加快页面的响应速度,客户 -> 服务器 -> 缓存 -> 数据库,并且提供了RDB和AOF等数据持久化机制。
共享Session
分布式应用，用redis管理用户的session信息，每次客户更新查询登录信息都直接从Redis中获取。
计数器
可以用来记录浏览量、点赞量。
排行榜
Redis提供了列表和有序集合数据结构，合理地使用这些数据结构可以很方便地构建各种排行榜系统，Set 可以实现交集、并集等操作，从而实现共同好友等功能。ZSet 可以实现有序性操作，从而实现排行榜等功能。
社交网络
赞/踩、粉丝、共同好友/喜好、推送、下拉刷新等访问量比较大的操作，数据库不太适合频繁的大量做这种操作。
消息队列
提供了发布订阅功能和阻塞队列的功能，可以满足一般消息队列功能
分布式锁
分布式环境下，利用Redis实现分布式锁，也是Redis常见的应用 在分布式场景下，无法使用单机环境下的锁来对多个节点上的进程进行同步。可以使用 Redis 自带的 SETNX 命令实现分布式锁，除此之外，还可以使用官方提供的 RedLock 分布式锁实现
redis 数据类型有哪些
数据类型
string （字符串）
list （列表）
hash （哈希）占用空间少
set （集合）
zset （有序集合）
Bitmap (位图)
GEO （地理信息定位）
Stream (redis 5 用于消息队列) 有持久化功能
Hyperloglog (基数计数) 占用空间少
Redis 数据持久化
RDB
利用 RDB 持久化在指定的时间间隔生成数据集的时间点快照（point-in-time ），RDB(Redis Database) 通过快照的形式将数据保存到磁盘中。所谓快照，可以理解为在某一时间点将数据集拍照并保存下来。Redis 通过这种方式可以在指定的时间间隔或者执行特定命令时将当前系统中的数据保存备份，以二进制的形式写入磁盘中，默认文件名为dump.rdb。
RDB 的触发有三种机制，执行save命令；执行bgsave命令；在redis.config中配置自动化。
- save命令：阻塞当前Redis服务器，直到RDB过程完成为止，对于内存比较大的实例会造成长时间阻塞，线上环境不建议使用。
- bgsave命令：Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短。
+------------------------------------------+
| Redis Server |
+------------------------------------------+
| ^
| |
+------------------------+ +--------------+
| Save Command | | Background |
| (Trigger RDB) | | Save |
+------------------------+ +--------------+
| ^
v |
+------------------------------------------+
| RDB Process |
+------------------------------------------+
| ^
v |
+------------------------------------------+
| RDB File |
+------------------------------------------+
在上面的示意图中，Redis Server 接收到 Save Command 或者 Background Save 命令触发RDB持久化操作。然后 RDB Process 开始处理 Redis 数据库快照（snapshot）并将其写入磁盘上的RDB文件中。RDB文件通常具有 .rdb 扩展名。
当Redis Server重启时，它会检查是否存在RDB文件。如果存在，则Redis会从RDB文件中加载数据并恢复Redis Server的状态。如果不存在，则Redis会启动一个空数据库。
RDB优点
适合大规模的数据恢复场景，备份、全量复制，恢复速度远远快于AOF方式
RDB缺点
实时性低，RDB是间隔一段时间进行持久化，如果在间隔时发生问题就会丢失数据。 兼容性，新老版本存在RDB格式兼容问题
AOF
AOF(Append Only-file)持久化方案，简单描述它的工作原理：AOF日志存储的是Redis服务器指令序列，AOF只记录对内存进行修改的指令记录。Redis会在收到客户端修改指令后，进行参数修改、逻辑处理，如果没有问题，就立即将该指令文本存储到 AOF 日志中，也就是说，先执行指令才将日志存盘。AOF的工作流程操作：命令写入 （append）、文件同步（sync）、文件重写（rewrite）、重启加载 （load）;
AOF也有不同的触发方案，这里简要描述以下三种触发方案：
always：每次发生数据修改就会立即记录到磁盘文件中，这种方案的完整性好但是IO开销很大，性能较差；
everysec：在每一秒中进行同步，速度有所提升。但是如果在一秒内宕机的话可能失去这一秒内的数据；
no：默认配置，即不使用 AOF 持久化方案，由操作系统控制何时写入。
+------------------------------------------+
| Redis Server |
+------------------------------------------+
| ^
| |
+------------------------+ +--------------+
| Write | | Rewrite |
| Command | | AOF |
+------------------------+ +--------------+
| ^
v |
+------------------------------------------+
| AOF File |
+------------------------------------------+
在上面的示意图中，Redis Server 接收到 Write Command 命令时，它将该命令追加到AOF文件的末尾。AOF文件以文本格式保存，其中包含了所有执行的命令。
当AOF文件变得越来越大时，Redis会执行一个Rewrite AOF操作。在这个操作中，Redis会根据内存中的数据重写一个新的AOF文件，并将其中的所有命令压缩成更紧凑的格式。这可以减少AOF文件的大小并提高性能。
当Redis Server重启时，它会检查是否存在AOF文件。如果存在，则Redis会加载AOF文件中的命令并恢复Redis Server的状态。如果不存在，则Redis会启动一个空数据库。
AOF优点
- 数据的一致性和完整性更高
- redis内存溢出后，AOF还会执行，是不依赖于redis内存的
AOF缺点
- AOF记录的内容越多，文件越大，数据恢复变慢。
redis启动加载数据流程
-
AOF持久化开启且存在AOF文件时，优先加载AOF文件。
-
AOF关闭或者AOF文件不存在时，加载RDB文件。
-
加载AOF/RDB文件成功后，Redis启动成功。
-
AOF/RDB文件存在错误时，Redis启动失败并打印错误信息。
redis集群
主从复制
+------------+ +------------+
| Master | | Slave1 |
| (W) | | (R) |
+------------+ +------------+
^ ^
| |
| |
+------------+ +------------+
| Slave2 | | Slave3 |
| (R) | | (R) |
+------------+ +------------+
一主多从
一个master，多个slave，slaves都连接同一个master
薪火相传
上一个slave可以是下一个slave的master,Slave同样可以接收其他slaves的连接和同步请求。
反客为主
master宕机后，后面的slave可以升级为master,其后面的slave 不用做任何修改。
哨兵模式
当一个 master 宕机后，后面的 slave 可以立刻升为 master，其后面的 slave 不用做任何修改。用 slaveof no one 指令将从机变为主机。而哨兵模式是反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。
+---------------+
| Sentinel 1 |
| (master) |
+---------------+
/ \
/ \
/ \
+------------------------+
| Gossip |
+------------------------+
/ | \
/ | \
/ | \
+---------------+ +---------------+ +---------------+
| Sentinel 2 | | Sentinel 3 | | Sentinel 4 |
| (slave) | | (slave) | | (slave) |
+---------------+ +---------------+ +---------------+
cluster（分片）
Redis Cluster是一种Redis数据库的分布式解决方案，它可以在多个节点上水平扩展，并且在出现节点失败或意外停机时保持高可用性。Redis Cluster采用分片（Sharding）的方式对数据进行分割，并把不同的分片分散到多个节点上，每个节点可以存储一部分数据，同时其他节点上的其他数据也可以存储在当前节点上。这种方式可以大大增加Redis的可扩展性和可用性。在Redis Cluster中，如果某个节点故障或者需要下线维护，其他节点能够自动接替它的工作，保障整个集群的正常运行。Redis Cluster还支持动态扩容和缩容，即在运行时可以动态增加或者删除节点，从而实现对集群的动态管理和灵活调整。
+------------------+
|Cluster Management|
| Node |
+------------------+
/ \
/ \
/ \
+------------+ +------------+
|Master Node1| ... |Master NodeN|
| (slot) | | (slot) |
+------------+ +------------+
| | | |
| | | |
| | | |
+------------+ +------------+
| Slave Node1| | Slave NodeN|
+------------+ +------------+
分布式锁
+------------------------------------------+
| Redis Server |
+------------------------------------------+
| ^
| |
+------------------------+ +--------------+
| SET lock_key | | DEL lock_key |
| NX (Not Exists) | | (Release) |
+------------------------+ +--------------+
| ^
v |
+------------------------------------------+
| Lock Acquired |
+------------------------------------------+
在上面的示意图中，SET命令使用了NX选项，这意味着只有当lock_key不存在时，才会设置成功。这样，多个客户端尝试同时获取锁时，只有一个客户端能够成功地将lock_key设置为锁的值。
当客户端需要释放锁时，它可以使用DEL命令来删除lock_key。这样，其他客户端就可以获取锁了。
需要注意的是，Redis分布式锁的实现通常需要处理死锁和误解锁等问题，因此在实际应用中需要进行谨慎设计和测试。
