Redis总结笔记
Redis总结笔记
应用场景
- 缓存——热数据
- 计算器
- 队列
- 位操作
- 分布式锁与单线程机制
- 最新列表
- 排行榜
Maxmemory-policy算法
- volatile-lru：使用LRU算法移除key，只对设置了过期时间的键。
- allkeys-lru：使用LRU算法移除key。
- volatile-random：在过期集合中移除随机的key，只对设置了过期的时间的键。
- allkeys-random：移除随机的key。
- volatile-ttl：移除那些TTL值最小的key，即那些最近要过期的key。
- noeviction：不进行移除。针对写操作，只返回错误信息。
RDB
介绍
RDB是整个内存在压缩过的Snapshot，RDB的数据结构，可以配置复合的快照触发条件。默认： 是1分钟内改了1万次， 或5分钟内改了10次， 或15分钟内该了1次。小总结
- RDB是一个非常紧凑的文件。
- RDB在保存RDB文件是父进程唯一需要做的就是fork出一个紫禁城，接下来的工作全部由子进程来做，父进程不需要再做其他I/O操作，所以RDB持久化方式可以最大化Redis的性能。
- 与AOF相比，在回复大的数据集的时候，RDB方式会更快一些。
- 数据丢失风险大。
- RDB需要经常fork子进程来保存数据集到硬盘上，当数据集比较大的时候，fork的进程过程是非常耗时的，可能会导致Redis在一些毫秒级不能响应客户端请求。
AOF
是什么 AOF保存的是appendonly.aof文件 配置位置 AOF启动/修复/恢复 Rewrite优势
劣势
小总结
- 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名字。
常用三招
- 一主二仆
- 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机器数量的增加也会使这个问题变得更加严重。
- 薪火相传
- 反客为主
- SlaveOf no one。使当前数据库停止与其他数据库同步，转为主数据库。
需了解的问题：
- RDB成功恢复，RDB可以搞定备份为什么会有OAF。新技术的出现一定要弥补老技术的不足同不同意，新技术一定会借鉴老技术，是老技术的子类，一般子类要比父类强大？
- 如果一个系统里面同时存在RDB和AOF是冲突还是协作？
- 为什么AOF会在RDB之后产生？
- AOF有什么优缺点？
一主二从典型问题
- 主机写入k1，从机写入k1，会报错，从机只能读。
- 主机宕机，从机不会上位争master，从机原地待命，如果主机重新恢复，主机写入，从机依然能获取到数据。
- 从机宕机了，主机能够写入，从机重启后需重新连接主机才能获取到主机数据，或者写入配置中。
- 从机备份时，是把主机的数据全部重新同步一遍。
更多精彩
