总结了Redis的事务机制,持久化机制,主从复制,Redis Cluster分片集群
事务机制总结
-
redis支持事务,但是是伪事务
-
redis事务是放入队列中的
-
编译时期出错则全部回滚,运行期出错不会全部回滚只回滚错误,所以redis中的事务很少使用到
-
开启事务:multi 执行事务:exec
持久化机制总结
redis中有两种持久化机制:RDB和AOF
RDB快照
-
RDB快照持久化为了保证性能
-
默认是RDB快照,在指定的时间间隔将内存中的数据集快照写入磁盘
-
RDB快照持久化默认bgsava异步子线程执行,sava会阻塞线程RDB文件保存完才执行
-
优点:基于二进制数据备份,占用空间少,传输快,还可以自定义规则,如:save 3600 1 表示1个小时(3600s)内有一个键(key)被修改就会保存快照
-
缺点:最后一次持久化的数据可能丢失,bgsava也会阻塞redis服务创建子线程,影响redis效率
AOF
-
AOF持久化为了保证安全
-
默认关闭,AOF为了解决RDB数据丢失的问题
-
AOF只保存写的操作(增删改)
-
三种触发方式:always和everysec和no
-
always:每个写的命令,都会同步写入磁盘,影响redis性能.
-
everysec:每秒保存一次,在这一秒内执行写的命令同步至磁盘.
-
no:不同步至磁盘
-
-
AOF重写主要是解决写入命令的AOF文件体积的庞大导致磁盘占用量大和数据还原速度巨慢.
RDB与AOF对比
-
RDB默认开启,AOF手动开启
-
RDB性能优先于AOF
-
AOF安全高于RDB
-
如果两个都开启的话,AOF优先级高于RDB
-
RDB储存的是指定时间的快照,AOF保存写的命令,逐行或每秒
-
AOF的文件比RDB文件要大
-
redis负载较高的时候,RDB要比AOF性能好
主从复制总结
-
主从复制是将一台服务器的数据复制到其他服务器上,前为主,后为从
-
主要解决是当一台服务器出现故障导致磁盘的损坏造成的单点故障,目的是提高高可用
-
主从复制的作用:
-
读写分离:主写从读,主节点可写可读,从节点只可读,提高服务器的负载能力
-
负载均衡:基于主从结构,配合读写分离,由从节点分担主节点负载,提高了服务器的并发量和数据的吞吐量
-
数据冗余:实现了数据了热备份,是持久化之外的一种数据冗余方式
-
故障恢复:主节点出现故障,从节点提供服务,实现快速的故障恢复
-
高可用基石:基于主从复制,构建哨兵模式与集群,实现Redis的高可用方案
-
-
哨兵模式主要解决的是当主服务宕机了,需要手动将从服务器切换为主服务器,将手动改为自动了
-
哨兵也是一台服务器,只是不提供数据服务,但哨兵也会出现单点故障,就需要搭建哨兵集群,数量为单数
-
哨兵三大工作任务
-
监控:不断的检查主服务器和从服务器是否运行正常
-
提醒:当某个服务器出现问题,会及时的通知管理员
-
自动故障迁移:当主服务器出现故障不能工作时就会出现自动故障转移,将主服务器的从服务器升级为主服务器,将其他的从服务器改为复制新的主服务器.当客户端试图连接失效的主服务器时,哨兵集群返回新主服务器地址.
-
-
主观下线:哨兵进程会使用PING命令检测与主和从服务器的连接状况.如果超时了或距离最后一次有效恢复PING命令down-after-milliseconds所指定的值的时间超过就标记为"主观下线".
-
如果检测到是从服务器就直接标记"主观下线",因为影响不大.
-
如果检测到是主服务器不能直接标记,因为会存在误判,这个时候就出现了客观下线.
-
-
客观下线:当哨兵将一个主服务器判断为下线之后,需要判断主服务器是否真的下线了,它会向同样监控主服务器的其他哨兵进行询问,如果其他哨兵认为主服务器也进入下线状态的话就确认客观下线.进行对主服务器自动故障转移.只适用于主服务器(Master).
-
一主二从三哨兵
-
问题解决:
-
主从集群间可以实现自动切换,可用性更高
-
数据更大限度的防止丢失
-
解决哨兵的集群高可用问题,减少误判率
-
-
存在主服务器的写能力和储存能力有限的问题
Redis Cluster分片集群总结
-
Redis Cluster分片集群主要是解决主从复制不能实现高可用,高可扩,在海量流量访问下提供稳定的服务
-
优点:
支持数据分片功能, 将数据分配给不同的服务器上
服务的高可用,自动故障转移,最大程度上避免了单点故障,提高并发量
无中心架构
-
PS:如果有哪位大佬看出来有什么错误,可以告知一二,谢谢了.