Redis系列之基础知识

---

一、Redis是什么？

是一个基于内存的高性能key-value数据库，可以用来作为数据库、缓存和消息队列。

Redis 与其他 key – value 缓存产品有以下三个特点：

1. Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用。
2. Redis不仅仅支持简单的key-value类型的数据，同时还提供list，set，zset，hash等数据结构的存储。
3. 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中文教程