redis

redis采用单线程+多路IO复用技术

RDB触发条件： 1）满足rdb保存策略 2）redis正常关闭 3）手动保存快照
RDB恢复：
1）关闭redis
2）将备份文件拷贝到工作目录下
3）启动redis，备份数据会自动加载
RDB的优点：
1）节省磁盘空间
2）恢复速度快
RDB的缺点：
1）虽然redis在fork时使用了写时拷贝技术（只有在真正持久化时才会占用cpu），但是如果数据庞大时还是比较消耗性能的
2）在备份周期在一定时间间隔做一次备份，如果redis意外down掉的话，就会丢失最后一次快照后的所有修改

AOF：以日志的形式来记录每个写操作，将redis执行果的所有写指令记录下来（读操作不记录），只许追加文件但不可以修改文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一以完成数据的恢复工作。

AOF默认不开启，需要手动在配置文件中配置
AOF同步频率：
1）始终同步，每次redis的写入都会立刻记入日志
2）每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失
3）不主动进行同步，把同步时机交给操作系统
Rewrite
AOF采用文件追加方式，导致文件会越来越大。为避免出现此种情况，新增了重写机制。当AOF文件的大小超过所设定的阈值时，redis就会启动AOF文件的内容压缩，只保留了可以恢复数据的最小指令集。可以使用命令bgrewriteaof。
1）如何重写：
AOF文件持续增长而过大时，会fork出一条新进程来将文件重写（先写临时文件最后再rename），遍历新进程的内存中数据，每条记录有一条的set语句。重写AOF文件的操作并没有读取旧的AOF文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的AOF文件。
2）何时重写？
满足以下条件：

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

系统载入时或者上次重写完毕时，redis会记录此时AOF文件的大小，设为base_size，如果redis的AOF当前大小>=base_size+base_size*100%%（默认）且当前大小>=64mb（默认）的情况下，redis会对AOF进行重写。

两种持久化方式怎么选择呢？
1）官方推荐两个都启用，两个都启用时以AOF为准
2）如果对数据不敏感，可以单独选用RDB
3）不建议单独使用AOF，因为可能会出现bug
4）如果单纯做纯内存缓存，可以都不用

master以写为主，slave以读为主
master宕机之后，slave原地等待
1
2

用处：
1）读写分离，性能扩展
2）容灾快速恢复
如何配置？
配从不配主
1）拷贝多个redis.conf文件include
2）开启daemonize yes
3） Pid文件名字pidfile（可以不指定）
4）指定端口port
5）log文件名字（可以不设置）
6）dump.red名字dbfilename
7）Appendonly 关掉或者换名字
复制原理
1）每次从机联通后，都会给主机发送sync指令
2）主机收到指令后，会立刻进行存盘操作，发送RDB文件给从机
3）从机收到RDB文件后，进行全盘加载
4）之后每次主机的写操作，都会立刻发送给从机，从机执行相同的命令

上一个slave可以是下一个slave的master。
主机宕机之后，从机原地等待，仍然是从机

1）对于薪火相传的关系，当一个master宕机之后，后面的slave可以立刻升级为master（需要手动升级），其后面的的slave不做修改。	
2）用slaveof no one可以将从机变为主机
1
2

redis集群实现了对redis的水平扩容，即启动N个redis节点，将整个数据库分布存储在这N个节点中，每个节点存储总数据的1/N。
redis集群通过分区来提供一定程度的可用性，即使集群中有一部分节点失效或者无法通讯，集群也可以继续处理命令请求。
一个redis集群包含16384个插槽，数据库中的每个键都属于这16384个插槽中的其中一个，集群使用公式CRC16（key）%%16384来计算key属于哪个插槽。
集群中的每个节点负责处理一部分插槽。
在redis-cli每次录入、查询key，redis都会计算出该key应该送往的插槽，如果不是该客户端对应服务器的插槽，redis会报错，并告知应前往的redis实例地址和端口。
redis-cli客户端提供了-c 参数实现自动重定向。
不在一个s插槽下的key，是不能使用mset，mget等多键操作
可以通过{}来定义组的概念，从而使key中{}内相同内容的键值对到一个插槽中去
故障恢复
1）主节点下线后，从节点会自动变为主节点
2）主节点恢复后，变为从节点
3）如果所有某一段插槽的主从节点都宕机，默认redis服务无法提供服务
可通过redis.conf中的cluster-require-full-coverage no来使redis其他正常节点能够正常提供服务（主从节点都宕机的插槽仍然无法使用）