redis（二）零碎知识点总结

1. redis采用单线程避免线程资源竞争上下文切换，io多路复用，基于内存操作，以支持高并发操作

2.redis持久化分为rdb和aof,

• rdb触发可通过save命令和bgsave命令，将当前进程的数据生成一个快照，bgsave只会阻塞fork阶段，(fork命令利用的copy on write机制。在生成快照时，将当前进程整个复制出来，fork出一个子进程，然后在子进程中循环所有的数据，将数据写成为RDB文件），rdb不适合做实时持久化，fork进程是比较重的操作，而且系统需要有大于实例两倍的内存预留，否则会内存不足崩溃。
• aof，所有写入命令会写到aof_buf缓冲区，再将缓冲区的内容同步到硬盘，写入数据采用文本协议。由于aof文件会越来越大，因此可以通过手动触发或自动触发进行文件重写（已经超时的数据无需保留，集合多条写命令可以合并成一条，多条操作命令只需要保存最后一个有效命令，比如重复对同一个键设值），自动触发有两种配置

• auto-aof-rewrite-min-size:表示运行AOF重写时文件最小体积，默认为64MB

• auto-aof-rewrite-percentage:代表当前AOF文件空间（aof_current_size）和上一次重写后AOF文件空间（aof_base_size）的值

      aof同步到硬盘有三种形式，

1. everysec  每秒刷一次，这种形式避免每次都直接往硬盘刷新，提高性能，又能保证一定的安全性，服务挂了顶多丢失1秒的数据。
2. no  随机时间刷新，刷新时机不可控，性能高，数据安全性低
3. always 每次都同步，安全性高，性能低，且受限机器硬盘负载

3. sentinel通过gossip协议进行故障检测failover,sentinel认为一个master不可用分为两种，一种是sdown 主观不可用，一种是odown 客观不可用，当一个sentinel通过心跳检测(ping)发现一个master没有在配置的超时时间内回复，或者回复内容不合法，该sentinel则主观认为master挂了，同时通过基于gossip协议将此信息广播到其他的sentinel，当一个sentinel接受到足够的sentinel的消息（failover票数，可配置，配置两个则两个sentinel认为master挂了，就会启动故障转移）之后，状态变成odown，此时会触发failover,但是在执行failover之前，该sentinel要获取其他sentinel的授权，其他sentinel知道要进行failover就不会使用当前版本号对应的master配置，而且这样就不会出现多个sentinel并发去对一个master进行failover。在failover完成后会更新一个配置版本号，广播到其他sentinel，其他sentinel发现版本号升级则会去更新配置。

4.sentinel不用配置某个master的所有slave的地址，sentinel会通过询问master来得到slave的地址，也不用配置其他sentinel节点信息，同样通过master去发现。

 

持续更新中。。。。