浅谈Redis持久化与主从复制及分布式下的CAP和BASE理论

因为redis为纯内存的数据库 所以在写项目的时候必须让其持久化存入硬盘以防止数据丢失 redis持久化分为两种 一种是AOF一种是RDB 咱们就来说说他俩的区别和优劣吧

RDB为默认开启的 使用了一个单独的子进程进行持久化 其主进程不会进行任何的IO操作 从而保证了高效率 其次相比较AOF而言 RDB的恢复速率是要快很多的  但是因为持久化是间隔一段时间的 所以如果在间隔时间段内出现故障 中间的数据就会丢失  并且如果数据量特别大的时候 因为是使用子进程fork协助 有可能会让服务器停止服务一段时间 系统默认的持久化条件为15分钟之内至少一次写操作、5分钟之内至少发生10次写操作、一分钟之内发生至少10000次写操作都会触发发生快照操作 不过这些是可以更改的。

AOF需要手动开启 他提供了更加高效的备份 系统提供了每秒保存 每修改保存与不保存 官方推荐为每秒保存 这样可以把数据丢失内容降低到一秒之内（注意不可以保证数据完全不丢失 只是把损失可以降到一秒以内） 但是反过来想如果真的要数据完完全全的持久化 那么为什么不用关系型数据库呢 这里又扯到了CAP与BASE理论 这个我们下面再说 因为每秒保存导致备份文件会越来越大 如果超过一定的阀值会把当前的文件进行压缩成更小的体积从而再次写入 并且因为使用的是append操作 所以在备份过程中遇到异常断电情况也不会破坏备份文件 但是其缺点也是有的 相比较RDB而言AOF备份文件更大 恢复速率也会更慢

ps：AOF优先级比RDB高 如果两者都开启 默认使用AOF

既然说到了备份 咱们就再来顺便聊聊redis的事务 学过关系型数据库的人可能都会感到疑惑 为什么redis支持事务 但是不支持回滚 这里主要有两点 其一是只有语法错误才会执行失败 这就说明 这个一般都是在开发环境就可以纠正的错误 一般不会弄到生产环境里 其次就是因为不支持事务所以redis内部更加简单 从而确保其高效 

好吧 言归正传 说说主从复制说白了就是一个主节点负责写 多个从节点负责读（因为实际需求里面读的操作远远大于写的操作） 主节点定期把数据同步到从节点保证数据的一致性 好处的话一方面可以读写分离提高效率 另一方面有利于容灾恢复 并且还可以达到高可用的目的 常见的模式可以分为一主二仆 薪火相传 反客为主 还有最为常用的哨兵模式

一主二仆为最基本的 当主机宕机时 从机会原地待命 不会争夺master权限 会一直等待主机上线 当从机宕机后 主从关系即断开 从机上线后变成默认的master

薪火相传为上一个从机可能为下一个从机的master 可以理解其作为一个中转站 最后的从机可以接收之前两个主机的信息 从机只有读的权限 

反客为主 当主机宕机后 从机可以自己上位成为master  这个时候如果主机重新上线 会发现自己已经没有master权限了

哨兵模式（敲黑板 划重点）为最常使用的模式 在该模式下 程序内部会每秒ping对方判断是否宕机 如果主机宕机 从机会自动投票选取新的master 选择规则为大于半数同意  这个时候如果主机重连 会发现自己会变成从机。

最后在说说CAP和BASE理论吧 不过感觉写的有点长能看到这的人应该不多吧（如果都看到这里了 就点个赞吧 哈哈）

CAP中 C代表强一致性 A代表高可用性 P代表分区容错性 但是一个分布式系统里面不可能同时满足三个 说白了就是 CA CP AP 你选一个吧 鱼和熊掌不可兼得啊嘿嘿  CA为保证强一致性和高可用性 举例为传统关系型数据库  CP的话放弃了高可用性 基本不会有人选择（这个也可以理解 连用都不能用了 你搞那么多复杂的有个毛用啊） AP的话放弃了强一致性 距离可为非关系型数据库 并且我们在做项目的时候 由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容错性是我们必须需要实现的 所以一般都会往A、P上面靠。
既然刚刚说到了CAP没有办法同时实现  但是写项目的时候又不能完全抛弃了强一致性 那么怎么办呢 于是BASE理论就由此而生了 BASE为基本可用 软状态和最终一致性  基本可用为允许响应时间上的损失和系统功能上的损失 软状态为系统允许存在中间状态 但是不影响其整体的可用性 最终一致性是允许在高并发访问量的基础上数据出现部分异常 但是等后期访问量下降时 需要达到最终的一致性