redis案例

redis案例

记录遇到过redis案例

发布订阅

Redis 发布订阅 (pub/sub) 是一种消息通信模式：发送者 (pub) 发送消息，订阅者 (sub) 接收消息。
Redis 客户端可以订阅任意数量的频道。

1. 客户端可以订阅频道如下图
   
2. 当给这个频道发布消息后，消息就会发送给订阅的客户端
   
   实现
   三台不同ip的虚拟机，其中两台作为192.168.3.106的客户端
   命令如下：
   

数据恢复

RDB数据恢复

开启RDB保存策略

表示 30秒内，key值修改10次 触发一次RDB快照
测试前删除原有的dump.rdb文件 rm -rf dump.rdb
重启服务器，启动redis，并进入客户端

此时数据为空
进行数据插入操作

插入13条数据，触发保存策略生成rdb文件

关闭redis，对dump.rdb文件改名mv dump.rdb dump.rdb.bp
此时没有dump.rdb文件 重启redis

没有任何数据，关闭redis再将dump.rdb.bp改回dump.rdb，再次启动redis，再次查看

注意:rdb会照成数据丢失，如果数据敏感不建议采用此方式持久化。

AOF数据恢复

步骤和RDB大同小异，如果AOF文件没有损坏怎复制aof文件到对应目录，重启redis即可
如果aof损坏通过redis-check-aof修复aof文件。
先开启aof持久化:在配置文件中修改appendonly yes appendfsync always
插入数据：

关闭redis查看aof文件，并对该文件进行修改，手动损坏该文件

在重新启动redis，发现启动出现问题，客户端无法连接

修复aof文件
/usr/local/bin/redis-check-aof --fix appendonly.aof

重启redis

此时数据恢复

集群模式搭建

集群搭建

redis-cli --cluster命令
crate 创建集群
call： 可以执行redis命令
add-node: 将一个节点添加到集群里面，第一个参数为新节点的ip:port ,第二个参数为集群中任意一个已存在的节点的 ip:port
del-node: 集群中存活的某个一个节点的ip:port 要删除节点的id (删除的节点必须把槽迁移)
reshard：集群中存活的某个一个节点的ip:port (针对的是整个集群，而不是填写的节点)
check：检查集群状态

水平扩容

集群扩容一主一从作为案例，未搭建集群的先看上面的集群搭建，本次集群案例采用集群搭建上的案例。
准备
已有集群

和两台redis服务器 分别为192.168.3.112 、192.168.3.113 。
步骤

1. 修改需要添加的两台redis服务器的配置文件 redis.conf
   主要修改集群配置、持久化配置，这些基础配置不在赘述

2. 正常启动这两个redis

3. 添加节点到集群中
   添加112到集群中：src/redis-cli --cluster add-node 192.168.3.112:6379 192.168.3.106:6379
   第一个ip:port 是需要添加的节点信息 第二个是集群中存活的ip信息
   
   同理添加113：src/redis-cli --cluster add-node 192.168.3.113:6379 192.168.3.106:6379
   连接任意一个集群客户端，查看集群节点信息
   
   可以看到112 113已经添加到集群中了，默认为master 但是是没有分配槽的，此时新添加的两个节点服务还不可用。

4. 为新节点分配槽
   为112分配槽：src/redis-cli --cluster reshard 192.168.3.12:6379
   
   然后询问要分配多少个槽
   
   How many slots do you want to move (from 1 to 16384)? 询问要移动多少个槽 案例输入2000
   What is the receiving node ID? 要移动的id 案例给新增加的节点添加槽 输入增加的节点的id
   Please enter all the source node IDs.
   Type ‘all’ to use all the nodes as source nodes for the hash slots. 是否将其它主节点的槽平均分配给目标节点 是的话输入all
   Type ‘done’ once you entered all the source nodes IDs. 从输入的id节点中分配 完成后输入done结束分配 案例采用这个模式
   Do you want to proceed with the proposed reshard plan (yes/no)? 是否按照这个列表分配 输入yes
   分配槽的过程会进行阻塞，槽分配之后 槽对应的数据也会迁移
   先查看节点信息
   
   到此主节点添加完成

5. 添加从节点
   任何新添加的节点都默认为主节点
   src/redis-cli -c -h 192.168.3.113 -p 6379 将113作为112的从节点
   cluster replicate 主节点id9(也就是112节点的id)
   cluster replicate 7c4bb890c8afbe7d9031c30e9a44d8f6e5589e82
   
   这样从节点就配置好了
   查看节点信息
   
   到此一主一从配置完成

水平缩容

本次以删除水平扩容案例中，新增的两个节点为案例
删除从节点
通过del-node 删除节点
src/redis-cli --cluster del-node 192.168.3.106:6379 d8daf4f5a906c0404c6d52c438908ae4795bb0e4
第一个ip：port 为及群众存活的任意一个节点信息
后面跟着的是要删除的节点id

查看节点信息

发现113节点已经不存在
删除主节点
先将需要删除的主节点的槽迁移到其他主节点上

查看节点信息

112没有了槽
然后通过del-node 删除节点
src/redis-cli --cluster del-node 192.168.3.106:6379 7c4bb890c8afbe7d9031c30e9a44d8f6e5589e82

到此完成缩容

集群数据恢复

集群中当一个主节点挂掉，该主节点的从节点就会成为主节点。
例如
106为主节点，110为106的从节点，106宕机后

110为主节点，数据不会丢失

一般来说只要重启106就可以，问题不大。
如果一主一从都宕机了

显示整个集群都down了。这个和redis.conf的配置参数有关
如果某一段插槽的主从都挂掉，而cluster-require-full-coverage 为yes ，那么 ，整个集群都挂掉
如果某一段插槽的主从都挂掉，而cluster-require-full-coverage 为no ，那么，该插槽数据全都不能使用，也无法存储。
数据恢复
如果是集群宕机，需要重新创建新的集群，保证之前的槽和新创建的集群的槽是一致的，否则会导致部分数据丢失。将旧集群的持久化文件复制到新集群对应的主节点就好，这和数据迁移类似，数据迁移也是如此