Redis总结笔记

Redis总结笔记 

应用场景

1. 缓存——热数据
2. 计算器
3. 队列
4. 位操做
5. 分布式锁与单线程机制
6. 最新列表
7. 排行榜

 

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是整个内存在压缩过的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应答以通知调用者事务执行失败。

单独的隔离操做：事务中的全部命令都会序列化、按顺序地执行。事务在执行过程当中，不会被其余客户端发送来的命令请求所打断。

没有隔离级别的概念：队列中的命令没有提交以前都不会实际的被执行，由于事务提交前任何指令都不会被实际执行，也不会存在“事务内的查询要看到事务里的更新，在事务外查询不能看到”这个让人万分头疼的问题。

不保证原子性：Redis同一个事务若是有一条命令执行失败，其后的命令仍然会被执行，没有回滚。

 

主从复制

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

从库配置：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. 从机备份时，是把主机的数据所有从新同步一遍。