技术编程|Redis面试知识点( 二 )


上面的配置文件有说重写 , 随着命令的不断写入 , aof文件会越来越大 , 为了解决这个问题 , redis引入了重写机制来压缩体积 。重写的意思是可以简单理解为对于一个数据的若干个执行命令转化为最终结果的执行的命令 , 这样的话日志文件就会小很多 。
如果aof文件有问题 , redis是启动不起来的 , 有一个redis-check-aof,所以如果有问题的话 , 可以用这个工具进行修复 redis-check=aof --fix xxxxx
这种方式的优点是: 最安全 , 数据不会轻易的丢失 , 即使配置的模式是everysec , 每秒执行执行一次 , 也只会丢失一秒的数据 , 在写aof文件的时候哪怕只写了一半 , 导致aof文件损坏 , 可以用工具进行恢复 , 而且aof文件易于修改 , 我们可以直接进行修改 。
缺点是:AOF文件太大 , 性能消耗高 , 恢复慢redis的消息发布与订阅:SUBSCRIBEchannel[channel...]订阅一个或多个频道PUBLISHchannelmessage发布消息
原理:
通过subscribe命令订阅了一个频道后 , redis-server里会维护一个字典 , 字典里面的每一个值就是一个频道 , 每一个值对应一个链表 , 链表中存储的是每一个订阅了这个频道的客户端 , 所以subscribe的作用就是把客户端添加到链表中 。publish向订阅者发布消息的时候 , redis-server会用给定的频道 , 在字典中查找这个频道的链表 , 遍历链表 , 将消息发布给订阅的客户端 。Redis 集群
单个的redis-server存在不确定性 , 当redis-server挂了就没有服务可用了 , 而且单个server的读写能力有限 ,所以需要集群模式 。在集群中分为主节点master , 和从节点slave , redis集群基于主从复制实现 。
在redis的的集群中一个master节点 , 多个slave节点 , master节点负责写 , slave节点负责读 。master节点会一直将数据同步给从节点 。这种架构实现了读写分离 , 也不用担心数据的恢复 。
这种模式的配置也很简单只需要在从节点的配置文件中加上:slaveofmaster节点6379
如果配置文件没有加 , 直接使用命令也可以的 。
这种架构中master节点只负责写 , 但是如果master节点挂了 , 那么系统中也就没有能写的节点了 , 所以这种架构也是有问题了 , 为了解决这个问题 , 提供了一种哨兵模式 。
哨兵模式: sentinel 哨兵 。sentinel系统用于管理多个redis服务器 , 监控主节点和从节点是否能正常的运行 , 当某一个redis服务器出现了故障 , 哨兵可以通过api向管理员或者其他程序发出通知 , 最主要的功能是 , 当master节点不能正常工作了之后 , sentinel会进行一次故障迁移操作 , 从从节点中选取一个节点作为主节点 , 那这样的话就解决了主节点挂了就没有节点可以写的问题了 。
哨兵作为一个单独的进程而存在的 , 所以需要不同的配置文件:vimsentinel.conf#port26379端口 , 如果一台机器上只开启一个哨兵可以不配置 , sentinelmonitormymaster192.168.8.10063792#sentinelmonitor代表监控 , mymaster是服务名称,可以自定义;#192.168.8.100地址;6379代表端口,2代表只有两个或两个以上的哨兵认为主服务器不可用的时候 , #才会进行failover操作
需要注意的是最后那个2 , 表示的是在哨兵集群中 只有两个以上的哨兵认为主服务器不可用的时候才会进行迁移操作 。
哨兵作为一个单独的进程 , 如果只有一个哨兵的话 , 那这个进程挂了 , 那哨兵系统也就挂了 , 所以一般会为哨兵配置一个集群 , 一般是三个 。在测试中一般是一个就可以 , 那么2应该改为1Redis的缓存穿透 , 击穿和雪崩
缓存穿透指的是当用户查询一个数据的时候 , 发现redis内存没有 , 那么就需要去数据库查询 , 发现数据库也没有 , 这次查询失败 。当用户很多的时候 , 查询都没有命中 , 这就会给数据库造成很大的压力 , 这就是缓存穿透 。


推荐阅读