redis必备知识
redis持久化
谈到redis的持久化，肯定离不开RDB（Redis DataBase）和AOF（Append Only File）这两个概念
1.什么是RDB(Redis DataBase)?
在指定的时间间隔内将内存中的数据集快照写入磁盘，
也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里
Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到
一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。
整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能
如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方
式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。
2.rdb 保存的是dump.rdb文件
3.如何触发RDB快照
配置文件中默认的快照配置,冷拷贝后重新使用,可以cp dump.rdb dump_new.rdb
命令save或者是bgsave
Save：save时只管保存，其它不管，全部阻塞
BGSAVE：Redis会在后台异步进行快照操作，
快照同时还可以响应客户端请求。可以通过lastsave
命令获取最后一次成功执行快照的时间
执行flushall命令，也会产生dump.rdb文件，但里面是空的，无意义
4.如何恢复
将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可
CONFIG GET dir获取目录
5.优点:
适合大规模的数据恢复
对数据完整性和一致性要求不高
快速持久化，
占用磁盘空间少，
一般备份是通过RDB实现的，
主从复制功能也是通RDB功能实现的。
6.缺点
在一定间隔时间做一次备份，所以如果redis意外down掉的话，就
会丢失最后一次快照后的所有修改
fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑
7.如何停止
动态所有停止RDB保存规则的方法：redis-cli config set save ""
2.什么是AOF（Append Only File）
以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，
只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis
重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
1.Aof保存的是appendonly.aof文件
2.优点:
每修改同步：appendfsync always 同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好
每秒同步：appendfsync everysec 异步操作，每秒记录 如果一秒内宕机，有数据丢失
3.缺点:
相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb
aof运行效率要慢于rdb,每秒同步策略效率较好，不同步效率和rdb相同
3.总结
RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储
AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些
命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.
Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大
只做缓存：如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式.
同时开启两种持久化方式:
在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据,
因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.
RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢？
作者建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，
快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段。
因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。 如果Enalbe AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了。代价一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。默认超过原大小100%大小时重写可以改到适当的数值。 如果不Enable AOF ，仅靠Master-Slave Replication 实现高可用性也可以。能省掉一大笔IO也减少了rewrite时带来的系统波动。代价是如果Master/Slave同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个Master/Slave中的RDB文件，载入较新的那个。新浪微博就选用了这种架构
redis事务
可以一次执行多个命令，本质是一组命令的集合。一个事务中的
所有命令都会序列化，按顺序地串行化执行而不会被其它命令插入，不许加塞
能干嘛？
一个队列中，一次性、顺序性、排他性的执行一系列命令
这里watch监控意义在于保证我的事务在执行期间，被监控的数据都是没有做改动的，如果这些被监控的数据有改动，那么我的事务立刻停止执行，需要再去数据库抓取一次数据再来重写我们的事务流程(比如对信用卡的关键key余额做监控，一旦在我事务执行期间改动了，那整个事务停止执行)，解决方式是发起本次监控并重新抓取数据......
事务之全体连坐
在创建事务的时候，如果事务内有一行代码在创建的时候就已经报错，那么整个事务都不会被执行
事务之冤头债主
在创建事务的时候，代码都没有报错，但是在执行阶段有几个语句无法操作，比如你的语句是让值加一，然而值是字符串类型，没法加一，这个时候所有不报错的语句都会执行成功，只有那些执行阶段报错的语句不会执行成功
原因:redis是部分支持事务，不像传统的数据库对事务是强一致性的要求
事务之watch监控
悲观锁
类似于关系型数据库的表锁，行锁。redis里面的悲观锁也是如此，对于数据操作会上锁，也就是它默认我在操作数据的时候，别人肯定会来改，所以我要提前加锁
我在改的时候，你们都给我排队等着
乐观锁
乐观锁则认为我的数据在操作的时候不会被改动，但是乐观锁采用另一种机制来保证数据修改的安全性和一致性，即给每一条数据后面加上一个类似于版本号的东西，
例子:张三和李四都需要修改这条数据的微信号和qq号，数据起始版本号为1，这样张三和李四可以同时修改数据，但是在提交的时候，加入张三比李四提前0.2秒提交了数据，并且提交时库里的版本号就是1，那么张三提交后版本号变为2，这个时候李四再提交的时候，就会报错，因为李四在拿这条数据的时候版本是1，而由于张三提前修改了，版本号变成2了，所以没法进行这一次的修改，必须重新抓取张三改过的数据再来进行修改，当然，如果又有人在李四修改期间提前提交修改操作，版本号又会更新，李四提交操作仍然会失败
关键点就在于:提交版本必须大于当前记录的版本才能更新
总结:
实际应用中，乐观锁比悲观锁应用较多，他能更好的实现高并发，提高数据的吞吐量(起码我们可以同时拿到数据)
watch监控
此时如想继续修改，必选先放弃监控，再重新监控从头来过
消息订阅
什么是消息订阅(实际不用它来做消息中间介)
是进程与进程之间的一种通信模式，发送者(pub)发布消息，订阅者(sub)接收消息(微信关注公众号，qq订阅消息频道)
订阅了之后，只有频道发布消息，会自动推送给订阅者，通配符形式的相当于统统匹配，比如我的new频道有13个台，那么我在创建的时候，可以直接new*，订阅者也只需要订阅这一个new*即可收到所有new开头的频道内容
主从复制
是什么
主机数据更新后根据配置和策略，自动同步到备机的master/slaver机制，Master以写为主，Slave以读为主
能干嘛
读写分离，容灾恢复
怎么玩
1.当有主机转型成从机之后，它会从头到尾将主机的数据复制一份(第一次)全量复制，后续主机加一个，从机也就仅仅加一个，不会从头到尾再复制了(增量复制)
2.读写分离:从机只能读不能写，只有主机可以写
3.主机宕机后，在不设置相应配置的情况下，从机会原地待命，主机再次回来后依旧跟从
4.从机死了后，在不设置相应配置的情况下，重启后不再是从机而是单独的主机，需要重新设置，或者提前配置到文件中
主从复制优化(减轻主机负担)
薪火相传
反客为主
主机挂了之后，需要在从机中手动选出一个主机，这个时候老的主机再回来就不再是我这个体制内的了，自成一派光杆司令。
哨兵模式
简单的理解哨兵模式就是反客为主的自动版
在哨兵模式下，如果主机宕机了，会在从机里面投票选出一个从机当主机，之后如果原来的主机又回来了，在较短的时间内还没有被哨兵模式监控到的时候，回来的主机就是自己一个人单独一套体系自己是光杆司令，但是一会儿功夫，哨兵模式监控到了这个重启的主机后，哨兵模式会告诉这个新来的主机，已经换老大了，你需要跟着新老大混，这个时候新来的就会自动变为从机依附于前面投票选出来的主机
