33.Redis详解

最新推荐文章于 2024-04-25 10:32:59 发布

特洛伊CAR

最新推荐文章于 2024-04-25 10:32:59 发布

阅读量1.4k

点赞数

文章标签： redis

本文链接：https://blog.csdn.net/weixin_46238755/article/details/118772969

版权

一缓存概念

缓存是为了调节速度不一致的两个或多个不同的物质的速度，在中间对速度较快的一方起到一个加速访问速度较慢的一方的作用，比如CPU的一级、二级缓存是保存了CPU最近经常访问的数据，内存是保存CPU经常访问硬盘的数据，而且硬盘也有大小不一的缓存，甚至是物理服务器的raid 卡有也缓存，都是为了起到加速CPU 访问硬盘数据的目的，因为CPU的速度太快了，CPU需要的数据由于硬盘往往不能在短时间内满足CPU的需求，因此PCU缓存、内存、Raid 卡缓存以及硬盘缓存就在一定程度上满足了CPU的数据需求，即CPU 从缓存读取数据可以大幅提高CPU的工作效率。

http://www.sohu.com/a/246498483_468626

1.1 系统缓存

1.1.1 buffer与cache

buffer 缓冲也叫写缓冲，一般用于写操作，可以将数据先写入内存在写入磁盘，buffer 一般用于写缓冲，用于解决不同介质的速度不一致的缓冲，先将数据临时写入到里自己最近的地方，以提高写入速度，CPU会把数据先写到内存的磁盘缓冲区，然后就认为数据已经写入完成，然后由内核在后续的时间在写入磁盘，所以服务器突然断电会丢失内存中的部分数据。

cache 缓存也叫读缓存，一般用于读操作，CPU读文件从内存读，如果内存没有就先从硬盘读到内存再读到CPU，将需要频繁读取的数据放在里自己最近的缓存区域，下次读取的时候即可快速读取。

[root@redis-node1 ~ 1]#free -m
              total        used        free      shared  buff/cache   available
Mem:           1819         123        1533           9         161        1543
Swap:          2047           0        2047

1.1.2 cache的保存位置

客户端：浏览器
内存：本地服务器、远程服务器
硬盘：本机硬盘、远程服务器硬盘

1.1.3 cache的特性

自动过期：给缓存的数据加上有效时间，超出时间后自动过期删除
过期时间：强制过期，源网站更新图片后CDN是不会更新的，需要强制刷新使图片缓存过期
命中率：即缓存的读取命中率

1.2 用户层缓存

1.2.1 DNS缓存

默认为60秒，即60秒之内在访问同一个域名就不在进行DNS解析

查看chrome浏览器的DNS缓存（现在看不到了）

chrome://net-internals/#dns

1.2.2 火狐浏览器缓存

about:cache

1.2.3 浏览器缓存过期机制

1.2.3.1 最后修改时间

系统调用文件的时候会获取文件的最后修改时间，如果没有发生变化就返回给浏览器304的状态码，表示没有发生变化，然后浏览器就使用的本地的缓存展示资源，

如果服务端返回最后修改时间没有发生过变化，则直接使用浏览器的本地缓存，状态码就是304；发生过变化就是200

1.2.3.2 Etag标记

基于Etag标记是否一致做判断页面是否发生过变化，比如基于Nginx 的etag on来实现。

1.2.3.3 过期时间

以上两种都需要发送请求，即不管资源是否过期都要发送请求进行协商，这样会消耗不必要的时间，因此有了缓存的过期时间，即第一次请求资源的时候带一个资源的过期时间，默认为30天，当前这种方式使用的比较多，但是无法保证客户的时间都是准确并且一致的，因此会加入一个最大生存周期，使用用户本地的时间计算缓存数据是否超过多少天，下面的过期时间为2027年，但是缓存的最大生存周期计算为天等于3650天即10年，过期时间如下

说明：以用户的电脑时间为准

1.3 CDN缓存

1.3.1 什么是CDN

内容分发网络（Content Delivery Network），通过将服务内容分发至全网加速节点，利用全球调度系统使用户能够就近获取，有效降低访问延迟，提升服务可用性

CDN的优点：

第一降低机房的使用带宽，因为很多资源通过CDN就直接返回用户了
第二解决不同运营商之间的互联，因为可以让联通的网络访问联通让电信的网络访问电信，起到加速用户访问的目的
第三解决用户访问的地域问题，就近返回用户资源。

百度CDN：https://cloud.baidu.com/product/cdn.html

阿里CDN：https://www.aliyun.com/product/cdn?spm=5176.8269123.416540.50.728y8n

腾讯CDN：https://www.qcloud.com/product/cdn

1.3.2 用户请求CDN流程

提前对静态内容进行预缓存，避免大量的请求回源，导致主站网络带宽被打满而导致数据无法更新，另外CDN可以将数据根据访问的热度不同而进行不同级别的缓存，例如访问量最高的资源访问CDN 边缘节点的内存，其次的放在SSD或者SATA，再其次的放在云存储，这样兼顾了速度与成本。

1.3.3 CDN主要优势

提前对静态内容进行预缓存，避免大量的请求回源，导致主站网络带宽被打满而导致数据无法更新，另外CDN可以将数据根据访问的热度不同而进行不同级别的缓存，例如访问量最高的资源访问CDN 边缘节点的内存，其次的放在SSD或者SATA，再其次的放在云存储，这样兼顾了速度与成本。缓存-缓存到最快的地方如内存，缓存的数据准确命中率高，访问速度就快。

调度准确：将用户调度到最近的边缘节点
性能优化：CDN 专门用于缓存，响应速度快
安全相关：抵御攻击
节省带宽：由于用户请求由边缘节点响应，因此大幅降低到源站带宽。

1.4 应用层缓存

Nginx、PHP等web服务可以设置应用缓存以加速响应用户请求，另外有些解释性语言比如PHP/Python/Java不能直接运行，需要先编译成字节码，但字节码需要解释器解释为机器码之后才能执行，因此字节码也是一种缓存，有时候会出现程序代码上线后字节码没有更新的现象。

1.5 其他层面缓存

1.5.1 CPU缓存

CPU缓存(L1的数据缓存和L1的指令缓存)、二级缓存、三级缓存（一般是共享的）

1.5.2 cookie与session

Cookie是访问某些网站以后在本地存储的一些网站相关的信息，下次再访问的时候减少一些步骤,比如加密后的账户名密码等信息

Cookies是服务器在客户端浏览器上存储的小段文本并随每一个请求发送至同一个服务器，是一种实现客户端保持状态的方案。
session称为会话信息，位于web服务器上，主要负责访问者与网站之间的交互，当浏览器请求http地址时，可以基于之前的session实现会话保持、session共享等。

1.5.3 session与cookie的区别

Cookie以文本文件格式存储在浏览器中，而session存储在服务端。
cookie的存储限制了数据量，只允许4KB，而session是无限制的。
cookie包含在每一个客户端请求报文中，因此容易被人捕获。
cookie和session都可以设置过期时间。

二 redis部署与使用

2.1 redis基础

官网地址 https://redis.io/

Redis和Memcached是非关系型数据库也称为NoSQL数据库，MySQL、Mariadb、SQL Server、PostgreSQL、Oracle 数据库属于关系型数据(RDBMS, Relational Database Management System)

2.1.1 redis简介

Redis(Remote Dictionary Server)在2009年发布，开发者Salvatore Sanfilippo是意大利开发者，他本想为自己的公司开发一个用于替换MySQL的产品Redis，但是没有想到他把Redis开源后大受欢迎，短短几年，Redis就有了很大的用户群体，目前国内外使用的公司有知乎网、新浪微博、GitHub等

redis是一个开源的、遵循BSD协议的、基于内存的而且目前比较流行的键值数据库(key-value database)，是一个非关系型数据库，redis提供将内存通过网络远程共享的一种服务，提供类似功能的还有memcache，但相比memcache，redis还提供了易扩展、高性能、具备数据持久性等功能。

Redis在高并发、低延迟环境要求比较高的环境使用量非常广泛，目前redis在DB-Engine月排行榜https://db-engines.com/en/ranking 中一直比较靠前，而且一直是键值型存储类的首位。

2.1.2 redis对比memcached

支持数据的持久化：这是最重要的区别，可以将内存中的数据保持在磁盘中，重启redis服务或者服务器之后可以从备份文件中恢复数据到内存继续使用。

支持更多的数据类型：支持string(字符串)、hash(哈希数据)、list(列表)、set(集合)、zet(有序集合)
支持数据的备份：可以实现类似于数据的master-slave模式的数据备份，另外也支持使用快照+AOF。
支持更大的value数据：memcache单个key value最大只支持1MB，而redis最大支持512MB。
Redis 是单线程，而memcache是多线程，所以单机情况下没有memcache并发高，但redis 支持分布式集群以实现更高的并发，单Redis实例可以实现数万并发。
支持集群横向扩展：基于redis cluster的横向扩展，可以实现分布式集群，大幅提升性能和数据安全性。
都是基于C语言开发。

2.1.3 redis 典型应用场景

Session 共享：常见于web集群中的Tomcat或者PHP中多web服务器session共享
消息队列：ELK的日志缓存、部分业务的订阅发布系统
计数器：访问排行榜、商品浏览数等和次数相关的数值统计场景
缓存：数据库查询缓存、电商网站商品信息、新闻内容
微博/微信社交场合：共同好友、点赞评论等

2.2 Redis安装及使用

官方下载地址 http://download.redis.io/releases/

2.2.1 yum安装redis

在centos系统上需要安装epel源。

2.2.1.1 查看yum仓库redis版本

2.2.1.2 安装redis

[root@redis ~]# yum install redis –y
[root@redis ~]# systemctl enable --now redis
[root@redis ~]# redis-cli
127.0.0.1:6379> info
# Server
redis_version:3.2.12
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:7897e7d0e13773f
redis_mode:standalone
os:Linux 3.10.0-1127.el7.x86_64 x86_64
arch_bits:64

2.2.2 编译安装redis

下载当前最新release版本redis 源码包 http://download.redis.io/releases/

2.2.2.1 编译安装命令

官方的安装命令

https://redis.io/download

[root@redis-node1 src]#pwd
/usr/local/src
[root@redis-node1 src]#tar xf redis-5.0.3.tar.gz
[root@redis-node1 src]#cd redis-4.0.14/
[root@redis-node1 redis-4.0.14]#make PREFIX=/apps/redis install #指定redis安装目录
[root@redis-node1 redis-4.0.14]#ll /apps/redis/
total 0
drwxr-xr-x 2 root root 134 Aug  9 21:00 bin

[root@redis-node1 redis-4.0.14]#mkdir /apps/redis/{etc,logs,data,run} #创建配置文件、日志、数据等目录
[root@redis-node1 redis-4.0.14]#cp redis.conf /apps/redis/etc/

2.2.2.2 前台启动redis

2.2.2.3 解决当前的警告提示

2.2.2.3.1 tcp-backlog

The backlog argument defines the maximum length to which the queue of pending connections for sockfd may grow. If a connection request arrives when the queue is full, the client may receive an error with an indication of ECONNREFUSED or, if the underlying protocol supports retransmission, the request may be ignored so that a later reattempt at connection succeeds.

backlog参数控制的是三次握手的时候server端收到client ack确认号之后的队列值。

[root@redis-node1 redis-4.0.14]#vim /etc/sysctl.conf 
net.core.somaxconn = 512
[root@redis-node1 redis-4.0.14]#sysctl -p
net.core.somaxconn = 512

2.2.2.3.2 vm.overcommit_memory

0、表示内核将检查是否有足够的可用内存供应用进程使用；如果有足够的可用内存，内存申请允许；否则，内存申请失败，并把错误返回给应用进程。
1、表示内核允许分配所有的物理内存，而不管当前的内存状态如何。
2、表示内核允许分配超过所有物理内存和交换空间总和的内存

[root@redis-node1 redis-4.0.14]#vim /etc/sysctl.conf
vm.overcommit_memory = 1

2.2.2.3.3 transparent hugepage

大页内存动态分配，需要关闭让redis 负责内存管理。

echo never > /sys/kernel/mm/transparent_hugepage/enabled

2.2.2.3.4 再次启动redis

将以上配置同步到其他redis 服务器。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-tYTAqQjb-1626366717547)(C:\Users\cui\Desktop\课程截图\Redis详解_图片\image-20200809222407515.png)]

2.2.2.4 编辑redis服务启动脚本

[root@s1 ~]# cat /usr/lib/systemd/system/redis.service
[Unit]
Description=Redis persistent key-value database
After=network.target
After=network-online.target
Wants=network-online.target

[Service]
#ExecStart=/usr/bin/redis-server /etc/redis.conf --supervised systemd
ExecStart=/apps/redis/bin/redis-server /apps/redis/etc/redis.conf --supervised systemd
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s QUIT $MAINPID
Type=notify
User=redis
Group=redis
RuntimeDirectory=redis
RuntimeDirectoryMode=0755

[Install]
WantedBy=multi-user.target

2.2.2.5 创建redis 用户和数据目录

# groupadd -g 1000 redis && useradd -u 1000 -g 1000 redis -s /sbin/nologin
[root@redis-node1 ~]#useradd -u 2020 redis
[root@redis-node1 ~]#id 2020
uid=2020(redis) gid=2020(redis) groups=2020(redis)
[root@redis-node1 ~]#chown redis.redis /apps/redis/ -R

2.2.2.6 验证redis 启动

# useradd redis -s /sbin/nologin
# chown redis.redis /apps/redis/ -R
# chown redis.redis /apps/redis/ -R #注意目录权限
[root@redis-node1 ~]#vim /apps/redis/etc/redis.conf
bind 0.0.0.0
[root@redis-node1 ~]#systemctl daemon-reload
[root@redis-node1 ~]#systemctl enable --now redis

2.2.2.7 使用客户端连接redis

#/apps/redis/bin/redis-cli -h IP/HOSTNAME -p PORT -a PASSWORD

2.2.2.8 创建命令软连接

[root@redis-node1 ~]#ln -sv /apps/redis/bin/redis-* /usr/bin/
‘/usr/bin/redis-benchmark’ -> ‘/apps/redis/bin/redis-benchmark’
‘/usr/bin/redis-check-aof’ -> ‘/apps/redis/bin/redis-check-aof’
‘/usr/bin/redis-check-rdb’ -> ‘/apps/redis/bin/redis-check-rdb’
‘/usr/bin/redis-cli’ -> ‘/apps/redis/bin/redis-cli’
‘/usr/bin/redis-sentinel’ -> ‘/apps/redis/bin/redis-sentinel’
‘/usr/bin/redis-server’ -> ‘/apps/redis/bin/redis-server’

2.2.2.9 编译安装后的命令

[root@redis-node1 ~]#ll /apps/redis/bin/
total 21888
-rwxr-xr-x 1 redis redis 2452144 Aug  9 21:00 redis-benchmark #redis性能测试工具
-rwxr-xr-x 1 redis redis 5777720 Aug  9 21:00 redis-check-aof #AOF文件检查工具
-rwxr-xr-x 1 redis redis 5777720 Aug  9 21:00 redis-check-rdb #RDB文件检查工具
-rwxr-xr-x 1 redis redis 2618176 Aug  9 21:00 redis-cli		  #客户端工具
lrwxrwxrwx 1 redis redis      12 Aug  9 21:00 redis-sentinel -> redis-server #哨兵，软连接到server
-rwxr-xr-x 1 redis redis 5777720 Aug  9 21:00 redis-server    #redis 服务启动命令

2.2.3 windows 安装redis

基本用不上

Windows版 Redis下载地址

https://github.com/MicrosoftArchive/redis/releases

强烈不推荐在生产环境使用Windows 系统运行Redis服务。

2.2.3.1 解压后的目录

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-cq9JNDTn-1626366717563)(C:\Users\cui\Desktop\课程截图\Redis详解_图片\image-20200808225132657.png)]

2.2.3.2 编辑配置文件并执行redis-server.exe

C:\Users\ZhangShiJie>cd C:\Users\ZhangShiJie\Desktop\Redis-x64-3.0.504
C:\Users\ZhangShiJie\Desktop\Redis-x64-3.0.504>redis-server.exe redis.windows.conf

2.2.3.3 验证Redis服务端口

2.2.3.4 执行redis-cli客户端

使用客户端连接到Windows版redis server，进行创建key与获取key操作。

2.2.4 连接到Redis

主要分为运维人员的连接和程序的连接

2.2.4.1 本机非密码连接

# redis-cli

2.2.4.2 跨主机非密码连接

# redis-cli -h HOSTNAME/IP -p PORT

2.2.4.3 跨主机密码连接

# redis-cli -h HOSTNAME/IP -p PORT -a PASSWORD

2.2.4.4 shell脚本写入数据到Redis

2.2.4.4.1 shell脚本内容

#先把快照功能关闭
[root@redis-node1 ~]#vim /apps/redis/etc/redis.conf
save ""
#save 900 1
#save 300 10
#save 60 10000
[root@redis-node1 ~]#systemctl restart redis

# cat redis_write-linux38.sh
#!/bin/bash
NUM=`seq 1 100000`
for i in ${NUM};do
  redis-cli -h 127.0.0.1 set key-${i} value-${i}
  echo "key-${i} value-${i} 写入完成"
done
echo "十万个key写入到Redis完成

2.2.4.4.2 shell脚本执行结果

2.2.4.5 python连接方式

[root@redis-node1 ~]#vim redis-linux41.py
#!/bin/env python
#Author: ZhangJie
import redis
import time
pool = redis.ConnectionPool(host="10.0.7.101", port=6379,password="")
r = redis.Redis(connection_pool=pool)
for i in range(1000):
	r.set("key-%d" % i,"value-%d" % i)
	time.sleep(1)
	data=r.get("key-%d" % i)
	print(data)
	
[root@redis-node1 ~]#python redis-linux41.py  #直接用会提示缺少模块
Traceback (most recent call last):
  File "redis-linux41.py", line 3, in <module>
    import redis
ImportError: No module named redis

#Ubuntu环境安装模块
[root@redis-node1 ~]#yum install python-pip
[root@redis-node1 ~]#pip install redis
[root@redis-node1 ~]#python redis-linux41.py

2.3 redis配置文件

2.3.1 redis主要配置项

bind 0.0.0.0 #监听地址，可以用空格隔开后多个监听IP
protected-mode yes #redis3.2 之后加入的新特性，在没有设置bind IP和密码的时候,redis只允许访问127.0.0.1:6379，远程访问将提示警告信息并拒绝远程访问

下图为关闭监听地址后，远程连接输入命令后提示的错误，其中前三条说的都是修改protected-mode为no，最后一条提示设置bind IP或密码
port 6379 #监听端口，默认6379，不要去改
tcp-backlog 511 #三次握手的时候server端收到client ack确认号之后的队列值。
timeout 0 #客户端和Redis服务端的连接超时时间，默认是0，表示永不超时。
tcp-keepalive 300 #tcp 会话保持时间，默认不动
daemonize n #默认情况下 redis 不是作为守护进程运行的，如果你想让它在后台运行，你就把它改成 yes，当redis作为守护进程运行的时候，它会写一个 pid 到 /var/run/redis.pid 文件里面
supervised no #和操作系统相关参数，可以设置通过upstart和systemd管理Redis守护进程，centos 7以后都使用systemd
pidfile /var/run/redis_6379.pid #pid文件路径，可以修改为/apps/redis/run/redis_6379.pid
loglevel notice #日志级别，详细日志改为debug
logfile “” #日志路径，可修改为/apps/redis/logs/redis_6379.log
databases 16 #设置db 库数量，默认16个库（0-15），隔离不同业务的数据
always-show-logo yes #在启动redis 时是否显示log
save 900 1 #在900秒内有一个键内容发生更改就出就快照机制
save 300 10 #三条满足任何一个就会触发快照机制
save 60 10000
stop-writes-on-bgsave-error no #快照出错时是否禁止redis 写入操作，一定要关掉
rdbcompression yes #持久化到RDB文件时，是否压缩，"yes"为压缩，"no"则反之，保持默认即可
rdbchecksum yes #是否开启RC64校验，默认是开启，保持默认
dbfilename dump.rdb #快照文件名，dump_6379.rdb

dir ./ #快照文件保存路径，建议改为/apps/redis/data，同时修改权限，有问题，修改后不能启动

[root@redis-node1 ~]#chown root.root /apps/redis/data/ -R
[root@redis-node1 ~]#ll /apps/redis/data/
total 20
-rw-r--r-- 1 root root 18879 Aug 10 07:14 dump_6379.rdb

replica-serve-stale-data yes #当从库同主库失去连接或者复制正在进行，从机库有两种运行方式
1、如果replica-serve-stale-data设置为yes(默认设置)，从库会继续响应客户端的读请求。
2、如果replica-serve-stale-data设置为no，除去指定的命令之外的任何请求都会返回一个错误"SYNC with master in progress"。
replica-read-only yes #是否设置从库只读，建议设为yes
repl-diskless-sync no #是否使用socket方式复制数据(无盘同步)，新slave连接连接时候需要做数据的全量同步，redis server就要从内存dump出新的RDB文件，然后从master传到slave，有两种方式把RDB文件传输给客户端

1、基于硬盘（disk-backed） master创建一个新进程dump RDB，RDB完成之后由父进程（即主进程）传给slaves。
2、基于socket（diskless） master创建一个新进程直接dump RDB到slave的socket，不经过主进程，不经过硬盘。

基于硬盘的话，RDB文件创建后，一旦创建完毕，可以同时服务更多的slave，但是基于socket的话，新slave连接到master之后得逐个同步数据。
在较慢并且网络较快的时候，可以用diskless(yes),否则使用磁盘(no)

repl-diskless-sync-delay 30 #默认5秒，diskless复制的延迟时间，设置0为关闭，在延迟时间内连接的新客户端，会一起通过disk方式同步数据，但是一旦复制开始还没有结束之前，master节点不会再接收新slave的复制请求，直到下一次同步开始。
repl-ping-slave-period 10 #slave根据master指定的时间进行周期性的PING 监测
repl-timeout 60 #复制连接的超时时间，需要大于repl-ping-slave-period，否则会经常报超时
repl-disable-tcp-nodelay no #在socket模式下是否在slave套接字发送SYNC之后禁用 TCP_NODELAY，如果选择“yes“，Redis将使用更少的TCP包和带宽来向slaves发送数据，但是这将使数据传输到slave上有延迟，Linux内核的默认配置会达到40毫秒，如果你选择了 “no” 数据传输到salve的延迟将会减少但要使用更多的带宽。保持默认。
repl-backlog-size 512mb #复制缓冲区内存大小，只有在slave连接之后才分配内存。
repl-backlog-ttl 3600 #多次时间master没有slave连接，就清空backlog缓冲区。建议设为120
replica-priority 100 #当master不可用，Sentinel会根据slave的优先级选举一个master，最低的优先级的slave，当选master，而配置成0，永远不会被选举。
requirepass foobared #设置redis 连接密码，最好用双引号引起来，可能会有特殊字符

rename-command #重命名一些高危命令，可以给del设置，rename-command del linux41，工作中建议设置

127.0.0.1:6379> keys *
1000) "key-83"
127.0.0.1:6379> del key-83
(error) ERR unknown command `del`, with args beginning with: `key-83`,
127.0.0.1:6379> linux41 key-83
(integer) 1

maxclients 10000 #Redis最大连接客户端，可以改大一点
maxmemory #最大内存，单位为bytes字节，推荐设置为物理服务器内存的一半

8G内存的计算方式8(G)*1024(MB)*1024(KB)*1024(Kbyte)，需要注意的是slave的输出缓冲区是不计算在maxmemory内。
appendonly no #是否开启AOF日志记录，默认redis使用的是rdb方式持久化，这种方式在许多应用中已经足够用了，但是redis如果中途宕机，会导致可能有几分钟的数据丢失(取决于dumpd数据的间隔时间)，根据save来策略进行持久化，Append Only File是另一种持久化方式，可以提供更好的持久化特性，Redis会把每次写入的数据在接收后都写入 appendonly.aof 文件，每次启动时Redis都会先把这个文件的数据读入内存里，先忽略RDB文件。
appendfilename “appendonly.aof” #AOF文件名，可改为"appendonly_6379.aof"，文件路径和快照文件保存路径一样，注意路径的属主属组必须是redis，不然无法重启
appendfsync everysec #aof持久化策略的配置，no表示不执行fsync，由操作系统保证数据同步到磁盘,always表示每次写入都执行fsync，以保证数据同步到磁盘,everysec表示每秒执行一次fsync，可能会导致丢失这1s数据。保持默认即可
no-appendfsync-on-rewrite no在aof rewrite期间,是否对aof新记录的append暂缓使用文件同步策略,主要考虑磁盘IO开支和请求阻塞时间。默认为no,表示"不暂缓",新的aof记录仍然会被立即同步，Linux的默认fsync策略是30秒，如果为yes 可能丢失30秒数据，但由于yes性能较好而且会避免出现阻塞因此比较推荐。保持默认即可
auto-aof-rewrite-percentage 100 # 当Aof log增长超过指定百分比例时，重写AOF文件，设置为0表示不自动重写Aof 日志，重写是为了使aof体积保持最小，但是还可以确保保存最完整的数据。

例如：AOF文件大小为64M，增长100%达到128M后，进行了重写（实际是优化，去除了不重要的东西），重写后大小假设为80M，那么在增长到160M后会再次重写
auto-aof-rewrite-min-size 64mb #触发aof rewrite的最小文件大小
aof-load-truncated yes #是否加载由于其他原因导致的末尾异常的AOF文件(主进程被kill/断电等)
aof-use-rdb-preamble no #redis4.0新增RDB-AOF混合持久化格式，在开启了这个功能之后，AOF重写产生的文件将同时包含RDB格式的内容和AOF格式的内容，其中RDB格式的内容用于记录已有的数据，而AOF格式的内存则用于记录最近发生了变化的数据，这样Redis就可以同时兼有RDB持久化和AOF持久化的优点（既能够快速地生成重写文件，也能够在出现问题时，快速地载入数据）。
lua-time-limit 5000 #lua脚本的最大执行时间，单位为毫秒
cluster-enabled yes #是否开启集群模式，默认是单机模式
cluster-config-file nodes-6379.conf #由node节点自动生成的集群配置文件
cluster-node-timeout 15000 #集群中node节点连接超时时间，单位为毫秒
cluster-replica-validity-factor 10 #在执行故障转移的时候可能有些节点和master断开一段时间数据比较旧，这些节点就不适用于选举为master，超过这个时间的就不会被进行故障转移
cluster-migration-barrier 1 #集群迁移屏障，一个主节点拥有的至少正常工作的从节点，即如果主节点的slave节点故障后会将多余的从节点分配到当前主节点成为其新的从节点。至少一个，两个的话会比较消耗资源
cluster-require-full-coverage no #集群请求槽位全部覆盖，如果一个主库宕机且没有备库就会出现集群槽位不全，那么yes情况下redis集群槽位验证不全就不再对外提供服务，而no则可以继续使用但是会出现查询数据查不到的情况(因为有数据丢失)。建议设为no
#Slow log 是 Redis 用来记录查询执行时间的日志系统，slow log 保存在内存里面，读写速度非常快，因此你可以放心地使用它，不必担心因为开启 slow log 而损害 Redis 的速度。
slowlog-log-slower-than 10000 #以微秒为单位的慢日志记录，为负数会禁用慢日志，为0会记录每个命令操作。建议设为1000000（1秒）

slowlog-max-len 128 #记录多少条慢日志保存在队列，超出后会删除最早的，以此滚动删除

127.0.0.1:6379> slowlog len
(integer) 14  127.0.0.1:6379> slowlog get
1) 1) (integer) 14
2) (integer) 1544690617
3) (integer) 4
4) 1) "slowlog"
127.0.0.1:6379> SLOWLOG reset
OK

注意：大文件不要用vim打开，会被加载到内存，增大负载

2.3.2 redis持久化

Redis 虽然是一个内存级别的缓存程序，也就是redis 是使用内存进行数据的缓存的，但是其可以将内存的数据按照一定的策略保存到硬盘上，从而实现数据持久保存的目的，目前redis支持两种不同方式的数据持久化保存机制，分别是RDB和AOF

2.3.2.1 RDB模式

RDB(Redis DataBase) 基于时间的快照，其默认只保留当前最新的一次快照，特点是执行速度比较快，缺点是可能会丢失从上次快照到当前时间点之间未做快照的数据。

RDB实现的具体过程Redis从主进程先fork出一个子进程，使用写时复制机制，子进程将内存的数据保存为一个临时文件，比如dump.rdb.temp，当数据保存完成之后再将上一次保存的RDB文件替换掉，然后关闭子进程，这样可以保证每一次做RDB快照的时候保存的数据都是完整的，因为直接替换RDB文件的时候可能会出现突然断电等问题而导致RDB文件还没有保存完整就突然关机停止保存而导致数据丢失的情况，可以手动将每次生成的RDB文件进程备份，这样可以最大化保存历史数据。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0qwYO6OQ-1626366717624)(C:\Users\cui\Desktop\课程截图\Redis详解_图片\image-20200810110710394.png)]

范例：

[root@redis-node1 ~]#cat redis-backup.sh
#!/bin/bash
redis-cli -h 10.0.7.101 -a 123456 bgsave
DATE=`date +%F_%T`
sleep 3
mv /apps/redis/data/dump_6379.rdb /data/redis/dump_6379-${DATE}.rdb

[root@redis-node1 ~]#bash redis-backup.sh
Warning: Using a password with '-a' option on the command line interface may not be safe.
Background saving started

#要恢复数据时，只需把此文件拷贝到/apps/redis/data/目录下改名为dump_6379.rdb重启即可；相应的，把save 900 1三行注释掉，把脚本写进计划任务，每隔一小时执行一次即可
[root@redis-node1 ~]#ll /data/redis/
total 20
-rw-r--r-- 1 redis redis 18879 Aug 10 11:16 dump_6379-2020-08-10_11:16:52.rdb

范例：

[root@redis-node1 ~]#vim /apps/redis/etc/redis.conf
appendonly no

[root@redis-node1 ~]#redis-cli -a 123456
127.0.0.1:6379> SET name1 qinghe
OK
127.0.0.1:6379> SET name2 yuanyuan
OK
127.0.0.1:6379> keys *
1) "name1"
2) "name2"

[root@redis-node1 ~]#bash redis-backup.sh
[root@redis-node1 ~]#redis-cli -a 123456
127.0.0.1:6379> del name1
(integer) 1
127.0.0.1:6379> KEYS *
1) "name2"


[root@redis-node1 ~]#cp /data/redis/dump_6379-2020-08-10_11:42:05.rdb /apps/redis/data/dump_6379.rdb
[root@redis-node1 ~]#systemctl restart redis

[root@redis-node1 ~]#redis-cli -a 123456
127.0.0.1:6379> KEYS *
1) "name1"
2) "name2"

2.3.2.2 RDB模式的优缺点

优点

RDB快照保存了某个时间点的数据，可以通过脚本执行bgsave(非阻塞)或者save(阻塞，不要用)命令自定义时间点备份，可以保留多个备份，当出现问题可以恢复到不同时间点的版本。
可以最大化IO 的性能，因为父进程在保存RDB 文件的时候唯一要做的是fork出一个子进程，然后的-操作都会有这个子进程操作，父进程无需任何的IO操作
RDB在大量数据比如几个G的数据，恢复的速度比AOF的快

缺点

不能实时的保存数据，会丢失自上一次执行RDB备份到当前的内存数据
数据量非常大的时候，从父进程fork的时候需要一点时间，可能是毫秒或者秒或者分钟，取决于磁盘IO性能。

2.3.2.3 AOF模式

AOF 按照操作顺序依次将操作添加到指定的日志文件当中，特点是数据安全性相对较高，缺点是即使有些操作是重复的也会全部记录。

AOF和RDB一样使用了写时复制机制，AOF默认为每秒钟fsync一次，即将执行的命令保存到AOF文件当中，这样即使redis服务器发生故障的话顶多也就丢失1秒钟之内的数据，也可以设置不同的fsync策略，或者设置每次执行命令的时候执行fsync，fsync会在后台执行线程，所以主线程可以继续处理用户的正常请求而不受到写入AOF文件的IO影响。

说明：

AOF 优先级高于RDB，两个同时开启时，AOF优先，正常情况下只用RDB就足够了
RDB：保存的最新的数据
AOF：保存的最全的数据，如果数据被删除，AOF不好恢复

2.3.2.4 AOF模式优缺点

AOF的文件大小要大于RDB格式的文件

根据所使用的fsync策略(fsync是同步内存中redis所有已经修改的文件到存储设备)，默认是appendfsync everysec即每秒执行一次fsync。

2.4 redis 数据类型（了解，开发关注）

http://www.redis.cn/topics/data-types.html

2.4.1 字符串(string)

字符串是所有编程语言中最常见的和最常用的数据类型，而且也是redis最基本的数据类型之一，而且redis中所有的key的类型都是字符串。

2.4.1.1 添加一个key

127.0.0.1:6379> set key1 value1
OK

127.0.0.1:6379> get key1
"value1"

127.0.0.1:6379> TYPE key1
string

127.0.0.1:6379> SET name2 jack2 ex 3 #设置自动过期时间
OK

2.4.1.2 获取一个key的内容

127.0.0.1:6379> get key1
"value1"

2.4.1.3 删除一个key

127.0.0.1:6379> DEL key1
(integer) 1

2.4.1.4 批量设置多个key

127.0.0.1:6379> MSET key1 value1 key2 value2
OK

2.4.1.5 批量获取多个key

127.0.0.1:6379> MGET key1 key2
1) "value1"
2) "value2"

2.4.1.6 追加数据

127.0.0.1:6379> APPEND key1 append
(integer) 12

127.0.0.1:6379> get key1
"value1append"

2.4.1.7 数值递增

127.0.0.1:6379> set num 10
OK

127.0.0.1:6379> INCR num
(integer) 11

127.0.0.1:6379> get num
"11"

2.4.1.8 数值递减

127.0.0.1:6379> set num 10
OK

127.0.0.1:6379> DECR num
(integer) 9

127.0.0.1:6379> get num
"9"

2.4.1.9 返回字符串key长度

127.0.0.1:6379> STRLEN key1
(integer) 12

2.4.1.10 判断key是否存在

127.0.0.1:6379> EXISTS key1
(integer) 1
127.0.0.1:6379> EXISTS key2
(integer) 0

2.4.1.11 查看key的过期时间

ttl #查看key的剩余生存时间
	-1 #负一为永不过期，默认创建的key是永不过期，重新对key赋值，也会从由剩余生命周期变成永不过期
	-2 #为没有此key
	num #key的剩余有效期
	
127.0.0.1:6379> TTL key1
(integer) -1

2.4.1.12 设置key的过期时间

127.0.0.1:6379> EXPIRE key1 86400
(integer) 1

2.4.1.13 取消key的过期时间

127.0.0.1:6379> PERSIST key1
(integer) 1

2.4.2 列表(list)

列表是一个双向可读写的管道，其头部是左侧尾部是右侧，一个列表最多可以包含2^32-1个元素即4294967295个元素。

2.4.2.1 生成列表并插入数据

127.0.0.1:6379> LPUSH zhangsan lisi wangwu magedu #根据顺序逐个写入list1，最后的magedu会在列表的最左侧。
(integer) 3

127.0.0.1:6379> TYPE zhangsan
list

2.4.2.2 向列表追加数据

RPUSH：从右侧向列表插入数据

LPUSH：从左侧向列表插入数据

127.0.0.1:6379> LPUSH list1 tom
(integer) 2

127.0.0.1:6379> RPUSH list1 jack
(integer) 3

2.4.2.3 获取列表长度

127.0.0.1:6379> LLEN list1
(integer) 3

2.4.2.4 获取列表指定位置数据

127.0.0.1:6379> RPUSH list1 zhang wang li zhao
(integer) 4

127.0.0.1:6379> LRANGE list1 1 2 #指定范围，index(下标)
1) "wang"
2) "li"

127.0.0.1:6379> LRANGE list1 2 2 #指定位置
1) "li"

2.4.2.5 移除列表数据

RPOP：从列表右侧弹出数据，一旦弹出，数据将不再存在

LPOP：从列表左侧弹出数据

127.0.0.1:6379> RPOP list1 #最后一个
"jack"

127.0.0.1:6379> LPOP list1 #第一个
"tom"

2.4.3 集合(set)

Set 是 String 类型的无序集合，集合中的成员是唯一的，这就意味着集合中不能出现重复的数据，可以在两个不同的集合中对数据进行对比并取值。

2.4.3.1 生成集合key:

127.0.0.1:6379> SADD set1 v1
(integer) 1

127.0.0.1:6379> SADD set2 v2 v4
(integer) 2

127.0.0.1:6379> TYPE set1
set

127.0.0.1:6379> TYPE set2
set

2.4.3.2 追加数值

追加的时候不能追加已经存在的数值
127.0.0.1:6379> SADD set1 v2 v3 v4
(integer) 3

127.0.0.1:6379> SADD set1 v2 #没有追加成功
(integer) 0

127.0.0.1:6379> TYPE set1
set

127.0.0.1:6379> TYPE set2
set

2.4.3.3 查看集合的所有数据

127.0.0.1:6379> SMEMBERS set1
1) "v4"
2) "v1"
3) "v3"
4) "v2"

127.0.0.1:6379> SMEMBERS set2
1) "v4"
2) "v2"

2.4.2.4 获取集合的差集

差集已属于A而不属于B的元素称为A与B的差（集）

127.0.0.1:6379> SDIFF set1 set2
1) "v1"
2) "v3"

2.4.3.5 获取集合的交集

交集：已属于A且属于B的元素称为A与B的交（集）

127.0.0.1:6379> SINTER set1 set2
1) "v4"
2) "v2"

2.4.3.6 获取集合的并集

并集：已属于A或属于B的元素为称为A与B的并（集）

127.0.0.1:6379> SUNION set1 set2
1) "v2"
2) "v4"
3) "v1"
4) "v3"

2.4.4 sorted set(有序集合):

Redis 有序集合和集合一样也是string类型元素的集合,且不允许重复的成员，不同的是每个元素都会关联一个double(双精度浮点型)类型的分数，redis正是通过该分数来为集合中的成员进行从小到大的排序，有序集合的成员是唯一的,但分数(score)却可以重复，集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是O(1)，集合中最大的成员数为 2^32 - 1 (4294967295, 每个集合可存储40多亿个成员)。

2.4.4.1 生成有序集合

127.0.0.1:6379> ZADD zset1 1 v1
(integer) 1

127.0.0.1:6379> ZADD zset1 2 v2
(integer) 1

127.0.0.1:6379> ZADD zset1 2 v3
(integer) 1

127.0.0.1:6379> ZADD zset1 3 v4
(integer) 1

127.0.0.1:6379> TYPE zset1
zset

127.0.0.1:6379> TYPE zset2
zset

一次生成多个数据：
192.168.7.101:6379> ZADD zset2 1 v1 2 v2 3 v3 4 v4 5 v5
(integer) 5

2.4.4.2 集合排行案例

192.168.7.104:6379> ZADD paihangbang 90 nezha 199 zhanlang 60 zhuluoji 30 gangtiexia
(integer) 4

192.168.7.101:6379> ZRANGE paihangbang 0 -1 #显示集合内所有的key
1) "gangtiexia"
2) "zhuluoji"
3) "nezha"
4) "zhanlang"

192.168.7.104:6379> ZREVRANGE paihangbang 0 -1 withscores #显示指定集合内所有key和得分情况
1) "zhuluoji"
2) "60"
3) "nezha"
4) "90"
5) "zhanlang"
6) "199"

2.4.4.3 获取集合的长度数

127.0.0.1:6379> ZCARD zset1
(integer) 4

127.0.0.1:6379> ZCARD zset2
(integer) 4

2.4.4.4 基于索引返回数值

127.0.0.1:6379> ZRANGE zset1 1 3
1) "v2"
2) "v3"
3) "v4"

127.0.0.1:6379> ZRANGE zset1 0 2
1) "v1"
2) "v2"
3) "v3"

127.0.0.1:6379> ZRANGE zset1 2 2
1) "v3"

2.4.4.5 返回某个数值的索引

127.0.0.1:6379> ZRANK zset1 v2
(integer) 1

127.0.0.1:6379> ZRANK zset1 v3
(integer) 2

2.4.5 哈希(hash)

hash 是一个string类型的field和value的映射表，hash特别适合用于存储对象,Redis 中每个 hash 可以存储 2^32 -1 键值对（40多亿）。

2.4.5.1 生成hash key

127.0.0.1:6379> HSET hash1 name tom age 18
(integer) 1
127.0.0.1:6379> TYPE hash1
hash

2.4.5.2 获取hash key字段值

127.0.0.1:6379> HGET hash1 name
"tom"

127.0.0.1:6379> HGET hash1 age
"18"

2.4.5.3 删除一个hash key的字段

127.0.0.1:6379> HDEL hash1 age
(integer) 1

2.4.5.4 获取所有hash表中的key

127.0.0.1:6379> HMSET hash1 name tom age 19
(integer) 1
127.0.0.1:6379> HKEYS hash1
1) "name"
2) "age"

2.4.5.5 获取指定hash的所有key及value

127.0.0.1:6379> HGETALL hash1
1) "name"
2) "tom"
3) "age"
4) "19"

2.5 消息队列

消息队列主要分为两种，分别是生产者消费者模式和发布者订阅者模式，这两种模式Redis都支持。

2.5.1 生产者消费者模式

在生产者消费者(Producer/Consumer)模式下，上层应用接收到的外部请求后开始处理其当前步骤的操作，在执行完成后将已经完成的操作发送至指定的频道(channel)当中，并由其下层的应用监听该频道并继续下一步的操作，如果其处理完成后没有下一步的操作就直接返回数据给外部请求，如果还有下一步的操作就再将任务发布到另外一个频道，由另外一个消费者继续监听和处理。

此图说明：

假如是登陆京东的场景：首先会有前端页面，前端页面经过消息队列到达注册服务、登陆服务等，注册或登陆服务器都会监听消息队列中指定的消息队列名，一条消息只能被一个服务器所消费

生产者是前端页面，登陆服务和注册服务就是消费者

2.5.1.1 模式介绍

生产者消费者模式下，多个消费者同时监听一个队列，但是一个消息只能被最先抢到消息的消费者消费，即消息任务是一次性读取和处理，此模式在分布式业务架构中非常常用，比较常用的软件还RabbitMQ、Kafka、RocketMQ、ActiveMQ等。

上图说明：高可用，高性能；消费者处理用户请求，消费者监听队列1；队列二负责发邮件

2.5.1.2 队列介绍

队列当中的消息由不同的生产者写入也会有不同的消费者取出进行消费处理，但是一个消息一定是只能被取出一次也就是被消费一次。

先进先出

2.5.1.3 生产者发布消息

[root@redis-s4 ~]# redis-cli
127.0.0.1:6379> AUTH 123456
OK

127.0.0.1:6379> LPUSH channel1 msg1 #从管道的左侧写入
(integer) 1

127.0.0.1:6379> LPUSH channel1 msg2
(integer) 2

127.0.0.1:6379> LPUSH channel1 msg3
(integer) 3

127.0.0.1:6379> LPUSH channel1 msg4
(integer) 4

127.0.0.1:6379> LPUSH channel1 msg5
(integer) 5

2.5.1.4 查看队列所有消息

127.0.0.1:6379> LRANGE channel1 0 -1
1) "msg5"
2) "msg4"
3) "msg3"
4) "msg2"
5) "msg1"

2.5.1.5 消费者消费消息

127.0.0.1:6379>RPOP channel1 #从管道的右侧消费
"msg1"

127.0.0.1:6379> RPOP channel1
"msg2"

127.0.0.1:6379> RPOP channel1
"msg3"

127.0.0.1:6379> RPOP channel1
"msg4"

127.0.0.1:6379> RPOP channel1
"msg5"

127.0.0.1:6379> RPOP channel1
(nil)

2.5.1.6 再次验证队列消息

127.0.0.1:6379> LRANGE channel1 0 -1
(empty list or set) #队列中的消息已经被已全部消费完毕

2.5.2 发布者订阅模式

2.5.2.1 模式简介

在发布者订阅者模式下，发布者将消息发布到指定的channel里面，凡是监听该channel的消费者都会收到同样的一份消息，这种模式类似于是收音机的广播模式，即凡是收听某个频道的听众都会收到主持人发布的相同的消息内容。

此模式常用语群聊天、群通知、群公告等场景。
Subscriber：订阅者
Publisher：发布者
Channel：频道

2.5.2.2 订阅者监听频道

[root@redis-s4 ~]# redis-cli
127.0.0.1:6379> AUTH 123456
OK

127.0.0.1:6379> SUBSCRIBE channel1 #订阅者订阅指定的频道
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "channel1"
3) (integer) 1

2.5.2.3 发布者发布消息

127.0.0.1:6379> PUBLISH channel1 test1 #发布者发布消息
(integer) 2

127.0.0.1:6379> PUBLISH channel1 test2
(integer) 2

2.5.2.4 各订阅者验证消息

2.5.2.5 订阅多个频道

订阅指定的多个频道
> SUBSCRIBE channel1 channel2

2.5.2.6 订阅所有频道

127.0.0.1:6379> PSUBSCRIBE *

2.7.2.7 订阅匹配的频道

> PSUBSCRIBE chann* #匹配订阅多个频道

2.6 Redis 常用命令

2.6.1 CONFIG

config 命令用于查看当前redis配置、以及不重启更改redis配置等

2.6.1.1 更改最大内存

127.0.0.1:6379> CONFIG set maxmemory 8589934592
OK

127.0.0.1:6379> CONFIG get maxmemory
1) "maxmemory"
2) "8589934592"

2.6.1.2 设置连接密码

127.0.0.1:6379> CONFIG SET requirepass 123456
OK

2.6.1.3 获取当前配置

2.6.2 info

显示当前节点redis运行状态信息

2.6.3 SELECT

切换数据库，等于MySQL的use DBNAME指令。

2.6.4 keys:

查看当前库下的所有key，尽量不要使用，会占用大量资源

2.6.5 BGSAVE

手动在后台执行RDB持久化操作

2.6.6 DBSIZE

返回当前库下的所有key 数量

2.6.7 FLUSHDB

强制清空当前库中的所有key。最好重命名

2.6.8 FLUSHALL

强制清空当前redis服务器所有数据库中的所有key，即删除所有数据，最好重命名

三 redis 高可用与集群

虽然Redis可以实现单机的数据持久化，但无论是RDB也好或者AOF也好，都解决不了单点宕机问题，即一旦单台redis服务器本身出现系统故障、硬件故障等问题后，就会直接造成数据的丢失，因此需要使用另外的技术来解决单点问题。

3.1 配置reids 主从

主备模式，可以实现Redis数据的跨主机备份。

程序端连接到高可用负载的VIP，然后连接到负载服务器设置的Redis后端real server，此模式不需要在程序里面配置Redis服务器的真实IP地址，当后期Redis服务器IP地址发生变更只需要更改redis 相应的后端real server即可，可避免更改程序中的IP地址设置。

3.1.1 Slave主要配置

Redis Slave 也要开启持久化并设置和master同样的连接密码，因为后期slave会有提升为master的可能,Slave端切换master同步后会丢失之前的所有数据。

一旦某个Slave成为一个master的slave，Redis Slave服务会清空当前redis服务器上的所有数据并将master的数据导入到自己的内存，但是断开同步关系后不会删除当前已经同步过的数据。

3.1.1.1 命令行配置

#环境准备
[root@redis-node1 apps]#tar czvf redis-4.0.14-linux41.tar.gz redis/*
[root@redis-node1 apps]#scp redis-4.0.14-linux41.tar.gz 10.0.7.102:/apps/
[root@redis-node1 apps]#scp redis-4.0.14-linux41.tar.gz 10.0.7.103:/apps/
[root@redis-node1 apps]#id redis
uid=2020(redis) gid=2020(redis) groups=2020(redis)
[root@redis-node1 apps]#scp /usr/lib/systemd/system/redis.service 10.0.7.102:/usr/lib/systemd/system/redis.service 
[root@redis-node1 apps]#scp /usr/lib/systemd/system/redis.service 10.0.7.103:/usr/lib/systemd/system/redis.service

#从节点环境准备，103同理
[root@redis-node2 ~]#ntpdate time1.aliyun.com
10 Aug 11:09:27 ntpdate[27498]: step time server 203.107.6.88 offset 5025.596537 sec
[root@redis-node2 ~]#hwclock -w
[root@redis-node2 ~]#mkdir /apps
[root@redis-node2 ~]#ll /apps
total 7644
-rw-r--r-- 1 root root 7826035 Aug 10 16:35 redis-4.0.14-linux41.tar.gz
[root@redis-node2 ~]#useradd redis -u 2020
[root@redis-node2 ~]#cd /apps/
[root@redis-node2 apps]#tar xvf redis-4.0.14-linux41.tar.gz 
[root@redis-node2 apps]#chown redis.redis /apps/redis -R
[root@redis-node2 apps]#ll
total 7644
drwxr-xr-x 7 redis redis      63 Aug 10 16:42 redis
-rw-r--r-- 1 root  root  7826035 Aug 10 16:35 redis-4.0.14-linux41.tar.gz
[root@redis-node2 apps]#systemctl enable --now redis
Created symlink from /etc/systemd/system/multi-user.target.wants/redis.service to /usr/lib/systemd/system/redis.service.
[root@redis-node2 apps]#ss -ntl
State      Recv-Q Send-Q                  Local Address:Port                                 Peer Address:Port                               
LISTEN     0      128                                 *:6379                                            *:*  

#给主节点写入数据
[root@redis-node1 ~]#python redis-linux41.py

当前状态为master，需要转换为slave角色并指向master服务器的IP+PORT+Password

#redis4x版本
192.168.7.104:6379> REPLICAOF 192.168.7.103 6379
OK
#redis5x版本
192.168.7.104:6379> CONFIG SET masterauth 123456
OK

3.1.1.2 同步日志

3.1.1.3 当前slave状态

3.1.1.4 保存配置到redis.conf

#redis5
replicaof 10.0.7.0.1 6379
masterauth 123456 #master如果密码需要设置

#redis4
slaveof 10.0.7.101 6379
masterauth 123456

3.1.1.5 重启slave验证

3.1.1.6 验证slave数据

127.0.0.1:6379> KEYS *
1) "num"
2) "hset1"
3) "key1"
4) "name1"
5) "zset2"
6) "key2"
7) "zset1"
8) "set2"

3.1.1.7 slave 状态只读无法写入数据

3.1.1.8 Master日志

3.1.1.9 主从复制过程

Redis支持主从复制分为全量同步和增量同步，首次同步是全量同步，主从同步可以让从服务器从主服务器备份数据，而且从服务器还可与有从服务器，即另外一台redis服务器可以从一台从服务器进行数据同步，redis 的主从同步是非阻塞的，master收到从服务器的sync(2.8版本之前是PSYNC)命令会fork一个子进程在后台执行bgsave命令，并将新写入的数据写入到一个缓冲区里面，bgsave执行完成之后并生成的将RDB文件发送给客户端，客户端将收到后的RDB文件载入自己的内存，然后redis master再将缓冲区的内容在全部发送给redis slave，之后的同步slave服务器会发送一个offset的位置(等同于MySQL的binlog的位置)给主服务器，主服务器检查后位置没有错误将此位置之后的数据包括写在缓冲区的积压数据发送给redis从服务器，从服务器将主服务器发送的挤压数据写入内存，这样一次完整的数据同步，再之后再同步的时候从服务器只要发送当前的offset位置给主服务器，然后主服务器根据相应的位置将之后的数据发送给从服务器保存到其内存即可。

Redis全量复制一般发生在Slave首次初始化阶段，这时Slave需要将Master上的所有数据都复制一份。具体主从同步步骤如下

1）从服务器连接主服务器，发送SYNC命令；
2）主服务器接收到SYNC命名后，开始执行BGSAVE命令生成RDB快照文件并使用缓冲区记录此后执行的所有写命令；
3）主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令；
4）从服务器收到快照文件后丢弃所有旧数据，载入收到的快照；
5）主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令；
6）从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；
7）后期同步会先发送自己slave_repl_offset位置，只同步新增加的数据，不再全量同步。

3.1.1.10 主从同步优化

Redis在2.8版本之前没有提供增量部分复制的功能，当网络闪断或者slave Redis重启之后会导致主从之间的全量同步，即从2.8版本开始增加了部分复制的功能。

repl-diskless-sync no # 是否使用无盘同步RDB文件，默认为no，no为不使用无盘，需要将RDB文件保存到磁盘后再发送给slave，yes为支持无盘，支持无盘就是RDB文件不需要保存至本地磁盘，而且直接通过socket文件发送给slave。
repl-diskless-sync-delay 5 #Master准备好RDB文件后等等待传输时间
repl-ping-slave-period 10 #slave端向server端发送ping的时间区间设置，默认为10秒
repl-timeout 60 #设置超时时间
repl-disable-tcp-nodelay no #是否启用TCP_NODELAY，如设置成yes，则redis会合并小的TCP包从而节省带宽，但会增加同步延迟（40ms），造成master与slave数据不一致，假如设置成no，则redis master会立即发送同步数据，没有延迟，前者关注性能，后者关注redis服务中的数据一致性。
repl-backlog-size 1mb #master的写入数据缓冲区，用于记录自上一次同步后到下一次同步过程中间的写入命令，计算公式 repl-backlog-size = 允许从节点最大中断时长 * 主实例offset每秒写入量，比如master每秒最大写入64mb，最大允许60秒，那么就要设置为64mb*60秒=3840MB(3.8G)
repl-backlog-ttl 3600 #如果一段时间后没有slave连接到master，则backlog size的内存将会被释放。如果值为0则表示永远不释放这部份内存。
slave-priority 100 #slave端的优先级设置，值是一个整数，数字越小表示优先级越高。当master故障时将会按照优先级来选择slave端进行恢复，如果值设置为0，则表示该slave永远不会被选择。
#min-slaves-to-write 1 #设置一个master端的可用slave少于多少个
#min-slaves-max-lag 20 #设置所有slave延迟时间都大于多少秒时，master不接收写操作(拒绝写入)。

3.1.1.11 Slave同步过程日志

3.1.1.12 master同步日志

3.1.1.13 slave切换master

Master的切换会导致master_replid发生变化，slave之前的master_replid就和当前master不一致从而会引发所有slave的全量同步。

当前状态

192.168.7.101:6379> info Replication
# Replication
role:slave
master_host:192.168.7.103
master_port:6379
master_link_status:up
master_last_io_seconds_ago:8
master_sync_in_progress:0

停止slave同步并查看当前状态

192.168.7.101:6379> SLAVEOF no one
OK
192.168.7.101:6379> info Replication
\# Replication
role:master
connected_slaves:0
master_replid:ac3475e5e4fae8c5f47711a643e465b9520c4182
master_replid2:8ee6bc1ac452fd4d2ccbaa660a219f78d218399a
master_repl_offset:8840
second_repl_offset:8841
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:8547
repl_backlog_histlen:294

测试能否写入数据

192.168.7.101:6379> set key1 value1
OK

3.1.1.13 Slave节点再有Slave

在有slave的”master”查看状态，也就是中间那个slave

\# Replication
role:slave
master_host:192.168.7.102
master_port:6379
master_link_status:up
master_last_io_seconds_ago:9 #最近一次与master通信已经过去多少秒。
master_sync_in_progress:0 #是否正在与master通信。
slave_repl_offset:5334 #当前同步的偏移量。
slave_priority:100 #slave优先级，master故障后值越小越优先同步。
slave_read_only:1
connected_slaves:1
slave0:ip=192.168.7.104,port=6379,state=online,offset=5334,lag=1
master_replid:0f0318c25a022add7fd51d4438c470cf608631f9
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:5334
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:5334

3.1.2 常见问题汇总

3.1.2.1 master密码不对

即配置的master密码不对，导致验证不通过而无法建立主从同步关系。

3.1.2.2 Redis版本不一致

不同的redis 版本之间存在兼容性问题，因此各master和slave之间必须保持版本一致。

3.1.2.3 无法远程连接

在开启了安全模式情况下，没有设置bind地址或者密码。

[root@redis-s1 ~]# redis-cli -h 192.168.7.104
192.168.7.104:6379> KEYS *
(error) DENIED Redis is running in protected mode because protected mode is enabled, no bind address was specified, no authentication password
is requested to clients. In this mode connections are only accepted from the loopback interface. If you want to connect from external computers to Redis you may adopt one of the following solutions:

1) Just disable protected mode sending the command 'CONFIG SET protected-mode no' from the loopback interface by connecting to Redis from the same host the server is running,however MAKE SURE Redis is not publicly accessible from internet if you do so. Use CONFIG REWRITE to make this change permanent.

2) Alternatively you can just disable the protected mode by editing the Redis configuration file, and setting the protected mode option to 'no', and then restarting the server.

3) If you started the server manually just for testing, restart it with the '--protectedmode no' option.

4) Setup a bind address or an authentication password. NOTE: You only need to do one of the above things in order for the server to start accepting connections from the outside.

3.2 redis 集群

上一个步骤的主从架构无法实现master和slave角色的自动切换，即当master出现redis服务异常、主机断电、磁盘损坏等问题导致master无法使用，而redis高可用无法实现自故障转移(将slave提升为master)，需要手动改环境配置才能切换到slave redis服务器，另外也无法横向扩展Redis服务的并行写入性能，当单台Redis服务器性能无法满足业务写入需求的时候就必须需要一种方式解决以上的两个核心问题，即

master和slave角色的无缝切换，让业务无感知从而不影响业务使用
可以横向动态扩展Redis服务器，从而实现多台服务器并行写入以实现更高并发的目的。

Redis 集群实现方式：客户端分片(用的较少)；代理分片 Redis Cluster

redis proxy 是瓶颈

3.2.1 Sentinel(哨兵)

Sentinel 进程是用于监控redis集群中Master主服务器工作的状态，在Master主服务器发生故障的时候，可以实现Master和Slave服务器的切换，保证系统的高可用，其已经被集成在redis2.6+的版本中，Redis的哨兵模式到了2.8版本之后就稳定了下来。一般在生产环境也建议使用Redis的2.8版本的以后版本。

哨兵(Sentinel) 是一个分布式系统，可以在一个架构中运行多个哨兵(sentinel) 进程，这些进程使用流言协议(gossip protocols)来接收关于Master主服务器是否下线的信息，并使用投票协议(Agreement Protocols)来决定是否执行自动故障迁移,以及选择哪个Slave作为新的Master。

每个哨兵(Sentinel)进程会向其它哨兵(Sentinel)、Master、Slave定时发送消息，以确认对方是否”活”着，如果发现对方在指定配置时间(可配置的)内未得到回应，则暂时认为对方已掉线，也就是所谓的”主观认为宕机” ，主观是每个成员都具有的独自的而且可能相同也可能不同的意识，英文名称 Subjective Down，简称SDOWN。

有主观宕机，肯定就有客观宕机。当“哨兵群”中的多数Sentinel进程在对Master主服务器做出SDOWN 的判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的Master Server下线判断，这种方式就是“客观宕机”，客观是不依赖于某种意识而已经实际存在的一切事物，英文名称是 Objectively Down，简称 ODOWN。通过一定的vote算法，从剩下的slave从服务器节点中，选一台提升为Master服务器节点，然后自动修改相关配置，并开启故障转移（failover）。

Sentinel 机制可以解决master和slave角色的切换问题。

3.2.1.1 手动配置master

需要手动先指定某一台Redis服务器为master，然后将其他slave服务器使用命令配置为master服务器的slave,哨兵的前提是已经手动实现了一个redis master-slave的运行环境。

实现一个一主两从基于哨兵的高可用redis架构。

3.2.1.1.1 服务器A配置slave

192.168.7.102:6379> REPLICAOF 192.168.7.101 6379
OK
192.168.7.102:6379> CONFIG SET masterauth "123456"
OK

3.2.1.1.2 服务器B配置slave

192.168.7.103:6379> REPLICAOF 192.168.7.101 6379
OK
192.168.7.103:6379> CONFIG SET masterauth "123456"
OK

3.2.1.1.2 当前master状态

3.2.1.1.3 应用程序如何连接redis？

Redis 官方客户端 https://redis.io/clients

java客户端连接redis是通过Jedis来实现的，java代码用的时候只要创建Jedis对象就可以建多个Jedis连接池来连接redis，应用程序再直接调用连接池即可连接Redis。

而Redis为了保障高可用,服务一般都是Sentinel部署方式，当Redis服务中的主服务挂掉之后,会仲裁出另外一台Slaves服务充当Master。这个时候，我们的应用即使使用了Jedis 连接池,Master服务挂了，我们的应用将还是无法连接新的Master服务，为了解决这个问题， Jedis也提供了相应的Sentinel实现，能够在Redis Sentinel主从切换时候，通知我们的应用,把我们的应用连接到新的Master服务。

Redis Sentinel的使用也是十分简单的,只是在JedisPool中添加了Sentinel和MasterName参数，JRedis Sentinel底层基于Redis订阅实现Redis主从服务的切换通知，当Reids发生主从切换时，Sentinel会发送通知主动通知Jedis进行连接的切换，JedisSentinelPool在每次从连接池中获取链接对象的时候，都要对连接对象进行检测，如果此链接和Sentinel的Master服务连接参数不一致，则会关闭此连接，重新获取新的Jedis连接对象。

3.2.1.1.4 python连接redis

yum install python-pip
pip install redis

[root@redis-s3 ~]# cat test.py
#!/bin/env python
#Author: ZhangJie
import redis
pool = redis.ConnectionPool(host="192.168.7.101", port=6379,password="123456")
r = redis.Redis(connection_pool=pool)
for i in range(100):
	r.set("k%d" % i,"v%d" % i)
	data=r.get("k%d" % i)
print(data)

3.2.1.1.5 各Redis服务器验证数据

3.2.1.1 编辑配置文件sentinel.conf

3.2.1.1.1 Server1 配置

哨兵可以不和Redis服务器部署在一起

[root@redis-s1 etc]# grep "^[a-Z]" /usr/local/redis/etc/sentinel.conf
bind 0.0.0.0
port 26379
daemonize yes
pidfile "redis-sentinel.pid"
logfile "sentinel_26379.log"
dir "/usr/local/redis"
sentinel monitor mymaster 10.0.7.101 6379 2 #法定人数限制(quorum)，即有几个slave认为masterdown了就进行故障转移
sentinel auth-pass mymaster 123456 #密码必须保持一致
sentinel down-after-milliseconds mymaster 30000 #(SDOWN)主观下线的时间，可以配成10秒或者15秒
sentinel parallel-syncs mymaster 1 #发生故障转移时候同时向新master同步数据的slave数量，数字越小总同步时间越长
sentinel failover-timeout mymaster 180000 #所有slaves指向新的master所需的超时时间
sentinel deny-scripts-reconfig yes #禁止修改脚本

最终配置如下：

bind 0.0.0.0
port 26379
daemonize yes
pidfile "redis-sentinel.pid"
logfile "sentinel_26379.log"
dir "/apps/redis/data"
sentinel monitor mymaster 10.0.7.101 6379 2 
sentinel auth-pass mymaster 123456 
sentinel down-after-milliseconds mymaster 15000
sentinel parallel-syncs mymaster 1 
sentinel failover-timeout mymaster 180000 
sentinel deny-scripts-reconfig yes

3.2.1.1.2 Server2 配置

bind 10.0.7.102
port 26379
daemonize yes
pidfile "redis-sentinel.pid"
logfile "sentinel_26379.log"
dir "/apps/redis/data"
sentinel deny-scripts-reconfig yes
sentinel monitor mymaster 10.0.7.101 6379 2
sentinel auth-pass mymaster 123456

3.2.1.1.3 Server3配置

bind 10.0.7.103
port 26379
daemonize yes
pidfile "redis-sentinel.pid"
logfile "sentinel_26379.log"
dir "/apps/redis/data"
sentinel deny-scripts-reconfig yes
sentinel monitor mymaster 10.0.7.101 6379 2
sentinel auth-pass mymaster 123456

3.2.1.2 启动哨兵

三台哨兵都要启动

#/usr/local/redis/bin/redis-sentinel /usr/local/redis/etc/sentinel.conf
#/usr/local/redis/bin/redis-sentinel /usr/local/redis/etc/sentinel.conf
#/usr/local/redis/bin/redis-sentinel /usr/local/redis/etc/sentinel.conf

3.2.1.3 验证哨兵端口

3.2.1.4 哨兵日志

3.2.1.5 当前redis master状态

10.0.7.101:6379> INFO Replication
# Replication
role:master
connected_slaves:2
slave0:ip=10.0.7.102,port=6379,state=online,offset=131918,lag=0
slave1:ip=10.0.7.103,port=6379,state=online,offset=131918,lag=1
master_replid:d014dc38628613a82f0d36aa8f43d2587aafe141
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:132053
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:134217728
repl_backlog_first_byte_offset:1
repl_backlog_histlen:132053

3.2.1.6 当前sentinel状态

在sentinel状态中尤其是最后一行，涉及到masterIP是多少，有几个slave，有几个sentinels，必须是符合全部服务器数量的。

3.2.1.6 停止Redis Master测试故障转移

[root@redis-s1 ~]# systemctl stop redis

查看Redis集群master信息

10.0.7.103:6379> INFO Replication
# Replication
role:master
connected_slaves:1
slave0:ip=10.0.7.102,port=6379,state=online,offset=200997,lag=1
master_replid:c1075f752e54b4380e1832552068e6ffa77ca014
master_replid2:d014dc38628613a82f0d36aa8f43d2587aafe141
master_repl_offset:201132
second_repl_offset:172024
repl_backlog_active:1
repl_backlog_size:134217728
repl_backlog_first_byte_offset:1
repl_backlog_histlen:201132

查看哨兵信息

[root@redis-node3 ~]#redis-cli -h 10.0.7.103 -p 26379
10.0.7.103:26379> INFO Sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=10.0.7.103:6379,slaves=2,sentinels=3

故障转移时sentinel的信息

3.2.1.7 故障转移后的redis配置文件

故障转移后redis.conf中的replicaof行的master IP会被修改，sentinel.conf中的sentinel monitor IP会被修改。

3.2.1.8 当前reids状态

旧的master修复好之后：让它以slave的身份加入集群

[root@redis-node1 etc]#vim /apps/redis/etc/redis.conf 
slaveof 10.0.7.103 6379
masterauth 123456
[root@redis-node1 etc]#systemctl restart redis

3.2.2 Redis Cluster

早期Redis 分布式集群部署方案

客户端分区：由客户端程序决定key写分配和写入的redis node，但是需要客户端自己处理写入分配、高可用管理和故障转移等
代理方案：基于三方软件实现redis proxy，客户端先连接之代理层，由代理层实现key的写入分配，对客户端来说是有比较简单，但是对于集群管节点增减相对比较麻烦，而且代理本身也是单点和性能瓶颈。

在哨兵sentinel机制中，可以解决redis高可用的问题，即当master故障后可以自动将slave提升为master从而可以保证redis服务的正常使用，但是无法解决redis单机写入的瓶颈问题，即单机的redis写入性能受限于单机的内存大小、并发数量、网卡速率等因素，因此redis官方在redis 3.0版本之后推出了无中心架构的redis cluster机制，在无中心的redis集群当中，其每个节点保存当前节点数据和整个集群状态,每个节点都和其他所有节点连接，特点如下

所有Redis节点使用(PING机制)互联，即相互检测对方是否存活
集群中某个节点的失效，是整个集群中超过半数的节点监测都失效才算真正的失效
客户端不需要proxy即可直接连接redis，应用程序需要写全部的redis服务器IP。
redis cluster把所有的redis node映射到 0-16383个槽位(slot)上，读写需要到指定的redis node上进行操作，因此有多少个reids node相当于redis 并发扩展了多少倍。
Redis cluster预先分配16384个(slot)槽位，当需要在redis集群中写入一个key -value的时候，会使用CRC16(key) mod 16384之后的值，决定将key写入值哪一个槽位从而决定写入哪一个Redis节点上，从而有效解决单机瓶颈。

3.2.2.1 Redis cluster架构

3.2.2.1.1 Redis cluster基本架构

假如三个主节点分别是 A, B, C 三个节点，采用哈希槽 (hash slot)的方式来分配16384个slot 的话，它们三个节点分别承担的slot 区间是

节点A覆盖 0－5460
节点B覆盖 5461－10922
节点C覆盖 10923－16383

https://zh.wikipedia.org/zh-cn/%E5%BE%AA%E7%92%B0%E5%86%97%E9%A4%98%E6%A0%A1%E9%A9%97

3.2.2.1.2 Redis cluster主从架构

Redis cluster的架构虽然解决了并发的问题，但是又引入了一个新的问题，每个Redis master的高可用如何解决？

3.2.2.2 部署redis集群

环境准备：生产环境建议直接6台服务器。

10.0.7.101	10.0.7.102	10.0.7.103
10.0.7.104	10.0.7.105	10.0.7.106
预留服务器（10.0.7.109）	10.0.7.107	10.0.7.108

另外预留一台服务器做集群添加节点测试。

10.0.7.109:6379

修改配置文件，每个服务器都要改

[root@redis-node1 apps]#vim /apps/redis/etc/redis.conf
cluster-enabled yes
cluster-config-file nodes-6379.conf

3.2.2.2.1 创建redis cluster集群的前提

1.每个redis node节点采用相同的硬件配置、相同的密码、相同的redis版本。
2.每个节点必须开启的参数
cluster-enabled yes #必须开启集群状态，开启后redis 进程会有cluster显示
cluster-config-file nodes-6379.conf #此文件有redis cluster集群自动创建和维护，不需要任何手动操作
3.所有redis服务器必须没有任何数据
4.先启动为单机redis且没有任何key value

验证当前Redis服务状态（端口号在6379基础上加了10000）

3.2.2.2.2 创建集群

Redis 3和 4版本

需要使用到集群管理工具redis-trib.rb，这个工具是redis官方推出的管理redis集群的工具，集成在redis的源码src目录下，是基于redis提供的集群命令封装成简单、便捷、实用的操作工具，redis-trib.rb是redis作者用ruby开发完成的，centos 系统yum安装的ruby存在版本较低问题，如下

只需要在一个服务器上初始化成功即可，其他服务器可以加入

[root@redis-node1 ~]# yum install ruby rubygems -y
[root@redis-node1 ~]# find / -name redis-trib.rb
/usr/local/src/redis-4.0.14/src/redis-trib.rb
[root@redis-node1 ~]# cp /usr/local/src/redis-4.0.14/src/redis-trib.rb /usr/bin/
[root@redis-node1 src]# gem install redis
Fetching: redis-4.1.2.gem (100%)
ERROR: Error installing redis:
	redis requires Ruby version >= 2.3.0.

#解决ruby版本较低问题：

[root@redis-node1 src]# yum remove ruby rubygems -y
[root@redis-node1 src]# wget https://cache.ruby-lang.org/pub/ruby/2.5/ruby-2.5.5.tar.gz
[root@redis-node1 src]# tar xf ruby-2.5.5.tar.gz
[root@redis-node1 src]# cd ruby-2.5.5
[root@redis-node1 ruby-2.5.5]# ./configure
[root@redis-node1 ruby-2.5.5]# make -j 2
[root@redis-node1 ruby-2.5.5]# make install
[root@redis-node1 ruby-2.5.5]# gem install redis

#如果无法在线安装，可以下载reids模块安装包离线安装
#https://rubygems.org/gems/redis #先下载redis模块安装包
#gem install -l redis-3.3.0.gem #安装redis模块

验证redis-trib.rb命令是否可执行:

[root@redis-node1 ruby-2.5.5]#redis-trib.rb
Usage: redis-trib <command> <options> <arguments ...>

create 			host1:port1 ... hostN:portN #创建集群
				--replicas <arg> 			#指定master的副本数量
check 			host:port 					#检查集群信息
info 			host:port 					#查看集群主机信息
fix 			host:port 					#修复集群
				--timeout <arg>             #修复的超时时间，可以稍长一点
reshard 		host:port 					#在线热迁移集群指定主机的slots数据
				--from <arg>
				--to <arg>
				--slots <arg>
				--yes
				--timeout <arg>
				--pipeline <arg>
rebalance 		host:port 					#平衡集群中各主机的slot数量
				--weight <arg>
				--auto-weights
				--use-empty-masters
                --timeout <arg>
				--simulate
				--pipeline <arg>
				--threshold <arg>
add-node 		new_host:new_port existing_host:existing_port #添加主机到集群
				--slave
				--master-id <arg>
del-node 		host:port node_id 			#删除主机
set-timeout 	host:port milliseconds 		#设置节点的超时时间
call 			host:port command arg arg .. arg #在集群上的所有节点上执行命令
import 			host:port 					#导入外部redis服务器的数据到当前集群
				--from <arg>
				--copy
				--replace
help 			(show this help)

修改密码redis 登录密码

[root@redis-node1 ruby-2.5.5]#vim /usr/local/lib/ruby/gems/2.5.0/gems/redis-4.2.1/lib/redis/client.rb

创建redis cluster集群：

Redis 3/4版本：

[root@s1 ~]# redis-trib.rb create --replicas 1 10.0.7.101:6379 10.0.7.102:6379 10.0.7.103:6379 10.0.7.104:6379 10.0.7.105:6379 10.0.7.106:6379

如果有之前的操作导致Redis集群创建报错，则执行清空数据和集群命令：

127.0.0.1:6379> FLUSHALL
OK
127.0.0.1:6379> cluster reset
OK

Redis 5版本：

[root@redis-s1 ~]# redis-cli -a 123456 --cluster create 192.168.7.101:6379
192.168.7.101:6380 192.168.7.102:6379 192.168.7.102:6380 1
92.168.7.103:6379 192.168.7.103:6380 --cluster-replicas 1
Warning: Using a password with '-a' or '-u' option on the command line interface may not
be safe.
\>>> Performing hash slots allocation on 6 nodes...
Master[0] -> Slots 0 - 5460
Master[1] -> Slots 5461 - 10922
Master[2] -> Slots 10923 - 16383
Adding replica 192.168.7.102:6380 to 192.168.7.101:6379
Adding replica 192.168.7.101:6380 to 192.168.7.102:6379
Adding replica 192.168.7.103:6380 to 192.168.7.103:6379
\>>> Trying to optimize slaves allocation for anti-affinity
[OK] Perfect anti-affinity obtained!
M: f4cfc5cf821c0d855016488d6fbfb62c03a14fda 192.168.7.101:6379 #带M的为master  

slots:[0-5460] (5461 slots) master #当前master的槽位起始和结束位
S: 2b6e5d9c3944d79a5b64a19e54e52f83d48438d6 192.168.7.101:6380 #带S的slave
replicates 70de3821dde4701c647bd6c23b9dd3c5c9f24a62
M: 116c4c6de036fdbac5aaad25eb1a61ea262b64af 192.168.7.102:6379
slots:[5461-10922] (5462 slots) master #当前master的槽位起始和结束位
S: 7186c6d03dd9a5e3be658f2d08e800bc55b04a09 192.168.7.102:6380
replicates f4cfc5cf821c0d855016488d6fbfb62c03a14fda
M: 70de3821dde4701c647bd6c23b9dd3c5c9f24a62 192.168.7.103:6379
slots:[10923-16383] (5461 slots) master #当前master的槽位起始和结束位
S: 7eda0bcf0c01bb7343313b81267c42dd1b26c8a6 192.168.7.103:6380
replicates 116c4c6de036fdbac5aaad25eb1a61ea262b64af
Can I set the above configuration? (type 'yes' to accept): yes #输入yes自动创建集群
\>>> Nodes configuration updated
\>>> Assign a different config epoch to each node
\>>> Sending CLUSTER MEET messages to join the cluster
Waiting for the cluster to join
.....
\>>> Performing Cluster Check (using node 192.168.7.101:6379)
M: f4cfc5cf821c0d855016488d6fbfb62c03a14fda 192.168.7.101:6379 #master的ID及端口
slots:[0-5460] (5461 slots) master #已经分配的槽位
1 additional replica(s) #分配了一个slave
S: 7186c6d03dd9a5e3be658f2d08e800bc55b04a09 192.168.7.102:6380
slots: (0 slots) slave #slave没有分配槽位
replicates f4cfc5cf821c0d855016488d6fbfb62c03a14fda
M: 70de3821dde4701c647bd6c23b9dd3c5c9f24a62 192.168.7.103:6379
slots:[10923-16383] (5461 slots) master
1 additional replica(s)
M: 116c4c6de036fdbac5aaad25eb1a61ea262b64af 192.168.7.102:6379
slots:[5461-10922] (5462 slots) master
1 additional replica(s)
S: 2b6e5d9c3944d79a5b64a19e54e52f83d48438d6 192.168.7.101:6380
slots: (0 slots) slave
replicates 70de3821dde4701c647bd6c23b9dd3c5c9f24a62
S: 7eda0bcf0c01bb7343313b81267c42dd1b26c8a6 192.168.7.103:6380
slots: (0 slots) slave
replicates 116c4c6de036fdbac5aaad25eb1a61ea262b64af
[OK] All nodes agree about slots configuration. #所有节点槽位分配完成
\>>> Check for open slots... #检查打开的槽位
\>>> Check slots coverage... #检查插槽覆盖范围
[OK] All 16384 slots covered. #所有槽位(16384个)分配完成

3.2.2.2.3 验证Redis集群状态

由于未设置masterauth认证密码，所以主从未建立起来，但是集群已经运行，所以需要在每个slave控制台使用config set设置masterauth密码，或者写在每个redis配置文件中，最好是在控制点设置密码之后再写入配置文件当中。

3.2.2.2.4 分别设置masterauth密码

每个服务器都要配！

[root@redis-node1 ~]#redis-cli -h 10.0.7.101 -a 123456 -p 6379
Warning: Using a password with '-a' option on the command line interface may not be safe.
10.0.7.101:6379> CONFIG SET masterauth 123456
OK

[root@redis-node2 ~]#redis-cli -h 10.0.7.102 -p 6379 -a 123456
Warning: Using a password with '-a' option on the command line interface may not be safe.
10.0.7.102:6379> CONFIG SET masterauth 123456
OK

3.2.2.2.5 确认slave状态为up

3.2.2.2.6 验证master状态

[root@redis-node1 ~]#redis-cli -h 10.0.7.101 -a 123456 -p 6379
Warning: Using a password with '-a' option on the command line interface may not be safe.
10.0.7.101:6379> INFO Replication
# Replication
role:master
connected_slaves:1
slave0:ip=10.0.7.105,port=6379,state=online,offset=252,lag=1
master_replid:f04228dba4daaee8aa968b6efb6db43310681300
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:252
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:134217728
repl_backlog_first_byte_offset:1
repl_backlog_histlen:252
10.0.7.101:6379>

3.2.2.2.7 验证集群状态

#可以写个脚本检测状态是否为ok
10.0.7.101:6379> CLUSTER info
cluster_state:ok
cluster_slots_assigned:16384
cluster_slots_ok:16384
cluster_slots_pfail:0
cluster_slots_fail:0
cluster_known_nodes:6
cluster_size:3
cluster_current_epoch:6
cluster_my_epoch:1
cluster_stats_messages_ping_sent:2581
cluster_stats_messages_pong_sent:2641
cluster_stats_messages_sent:5222
cluster_stats_messages_ping_received:2636
cluster_stats_messages_pong_received:2581
cluster_stats_messages_meet_received:5
cluster_stats_messages_received:5222

3.2.2.2.8 查看集群node对应关系

使用命令cluster nodes

10.0.7.101:6379> CLUSTER nodes
bd5d8feda4774007af2328c36617623fc6df4189 10.0.7.106:6379@16379 slave 43479c471461814c84d378e5449b13dda5a3f4b0 0 1597129902715 6 connected
f257f4d8a88e6c31a30ead06d0269bc521e7593c 10.0.7.104:6379@16379 slave 0a179fe5654e984023386f84f86bcfcb4764e4b8 0 1597129903722 4 connected
43479c471461814c84d378e5449b13dda5a3f4b0 10.0.7.102:6379@16379 master - 0 1597129903000 2 connected 5461-10922
8457957c0f7f42b3680820de6279cc18e89e50e2 10.0.7.105:6379@16379 slave aa43fa6f67cf60d4eb812ba9da0f0cb99ad3b0f7 0 1597129902000 5 connected
0a179fe5654e984023386f84f86bcfcb4764e4b8 10.0.7.103:6379@16379 master - 0 1597129901000 3 connected 10923-16383
aa43fa6f67cf60d4eb812ba9da0f0cb99ad3b0f7 10.0.7.101:6379@16379 myself,master - 0 1597129902000 1 connected 0-5460

3.2.2.2.9 验证集群写入key

10.0.7.101:6379> set key1 value1 #经过算法计算，当前key的槽位需要写入指定的node
(error) MOVED 9189 10.0.7.102:6379 #槽位不在当前node所以无法写入

10.0.7.102:6379> set key1 value1 #指定的node就可以写入
OK
10.0.7.102:6379> KEYS *
1) "key1"

10.0.7.101:6379> KEYS *
(empty list or set)
10.0.7.103:6379> KEYS *
(empty list or set)

3.2.2.2.10 集群状态验证与监控

Redis 4:

>>> Performing Cluster Check (using node 10.0.7.101:6379)
M: aa43fa6f67cf60d4eb812ba9da0f0cb99ad3b0f7 10.0.7.101:6379
   slots:0-5460 (5461 slots) master
   1 additional replica(s)
S: bd5d8feda4774007af2328c36617623fc6df4189 10.0.7.106:6379
   slots: (0 slots) slave
   replicates 43479c471461814c84d378e5449b13dda5a3f4b0
S: f257f4d8a88e6c31a30ead06d0269bc521e7593c 10.0.7.104:6379
   slots: (0 slots) slave
   replicates 0a179fe5654e984023386f84f86bcfcb4764e4b8
M: 43479c471461814c84d378e5449b13dda5a3f4b0 10.0.7.102:6379
   slots:5461-10922 (5462 slots) master
   1 additional replica(s)
S: 8457957c0f7f42b3680820de6279cc18e89e50e2 10.0.7.105:6379
   slots: (0 slots) slave
   replicates aa43fa6f67cf60d4eb812ba9da0f0cb99ad3b0f7
M: 0a179fe5654e984023386f84f86bcfcb4764e4b8 10.0.7.103:6379
   slots:10923-16383 (5461 slots) master
   1 additional replica(s)
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.

[root@redis-node1 ~]#redis-trib.rb info 10.0.7.102:6379
10.0.7.102:6379 (43479c47...) -> 0 keys | 5462 slots | 1 slaves.
10.0.7.103:6379 (0a179fe5...) -> 0 keys | 5461 slots | 1 slaves.
10.0.7.101:6379 (aa43fa6f...) -> 0 keys | 5461 slots | 1 slaves.
[OK] 0 keys in 3 masters.
0.00 keys per slot on average.

Redis 5：

# redis-cli -a 123456 --cluster check 192.168.7.101:6379

3.2.3 Redis cluster集群节点维护

集群运行时间长久之后，难免由于硬件故障、网络规划、业务增长等原因对已有集群进行相应的调整，比如增加Redis node节点、减少节点、节点迁移、更换服务器等。

增加节点和删除节点会涉及到已有的槽位重新分配及数据迁移。

3.2.3.1 集群维护之动态添加节点

增加Redis node节点，需要与之前的Redis node版本相同、配置一致，然后分别启动两台Redis node，因为一主一从。

案例

因公司业务发展迅猛，现有的三主三从redis cluster架构可能无法满足现有业务的并发写入需求，因此公司紧急采购一台服务器192.168.7.107，需要将其动态添加到集群当中其不能影响业务使用和数据丢失，则添加过程如下:

同步之前Redis node的配置文件到192.168.7.104 Redis编译安装目录，注意配置文件的监听 IP。

# scp redis.conf 192.168.7.104:/usr/local/redis/etc/
# scp redis_6380.conf 192.168.7.104:/usr/local/redis/etc/

分别启动redis服务

# systemctl daemon-reload
# systemctl restart redis
# /usr/local/redis/bin/redis-server /usr/local/redis/etc/redis_6380.conf

3.2.3.1.1 添加节点到集群

add-node new_host:new_port existing_host:existing_port
要添加的新redis节点IP和端口 添加到的集群中的master IP:端口，新的node节点加到集群之后默认是master节点，但是没有slots数据，需要重新分配。

Redis 4添加方式

把新的Redis 节点10.0.7.107添加到当前Redis集群当中。

[root@redis-node1 ~]# redis-trib.rb add-node 10.0.7.101:6379 192.168.7.107:6379

Redis 5添加方式

# redis-cli -a 123456 --cluster add-node 192.168.7.104:6379 192.168.7.101:6379

3.2.3.1.2 重新分配槽位

添加主机之后需要对添加至集群种的新主机重新分片否则其没有分片也就无法写入数据。
验证当前状态

[root@redis-node1 ~]# redis-trib.rb check 10.0.7.101:6379 #当前状态
[root@redis-node1 ~]# redis-trib.rb reshard 10.0.7.107:6379 #重新分片

Redis 5

Redis 5使用命令对新加的主机重新分配槽位:

[root@redis-s1 ~]# redis-cli -a 123456 --cluster reshard 192.168.7.104:6379
Warning: Using a password with '-a' or '-u' option on the command line interface may not
be safe.
>>> Performing Cluster Check (using node 192.168.7.104:6379)
M: 886338acd50c3015be68a760502b239f4509881c 192.168.7.104:6379
slots: (0 slots) master
M: 116c4c6de036fdbac5aaad25eb1a61ea262b64af 192.168.7.102:6379
slots:[5461-10922] (5462 slots) master
1 additional replica(s)
S: 2b6e5d9c3944d79a5b64a19e54e52f83d48438d6 192.168.7.101:6380
slots: (0 slots) slave
replicates 70de3821dde4701c647bd6c23b9dd3c5c9f24a62
S: 7186c6d03dd9a5e3be658f2d08e800bc55b04a09 192.168.7.102:6380
slots: (0 slots) slave
replicates f4cfc5cf821c0d855016488d6fbfb62c03a14fda
M: 70de3821dde4701c647bd6c23b9dd3c5c9f24a62 192.168.7.103:6379
slots:[10923-16383] (5461 slots) master
1 additional replica(s)
S: 7eda0bcf0c01bb7343313b81267c42dd1b26c8a6 192.168.7.103:6380
slots: (0 slots) slave
replicates 116c4c6de036fdbac5aaad25eb1a61ea262b64af
M: f4cfc5cf821c0d855016488d6fbfb62c03a14fda 192.168.7.101:6379
slots:[0-5460] (5461 slots) master
1 additional replica(s)
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.
How many slots do you want to move (from 1 to 16384)? 4096 #分配多少个槽位
192.168.7.104:6379
What is the receiving node ID? 886338acd50c3015be68a760502b239f4509881c #接收slot的服务器
ID，手动输入192.168.7.104的node ID
Please enter all the source node IDs.
Type 'all' to use all the nodes as source nodes for the hash slots.
Type 'done' once you entered all the source nodes IDs.
Source node #1: all #将哪些源主机的槽位分配给192.168.7.104:6379，all是自动在所有的redis node选择
划分，如果是从redis cluster删除主机可以使用此方式将主机上的槽位全部移动到别的redis主机
………………………………..
Moving slot 6823 from 116c4c6de036fdbac5aaad25eb1a61ea262b64af
Moving slot 6824 from 116c4c6de036fdbac5aaad25eb1a61ea262b64af
Moving slot 6825 from 116c4c6de036fdbac5aaad25eb1a61ea262b64af
Moving slot 6826 from 116c4c6de036fdbac5aaad25eb1a61ea262b64af
Moving slot 10923 from 70de3821dde4701c647bd6c23b9dd3c5c9f24a62
Moving slot 10924 from 70de3821dde4701c647bd6c23b9dd3c5c9f24a62
Moving slot 10925 from 70de3821dde4701c647bd6c23b9dd3c5c9f24a62
Moving slot 10926 from 70de3821dde4701c647bd6c23b9dd3c5c9f24a62
…………………………………..
Moving slot 1364 from f4cfc5cf821c0d855016488d6fbfb62c03a14fda
Do you want to proceed with the proposed reshard plan (yes/no)? yes #确认分配

3.2.3.1.3 验证重新分配槽位之后的集群状态

3.2.3.1.4 为新的master添加slave节点

需要再向当前的Redis集群中添加一个Redis单机服务器，用于解决当前192.168.7.107单机的潜在宕机问题，即实现响应的高可用功能。

命令格式

Redis 3/4

[root@redis-node1 ~]#redis-trib.rb add-node 10.0.7.108:6379 10.0.7.101:6379

Redis 5版本

把192.168.7.104:6380添加到集群中

\# redis-cli -a 123456 --cluster add-node 192.168.7.104:6380 192.168.7.104:6379

3.2.3.1.5 更改新节点更改状态为slave

需要手动将其指定为某个master的slave，否则其默认角色为master。

[root@redis-s1 ~]# redis-cli -h 192.168.7.104 -p 6380 -a 123456 #登录到新添加节点
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
192.168.7.104:6380> CLUSTER NODES #查看当前集群节点，找到目标master 的ID
127.0.0.1:6379> CLUSTER nodes
ab8f96219d6548957d97c9179b8a45a73292477d 10.0.7.107:6379@16379 master - 0 1597134912246 0 connected
bd5d8feda4774007af2328c36617623fc6df4189 10.0.7.106:6379@16379 slave 43479c471461814c84d378e5449b13dda5a3f4b0 0 1597134909213 6 connected
f257f4d8a88e6c31a30ead06d0269bc521e7593c 10.0.7.104:6379@16379 slave 0a179fe5654e984023386f84f86bcfcb4764e4b8 0 1597134909000 4 connected
43479c471461814c84d378e5449b13dda5a3f4b0 10.0.7.102:6379@16379 master - 0 1597134912000 2 connected 5461-10922
8457957c0f7f42b3680820de6279cc18e89e50e2 10.0.7.105:6379@16379 slave aa43fa6f67cf60d4eb812ba9da0f0cb99ad3b0f7 0 1597134911234 5 connected
0a179fe5654e984023386f84f86bcfcb4764e4b8 10.0.7.103:6379@16379 master - 0 1597134913254 3 connected 10923-16383
aa43fa6f67cf60d4eb812ba9da0f0cb99ad3b0f7 10.0.7.101:6379@16379 myself,master - 0 1597134911000 1 connected 0-5460
90fd8bb78baf2ef138d1291d253b3690d1dad48a 10.0.7.108:6379@16379 master - 0 1597134910000 7 connected


10.0.7.108:6379> CLUSTER REPLICATE ab8f96219d6548957d97c9179b8a45a73292477d #将其设置slave，命令格式为cluster replicate MASTERID
OK
10.0.7.108:6379> CLUSTER nodes #再次查看集群节点状态，验证节点是否已经更改为指定master 的slave
bd5d8feda4774007af2328c36617623fc6df4189 10.0.7.106:6379@16379 slave 43479c471461814c84d378e5449b13dda5a3f4b0 0 1597135175000 2 connected
8457957c0f7f42b3680820de6279cc18e89e50e2 10.0.7.105:6379@16379 slave aa43fa6f67cf60d4eb812ba9da0f0cb99ad3b0f7 0 1597135177248 1 connected
aa43fa6f67cf60d4eb812ba9da0f0cb99ad3b0f7 10.0.7.101:6379@16379 master - 0 1597135175000 1 connected 0-5460
90fd8bb78baf2ef138d1291d253b3690d1dad48a 10.0.7.108:6379@16379 myself,slave ab8f96219d6548957d97c9179b8a45a73292477d 0 1597135174000 7 connected
0a179fe5654e984023386f84f86bcfcb4764e4b8 10.0.7.103:6379@16379 master - 0 1597135176239 3 connected 10923-16383
43479c471461814c84d378e5449b13dda5a3f4b0 10.0.7.102:6379@16379 master - 0 1597135176000 2 connected 5461-10922
f257f4d8a88e6c31a30ead06d0269bc521e7593c 10.0.7.104:6379@16379 slave 0a179fe5654e984023386f84f86bcfcb4764e4b8 0 1597135175230 3 connected
ab8f96219d6548957d97c9179b8a45a73292477d 10.0.7.107:6379@16379 master - 0 1597135176000 0 connected

3.2.3.1.6 验证当前集群状态

确认每个master都有一个slave。

3.2.3.2 集群维护之动态删除节点

添加节点的时候是先添加node节点到集群，然后分配槽位，删除节点的操作与添加节点的操作正好相反，是先将被删除的Redis node上的槽位迁移到集群中的其他Redis node节点上，然后再将其删除，如果一个Redis node节点上的槽位没有被完全迁移，删除该node的时候会提示有数据且无法删除。

案例

由于192.168.7.101服务器使用年限已经超过三年，已经超过厂商质保期而且硬盘出现异常报警，经运维部架构师提交方案并同开发同事开会商议，决定将现有Redis集群的4台主服务器分别是
192.168.7.101/192.168.7.102/192.168.7.103/192.168.7.104中的192.168.7.101临时下线，三台服务器的并发写入性能足够支出未来1-2年的业务需求，则删除Redis node 192.168.7.101的操作如下

3.2.3.2.1 迁移master 的槽位之其他master

被迁移Redis master源服务器必须保证没有数据，否则迁移报错并会被强制中断。

[root@s1 ~]# redis-trib.rb reshard 192.168.7.101:6379
[root@s1 ~]# redis-trib.rb fix 192.168.7101:6379 #如果迁移失败使用此命令修复集群

连接到192.168.7.102将集群中的192.168.7.101服务器删除

[root@redis-s1 ~]# redis-cli -a 123456 --cluster reshard 192.168.7.102:6379
>>> Performing Cluster Check (using node 192.168.7.102:6379)
M: 2252cfc400df0e6719b12475ac703abe3d5dff6c 192.168.7.102:6379
slots:6827-10922 (4096 slots) master
1 additional replica(s)
S: 13f0a7ba8d3af16a6c43f48beffdf0889fea02e5 192.168.7.105:6379
slots: (0 slots) slave
replicates dfffc371085859f2858730e1f350e9167e287073
M: dfffc371085859f2858730e1f350e9167e287073 192.168.7.101:6379
slots:1365-5460 (4096 slots) master
1 additional replica(s)
S: 3b451ce5af25431cd3bc4e9a4f72da1f18585e66 192.168.7.108:6379
slots: (0 slots) slave
replicates 81dc72890cf75dd614ef45795b04cc3a58e50a10
S: 4a2dca6d93b3800077155c97bb89e1a0065dc5cc 192.168.7.104:6379
slots: (0 slots) slave
replicates 7da68934007d2da4dd9351f9fd3fecd14dc8e18c
M: 7da68934007d2da4dd9351f9fd3fecd14dc8e18c 192.168.7.103:6379
slots:12288-16383 (4096 slots) master
1 additional replica(s)
M: 81dc72890cf75dd614ef45795b04cc3a58e50a10 192.168.7.107:6379
slots:0-1364,5461-6826,10923-12287 (4096 slots) master
1 additional replica(s)
S: fb0dc651f774ff9844d4eda46152f674e60f1b22 192.168.7.106:6379
slots: (0 slots) slave
replicates 2252cfc400df0e6719b12475ac703abe3d5dff6c
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.
How many slots do you want to move (from 1 to 16384)? 4096 #迁移master上的多少个槽位
What is the receiving node ID? 2252cfc400df0e6719b12475ac703abe3d5dff6c #接收槽位的服务器ID
Please enter all the source node IDs.
Type 'all' to use all the nodes as source nodes for the hash slots.
Type 'done' once you entered all the source nodes IDs.
Source node #1: dfffc371085859f2858730e1f350e9167e287073 #从哪个服务器迁移4096个槽位
Source node #2: done #写done，表示没有其他master了
Moving slot 5457 from dfffc371085859f2858730e1f350e9167e287073
Moving slot 5458 from dfffc371085859f2858730e1f350e9167e287073
Moving slot 5459 from dfffc371085859f2858730e1f350e9167e287073
Moving slot 5460 from dfffc371085859f2858730e1f350e9167e287073
Do you want to proceed with the proposed reshard plan (yes/no)? yes #是否继续

迁移完成！

redis4做法：

[root@redis-node1 ~]#redis-trib.rb reshard 10.0.7.101:6379
>>> Performing Cluster Check (using node 10.0.7.101:6379)
M: aa43fa6f67cf60d4eb812ba9da0f0cb99ad3b0f7 10.0.7.101:6379
   slots:1093-5460 (4368 slots) master
   1 additional replica(s)
M: 0a179fe5654e984023386f84f86bcfcb4764e4b8 10.0.7.103:6379
   slots:12016-16383 (4368 slots) master
   1 additional replica(s)
S: 90fd8bb78baf2ef138d1291d253b3690d1dad48a 10.0.7.108:6379
   slots: (0 slots) slave
   replicates ab8f96219d6548957d97c9179b8a45a73292477d
S: bd5d8feda4774007af2328c36617623fc6df4189 10.0.7.106:6379
   slots: (0 slots) slave
   replicates 43479c471461814c84d378e5449b13dda5a3f4b0
M: ab8f96219d6548957d97c9179b8a45a73292477d 10.0.7.107:6379
   slots:0-1092,5461-6554,10923-12015 (3280 slots) master
   1 additional replica(s)
M: 6d863f14722aa0b27d3f31d7ce83dd8681a3bf38 10.0.7.109:6379
   slots: (0 slots) master
   0 additional replica(s)
S: f257f4d8a88e6c31a30ead06d0269bc521e7593c 10.0.7.104:6379
   slots: (0 slots) slave
   replicates 0a179fe5654e984023386f84f86bcfcb4764e4b8
M: 43479c471461814c84d378e5449b13dda5a3f4b0 10.0.7.102:6379
   slots:6555-10922 (4368 slots) master
   1 additional replica(s)
S: 8457957c0f7f42b3680820de6279cc18e89e50e2 10.0.7.105:6379
   slots: (0 slots) slave
   replicates aa43fa6f67cf60d4eb812ba9da0f0cb99ad3b0f7
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.
How many slots do you want to move (from 1 to 16384)? 3280
What is the receiving node ID? 6d863f14722aa0b27d3f31d7ce83dd8681a3bf38
Please enter all the source node IDs.
  Type 'all' to use all the nodes as source nodes for the hash slots.
  Type 'done' once you entered all the source nodes IDs.
Source node #1:ab8f96219d6548957d97c9179b8a45a73292477d
Source node #2:done
    Moving slot 12012 from ab8f96219d6548957d97c9179b8a45a73292477d
    Moving slot 12013 from ab8f96219d6548957d97c9179b8a45a73292477d
    Moving slot 12014 from ab8f96219d6548957d97c9179b8a45a73292477d
    Moving slot 12015 from ab8f96219d6548957d97c9179b8a45a73292477d
Do you want to proceed with the proposed reshard plan (yes/no)? yes

[root@redis-node1 ~]#redis-trib.rb info 10.0.7.101:6379
10.0.7.101:6379 (aa43fa6f...) -> 0 keys | 4368 slots | 1 slaves.
10.0.7.103:6379 (0a179fe5...) -> 0 keys | 4368 slots | 1 slaves.
10.0.7.107:6379 (ab8f9621...) -> 0 keys | 0 slots | 0 slaves.
10.0.7.109:6379 (6d863f14...) -> 0 keys | 3280 slots | 1 slaves.
10.0.7.102:6379 (43479c47...) -> 0 keys | 4368 slots | 1 slaves.
[OK] 0 keys in 5 masters.
0.00 keys per slot on average.

3.2.3.2.2 验证槽位迁移完成

3.2.3.2.4 从集群删除服务器

虽然槽位已经迁移完成，但是服务器IP信息还在集群当中，因此还需要将IP信息从集群删除

#删除master

Redis 3/4

[root@redis-node1 ~]#redis-trib.rb del-node 10.0.7.101:6379 ab8f96219d6548957d97c9179b8a45a73292477d
>>> Removing node ab8f96219d6548957d97c9179b8a45a73292477d from cluster 10.0.7.101:6379
>>> Sending CLUSTER FORGET messages to the cluster...
>>> SHUTDOWN the node.

Redis 5

[root@redis-s1 ~]# redis-cli -a 123456 --cluster del-node 192.168.7.102:6379
f4cfc5cf821c0d855016488d6fbfb62c03a14fda
Warning: Using a password with '-a' or '-u' option on the command line interface may
not be safe.
>>> Removing node f4cfc5cf821c0d855016488d6fbfb62c03a14fda from cluster
192.168.7.101:6379
>>> Sending CLUSTER FORGET messages to the cluster...
>>> SHUTDOWN the node.

3.2.3.2.5 验证node 是否删除

验证并确认192.168.7.101:6379已经从Redis集群中删除。

注： 192.168.7.101被删除之后，其之前的slave自动成为了Redis集群中其他master的slave，此节点如果不需要也可以一并删除。

3.2.3.2.6 验证master与slave

确认整个Redis cluster集群中，每个master至少有一个slave，可以有多个，但是至少要有一个提供数据备份和服务高可用。

3.2.3.2.7 验证集群Master与Slave对应关系

Redis Slave节点一定不能个master在一个服务器，必须为跨主机交叉备份模式，避免主机故障后主备全部挂掉，如果出现Redis Slave与Redis master在同一台Redis node的情况，则需要安装以上步骤重新进行slave分配，直到不相互交叉备份为止。

3.2.3.3 集群维护之模拟Master宕机

目前的架构为三主三从，互为跨主机master slave模式，测试master 宕机之后是否会自动切换至slave。

3.2.3.3.1 测试数据写入

测试在master写入数据，并在其对应的slave验证数据

10.0.7.101:6379> set key2 value2
OK

10.0.7.101:6379> get key2
"value1"

3.2.3.3.2 slave验证数据

10.0.7.105:6379> keys *
1) "key2"
10.0.7.105:6379> get key2
(error) MOVED 4998 10.0.7.101:6379 #slave不提供读写，只提供数据备份即master选举

3.2.3.3.3 停止master并验证故障转移

Redis Master服务停止之后，其对应的slave会被选举为master继续处理数据的读写操作。

[root@redis-node1 ~]#systemctl stop redis

3.2.3.3.4 验证slave 日志

[root@redis-node5 ~]#tail -f /apps/redis/logs/redis_6379.log #需要相应的数秒故障转移时间

3.2.3.3.5 验证slave当前状态

3.2.3.3.6 验证数据读写

确认slave 192.168.7.103:6380切换为master之后可以继续为业务提供读写业务且数据没有丢失。

10.0.7.105:6379> keys *
1) "key2"
10.0.7.105:6379> set key6 value6
OK

10.0.7.105:6379> get key2
"value2"

10.0.7.105:6379> get key6
"value6"

注：服务恢复之后重新验证各master的slave。

3.2.3.4 集群维护之导入现有Redis数据

导入数据需要redis cluster不能与被导入的数据有重复的key名称，否则导入不成功或中断。

案例

公司将redis cluster部署完成之后，需要将之前的数据导入之Redis cluster集群，但是由于Redis cluster使用的分片保存key的机制，因此使用传统的AOF文件或RDB快照无法满足需求，因此需要使用集群数据导入命令完成。

3.2.3.4.1 基础环境准备

导入数据之前需要关闭各redis 服务器的密码，包括集群中的各node和源Redis server，避免认证带来的环境不一致从而无法导入，可以加参数–cluster-replace 强制替换Redis cluster已有的key。

关闭各Redis密码认证:

[root@redis-s1 ~]# redis-cli -h 192.168.7.102 -p 6379 -a 123456
Warning: Using a password with '-a' or '-u' option on the command line interface may not
be safe.
192.168.7.102:6379> CONFIG SET requirepass ""
OK
[root@redis-s1 ~]# redis-cli -h 192.168.7.102 -p 6380 -a 123456
Warning: Using a password with '-a' or '-u' option on the command line interface may not
be safe.
192.168.7.102:6380> CONFIG SET requirepass ""
OK

[root@redis-s1 ~]# redis-cli -h 192.168.7.103 -p 6379 -a 123456
Warning: Using a password with '-a' or '-u' option on the command line interface may not
be safe.
192.168.7.103:6379> CONFIG SET requirepass ""
OK
[root@redis-s1 ~]# redis-cli -h 192.168.7.103 -p 6380 -a 123456
Warning: Using a password with '-a' or '-u' option on the command line interface may not
be safe.
192.168.7.103:6380> CONFIG SET requirepass ""
OK

[root@redis-s1 ~]# redis-cli -h 192.168.7.104 -p 6379 -a 123456
Warning: Using a password with '-a' or '-u' option on the command line interface may not
be safe.
192.168.7.104:6379> CONFIG SET requirepass ""
OK
192.168.7.104:6379> exit
[root@redis-s1 ~]# redis-cli -h 192.168.7.104 -p 6380 -a 123456
Warning: Using a password with '-a' or '-u' option on the command line interface may not
be safe.
192.168.7.104:6380> CONFIG SET requirepass ""
OK
192.168.7.104:6379> exit

3.2.3.4.2 执行数据导入

将源Redis server的数据直接导入之redis cluster。

命令格式

Redis 3/4：

[root@s1 ~]# redis-trib.rb import --from 172.18.200.107:6382 --replace
172.18.200.107:6379

Redis 5：

#redis-cli --cluster import 集群服务器IP:PORT --cluster-from 外部Redis node-IP:PORT --
cluster-copy --cluster-replace
[root@redis-s2 redis]# redis-cli --cluster import 192.168.7.103:6379 --cluster-from
192.168.7.101:6379 --cluster-copy

3.2.3.4.3 Redis cluster验证数据

3.2.4 redis扩展集群方案

除了Redis 官方自带的Redis cluster集群之外，还有一些开源的集群解决方案可供参考使用。

推荐CPU

3.2.4.1 codis

Codis 是一个分布式 Redis 解决方案, 对于上层的应用来说, 连接到 Codis Proxy 和连接原生的 Redis Server 没有显著区别 (不支持的命令列表), 上层应用可以像使用单机的 Redis 一样使用, Codis 底层会处理请求的转发, 不停机的数据迁移等工作, 所有后边的一切事情, 对于前面的客户端来说是透明的, 可以简单的认为后边连接的是一个内存无限大的 Redis 服务。

codis-proxy相当于redis，即连接codis-proxy和连接redis是没有任何区别的，codis-proxy无状态，不负责记录是否在哪保存，数据在zookeeper记录，即codis proxy向zookeeper查询key的记录位置，proxy 将请求转发到一个组进行处理，一个组里面有一个master和一个或者多个slave组成，默认有1024个槽位，redis cluster 默认有16384个槽位，其把不同的槽位的内容放在不同的group。

Github 地址 https://github.com/CodisLabs/codis/

architecture

3.2.4.2 twemproxy

由Twemproxy双向代理客户端实现分片，即代替用户将数据分片并到不同的后端服务器进行读写，其还支持memcached，可以为proxy配置算法，缺点为twemproxy是瓶颈，不支持数据迁移。

Github 地址 https://github.com/twitter/twemproxy

四 memcached

Memcache官网 http://memcached.org/

memcache本身没有像redis所具备的数据持久化功能，比如RDB和AOF都没有，但是可以通过做集群同步的方式，让各memcache服务器的数据进行同步，从而实现数据的一致性，即保证各memcache的数据是一样的，即使有任何一台memcache发生故障，只要集群种有一台memcache可用就不会出现数据丢失，当其他memcache重新加入到集群的时候可以自动从有数据的memcache当中自动获取数据并提供服务。

Memcache借助了操作系统的libevent工具做高效的读写。libevent是个程序库，它将Linux的epoll、BSD类操作系统的kqueue等事件处理功能封装成统一的接口。即使对服务器的连接数增加，也能发挥高性能。memcached使用这个libevent库，因此能在Linux、BSD、Solaris等操作系统上发挥其高性能。

Memcache支持最大的内存存储对象为1M，超过1M的数据可以使用客户端压缩或拆分报包放到多个key中，比较大的数据在进行读取的时候需要消耗的时间比较长，memcache最适合保存用户的session实现session共享，Memcached存储数据时, Memcached会去申请1MB的内存, 把该块内存称为一个slab, 也称为一个page。

memcached具有多种语言的客户端开发包，包括 Perl/PHP/JAVA/C/Python/Ruby/C#/

4.1 单机部署

4.1.1 yum安装与启动

通过yum 安装是相对简单的安装方式

[root@redis-node9 ~]#yum install memcached -y
[root@redis-node9 ~]#vim /etc/sysconfig/memcached
PORT="11211" 		#监听端口
USER="memcached" 	#启动用户
MAXCONN="1024" 		#最大连接数，视情况改
CACHESIZE="1024" 	#最大使用内存
OPTIONS="" 			#其他选项

4.1.2 python操作memcache

#!/usr/bin/env python
#coding:utf-8
#Author:Zhang ShiJie
import memcache
m = memcache.Client(['172.18.200.106:11211'], debug=True)
for i in range(100):
	m.set("key%d" % i,"v%d" % i)
	ret = m.get('key%d' % i)
	print ret

4.1.2 编译安装

\# yum install libevent libevent-devel –y
[root@redis-node10 src]#pwd
/usr/local/src
[root@redis-node10 src]#wget http://www.memcached.org/files/memcached-1.6.6.tar.gz
[root@redis-node10 src]#tar xvf memcached-1.6.6.tar.gz
[root@redis-node10 src]#cd memcached-1.6.6/
[root@redis-node10 memcached-1.6.6]#./configure --prefix=/apps/memcached
[root@redis-node10 memcached-1.6.6]#make && make install
#启动memcached
# /usr/local/memcache/bin/memcached -u memcached -p 11211 -m 2048 -c 65536 &

#启动memcached
\# /usr/local/memcache/bin/memcached -u memcached -p 11211 -m 2048 -c 65536 &

4.2 memcached集群部署架构

4.2.1 基于magent的部署架构

该部署方式依赖于magent实现高可用，应用端通过负载服务器连接到magent，然后再由magent代理用户应用请求到memcached处理，底层的memcached为双主结构会自动同步数据，本部署方式存在magent单点问题因此需要两个magent做高可用。

4.2.2 Repcached实现原理

在 master上可以通过 -X指定 replication port，在 slave上通过 -x/-X找到 master并 connect上去，事实上，如果同时指定了 -x/-X， repcached一定会尝试连接，但如果连接失败，它就会用 -X参数来自己 listen（成为master）；如果 master坏掉， slave侦测到连接断了，它会自动 listen而成为 master；而如果 slave坏掉，master也会侦测到连接断，它就会重新 listen等待新的 slave加入。

从这方案的技术实现来看，其实它是一个单 master单 slave的方案，但它的 master/slave都是可读写的，而且可以相互同步，所以从功能上看，也可以认为它是双机 master-master方案。

4.2.3 简化后的部署架构

magent已经有很长时间没有更新，因此可以不再使用magent，直接通过负载均衡连接之memcached，任然有两台memcached做高可用，memcached会自动同步数据保持数据一致性，即使一台memcached故障也不影响业务正常运行，故障的memcached修复上线后再自动从另外一台同步数据即可保持数据一致性。

4.2.4 部署repcached

http://repcached.sourceforge.net/

[root@s6 src]# yum install libevent libevent-devel
[root@s6 src]# wget https://sourceforge.net/projects/repcached/files/repcached/2.2.1-1.2.8/memcached-1.2.8-repcached-2.2.1.tar.gz
[root@centos7mini src]#tar xvf memcached-1.2.8-repcached-2.2.1.tar.gz
[root@centos7mini src]#cd memcached-1.2.8-repcached-2.2.1/
[root@centos7mini memcached-1.2.8-repcached-2.2.1]#./configure --prefix=/apps/memcached --enable-replication
[root@s6 memcached-1.2.8-repcached-2.2.1]# make #报错如下

解决办法：

[root@centos7mini memcached-1.2.8-repcached-2.2.1]#vim memcached.c
56 #ifndef IOV_MAX
57 #if defined(__FreeBSD__) || defined(__APPLE__)
58 # define IOV_MAX 1024
59 #endif
60 #endif
改为如下内容：
55 /* FreeBSD 4.x doesn't have IOV_MAX exposed. */
56 #ifndef IOV_MAX
57 # define IOV_MAX 1024
58 #endif

再次编译安装：

[root@centos7mini memcached-1.2.8-repcached-2.2.1]#make && make install

4.2.5 验证是否可执行

[root@centos7mini ~]#/apps/memcached/bin/memcached -h
memcached 1.2.8
repcached 2.2.1
-p <num>      TCP port number to listen on (default: 11211)
-U <num>      UDP port number to listen on (default: 11211, 0 is off)
-s <file>     unix socket path to listen on (disables network support)
-a <mask>     access mask for unix socket, in octal (default 0700)
-l <ip_addr>  interface to listen on, default is INDRR_ANY
-d            run as a daemon
-r            maximize core file limit
-u <username> assume identity of <username> (only when run as root)
-m <num>      max memory to use for items in megabytes, default is 64 MB
-M            return error on memory exhausted (rather than removing items)
-c <num>      max simultaneous connections, default is 1024
-k            lock down all paged memory.  Note that there is a
              limit on how much memory you may lock.  Trying to
              allocate more than that would fail, so be sure you
              set the limit correctly for the user you started
              the daemon with (not for -u <username> user;
              under sh this is done with 'ulimit -S -l NUM_KB').
-v            verbose (print errors/warnings while in event loop)
-vv           very verbose (also print client commands/reponses)
-h            print this help and exit
-i            print memcached and libevent license
-P <file>     save PID in <file>, only used with -d option
-f <factor>   chunk size growth factor, default 1.25
-n <bytes>    minimum space allocated for key+value+flags, default 48
-R            Maximum number of requests per event
              limits the number of requests process for a given con nection
              to prevent starvation.  default 20
-b            Set the backlog queue limit (default 1024)
-x <ip_addr>  hostname or IP address of peer repcached
-X <num:num>  TCP port number for replication. <listen:connect> (default: 11212)

4.3 启动memcache

4.3.1 server 1相关操作

[root@redis-node6 ~]#/apps/memcached/bin/memcached -d -m 2048 -p 11211 -u root -c 2048 -x 10.0.7.107

4.2.2 server 2相关操作

[root@centos7mini ~]#/apps/memcached/bin/memcached -d -m 2048 -p 11211 -u root -c 2048 -x 10.0.7.106

4.3.3 连接到memcache验证数据

4.3.3.1 shell命令

[root@redis-node9 ~]#telnet 10.0.7.107 11211
Trying 10.0.7.107...
Connected to 10.0.7.107.
Escape character is '^]'.
set name 0 0 4  #key 的名为name，且永不超时
yuan
STORED  #符合长度后自动保存
get name
VALUE name 0 4
yuan
END
quit
Connection closed by foreign host.

[root@redis-node9 ~]#telnet 10.0.7.106 11211 #到另外一台memcached服务器验证是否有数据
Trying 10.0.7.106...
Connected to 10.0.7.106.
Escape character is '^]'.苏
get name   #数据已经自动同步
VALUE name 0 4
yuan
END苏
quit
Connection closed by foreign host.

4.2.3.2 python 脚本连接memcached

\#!/usr/bin/env python
\#coding:utf-8
\#Author:Zhang ShiJie
import memcache
m = memcache.Client(['172.18.200.106:11211'], debug=True)
for i in range(100):
	m.set("key%d" % i,"v%d" % i)
	ret = m.get('key%d' % i)
	print ret

特洛伊CAR

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
33.Redis详解

一缓存概念缓存是为了调节速度不一致的两个或多个不同的物质的速度，在中间对速度较快的一方起到一个加速访问速度较慢的一方的作用，比如CPU的一级、二级缓存是保存了CPU最近经常访问的数据，内存是保存CPU经常访问硬盘的数据，而且硬盘也有大小不一的缓存，甚至是物理服务器的raid 卡有也缓存，都是为了起到加速CPU 访问硬盘数据的目的，因为CPU的速度太快了，CPU需要的数据由于硬盘往往不能在短时间内满足CPU的需求，因此PCU缓存、内存、Raid 卡缓存以及硬盘缓存就在一定程度上满足了CPU的数据需求，即C
复制链接

扫一扫