redis 硬件要求_redis知识总结

Redis并不是简单的key-value存储，实际上它是一个数据结构服务器，支持不同类型的值。值可以有以下5种基础类型。

1、String

二进制安全的字符串

2、list

按插入顺序排序的字符串元素的集合。他们基本上就是链表（linked lists）

3、set

不重复且无序的字符串元素的集合。

4、sorted set

类似Sets,但是每个字符串元素都关联到一个叫score浮动数值（floating number value）。里面的元素总是通过score进行着排序

5、hash

由field和关联的value组成的map。field和value都是字符串的。

主从复制

redis配置主从关系有两种方式，一个是用slaveof命令，另一个是在redis.conf中配置主节点的ip和端口信息。

主从复制可以是一主一从，也可以是一主多从。一个redis实例可以是另一个的slave，也可以是相对的master（a的slave是b，b的slave是c）。

主从复制，一般主都是写入数据，而从都是读取数据。Redis 使用异步复制，slave 和 master 之间异步地确认处理的数据量。一个redis如果对应多个slave，salve越多会对主机的性能产生影响，毕竟多个slave都是从master同步数据。

使用info replication和role两个命令，可以查看此redis实例的角色信息。

redis处理过期的key:

slave 不会让 key 过期，而是等待 master 让 key 过期。当一个 master 让一个 key 到期（或由于 LRU 算法将之驱逐）时，它会合成一个 DEL 命令并传输到所有的 slave。

当master无法提供del key时，slave中仍然可能存在过期的key。为了解决这种情况，slave 使用它的逻辑时钟以报告只有在不违反数据集的一致性的读取操作中才存在 key。

在Lua脚本执行期间，不执行任何 key 过期操作。

如果有三个redis实例，a是master，b和c都是slave，那么当a挂掉，重启a后，a仍然是master，这种角色不会改变。

但是如果配置了sentinel，监控master，那么当master挂掉，这个时候slave便会进行投票，选出新的master，剩下的一个slave重新连接到新的master，而原来的master如果这个时候重启，恢复，原来的master的角色将会是slave。

持久化

redis大部分情况下都是用作缓存，减少对数据库的访问，但是如果你需要存储redis的数据到硬盘，那么就需要用到redis持久化方案，redis提供两种持久化方案，一种是RDB，一种是AOF。

RDB是在指定的时间内对redis进行快照存储。

AOF则是存储redis服务器每一次的写命令，不断追加到文件的末尾。

可以同时开启RDB和AOF，但是重启服务器的时候会首先加载AOF，因为AOF的数据通常比RDB数据要完整。

相同数据量的情况下，RDB的文件占用空间小于AOF，因为RDB的数据是经过压缩的。

RDB的方式缺点是在时间间隔内（一般配置的是分钟级别），数据可能存在丢失的情况，假设在这一次刚备份之后到下一次备份的时间间隔内，服务器宕机，那么这个时间段内的数据就会丢失。而对于AOF来说，最多也就是丢失那一秒的数据。

AOF的缺点就是写命令不断追加到文件末尾，整个文件会越来越大，这个是无法避免的，redis虽然提供了一个机制，检查并合并AOF里面可以合并的命令，但是也只能缓解一时。

如果对数据的准确性要求不是那么高，建议用RDB方式，恢复数据时通常RDB也比AOF快，适合大规模的数据恢复。

RDB工作方式

当 Redis 需要保存 dump.rdb 文件时， 服务器执行以下操作:

Redis 调用forks. 同时拥有父进程和子进程。

子进程将数据集写入到一个临时 RDB 文件中。

当子进程完成对新 RDB 文件的写入时，Redis 用新 RDB 文件替换原来的 RDB 文件，并删除旧的 RDB 文件。

AOF工作方式

Redis 执行 fork() ，现在同时拥有父进程和子进程。

子进程开始将新 AOF 文件的内容写入到临时文件。

对于所有新执行的写入命令，父进程一边将它们累积到一个内存缓存中，一边将这些改动追加到现有 AOF 文件的末尾,这样样即使在重写的中途发生停机，现有的 AOF 文件也还是安全的。

当子进程完成重写工作时，它给父进程发送一个信号，父进程在接收到信号之后，将内存缓存中的所有数据追加到新 AOF 文件的末尾。

Redis 原子地用新文件替换旧文件，之后所有命令都会直接追加到新 AOF 文件的末尾。

RDB方式存储的文件名是dump.rdb，而AOF是appendonly.aof。

redis.conf文件里面，RDB快照的配置：

save 900 1

save 300 10

save 60 10000

上面分别表示15分钟内有一个key的值改动，5分钟内10个key值改动，1分钟内10000个key值改动，都会触发生成快照。

SHUTDOWN 和 FLUSHALL 命令都会触发RDB快照。

而AOF的配置：

appendfsync everysec

主要有no，everysec，always这三个值，no表示操作系统决定什么时候同步命令到文件，everysec表示每秒钟同步一次命令到aop文件，而always表示每次有写命令就同步到文件。

如果AOF文件混入了不正确的命令，可以使用redis-check-aof 进行检查修复。

redis事务

redis事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。

事务是一个原子操作：事务中的命令要么全部被执行，要么全部都不执行

redis事务命令

multi：标志事务的开始。

exec：执行事务命令，命令的回复是一个数组， 数组中的每个元素都是执行事务中的命令所产生的回复。

discard：清空事务队列，退出事务状态。

watch：锁定key值，直到执行了multi或者exec命令。如果监控了某个key值，同时在接下来的事务中对key值有修改，那么执行事务前，其他客户端如果修改了该key值，那么执行事务时会失败。需要生效，则重新执行事务。这个场景的描述就是乐观锁。

exec被调用时， 不管事务是否成功执行， 对所有键的监视都会被取消。

unwatch：去除监控状态。

使用 AOF 方式做持久化的时候， Redis 会使用单个 write 命令将事务写入到磁盘中。然而，如果 Redis 服务器因为某些原因被管理员杀死，或者遇上某种硬件故障，那么可能只有部分事务命令会被成功写入到磁盘中。如果 Redis 在重新启动时发现 AOF 文件出了这样的问题，那么它会退出，并汇报一个错误。使用redis-check-aof程序可以修复这一问题：它会移除 AOF 文件中不完整事务的信息，确保服务器可以顺利启动。

redis事务中只要有一条命令中显示地报错之后，虽然后面的命令也可以入队列，但是最后整个队列的命令都不会执行。这里对string类型使用incr命令，显示报错。

而另外一种情况，事务命令输入过程中虽然没报错，但是执行的时候报错，这个时候这条执行出错的命令未执行，其余正常的命令执行生效。下面就是用hash的命令操作string类型的key值。

正如前面描述，redis事务执行失败，不会进行回滚，而是继续执行后面的命令。

缓存和雪崩

参考下面的文章

编程之路：面试前必知Redis面试题—缓存雪崩+穿透+缓存与数据库双写一致问题

sffe：Redis的三种集群方式+穿透与雪崩的预防和解决