redis缓存命令
redis缓存其实就是把经常访问的数据放到redis里面，用户查询的时候先去redis查询，没有查到就执行sql语句查询，同时把数据同步到redis里面。redis只做读操作，在内存中查询速度快。
使用redis做缓存必须解决两个问题，首先就是确定用何种数据结构存储来自mysql的数据；确定数据结构之后就是需要确定用什么标识来作为数据的key。
mysql是按照表存储数据的，这些表是由若干行组成。每一次执行select查询，mysql都会返回一个结果集，这个结果是由若干行组成的。redis有五种数据结构：列表list，哈希hash，字符串string，集合set，sorted set(有序集合)，对比几种数据结构，string和hash是比较适合存储行的数据结构，可以把数据转成json字符串存入redis。
全量遍历键： keys pattern keys *
有人说 KEYS 相当于关系性数据的库的 select * ，在生产环境几乎是要禁用的
不管上面说的对不对， keys 肯定是有风险的。那我们就换一种方案，在存数据的时候。把数据的键存一下，也存到redis里面选hash类型，那么取的时候就可以直接通过这个hash获取所有的值，自我感觉非常好用！
㈡ 如何查询redis的缓存文件路径
1、首先找到redis的安装目录，如下图测试环境目录，进入到/opt/install/redis-2.8.19/src，如下图所示。
㈢ 测试技术-中间件-删除redis缓存key值
跳板机Xshell命令操作：
执行连接> redis-cli -h {ip} -p {port} -a {password}
执行登录> auth {password}
执行检查> exists {key}
执行删除> del {key}
set #set类型
hash #hash类型
(integer) -2 #不存在的 key
(integer) -1 #存在key ，但没有设置剩余生存时间
(integer) 6179 #存在key，有设置剩余生存时间（毫秒）
> HKEYS auth.client.details
1) "\xac\xed\x00\x05t\x00\x13mih7201092011201546" #字段名
2) "\xac\xed\x00\x05t\x00\x13mih5288722010211719" #字段名
3) "\xac\xed\x00\x05t\x00\x13mih9979092010211719" #字段名
> HMGET auth.client.details "\xac\xed\x00\x05t\x00\x13mih2749661808171742"
https://www.runoob.com/redis/redis-strings.html
㈣ 缓存-redis 三种模式搭建和运行原理
标签： redis 缓存 主从 哨兵 集群
本文简单的介绍redis三种模式在linux的安装部署和数据存储的总结，希望可以相互交流相互提升。
对于Centos7在安装redis之前需要进行一些常用工具的安装：
关闭防火墙
正式安装redis
在redis进行maketest时候会出现一系列的异常，有如下解决方案：
用redis-server启动一下redis，做一些实验没什么意义。
要把redis作为一个系统的daemon进程去运行的，每次系统启动，redis进程一起启动，操作不走如下：
RDB和AOF是redis的一种数据持久化的机制。 持久化 是为了避免系统在发生灾难性的系统故障时导致的系统数据丢失。我们一般会将数据存放在本地磁盘，还会定期的将数据上传到云服务器。
RDB 是redis的snapshotting，通过redis.conf中的save配置进行设置，如 save 60 1000:
AOF 是以appendonly方式进行数据的储存的，开启AOF模式后，所有存进redis内存的数据都会进入os cache中,然后默认1秒执行一次fsync写入追加到appendonly.aof文件中。一般我们配置redis.conf中的一下指令：
AOF和RDB模式我们一般在生产环境都会打开，一般而言，redis服务挂掉后进行重启会优先家在aof中的文件。
当启动一个slave node的时候，它会发送一个PSYNC命令给master node,如果这是slave node重新连接master node，那么master node仅仅会复制给slave部分缺少的数据;否则如果是slave node第一次连接master node，那么会触发一次full resynchronization;
开始full resynchronization的时候，master会启动一个后台线程，开始生成一份RDB快照文件，同时还会将从客户端收到的所有写命令缓存在内存中。RDB文件生成完毕之后，master会将这个RDB发送给slave，slave会先写入本地磁盘，然后再从本地磁盘加载到内存中。然后master会将内存中缓存的写命令发送给slave，slave也会同步这些数据。
slave node如果跟master node有网络故障，断开了连接，会自动重连。master如果发现有多个slave node都来重新连接，仅仅会启动一个rdb save操作，用一份数据服务所有slave node。
从redis 2.8开始，就支持主从复制的断点续传，如果主从复制过程中，网络连接断掉了，那么可以接着上次复制的地方，继续复制下去，而不是从头开始复制一份。
master node会在内存中常见一个backlog，master和slave都会保存一个replica offset还有一个master id，offset就是保存在backlog中的。如果master和slave网络连接断掉了，slave会让master从上次的replica offset开始继续复制,但是如果没有找到对应的offset，那么就会执行一次resynchronization。
master在内存中直接创建rdb，然后发送给slave，不会在自己本地落地磁盘了，可以有如下配置：
slave不会过期key，只会等待master过期key。如果master过期了一个key，或者通过LRU淘汰了一个key，那么会模拟一条del命令发送给slave。
在redis.conf配置文件中，上面的参数代表至少需要3个slaves节点与master节点进行连接，并且master和每个slave的数据同步延迟不能超过10秒。一旦上面的设定没有匹配上，则master不在提供相应的服务。
sdown达成的条件很简单，如果一个哨兵ping一个master，超过了 is-master-down-after-milliseconds 指定的毫秒数之后，就主观认为master宕机
sdown到odown转换的条件很简单，如果一个哨兵在指定时间内，收到了 quorum 指定数量的其他哨兵也认为那个master是sdown了，那么就认为是odown了，客观认为master宕机
如果一个slave跟master断开连接已经超过了down-after-milliseconds的10倍，外加master宕机的时长，那么slave就被认为不适合选举为master
(down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state
每次一个哨兵要做主备切换，首先需要quorum数量的哨兵认为odown，然后选举出一个slave来做切换，这个slave还得得到majority哨兵的授权，才能正式执行切换；
（2）SENTINEL RESET *，在所有sentinal上执行，清理所有的master状态
（3）SENTINEL MASTER mastername，在所有sentinal上执行，查看所有sentinal对数量是否达成了一致
4.3.2 slave的永久下线
让master摘除某个已经下线的slave：SENTINEL RESET mastername，在所有的哨兵上面执行.
redis的集群模式为了解决系统的横向扩展以及海量数据的存储问题，如果你的数据量很大，那么就可以用redis cluster。
redis cluster可以支撑N个redis master,一个master上面可以挂载多个slave，一般情况我门挂载一个到两个slave，master在挂掉以后会主动切换到slave上面，或者当一个master上面的slave都挂掉后，集群会从其他master上面找到冗余的slave挂载到这个master上面，达到了系统的高可用性。
2.1 redis cluster的重要配置
2.2 在三台机器上启动6个redis实例
将上面的配置文件，在/etc/redis下放6个，分别为: 7001.conf，7002.conf，7003.conf，7004.conf，7005.conf，7006.conf
每个启动脚本内，都修改对应的端口号
2.3 创建集群
解决办法是 先安装rvm，再把ruby版本提升至2.3.3
使用redis-trib.rb命令创建集群
--replicas: 表示每个master有几个slave
redis-trib.rb check 192.168.31.187:7001 查看状体
3.1 加入新master
以上相同配置完成后，设置启动脚本进行启动；然后用如下命令进行node节点添加：
3.2 reshard一些数据过去
3.3 添加node作为slave
3.4 删除node
㈤ Redis的LRU缓存淘汰算法实现
LRU， 最近最少使用 （Least Recently Used，LRU），经典缓存算法。
LRU会使用一个链表维护缓存中每个数据的访问情况，并根据数据的实时访问，调整数据在链表中的位置，然后通过数据在链表中的位置，表示数据是最近刚访问的，还是已有段时间未访问。
LRU会把链头、尾分别设为MRU端和LRU端：
LRU可分成如下情况：
case2图解：链表长度为5，从链表头部到尾部保存的数据分别是5，33，9，10，8。假设数据9被访问一次，则9就会被移动到链表头部，同时，数据5和33都要向链表尾部移动一位。
所以若严格按LRU实现，假设Redis保存的数据较多，还要在代码中实现：
最终导致降低Redis访问性能。
所以，无论是为节省内存 or 保持Redis高性能，Redis并未严格按LRU基本原理实现，而是 提供了一个近似LRU算法实现 。
Redis的内存淘汰机制是如何启用近似LRU算法的？redis.conf中的如下配置参数：
所以，一旦设定maxmemory选项，且将maxmemory-policy配为allkeys-lru或volatile-lru，近似LRU就被启用。allkeys-lru和volatile-lru都会使用近似LRU淘汰数据，区别在于：
Redis如何实现近似LRU算法的呢？
近似LRU算法仍需区分不同数据的访问时效性，即Redis需知道数据的最近一次访问时间。因此，有了LRU时钟：记录数据每次访问的时间戳。
Redis对每个KV对中的V，会使用个redisObject结构体保存指向V的指针。那redisObject除记录值的指针，还会使用24 bits保存LRU时钟信息，对应的是lru成员变量。这样，每个KV对都会把它最近一次被访问的时间戳，记录在lru变量。
redisObject定义包含lru成员变量的定义：
每个KV对的LRU时钟值是如何计算的？Redis Server使用一个实例级别的全局LRU时钟，每个KV对的LRU time会根据全局LRU时钟进行设置。
这全局LRU时钟保存在Redis全局变量server的成员变量 lruclock
当Redis Server启动后，调用initServerConfig初始化各项参数时，会调用getLRUClock设置lruclock的值：
于是，就得注意， 若一个数据前后两次访问的时间间隔 1s，那这两次访问的时间戳就是一样的！ 因为LRU时钟精度就是1s，它无法区分间隔小于1秒的不同时间戳！
getLRUClock函数将获得的UNIX时间戳，除以LRU_CLOCK_RESOLUTION后，就得到了以LRU时钟精度来计算的UNIX时间戳，也就是当前的LRU时钟值。
getLRUClock会把LRU时钟值和宏定义LRU_CLOCK_MAX（LRU时钟能表示的最大值）做与运算。
所以默认情况下，全局LRU时钟值是以1s为精度计算得UNIX时间戳，且是在initServerConfig中进行的初始化。
那Redis Server运行过程中，全局LRU时钟值是如何更新的？和Redis Server在事件驱动框架中，定期运行的时间事件所对应的serverCron有关。
serverCron作为时间事件的回调函数，本身会周期性执行，其频率值由redis.conf的 hz配置项 决定，默认值10，即serverCron函数会每100ms（1s/10 = 100ms）运行一次。serverCron中，全局LRU时钟值就会按该函数执行频率，定期调用getLRUClock进行更新：
这样，每个KV对就能从全局LRU时钟获取最新访问时间戳。
对于每个KV对，它对应的redisObject.lru在哪些函数进行初始化和更新的呢？
对于一个KV对，其LRU时钟值最初是在这KV对被创建时，进行初始化设置的，这初始化操作在 createObject函数 中调用，当Redis要创建一个KV对，就会调用该函数。
createObject除了会给redisObject分配内存空间，还会根据maxmemory_policy配置，初始化设置redisObject.lru。
LRU_CLOCK返回当前全局LRU时钟值。因为一个KV对一旦被创建，就相当于有了次访问，其对应LRU时钟值就表示了它的访问时间戳：
那一个KV对的LRU时钟值又是何时再被更新？
只要一个KV对被访问，其LRU时钟值就会被更新！而当一个KV对被访问时，访问操作最终都会调用 lookupKey 。
lookupKey会从全局哈希表中查找要访问的KV对。若该KV对存在，则lookupKey会根据maxmemory_policy的配置值，来更新键值对的LRU时钟值，也就是它的访问时间戳。
而当maxmemory_policy没有配置为LFU策略时，lookupKey函数就会调用LRU_CLOCK函数，来获取当前的全局LRU时钟值，并将其赋值给键值对的redisObject结构体中的lru变量
这样，每个KV对一旦被访问，就能获得最新的访问时间戳。但你可能好奇：这些访问时间戳最终是如何被用于近似LRU算法进行数据淘汰的？
Redis之所以实现近似LRU，是为减少内存资源和操作时间上的开销。
近似LRU主要逻辑在performEvictions。
performEvictions被evictionTimeProc调用，而evictionTimeProc函数又是被processCommand调用。
processCommand，Redis处理每个命令时都会调用：
然后，isSafeToPerformEvictions还会再次根据如下条件判断是否继续执行performEvictions：
一旦performEvictions被调用，且maxmemory-policy被设置为allkeys-lru或volatile-lru，近似LRU就被触发执行了。
执行可分成如下步骤：
调用getMaxmemoryState评估当前内存使用情况，判断当前Redis Server使用内存容量是否超过maxmemory配置值。
若未超过maxmemory ，则返回C_OK，performEvictions也会直接返回。
getMaxmemoryState评估当前内存使用情况的时候，若发现已用内存超出maxmemory，会计算需释放的内存量。这个释放内存大小=已使用内存量-maxmemory。
但已使用内存量并不包括用于主从复制的复制缓冲区大小，这是getMaxmemoryState通过调用freeMemoryGetNotCountedMemory计算的。
而若当前Server使用的内存量超出maxmemory上限 ，则performEvictions会执行while循环淘汰数据释放内存。
为淘汰数据，Redis定义数组EvictionPoolLRU，保存待淘汰的候选KV对，元素类型是evictionPoolEntry结构体，保存了待淘汰KV对的空闲时间idle、对应K等信息：
这样，Redis Server在执行initSever进行初始化时，会调用evictionPoolAlloc为EvictionPoolLRU数组分配内存空间，该数组大小由EVPOOL_SIZE决定，默认可保存16个待淘汰的候选KV对。
performEvictions在淘汰数据的循环流程中，就会更新这个待淘汰的候选KV对集合，即EvictionPoolLRU数组。
performEvictions调用evictionPoolPopulate，其会先调用dictGetSomeKeys，从待采样哈希表随机获取一定数量K：
于是，dictGetSomeKeys返回采样的KV对集合。evictionPoolPopulate根据实际采样到的KV对数量count，执行循环：调用estimateObjectIdleTime计算在采样集合中的每一个KV对的空闲时间：
接着，evictionPoolPopulate遍历待淘汰的候选KV对集合，即EvictionPoolLRU数组，尝试把采样的每个KV对插入EvictionPoolLRU数组，取决于如下条件之一：
有一成立，evictionPoolPopulate就能把采样KV对插入EvictionPoolLRU数组。等所有采样键值对都处理完后，evictionPoolPopulate函数就完成对待淘汰候选键值对集合的更新了。
接下来，performEvictions开始选择最终被淘汰的KV对。
因evictionPoolPopulate已更新EvictionPoolLRU数组，且该数组里的K，是按空闲时间从小到大排好序了。所以，performEvictions遍历一次EvictionPoolLRU数组，从数组的最后一个K开始选择，若选到的K非空，就把它作为最终淘汰的K。
该过程执行逻辑：
一旦选到被淘汰的K，performEvictions就会根据Redis server的惰性删除配置，执行同步删除或异步删除：
至此，performEvictions就淘汰了一个K。若此时释放的内存空间还不够，即没有达到待释放空间，则performEvictions还会 重复执行 前面所说的更新待淘汰候选KV对集合、选择最终淘汰K的过程，直到满足待释放空间的大小要求。
performEvictions流程：
近似LRU算法并未使用耗时且耗空间的链表，而使用 固定大小的待淘汰数据集合 ，每次随机选择一些K加入待淘汰数据集合。
最后，按待淘汰集合中K的空闲时间长度，删除空闲时间最长的K。
根据LRU算法的基本原理，发现若严格按基本原理实现LRU算法，则开发的系统就需要额外内存空间保存LRU链表，系统运行时也会受到LRU链表操作的开销影响。
而Redis的内存资源和性能都很重要，所以Redis实现近似LRU算法：
一个算法的基本原理和算法的实际执行，在系统开发中会有一定折中，需综合考虑所开发的系统，在资源和性能方面的要求，以避免严格按照算法实现带来的资源和性能开销。
㈥ Redis分布式缓存搭建
花了两天时间整理了之前记录的Redis单体与哨兵模式的搭建与使用，又补齐了集群模式的使用和搭建经验，并对集群的一些个原理做了理解。
笔者安装中遇到的一些问题：
如果make报错，可能是没装gcc或者gcc++编辑器，安装之 yum -y install gcc gcc-c++ kernel-devel ，有可能还是提示一些个c文件编译不过，gcc -v查看下版本，如果不到5.3那么升级一下gcc：
在 /etc/profile 追加一行 source /opt/rh/devtoolset-9/enable
scl enable devtoolset-9 bash
重新make clean, make
这回编译通过了，提示让你最好make test一下/
执行make test ，如果提示 You need tcl 8.5 or newer in order to run the Redis test
那就升级tcl， yum install tcl
重新make test，如果还有error就删了目录，重新tar包解压重新make , make test
o/ All tests passed without errors! ，表示编译成功。
然后make install即可。
直接运行命令： ./redis-server /usr/redis-6.0.3/redis.conf &
redis.conf 配置文件里 bind 0.0.0.0 设置外部访问， requirepass xxxx 设置密码。
redis高可用方案有两种：
常用搭建方案为1主1从或1主2从+3哨兵监控主节点， 以及3主3从6节点集群。
（1）sentinel哨兵
/usr/redis-6.0.3/src/redis-sentinel /usr/redis-6.0.3/sentinel2.conf &
sentinel2.conf配置：
坑1：master节点也会在故障转移后成为从节点，也需要配置masterauth
当kill master进程之后，经过sentinel选举，slave成为了新的master，再次启动原master，提示如下错误：
原因是此时的master再次启动已经是slave了，需要向现在的新master输入密码，所以需要在master.conf
中配置：
坑2：哨兵配置文件要暴露客户端可以访问到的master地址
在 sentinel.conf 配置文件的 sentinel monitor mymaster 122.xx.xxx.xxx 6379 2 中，配置该哨兵对应的master名字、master地址和端口，以及达到多少个哨兵选举通过认为master挂掉。其中master地址要站在redis访问者（也就是客户端）的角度、配置访问者能访问的地址，例如sentinel与master在一台服务器（122.xx.xxx.xxx）上，那么相对sentinel其master在本机也就是127.0.0.1上，这样 sentinel monitor mymaster 127.0.0.1 6379 2 逻辑上没有问题，但是如果另外服务器上的springboot通过lettuce访问这个redis哨兵，则得到的master地址为127.0.0.1，也就是springboot所在服务器本机，这显然就有问题了。
附springboot2.1 redis哨兵配置：
坑3：要注意配置文件.conf会被哨兵修改
redis-cli -h localhost -p 26379 ，可以登到sentinel上用info命令查看一下哨兵的信息。
曾经遇到过这样一个问题，大致的信息如下
slaves莫名其妙多了一个，master的地址也明明改了真实对外的地址，这里又变成127.0.0.1 !
最后，把5个redis进程都停掉，逐个检查配置文件，发现redis的配置文件在主从哨兵模式会被修改，master的配置文件最后边莫名其妙多了一行replicaof 127.0.0.1 7001， 怀疑应该是之前配置错误的时候（见坑2）被哨兵动态加上去的！ 总之，实践中一定要多注意配置文件的变化。
（2）集群
当数据量大到一定程度，比如几十上百G，哨兵模式不够用了需要做水平拆分，早些年是使用codis，twemproxy这些第三方中间件来做分片的，即 客户端 -> 中间件 -> Redis server 这样的模式，中间件使用一致性Hash算法来确定key在哪个分片上。后来Redis官方提供了方案，大家就都采用官方的Redis Cluster方案了。
Redis Cluster从逻辑上分16384个hash slot，分片算法是 CRC16(key) mod 16384 得到key应该对应哪个slot，据此判断这个slot属于哪个节点。
每个节点可以设置1或多个从节点，常用的是3主节点3从节点的方案。
reshard，重新分片，可以指定从哪几个节点移动一些hash槽到另一个节点去。重新分片的过程对客户端透明，不影响线上业务。
搭建Redis cluster
redis.conf文件关键的几个配置：
启动6个集群节点
[root@VM_0_11_centos redis-6.0.3]# ps -ef|grep redis
root 5508 1 0 21:25 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7001 [cluster]
root 6903 1 0 21:32 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7002 [cluster]
root 6939 1 0 21:33 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7003 [cluster]
root 6966 1 0 21:33 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7004 [cluster]
root 6993 1 0 21:33 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7005 [cluster]
root 7015 1 0 21:33 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7006 [cluster]
这时候这6个节点还是独立的，要把他们配置成集群：
说明： -a xxxx 是因为笔者在redis.conf中配置了requirepass xxxx密码，然后 --cluster-replicas 1 中的1表示每个master节点有1个从节点。
上述命令执行完以后会有一个询问： Can I set the above configuration? yes同意自动做好的分片即可。
最后 All 16384 slots covered. 表示集群中16384个slot中的每一个都有至少有1个master节点在处理，集群启动成功。
查看集群状态：
坑1：暴露给客户端的节点地址不对
使用lettuce连接发现连不上，查看日志 Connection refused: no further information: /127.0.0.1:7002 ，跟之前哨兵配置文件sentinel.conf里边配置master地址犯的错误一样，集群启动的时候带的地址应该是提供给客户端访问的地址。
我们要重建集群：先把6个redis进程停掉，然后删除 nodes-7001.conf 这些节点配置文件，删除持久化文件 mp.rdb 、 appendonly.aof ，重新启动6个进程，在重新建立集群：
然后，还是连不上，这次报错 connection timed out: /172.xx.0.xx:7004 ，发现连到企鹅云服务器的内网地址上了！
解决办法，修改每个节点的redis.conf配置文件，找到如下说明：
所以增加配置：
然后再重新构建集群，停进程、改配置、删除节点文件和持久化文件、启动进程、配置集群。。。再来一套（累死了）
重新使用Lettuce测试，这次终于连上了！
坑2：Lettuce客户端在master节点故障时没有自动切换到从节点
name这个key在7002上，kill这个进程模拟master下线，然后Lettuce一直重连。我们期望的是应该能自动切换到其slave 7006上去，如下图：
重新启动7002进程，
7006已成为新master，7002成为它的slave，然后Lettuce也能连接上了。
解决办法，修改Lettuce的配置：
笔者用的是springboot 2.1 spring-boot-starter-data-redis 默认的Lettuce客户端，当使用Redis cluster集群模式时，需要配置一下 RedisConnectionFactory 开启自适应刷新来做故障转移时的自动切换从节点进行连接。
重新测试：停掉master 7006，这次Lettuce可以正常切换连到7002slave上去了。（仍然会不断的在日志里报连接错误，因为需要一直尝试重连7006，但因为有7002从节点顶上了、所以应用是可以正常使用的）
Redis不保证数据的强一致性
Redis并不保证数据的强一致性，也就是取CAP定理中的AP
关于一致性Hash算法，可以参考 一致性Hash算法 - (jianshu.com)
Redis cluster使用的是hash slot算法，跟一致性Hash算法不太一样，固定16384个hash槽，然后计算key落在哪个slot里边（计算key的CRC16值再对16384取模），key找的是slot而不是节点，而slot与节点的对应关系可以通过reshard改变并通过gossip协议扩散到集群中的每一个节点、进而可以为客户端获知，这样key的节点寻址就跟具体的节点个数没关系了。也同样解决了普通hash取模算法当节点个数发生变化时，大量key对应的寻址都发生改动导致缓存失效的问题。
比如集群增加了1个节点，这时候如果不做任何操作，那么新增加的这个节点上是没有slot的，所有slot都在原来的节点上且对应关系不变、所以没有因为节点个数变动而缓存失效，当reshard一部分slot到新节点后，客户端获取到新迁移的这部分slot与新节点的对应关系、寻址到新节点，而没迁移的slot仍然寻址到原来的节点。
关于热迁移，猜想，内部应该是先做复制迁移，等迁移完了，再切换slot与节点的对应关系，复制没有完成之前仍按照原来的slot与节点对应关系去原节点访问。复制结束之后，再删除原节点上已经迁移的slot所对应的key。
与哨兵模式比较类似，当1个节点发现某个master节点故障了、会对这个故障节点进行pfail主观宕机，然后会通过gossip协议通知到集群中的其他节点、其他节点也执行判断pfail并gossip扩散广播这一过程，当超过半数节点pfail时那么故障节点就是fail客观宕机。接下来所有的master节点会在故障节点的从节点中选出一个新的主节点，此时所有的master节点中超过半数的都投票选举了故障节点的某个从节点，那么这个从节点当选新的master节点。
所有节点都持有元数据，节点之间通过gossip这种二进制协议进行通信、发送自己的元数据信息给其他节点、故障检测、集群配置更新、故障转移授权等等。
这种去中心化的分布式节点之间内部协调，包括故障识别、故障转移、选主等等，核心在于gossip扩散协议，能够支撑这样的广播协议在于所有的节点都持有一份完整的集群元数据，即所有的节点都知悉当前集群全局的情况。
Redis高可用方案 - (jianshu.com)
面试题:Redis 集群模式的工作原理能说一下么 - 云+社区 - 腾讯云 (tencent.com)
深度图解Redis Cluster原理 - detectiveHLH - 博客园 (cnblogs.com)
Redis学习笔记之集群重启和遇到的坑-阿里云开发者社区 (aliyun.com)
云服务器Redis集群部署及客户端通过公网IP连接问题
㈦ 如何使用 Azure Redis 缓存
1.功能 Redis 是一种高级的键值存储，其中，键可以包含数据结构，例如字符串、哈希、列表、集合和有序集合。Redis 支持针对这些数据类型的一组原子操作。 Redis 还支持设置简单的主-从复制，具有非常快的非首先阻止同步、网络分割时自动重新连接等。 其他功能包括事务、发布/订阅、Lua 脚本、具有有限生存时间的键和配置设置，使 Redis 在行为上与缓存类似。 您可以通过当今最常用编程语言使用 Redis。 Azure Redis 缓存利用 Redis 身份验证并且还支持与 Redis 的 SSL 连接。 2.可复用黄色别墅 相比笔者之前写的文档： Windows Azure Cloud Service (44) 使用Azure In-Role Cache缓存(1)Co-located Role Windows Azure Cloud Service (45) 使用Azure In-Role Cache缓存(2)Dedicated Role 以上的In-Role Cache只会被部署的Cloud Service独享的，如果新创建的其他Cloud Service Project想共享是无法实现的。 我们通过创建Azure Redis Cache以后，这个Redis Cache就是共享的，一个或者多个Azure Application就可以同时使用这个Azure Redis Cache 3.服务级别 Microsoft Azure Redis Cache分为两个级别： (1)基本(Basic) - 单个节点。提供不同的大小。基本模式是没有SLA的。 (2)标准(Standard) - 双节点，主从模式。包括SLA和支持复制。提供多种大小。326电影网 (3)高级(Premium) - 企业级缓存服务。专为大规模并发设计。 Azure Redis Cache提供以下不同的服务级别： 基本(Basic，不包含SLA)： 缓存名称 缓存大小 网络性能 客户端连接数 C0 250MB 低 256 C1 1GB 低 1000 C2 2.5GB 中等 2000 C3 6GB 中等性喜剧 5000 C4 13GB 中等 10000 C5 26GB 高 15000 C6 53GB 最高 20000 标准(Standard，支持SLA)： 缓存名称 缓存大小 网络性能 客户端连接数 C0 250MB 低 256 C1 1GB 低 1000 C2 2.5GB 中等 2000 C3 6GB 中等 5000 C4 13GB 中等 10000 C5 26GB 高 15000 C6 53GB 最高 20000 高级(Premium)： 缓存名称 缓存大小 网络性能 客户端连接数量 P1 6GB 中等 7500 P2 13GB 中等 15000 P3 26GB 高 30000 P4 53GB 最高 40000 326影视 4.高性能 Azure Redis 缓存帮助您的应用程序变得更具响应性（甚至在用户负载增加时也如此），以及利用 Redis 引擎的低延迟、高吞吐量功能。此单独的分布式缓存层允许数据层独立扩展以便更高效地利用应用程序层中的计算资源。
㈧ redis常见问题
1. 缓存击穿
缓存击穿是指一个请求要访问的数据，缓存中没有，但数据库中有的情况。这种情况一般都是缓存过期了。
但是这时由于并发访问这个缓存的用户特别多，这是一个热点 key，这么多用户的请求同时过来，在缓存里面没有取到数据，所以又同时去访问数据库取数据，引起数据库流量激增，压力瞬间增大，直接崩溃给你看。
所以一个数据有缓存，每次请求都从缓存中快速的返回了数据，但是某个时间点缓存失效了，某个请求在缓存中没有请求到数据，这时候我们就说这个请求就"击穿"了缓存。
针对这个场景，对应的解决方案一般来说有三种。
借助Redis setNX命令设置一个标志位就行。设置成功的放行，设置失败的就轮询等待。就是在更新缓存时加把锁
后台开一个定时任务，专门主动更新过期数据
比如程序中设置 why 这个热点 key 的时候，同时设置了过期时间为 10 分钟，那后台程序在第 8 分钟的时候，会去数据库查询数据并重新放到缓存中，同时再次设置缓存为 10 分钟。
其实上面的后台续命思想的最终体现是也是永不过期。
只是后台续命的思想，会主动更新缓存，适用于缓存会变的场景。会出现缓存不一致的情况，取决于你的业务场景能接受多长时间的缓存不一致。
2. 缓存穿透
缓存穿透是指一个请求要访问的数据，缓存和数据库中都没有，而用户短时间、高密度的发起这样的请求，每次都打到数据库服务上，给数据库造成了压力。一般来说这样的请求属于恶意请求。
解决方案有两种：
就是在数据库即使没有查询到数据，我们也把这次请求当做 key 缓存起来，value 可以是 NULL。下次同样请求就会命中这个 NULL，缓存层就处理了这个请求，不会对数据库产生压力。这样实现起来简单，开发成本很低。
3. 缓存雪崩
缓存雪崩是指缓存中大多数的数据在同一时间到达过期时间，而查询数据量巨大，这时候，又是缓存中没有，数据库中有的情况了。
防止雪崩的方案简单来说就是错峰过期。
在设置 key 过期时间的时候，在加上一个短的随机过期时间，这样就能避免大量缓存在同一时间过期，引起的缓存雪崩。
如果发了雪崩，我们可以有服务降级、熔断、限流手段来拒绝一些请求，保证服务的正常。但是，这些对用户体验是有一定影响的。
4. Redis 高可用架构
Redis 高可用架构，大家基本上都能想到主从、哨兵、集群这三种模式。
哨兵模式：
它主要执行三种类型的任务：
哨兵其实也是一个分布式系统，我们可以运行多个哨兵。
然后这些哨兵之间需要相互通气，交流信息，通过投票来决定是否执行自动故障迁移，以及选择哪个从服务器作为新的主服务器。
哨兵之间采用的协议是 gossip，是一种去中心化的协议，达成的是最终一致性。
选举规则：
㈨ redis做缓存，怎么取出全部key
redis做缓存的时候，怎么取出全部相同前缀的key，网络到很多都是keys,scan
获取当前库下的所有key
可以使用 keys * 命令，keys支持模糊匹配，但是cpu使用率有点高。还有一种就是scan命令
设置一个set，在缓存的时候把数据的key存到这个set里面
㈩ php 分页查询怎么redis缓存
对于有分页条件的缓存，我们也可以按照不同的分页条件来缓存多个key，比如分页查询产品列表,page=1&limit=10和page=1&limit=5这两次请求可以这样缓存查询结果
proctList:page:1:limit:10
proctList:page:1:limit:5
这个是一种常见方案，但是存在着一些问题：
缓存的value存在冗余，proctList:page:1:limit:10缓存的内容其实是包括了proctList:page:1:limit:5中的内容（缓存两个key的时候，数据未发生变化的情况下）
仅仅是改变了查询条件的分页条件，就会导致缓存未命中，降低了缓存的命中率
为了保证数据一致性，需要清理缓存的时候，很难处理，redis的keys命令对性能影响很大，会导致redis很大的延迟，生产环境一般来说禁止该命令。自己手动拼缓存key，你可能根本不知道拼到哪一个page为止。
放弃数据一致性，通过设置失效时间来自动失效，可能会出现查询第一页命中了缓存，查询第二页的时候未命中缓存，但此时数据已经发生了改变，导致第二页查询返回的和第一页相同的结果。
以上，在分页条件下这样使用常规方案总感觉有诸多困扰，诸多麻烦，那是不是就应该放弃使用缓存？
基于SortedSet的分页查询缓存方案
首先想到的解决方法是使用@see ListOperations<K, V>不再根据分页条件使用多个key，而是使用一个key，也不分页将全部的数据缓存到redis中，然后按照分页条件使用range(key,start,limit)获取分页的结果，这个会导致一个问题，当缓存失效时，并发的写缓存会导致出现重复数据
所以想到通过使用set来处理并发时的重复数据，@see ZSetOperations<K, V>
代码逻辑如下：
range(key,start,limit)按照分页条件获取缓存，命中则直接返回
缓存未命中，查询（没有分页条件）数据库或是调用（没有分页）底层接口
add(key,valueScoreMap<value,score>)写入缓存，expire设置缓存时间
当需要清理缓存时，直接删除key，如果是因为数据新增和删除，可以add(key,value,score)或remove(key,value)
redis中会按照score分值升序排列map中的数据，一般的，score分值是sql语句的order by filedA的filedA的值，这样能保证数据一致性
但是这种方式也存在一定问题：
这个key缓存的value确实是热数据，但可能只有少数数据被频繁使用其余的可能根本就未被使用，比如数据有100页，实际可能只会用到前10页，这也会导致缓存空间的浪费，如果使用了redis虚拟内存，也会有一定影响
sql查询由原来的分页查询变成了不分页查询，缓存失效后，系统的处理能力较之前会有下降，尤其是对于大表.