一、Redis是什么？
是一个基于内存的高性能key-value数据库，可以用来作为数据库、缓存和消息队列。
Redis 与其他 key – value 缓存产品有以下三个特点：
- Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用。
- Redis不仅仅支持简单的key-value类型的数据，同时还提供list，set，zset，hash等数据结构的存储。
- Redis 支持主从复制，即 master-slave 模式的数据备份。
Redis架构
Redis 主要由有两个程序组成：
Redis 客户端 redis-cli
Redis 服务器 redis-server
客户端、服务器可以位于同一台计算机或两台不同的计算机中。
二、为什么使用Redis
因为传统的关系型数据库如Mysql已经不能适用所有的场景了，比如秒杀的库存扣减，APP首页的访问流量高峰等等，都很容易把数据库打崩，所以引入了缓存中间件。
三、Redis支持的数据类型
五种基本数据类型：
| 数据类型 |
Name |
实现方式 |
| 字符串 |
String |
内部存储默认 |
| 列表 |
List |
双向链表 |
| 哈希 |
Hash |
|
| 集合 |
Set |
value永远为null的HashMap |
| 有序集合 |
Sorted Set |
使用HashMap和跳跃表(SkipList)来保证数据的存储和有序，HashMap里放的是成员到score的映射，而跳跃表里存放的是所有的成员 |
附：跳表本质上是加了索引的有序链表，可参考跳表相关介绍了解
四、Redis支持的特殊数据结构
| 数据类型 |
Name |
应用场景 |
| 超级日志 |
HyperLogLog |
用于做基数统计，HyperLogLog 只会根据输入元素来计算基数，而不会储存输入元素本身 |
| 地理信息 |
Geo |
用于存储地理位置信息，并对存储的信息进行操作 |
| 订阅/发布 |
Pub/Sub |
用于消息分发，实现消息队列的功能，但消息无法持久化，如果出现网络断开、Redis 宕机等，消息就会被丢弃。 |
| 信息流 |
Stream |
5.0 版本新增。主要用于消息队列，提供了消息的持久化和主备复制功能，可以让任何客户端访问任何时刻的数据，并且能记住每一个客户端的访问位置，还能保证消息不丢失。 |
五、Redis持久化
redis 提供了两种持久化的方式，分别是RDB和AOF。
RDB：Redis DataBase
将 redis 某一时刻的数据持久化到磁盘中，是一种快照式的持久化方法。
redis 在进行数据持久化的过程中，会先将数据写入到一个临时文件中，待持久化过程都结束了，才会用这个临时文件替换上次持久化好的文件。正是这种特性，让我们可以随时来进行备份，因为快照文件总是完整可用的。
对于 RDB 方式，redis 会单独创建（fork）一个子进程来进行持久化，而主进程是不会进行任何 IO 操作的，这样就确保了 redis 极高的性能。
AOF：Append Only File
将 redis 执行过的所有写指令记录下来，在下次 redis 重新启动时，只要把这些写指令从前到后再重复执行一遍，就可以实现数据恢复了。
默认的 AOF 持久化策略是每秒钟 fsync 一次（fsync 是指把缓存中的写指令记录到磁盘中），因为在这种情况下，redis 仍然可以保持很好的处理性能，即使 redis 故障，也只会丢失最近 1 秒钟的数据。
如果在追加日志时，恰好遇到磁盘空间满、inode 满或断电等情况导致日志写入不完整，也没有关系，redis 提供了 redis-check-aof 工具，可以用来进行日志修复。
因为采用了追加方式，如果不做任何处理的话，AOF 文件会变得越来越大，为此，redis 提供了 AOF 文件重写（rewrite）机制，即当 AOF 文件的大小超过所设定的阈值时，redis 就会启动 AOF 文件的内容压缩，只保留可以恢复数据的最小指令集。举个例子或许更形象，假如我们调用了 100 次 INCR 指令，在 AOF 文件中就要存储 100 条指令，但这明显是很低效的，完全可以把这 100 条指令合并成一条 SET 指令，这就是重写机制的原理。
在进行 AOF 重写时，仍然是采用先写临时文件，全部完成后再替换的流程，所以断电、磁盘满等问题都不会影响 AOF 文件的可用性，
AOF重写原理
在重写即将开始之际，redis 会创建（fork）一个“重写子进程”，这个子进程会首先读取现有的 AOF 文件，并将其包含的指令进行分析压缩并写入到一个临时文件中。
与此同时，主工作进程会将新接收到的写指令一边累积到内存缓冲区中，一边继续写入到原有的 AOF 文件中，这样做是保证原有的 AOF 文件的可用性，避免在重写过程中出现意外。
当“重写子进程”完成重写工作后，它会给父进程发一个信号，父进程收到信号后就会将内存中缓存的写指令追加到新 AOF 文件中。
当追加结束后，redis 就会用新 AOF 文件来代替旧 AOF 文件，之后再有新的写指令，就都会追加到新的 AOF 文件中了。
RDB和AOF比较
RDB适用场景：需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感
AOF适用场景：对于数据恢复的完整性要求高
| 缺点 |
Value |
| RDB |
需要定时持久化，风险是可能会丢两次持久之间的数据，量可能很大。 |
| AOF |
AOF每秒fsync一次指令硬盘，如果硬盘IO慢，会阻塞父进程；风险是会丢失1秒多的数据；在Rewrite过程中，主进程把指令存到mem-buffer中，最后写盘时会阻塞主进程。 |
RDB 和 AOF 两种方式也可以同时使用，在这种情况下，如果 redis 重启的话，则会优先采用 AOF 方式来进行数据恢复，这是因为 AOF 方式的数据恢复完整度更高。
如果你没有数据持久化的需求，也完全可以关闭 RDB 和 AOF 方式，这样的话，redis 将变成一个纯内存数据库，就像 memcache 一样。
参考文档
redis简述
redis中文教程
