redis的使用（二）

继redis的使用（一）之后，继续redis的使用

redis发布订阅

开启两个客户端，publish发布管道消息，subscribe消费管道消息，subscribe端需要提前开启等待。

redis事务

mult开启事务，开启事务后，命令放在缓冲队列里，当执行exec时，执行命令。redis是单线程的，哪 个exec先执行就先执行哪个事务

设置过期时间，ttl查看还有多久过期，expire设置过期时间 ，expireat设置过期时间（时间戳），在过期时间之内发生写操作，过期时间会剔除。

redis持久化

Redis有两种不同形式的持久化策略：

1. RDB(redis database)

RDB是redis默认的持久化策略，将redis内存数据状态以内存快照的形式保存到磁盘里，RDB是通过二进制文件保存数据状态的，这个数据文件的名称及位置，可以在redis的配置文件中查看及修改。

RDB具有时点性，保存rdb文件的时机是分为两种的：一是手动执行save和bgsave,二是配置文件中有配置条件。save是阻塞式的保存文件（客户端请求会被拒绝），直到生成完毕，bgsave是非阻塞的，fork一个子进程来保存rdb文件，配置文件中的save标识其实是bgsave。900秒之后如果至少有一个key改变触发bgsave。

RDB优缺点：

缺点：不支持拉链，只有一个dump.rdb文件；丢失数据较多，时点与时点之间窗口容易数据丢失。

优点：恢复数据速度较快

2. AOF(append of file)

AOF持久化默认是关闭的，可以通过修改配置文件appendonly yes来开启，RDB与AOF可以同时开启，如果开启了AOF功能，会优先使用AOF恢复数据状态，AOF开启之后，命令会追加到aof文件中，aof文件目录与rdb文件在同一目录下，可在配置文件找到。AOF写操作会触发IO操作，redis支持三种不同的策略模式，在配置文件中可以体现。

appendfsync的值可以设置为always、everysec、no三种，默认值是everysec,值为always,每执行一个命令，都要将aof_buf缓冲区中的内容写入到磁盘aof文件中，everysec是每隔一秒钟，将aof_buf缓冲区中内容写入到磁盘aof文件中，no是何时写入磁盘由操作系统决定。always对redis高性能有严重的影响，数据安全，no数据最不安全。

Redis AKF原理

单节点，单实例会有一些问题：

1. 单点故障，只有一个Redis服务，如果出现故障，服务器就不可用了

2. 容量有限

3. 访问压力，单节点Redis在搞并发的环境下承受很大的压力

AKF原理试图解决以上问题，AKF从X、Y、Z三个方向尝试解决以上问题。

X轴：可以使用多节点Redis,水平复制多个副本，是主Redis的全量镜像，解决了单点故障问题，单不能解决容量有限问题。

Y轴：按业务、功能拆分Redis服务，数据可以分类，交集不多，解决容量有限问题。

Z轴：按照优先级或者特定的逻辑进行拆分，为了解决容量有限及访问压力问题，按业务拆分之后，数据依然很大，这时采用sharding分片方案：

1. 客户端使用逻辑方案hash+取模拆分，弊端取模的数值必须固定，影响分布式下的扩展性。

2. 客户端使用逻辑方案random,随机性较大，不知道数据放在哪，适用于消息队列如kafka，数据list类型的，放数据lpush,取数据rpop。

3. 客户端使用逻辑方案一致性哈希ketama,没有取模，结果值唯一，规划一个哈希环，环上的点是虚拟的，经过算法映射，找到离此结果最近的物理节点。

通过AKF服务器节点一变多后，会带来数据一致性问题。解决方案：1.同步阻塞方式，所有节点阻塞直到数据全部一致，强一致性，破坏可用性。2.异步方式，弱一致性，容忍丢失数据；最终一致性，最终数据会一致，有可能取到不一致的数据。

CAP理论，是指分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）,三者不可兼得。一致性高，可用性低；相反，一致性低，可用性高。

Redis主从复制

在redis客户端输入命令replicaof来指定要追随的主节点，从节点需要指定主节点，主节点不需要配置,默认情况下，从节点不能写数据，需要改配置文件。

从节点挂了之后，重启服务，使用命令redis-server /etc/redis/6381.conf --replicaof 127.0.0.16379 增量同步，使用命令redis-server /ect/redis/6381.conf --replicaoff 127.0.0.1 6379 --appendonly yes 开启aof,全量同步。主节点知道有多少个从节点追随。

使用replicaof no one 停止追随。

info replication命令查看该节点主从信息

新建哨兵配置文件，可自选放在哪个目录下，本文中放置在redis的配置文件目录下/etc/redis。配置文件内容为端口号，及哨兵要检查的主节点，后面的2为有多少个哨兵监测到主节点掉了才重新选择主节点，如果只有一个哨兵则应该设为1，否则不会重新票选新节点。若为2至少要两个哨兵检查主节点，可以多增加配置文件，修改端口号，启动多个哨兵来监测主节点。

哨兵启动命令 redis-server 哨兵配置文件 --sentinel,也可以使用命令redis-sentinel 哨兵配置文件。

哨兵监测到主节点故障，可以自动故障转移，投票选出新的主节点，哨兵会改变自己的配置文件，票选出新的主节点后配置文件中响应的监测主节点也相应的变化，哨兵根据redis的发布订阅确定其他哨兵的。

穿透：从业务接收查询的是系统不存在的数据，解决方案是使用布隆过滤器、布谷鸟过滤器或者使用空key。

击穿：key的过期造成并发访问数据库，解决方案使用分布式锁,只有获得锁的去访问数据库。

雪崩：大量的key同时失效，间接造成大量的访问到达数据库，解决方案：如果与时点性无关，使用随机过期时间，如果与时点性有关，业务层判断延时或者随机过期时间，强依赖与击穿的解决方案。

redis分布式锁：setnx锁，为了阻止并发到达数据库，使用分布式锁，首先，get key,为空加锁setnx,获得锁的去访问数据库，获得锁失败的sleep之后再get key重复上述过程，存在的问题是获得锁的挂了，就会出现死锁，解决办法可以设置锁的过期时间，另一个问题是没有挂但是锁超时了，解决办法是使用多线程，一个线程访问数据库，一个线程检查value是否取回来，更新锁时间。