Redis基础二

1.Redis持久化

持久化是把内存数据写到磁盘中，防止服务宕机内存数据丢失。

Redis 提供两种持久化方式：RDB（默认） 和AOF 。

RDB

RDB（Redis DataBase）是Redis默认的持久化方式。按照一定时间将内存数据以快照形式保存到硬盘中，产生的数据文件为dump.rdb。通过配置文件中的save参数来定义快照周期。

功能核心函数rdbSave(生成RDB文件)和rdbLoad（从文件加载内存）两个函数

AOF

AOF持久化(Append Only File)是将Redis执行的每次写命令记录到单独日志文件中，当重启Redis，从持久化的日志文件中重新恢复数据。当两种方式同时开启时，Redis会优先选择AOF恢复数据。

flushAppendOnlyFile 函数执行以下两个工作：

WRITE：根据条件，将 aof_buf 中的缓存写入到 AOF 文件

SAVE：根据条件，调用 fsync 或 fdatasync 函数，将 AOF 文件保存到磁盘中。

比较

• RDB 只有一个文件 dump.rdb，方便持久化，容灾性好
• RDB性能最大化，fork 子进程来完成写操作，让主进程继续处理命令， IO 最大化
• 数据集大时，RDB比 AOF 启动效率更高，恢复速度快
• 数据不安全，RDB 隔一段时间进行持久化，如果持久化之间 redis 发生故障，会发生数据丢失
• RDB在生成数据快照时，如果文件很大，客户端可能会暂停几毫秒甚至几秒

• AOF文件比RDB更新频率高，优先使用AOF还原数据
• 数据安全，aof 持久化可以配置 appendfsync 属性，有 always，每进行一次命令操作就记录到 aof 文件中一次
• 适合做灾难性数据误删除的紧急恢复，比如过flushall清空了所有的数据，只要这个时候后台重写还没发生，你马上拷贝一份AOF日志文件，把最后一条flushall命令删了
• 通过 append-only 模式写文件，写入性能好，即使中途服务器宕机，可通过 redis-check-aof 工具解决数据一致性问题
• 支持AOF的重写，重写的目的是减少硬盘的占用量，加快恢复的速度。
  • 1.无论是执行bgrewriteaof命令还是自动进行AOF重写，实际上都是执行BGREWRITEAOF命令
  • 2.执行bgrewriteaof命令,Redis会fork一个子进程
  • 3.子进程对内存中的Redis数据进行回溯，生成新的AOF文件
  • 4.Redis主进程会处理正常的命令操作
  • 5.同时Redis把会新的命令写入到aof_rewrite_buf当中，当bgrewriteaof命令执行完成，新的AOF文件生成完毕，Redis主进程会把aof_rewrite_buf中的命令追加到新的AOF文件中 6.用新生成的AOF文件替换旧的AOF文件
• AOF 文件比 RDB 文件大，且恢复速度慢；数据集大时，比 rdb 启动效率低

如何选择持久化方式

• 推荐使用两种持久化功能， Redis 重启时会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集完整
• 非常关心数据， 但仍然可承受数分钟以内的数据丢失，那么可以只使用RDB持久化
• 不推荐只使用AOF持久化，定时生成RDB快照非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比AOF快，除此之外，使用RDB还可以避免AOF程序的bug

扩容与持久化

• 使用一致性哈希实现动态扩容缩容
• 持久化存储：固定的keys-to-nodes映射关系、Redis集群

2.架构

单机

单机的redis能够承载的 QPS 大概就在上万到几万不等，内存容量有限、处理能力有限、无法高可用。

主从

概述

一主多从：主负责写，并且将数据复制到其它的 slave 节点，从节点负责读。这样也可以很轻松实现水平扩容，支撑读高并发。

• redis 采用异步方式复制数据到 slave 节点，不过 redis2.8 开始，slave node 会周期性地确认自己每次复制的数据量；
• 一个 master node 是可以配置多个 slave node 的；
• slave node 也可以连接其他的 slave node；
• slave node 做复制的时候，不会 block master node 的正常工作；
• slave node 在做复制的时候，也不会 block 对自己的查询操作，它会用旧的数据集来提供服务；但是复制完成的时候，需要删除旧数据集，加载新数据集，这个时候就会暂停对外服务了；
• slave node 主要用来进行横向扩容，做读写分离，扩容的 slave node 可以提高读的吞吐量。

注意，如果采用了主从架构，那么建议必须开启 master node 的持久化，不建议用 slave node 作为 master node 的数据热备，因为那样的话，如果你关掉 master 的持久化，可能在 master 宕机重启的时候数据是空的，然后可能一经过复制， slave node 的数据也丢了。

另外，master 的各种备份方案，也需要做。万一本地的所有文件丢失了，从备份中挑选一份 rdb 去恢复 master，这样才能确保启动的时候，是有数据的，即使采用了后续讲解的高可用机制，slave node 可以自动接管 master node，但也可能 sentinel 还没检测到 master failure，master node 就自动重启了，还是可能导致上面所有的 slave node 数据被清空。

原理

当启动一个 slave node 的时候，它会发送一个 PSYNC 命令给 master node。如果slave node 初次连接到 master node，那么会触发一次 full resynchronization 全量复制。此时 master 会启动一个后台线程，开始生成一份 RDB 快照文件，同时还会将从客户端 client 新收到的所有写命令缓存在内存中。RDB 文件生成完毕后， master 会将这个 RDB 发送给 slave，slave 会先写入本地磁盘，然后再从本地磁盘加载到内存中，接着 master 会将内存中缓存的写命令发送到 slave，slave 也会同步这些数据。

slave node 如果跟 master node 有网络故障，断开了连接，会自动重连，连接之后 master node 仅会复制给 slave 部分缺少的数据。

实践配置

wget http://download.redis.io/redis-stable/redis.conf
#主redis.conf进行如下修改：
#bind 127.0.0.1
port 6380
pidfile /var/run/redis_6380.pid
protected-mode no
daemonize no
#启动服务
docker run -p 6380:6380 --name redis01 -v /home/docker/redis/redis.conf:/usr/local/redis.conf -v /home/docker/redis/data:/data -d redis redis-server /usr/local/redis.conf
#从服务器1redis.conf进行如下修改：
#bind 127.0.0.1
port 6381
pidfile /var/run/redis_6381.pid
protected-mode no
daemonize no
replicaof 171.17.0.2 6380
#启动服务
docker run -p 6381:6381 --name redis02 -v /home/docker/redis/redis.conf:/usr/local/redis.conf -v /home/docker/redis/data:/data -d redis redis-server /usr/local/redis.conf
#从服务器2redis.conf进行如下修改：
#bind 127.0.0.1
port 6382
pidfile /var/run/redis_6382.pid
protected-mode no
daemonize no
replicaof 171.17.0.2 6380
#启动服务
docker run -p 6382:6382 --name redis03 -v /home/docker/redis/redis.conf:/usr/local/redis.conf -v /home/docker/redis/data:/data -d redis redis-server /usr/local/redis.conf

docker ps #查看服务
docker exec -it redis01 bash #进入容器
redis-cli -p 6380 #连接客户端
info replication #查看主从配置信息

redis01:0>set name ymn
>get name
"ymn"
redis02:0>get name
"ymn"
redis03:0>get name
"ymn"
redis03:0>set name lymn
"READONLY You can't write against a read only replica."

在redis5.x的主从配置中，从机配置要配置 replicaof 参数。而早期版本，要配置的是slaveof参数。

哨兵

概述

哨兵（sentinel）是 redis 集群机构中非常重要的一个组件，主要有以下功能：

• 集群监控：负责监控 redis master 和 slave 进程是否正常工作。
• 消息通知：如果某个 redis 实例有故障，那么哨兵负责发送消息作为报警通知给管理员。
• 故障转移：如果 master node 挂掉了，会自动转移到 slave node 上。
• 配置中心：如果故障转移发生了，通知 client 客户端新的 master 地址。

哨兵用于实现 redis 集群的高可用，本身也是分布式的，作为一个哨兵集群去运行，互相协同工作。哨兵至少需要 3 个实例，之间通过 Raft 协议来保证自身的高可用。。哨兵 + redis 主从的部署架构，是不保证数据零丢失的，只能保证 redis 集群的高可用性。

当主挂掉时，在从节点中根据一定策略选出新主，并调整其他从 slaveof 到新主。

选主的策略简单来说有三个：

• slave 的 priority 设置的越低，优先级越高；
• 同等情况下，slave 复制的数据越多优先级越高；
• 相同的条件下 runid 越小越容易被选中。

实践配置

在前面一主二从的基础上配置sentinel

#配置sentinel
wget http://download.redis.io/redis-stable/sentinel.conf
#sentinel.conf进行如下修改,复制两份，分别修改为端口26380 26381
port 26379
pidfile /var/run/26379.pid
sentinel monitor mymaster 171.17.0.2 6380
#启动服务
docker run -p 26379:26379 --name sentinel01 -v /home/docker/redis/data:/data -v /home/docker/redis/sentinel.conf:/usr/local/sentinel.conf -d redis  redis-sentinel /usr/local/sentinel.conf
docker run -p 26380:26380 --name sentinel02 -v /home/docker/redis/data:/data -v /home/docker/redis/sentinel2.conf:/usr/local/sentinel.conf -d redis  redis-sentinel /usr/local/sentinel.conf
docker run -p 26381:26381 --name sentinel03 -v /home/docker/redis/data:/data -v /home/docker/redis/sentinel3.conf:/usr/local/sentinel.conf -d redis  redis-sentinel /usr/local/sentinel.conf
#容器
docker exec -it sentinel01 bash
redis-cli -p 26379
sentinel master mymaster #查看监控状况
sentinel slaves mymaster

docker exec -it redis01  bash
redis-cli  -p 6380 debug sleep 60 #进入redis-master容器，休眠60秒redis服务
#或者停掉容器设置
docker stop redis01
#主节点变成从节点
redis01:0>info replication   
"# Replication
role:slave
master_host:172.17.0.3
master_port:6381
#主节点
redis02:0>info replication  
"# Replication
role:master
connected_slaves:1
slave0:ip=172.17.0.4,port=6382,state=online,offset=24705,lag=1
slave1:ip=172.17.0.2,port=6380,state=online,offset=68911,lag=0

redis03:0>info replication
"# Replication
role:slave
master_host:172.17.0.3
master_port:6381
#日志信息
+switch-master mymaster 172.17.0.2 6380 172.17.0.3 6381
+slave slave 172.17.0.4:6382 172.17.0.4 6382 @ mymaster 172.17.0.3 6381
+slave slave 172.17.0.2:6380 172.17.0.2 6380 @ mymaster 172.17.0.3 6381

基于客户端分配

Redis Sharding是Redis Cluster出来之前，业界普遍使用的多Redis实例集群方法。其主要思想是采用哈希算法将Redis数据的key进行散列，通过hash函数，特定的key会映射到特定的Redis节点上。Java redis客户端驱动jedis，支持Redis Sharding功能，即ShardedJedis以及结合缓存池的ShardedJedisPool

优点

• 优势在于非常简单，服务端的Redis实例彼此独立，相互无关联，每个Redis实例像单服务器一样运行，非常容易线性扩展，系统的灵活性很强

缺点

• 由于sharding处理放到客户端，规模进一步扩大时给运维带来挑战。
• 客户端sharding不支持动态增删节点。服务端Redis实例群拓扑结构有变化时，每个客户端都需要更新调整。连接不能共享，当应用规模增大时，资源浪费制约优化

基于代理服务器分片

客户端发送请求到一个代理组件，代理解析客户端的数据，并将请求转发至正确的节点，最后将结果回复给客户端

特征

• 透明接入，业务程序不用关心后端Redis实例，切换成本低
• Proxy 的逻辑和存储的逻辑是隔离的
• 代理层多了一次转发，性能有所损耗

业界开源方案

• Twtter开源的Twemproxy
• 豌豆荚开源的Codis

Cluster

概述

Redis Cluster是一种服务端Sharding技术，着眼于提高并发量，3.0版本开始正式提供。将请求发送到任意节点，接收到请求的节点会将查询请求发送到正确的节点上执行。

Redis Cluster并没有使用一致性hash，而是采用slot(槽)的概念，一共分成16384个槽，分布在所有 master 节点上，每个 master 节点负责一部分 slot。数据操作时按 key 做 CRC16 来计算在哪个 slot，由哪个 master 进行处理。数据的冗余是通过 slave 节点来保障。

集群元数据的维护有两种方式：集中式、Gossip 协议。redis cluster 节点间采用 gossip 协议进行通信。

在cluster架构下，默认一般redis-master用于接收读写，而redis-slave则用于备份，当有请求是在向slave发起时，会直接重定向到对应key所在的master来处理。 但如果不介意读取的是redis-cluster中有可能过期的数据并且对写请求不感兴趣时，则亦可通过readonly命令，将slave设置成可读，然后通过slave获取相关的key，达到读写分离。

优缺点

优点

• 无中心架构，支持动态扩容，对业务透明
• 具备Sentinel的监控和自动Failover(故障转移)能力
• 客户端不需要连接集群所有节点，连接集群中任何一个可用节点即可
• 高性能，客户端直连redis服务，免去了proxy代理的损耗

缺点

• 运维也很复杂，数据迁移需要人工干预
• 只能使用0号数据库
• 不支持批量操作(pipeline管道操作)
• 分布式逻辑和存储模块耦合

实践配置

docker pull centos #拉取centos
docker run -itd --name centos centos
docker exec -it centos bash

cd /home
mkdir redis cluster
#添加redis-cluster-config.sh内容如下
vi redis-cluster-config.sh
for port in `seq 7001 7006`; do \
  mkdir -p ./cluster/${port}/conf \
  && PORT=${port} envsubst < ./redis-cluster.tmpl > ./cluster/${port}/conf/redis.conf \
  && mkdir -p ./cluster/${port}/data; \
done

#添加redis-cluster.tmpl内容如下
vi redis-cluster.tmpl
# redis端口
port ${PORT}
# 关闭保护模式
protected-mode no
# 开启集群
cluster-enabled yes
# 集群节点配置
cluster-config-file nodes.conf
# 超时
cluster-node-timeout 5000
# 集群节点IP host模式为宿主机IP
cluster-announce-ip 192.168.99.101
# 集群节点端口 7001 - 7006
cluster-announce-port ${PORT}
cluster-announce-bus-port 1${PORT}
# 开启 appendonly 备份模式
appendonly yes
# 每秒钟备份
appendfsync everysec
# 对aof文件进行压缩时，是否执行同步操作
no-appendfsync-on-rewrite no
# 当目前aof文件大小超过上一次重写时的aof文件大小的100%时会再次进行重写
auto-aof-rewrite-percentage 100
# 重写前AOF文件的大小最小值 默认 64mb
auto-aof-rewrite-min-size 64mb

#启动脚本创建conf data
sh redis-cluster-config.sh #报错envsubst: not found，按照下述进行

#退出容器，复制实例到docker
docker cp 6ba4b120f010:/home/cluster ./

#在centos容器内安裝envsubst
yum provides envsubst
yum install gettext
envsubst --version

#安裝docker-compose
sudo curl -L https://github.com/docker/compose/releases/download/1.21.2/docker-compose-$(uname -s)-$(uname -m) -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose
docker-compose -v

#添加docker-compose-redis-cluster.yml内容如下
vi docker-compose-redis-cluster.yml
version: '3.3'

services:
  redis7001:
    image: 'redis'
    container_name: redis7001
    command:
      ["redis-server", "/usr/local/etc/redis/redis.conf"]
    volumes:
      - ./cluster/7001/conf/redis.conf:/usr/local/etc/redis/redis.conf
      - ./cluster/7001/data:/data
    ports:
      - "7001:7001"
      - "17001:17001"
    environment:
      # 设置时区为上海，否则时间会有问题
      - TZ=Asia/Shanghai


  redis7002:
    image: 'redis'
    container_name: redis7002
    command:
      ["redis-server", "/usr/local/etc/redis/redis.conf"]
    volumes:
      - ./cluster/7002/conf/redis.conf:/usr/local/etc/redis/redis.conf
      - ./cluster/7002/data:/data
    ports:
      - "7002:7002"
      - "17002:17002"
    environment:
      # 设置时区为上海，否则时间会有问题
      - TZ=Asia/Shanghai


  redis7003:
    image: 'redis'
    container_name: redis7003
    command:
      ["redis-server", "/usr/local/etc/redis/redis.conf"]
    volumes:
      - ./cluster/7003/conf/redis.conf:/usr/local/etc/redis/redis.conf
      - ./cluster/7003/data:/data
    ports:
      - "7003:7003"
      - "17003:17003"
    environment:
      # 设置时区为上海，否则时间会有问题
      - TZ=Asia/Shanghai


  redis7004:
    image: 'redis'
    container_name: redis7004
    command:
      ["redis-server", "/usr/local/etc/redis/redis.conf"]
    volumes:
      - ./cluster/7004/conf/redis.conf:/usr/local/etc/redis/redis.conf
      - ./cluster/7004/data:/data
    ports:
      - "7004:7004"
      - "17004:17004"
    environment:
      # 设置时区为上海，否则时间会有问题
      - TZ=Asia/Shanghai


  redis7005:
    image: 'redis'
    container_name: redis7005
    command:
      ["redis-server", "/usr/local/etc/redis/redis.conf"]
    volumes:
      - ./cluster/7005/conf/redis.conf:/usr/local/etc/redis/redis.conf
      - ./cluster/7005/data:/data
    ports:
      - "7005:7005"
      - "17005:17005"
    environment:
      # 设置时区为上海，否则时间会有问题
      - TZ=Asia/Shanghai


  redis7006:
    image: 'redis'
    container_name: redis7006
    command:
      ["redis-server", "/usr/local/etc/redis/redis.conf"]
    volumes:
      - ./cluster/7006/conf/redis.conf:/usr/local/etc/redis/redis.conf
      - ./cluster/7006/data:/data
    ports:
      - "7006:7006"
      - "17006:17006"
    environment:
      # 设置时区为上海，否则时间会有问题
      - TZ=Asia/Shanghai

#启动节点
docker-compose -f docker-compose-redis-cluster.yml up -d

docker exec -it redis7001
#集群配置
redis-cli -p 7001  --cluster create 192.168.99.101:7001 192.168.99.101:7002 192.168.99.101:7003 192.168.99.101:7004 192.168.99.101:7005 192.168.99.101:7006 --cluster-replicas 1

#集群测试
redis-cli -h 192.168.99.101 -p 7005 ping
redis-cli -h 192.168.99.101 -p 7005#redis7001主节点客户端操作redis7005主节点
192.168.99.101:7005> cluster nodes #查看集群节点
192.168.99.101:7005> cluster slots #查看slots分片情况
192.168.99.101:7005> cluster info #查看集群信息
192.168.99.101:7005> set name lymn
(error) MOVED 5798 192.168.99.101:7002 #由于Redis Cluster会根据key进行hash运算，然后将key分散到不同slots，name的hash运算结果在redis7002节点上的slots中。所以我们操作redis7003写操作会自动路由到7002。
redis-cli -h 192.168.99.101 -p 7005 -c 
192.168.99.101:7005> set name lymn
-> Redirected to slot [5798] located at 192.168.99.101:7002
OK
192.168.99.101:7002> get name
"lymn"
#读写分离 要在slave读取数据，那么需要带先执行 readonly 指令，然后 get key
redis-cli -h 192.168.99.101 -p 7005
192.168.99.101:7005> readonly
OK
192.168.99.101:7005> get name
(error) MOVED 5798 192.168.99.101:7002
#name的key分配在7002主节点，只有7006节点能读
redis-cli -h 192.168.99.101 -p 7006
192.168.99.101:7006> readonly
OK
192.168.99.101:7006> get name
"lymn"

#从节点redis7005接替7001成为主节点
docker stop redis7001
docker start redis7001

代码实践

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>2.0.9.RELEASE</version>
    <relativePath/>
</parent>
<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-data-redis</artifactId>
    </dependency>

    <dependency>
        <groupId>org.apache.commons</groupId>
        <artifactId>commons-pool2</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-test</artifactId>
    </dependency>
</dependencies>

spring:
  redis:
    timeout: 6000
    cluster:
      max-redirects: 3 # 获取失败 最大重定向次数
      nodes:
       - 192.168.99.101:7001
       - 192.168.99.101:7002
       - 192.168.99.101:7003
       - 192.168.99.101:7004
       - 192.168.99.101:7005
       - 192.168.99.101:7006
    lettuce:
      pool:
        max-active: 1000 #连接池最大连接数（使用负值表示没有限制）
        max-idle: 10 # 连接池中的最大空闲连接
        min-idle: 5 # 连接池中的最小空闲连接
        max-wait: -1 # 连接池最大阻塞等待时间（使用负值表示没有限制）

@Configuration
public class RedisConfig {

    @Bean
    public RedisTemplate<String,Object> redisTemplate(LettuceConnectionFactory lettuceConnectionFactory){
        RedisTemplate<String,Object> redisTemplate = new RedisTemplate<>();
        redisTemplate.setKeySerializer(new StringRedisSerializer());
        redisTemplate.setValueSerializer(new GenericJackson2JsonRedisSerializer());
        redisTemplate.setConnectionFactory(lettuceConnectionFactory);
        return redisTemplate;
    }
}

@SpringBootApplication
public class DemoApplication {
    public static void main(String[] args) {
        SpringApplication.run(DemoApplication.class,args);
    }
}

@RunWith(SpringRunner.class)
@SpringBootTest
public class RedisTest {
    @Autowired
    RedisTemplate<String,String> redisTemplate;
    @Test
    public void test(){
        redisTemplate.opsForValue().set("name","lymn");
        System.out.println(redisTemplate.opsForValue().get("name"));
    }
}

3.分区

为什么要做Redis分区？

分区可以让Redis管理更大的内存，Redis将可以使用所有机器的内存。如果没有分区，你最多只能使用一台机器的内存。分区使Redis的计算能力通过简单地增加计算机得到成倍提升，Redis的网络带宽也会随着计算机和网卡的增加而成倍增长。

Redis分区有什么缺点？

• 涉及多个key的操作通常不会被支持。例如你不能对两个集合求交集，因为他们可能被存储到不同的Redis实例（实际上这种情况也有办法，但是不能直接使用交集指令）。
• 同时操作多个key,则不能使用Redis事务.
• 分区使用的粒度是key，不能使用一个非常长的排序key存储一个数据集（The partitioning granularity is the key, so it is not possible to shard a dataset with a single huge key like a very big sorted set）
• 当使用分区的时候，数据处理会非常复杂，例如为了备份你必须从不同的Redis实例和主机同时收集RDB / AOF文件。
• 分区时动态扩容或缩容可能非常复杂。Redis集群在运行时增加或者删除Redis节点，能做到最大程度对用户透明地数据再平衡，但其他一些客户端分区或者代理分区方法则不支持这种特性。然而，有一种预分片的技术也可以较好的解决这个问题。

你知道有哪些Redis分区实现方案？

• 客户端分区就是在客户端就已经决定数据会被存储到哪个redis节点或者从哪个redis节点读取。大多数客户端已经实现了客户端分区。
• 代理分区 意味着客户端将请求发送给代理，然后代理决定去哪个节点写数据或者读数据。代理根据分区规则决定请求哪些Redis实例，然后根据Redis的响应结果返回给客户端。redis和memcached的一种代理实现就是Twemproxy
• 查询路由(Query routing) 的意思是客户端随机地请求任意一个redis实例，然后由Redis将请求转发给正确的Redis节点。Redis Cluster实现了一种混合形式的查询路由，但并不是直接将请求从一个redis节点转发到另一个redis节点，而是在客户端的帮助下直接redirected到正确的redis节点。

4.分布式锁

先拿setnx来争抢锁，抢到之后，再用expire给锁加一个过期时间防止锁忘记了释放。

如果在setnx之后执行expire之前进程意外crash或者要重启维护了，那会怎么样？

set指令有非常复杂的参数，这个应该是可以同时把setnx和expire合成一条指令来用的！

Lua脚本实现

详情见分布式锁章节

5.消息订阅发布

#订阅频道：subscribe chat1
#订阅一组频道： psubscribe java.*
#退订指定频道： unsubscrible chat1   , punsubscribe java.*
#发布消息：publish chat1 "hell0 ni hao"
#查看频道：pubsub channels
#查看某个频道的订阅者数量: pubsub numsub chat1

#客户端A
ruoyi:0>SUBSCRIBE channel1 channel2
切换到推送/订阅模式，关闭标签页来停止接收信息。
 1)  "subscribe"
 2)  "channel1"
 3)  "1"
 #使用客户端B给频道发信息，此时客户端A会收到以下信息
 1)  "message"
 2)  "channel1"
 3)  "hello-welcome-subscribe-channel1"
 1)  "message"
 2)  "channel2"
 3)  "hello-welcome-subscribe-channel2"
#客户端B
ruoyi:0>PUBLISH channel1 hello-welcome-subscribe-channel1
"1"
ruoyi:0>PUBLISH channel2 hello-welcome-subscribe-channel2
"1"
ruoyi:0>PUBLISH channel3 hello-welcome-subscribe-channel3
"0"

6.异步队列、延时队列实现

异步队列

一般使用list结构作为队列，rpush生产消息，lpop消费消息。当lpop没有消息的时候，要适当sleep一会再重试。如果不想sleep的话，可以使用blpop, 在没有信息的时候，会一直阻塞，直到信息的到来。

能不能生产一次消费多次呢？

使用pub/sub主题订阅者模式，可以实现1:N的消息队列。

延时队列

使用sortedset，使用时间戳做score, 消息内容作为key,调用zadd来生产消息，消费者使用zrangbyscore获取n秒之前的数据做轮询处理。

7.Pipeline

可以批量执行一组指令，一次性返回全部结果，可以减少频繁的请求应答。

pipeline可以提高Redis批量处理的并发的能力，但是并不能无节制的使用。 如果批量执行的命令数量过大，则很容易对网络及客户端造成很大影响，此时可以把命令分割，每次发送少量的命令到服务端执行。

#普通方式向Redis中写入10000条hash记录，需要的时间为2.00秒
import redis
import time

client = redis.StrictRedis(host='192.168.81.100',port=6379)
start_time = time.time()

for i in range(10000):
    client.hset('hashkey','field%d' % i,'value%d' % i)

ctime = time.time()
print(client.hlen('hashkey'))
print(ctime - start_time)

#pipeline每次只能作用在一个Redis节点上 使用Pipeline方式每次向Redis服务端发送100条命令，发送100次所需要的时间仅为0.31秒
import redis
import time

client = redis.StrictRedis(host='192.168.81.100',port=6379)
start_time = time.time()

for i in range(100):
    pipeline = client.pipeline()
    j = i * 100
    while j < (i+ 1) * 100:
        pipeline.hset('hashkey1','field%d' % j * 100,'value%d' % i)
        j += 1
    pipeline.execute()

ctime = time.time()
print(client.hlen('hashkey1'))
print(ctime - start_time)

8.Lua

Redis 支持提交 Lua 脚本来执行一系列的功能。

假如Redis里面有1亿个key，其中有10w个key是以某个固定的已知的前缀开头的，如果将它们全部找出来？

使用keys指令可以扫出指定模式的key列表。

如果这个redis正在给线上的业务提供服务，那使用keys指令会有什么问题？

这个时候你要回答redis关键的一个特性：redis的单线程的。keys指令会导致线程阻塞一段时间，线上服务会停顿，直到指令执行完毕，服务才能恢复。这个时候可以使用scan指令，scan指令可以无阻塞的提取出指定模式的key列表，但是会有一定的重复概率，在客户端做一次去重就可以了，但是整体所花费的时间会比直接用keys指令长。

9.Redis常见性能问题和解决方案

1. Master最好不要做任何持久化工作，包括内存快照和AOF日志文件，特别是不要启用内存快照做持久化。
2. 如果数据比较关键，某个Slave开启AOF备份数据，策略为每秒同步一次。
3. 为了主从复制的速度和连接的稳定性，Slave和Master最好在同一个局域网内。
4. 尽量避免在压力较大的主库上增加从库
5. Master调用BGREWRITEAOF重写AOF文件，AOF在重写的时候会占大量的CPU和内存资源，导致服务load过高，出现短暂服务暂停现象。
6. 为了Master的稳定性，主从复制不要用图状结构，用单向链表结构更稳定，即主从关系为：Master<–Slave1<–Slave2<–Slave3…，这样的结构也方便解决单点故障问题，实现Slave对Master的替换，也即，如果Master挂了，可以立马启用Slave1做Master，其他不变。

10.生产环境中的 redis 是怎么部署的？

redis cluster，10 台机器，5 台机器部署了 redis 主实例，另外 5 台机器部署了 redis 的从实例，每个主实例挂了一个从实例，5 个节点对外提供读写服务，每个节点的读写高峰qps可能可以达到每秒 5 万，5 台机器最多是 25 万读写请求/s。

机器是什么配置？32G 内存+ 8 核 CPU + 1T 磁盘，但是分配给 redis 进程的是10g内存，一般线上生产环境，redis 的内存尽量不要超过 10g，超过 10g 可能会有问题。

5 台机器对外提供读写，一共有 50g 内存。

因为每个主实例都挂了一个从实例，所以是高可用的，任何一个主实例宕机，都会自动故障迁移，redis 从实例会自动变成主实例继续提供读写服务。

你往内存里写的是什么数据？每条数据的大小是多少？商品数据，每条数据是 10kb。100 条数据是 1mb，10 万条数据是 1g。常驻内存的是 200 万条商品数据，占用内存是 20g，仅仅不到总内存的 50%。目前高峰期每秒就是 3500 左右的请求量。

一致性哈希算法

Redis哈希槽

Redis集群没有使用一致性hash,而是引入了哈希槽的概念，Redis集群有16384个哈希槽，每个key通过CRC16校验后对16384取模来决定放置哪个槽，集群的每个节点负责一部分hash槽。

总结

参考

Docker实战之Redis-Cluster集群