Redis总结笔记 

应用场景

Maxmemory-policy算法

1. volatile-lru：使用LRU算法移除key，只对设置了过期时间的键。
2. allkeys-lru：使用LRU算法移除key。
3. volatile-random：在过期集合中移除随机的key，只对设置了过期的时间的键。
4. allkeys-random：移除随机的key。
5. volatile-ttl：移除那些TTL值最小的key，即那些最近要过期的key。
6. noeviction：不进行移除。针对写操作，只返回错误信息。

RDB

介绍 

小总结

• RDB是一个非常紧凑的文件。
• RDB在保存RDB文件是父进程唯一需要做的就是fork出一个紫禁城，接下来的工作全部由子进程来做，父进程不需要再做其他I/O操作，所以RDB持久化方式可以最大化Redis的性能。
• 与AOF相比，在回复大的数据集的时候，RDB方式会更快一些。
• 数据丢失风险大。
• RDB需要经常fork子进程来保存数据集到硬盘上，当数据集比较大的时候，fork的进程过程是非常耗时的，可能会导致Redis在一些毫秒级不能响应客户端请求。

AOF

优势

劣势

小总结

• AOF文件是一个只进行追加的日志文件。
• Redis可以在AOF文件体积变得过大时，自动地在后台对AOF进行重写。
• AOF文件有序地保存了对数据库执行的所有写入操作，这些写入操作以Redis协议的格式保存，因此AOF文件的内容非常容易被人读懂，对文件进行分析也很轻松。
• 对于相同的数据集来说，AOF文件的体积通常要大于RDB文件的体积。
• 根据所使用的fsync策略，AOF的速度可能会慢于RDB。

持久化总结

• RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储。
• AOF持久化方式记录每次对服务器写的操作，当服务器重启的时候回重新执行这些命令来恢复原始的数据，AOF命令以redis协议追加保存每次写的操作到文件末尾。
• Redis还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大。
• 只做缓存：如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化方式。
• 同时开启两种持久化方式。
• RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢？
• 作者建议不要，因为RDB更适合用于备份数据库（AOF在不断变化不好备份）。
• 快速重启，而且不会有AOF可能潜在的BUG，留着作为一个万一的手段。
• 性能建议。
• 因为RDB文件只用做后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。
• 如果Enable AOF，好处是在最恶劣情况下也智慧丢失不超过两秒的数据，启动脚本比较简单只load自己的AOF文件就可以了。代价以是带来了持续的I/O，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M大小了，可以设到5G以上，默认超过原大小的100%大小时重写可以改到适当的数值。
• 如果不Enable AOF，仅靠Master-Slave Replication实现高可用也可以，能省掉一大笔I/O也减少了rewrite时带来的系统波动，代价是如果Master/Slave同时挂掉，会丢失十几分钟的数据，启动脚本也要比较买两个Master/Slave中的RDB文件，载入较新的那个，新浪微博就选用了这种架构。

事务

小结

• Watch指令类似乐观锁，事务提交时，如果key的值已被别的客户端改变，比如某个list已被别的客户端push/pop过了，整个事务队列不会被执行。
• 通过Watch命令在事务执行之前监听了多个keys，倘若在Watch之后有任何key的值发生了变化，Exec命令执行的事务都会被放弃，同时Nullmulti-bulk应答以通知调用者事务执行失败。

主从复制

配置从（库）不配主（库）

从库配置：slaveof主库IP主库端口

• 每次与master断开之后，都需要重新连接，除非你配置进redis.conf文件。
• Info Replication。

修改配置文件细节操作

• 拷贝多个redis.conf文件。
• 开启daemonize yes。
• Pid文件名字。
• 指定端口。
• Log文件名字。
• Dump.rdb名字。

常用三招

1. 一主二仆

• Init。
• 一个Master两个Slave。
• 日志查看。
• 主从问题演示。
• 能干嘛。
• 怎么玩。
• 复制原理。
• Slave启动成功连接到Master后会发送一个sync命令。
• Master连接命令启动后台的存盘进程，同时收集所有接受到的用于修改数据命令，在后台进程执行完毕之后，master将传送整个数据到slave，以完成一次完全同步。
• 全量复制：而Slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。
• 增量复制：Master继续将新的所有收集到的修改命令一次传给slave，完成同步，但是只要重新连接master，一次完全同步（全量复制）将被自动执行。
• 哨兵模式。
• 是什么。
• 怎么玩。
• 自定义/myredis目录下新建sentinel.conf文件，名字绝对不能错。
• 配置哨兵，填写内容
• sentinel monitor被监控的数据库名字（自己起名字）如：127.0.0.1 6379 1。
• 上面最后的一个数字1，表示主机挂掉后slave投票看让谁接替为主机，得票数多称为主机。
• 启动哨兵。
• Redis-sentinel /myredis/sentinel.conf。
• 上述目录依照各自的实际情况配置，可能目录不同。
• 正常主从演示。
• 原有的master挂了。
• 投票新选。
• 重新主从继续开工，Info Replication查查看。
• 问题：如果之前的master重新回来，会不会master冲突？
• 一组sentinel能同时监控多个master。

• 复制缺点。
• 由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题变得更加严重。

2. 薪火相传
3. 反客为主

• SlaveOf no one。使当前数据库停止与其他数据库同步，转为主数据库。

需了解的问题：

1. RDB成功恢复，RDB可以搞定备份为什么会有OAF。新技术的出现一定要弥补老技术的不足同不同意，新技术一定会借鉴老技术，是老技术的子类，一般子类要比父类强大？
2. 如果一个系统里面同时存在RDB和AOF是冲突还是协作？
3. 为什么AOF会在RDB之后产生？
4. AOF有什么优缺点？

一主二从典型问题

1. 主机写入k1，从机写入k1，会报错，从机只能读。
2. 主机宕机，从机不会上位争master，从机原地待命，如果主机重新恢复，主机写入，从机依然能获取到数据。
3. 从机宕机了，主机能够写入，从机重启后需重新连接主机才能获取到主机数据，或者写入配置中。
4. 从机备份时，是把主机的数据全部重新同步一遍。

原文：https://www.cnblogs.com/will-xz/p/10045048.html