NoSQL概念
什么是NoSQL
NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用难题，NoSQL是key-value形式存储，和传统的关系型数据库不一样,不一定遵循传统数据库的一些基本要求
随着WEB2.0的兴起，关系型数据库管理系统（RDBMS）中的数据越来越多，单独的关系型数据库的IO逐渐成为系统架构的瓶颈，非关系数据库的出现正是为了解决这种问题。
特点
非关系型的、分布式、开源的
水平可扩展的处理超大量数据
击碎了性能瓶颈
对数据高并发读写
对海量数据的高效率存储和访问
NoSQL分类
键值数据库（key-value）
Tokyo Redis Cabinet
内容缓存，主要用于处理大量数据的高访问负载，也用于一 些日志系统
文档型数据库
MongoDb
Web应用与Key-Value类似，Value是结构化的，不同的是数据库能够了解Value的内容
列存储数据库
HBase,
主要用于分布式的文件系统
图形(Graph)数据库
社交网络
Neo4J
Redis
简介
存储类型
Redis是一个开源的，先进的key-value存储。它通常被称为数据结构服务器，因为键可以包含string（字符串）、hash（哈希）、list（链表）、set（集合）和zset（sorted-set--有序集合）。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作。
存储方式
因为Redis会将所有的数据都放在内存中,所以他的读写性能非常惊人
Redis和Memcached类似，它支持存储的value类型相对更多，与memcached一样，为了保证效率，数据都是缓存在内存中，区别是Redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件
Redis特性
速度快
Redis所有的数据都存放在内存中
Redis使用C语言实现
Redis使用单线程架构
基于键值对的数据结构服务器
五种数据结构:字符串,哈希,列表,集合,有序集合
丰富的功能
提供了键过期功能,可以实现缓存
提供了发布订阅功能,可以实现消息系统
提供了pipeline功能,客户端可以将一批命令一次性传到Redis,减少了网络开销
简单稳定
使用单线程模型法,使Redis服务端处理模型变得简单.
不依赖操作系统的中的类库
客户端语言多
java,PHP,python,C,C++等
持久化
RDB和AOF模式提供持久化功能
主从复制
高可用和分布式
哨兵
集群
Redis应用场景
缓存session会话
缓存用户信息
热度排名排行榜
发布时间排行榜
天然支持计数器
帖子浏览数
视频播放次数
商品浏览数
社交网络-集合
共同好友/喜好,推送
消息队列系统-发布订阅
配合elk实现日志收集
redis作缓存架构图
Redis安装部署
yum安装
下载阿里镜像源
wget -O /etc/yum.repos.d/CentOS-Base.repo https://mirrors.aliyun.com/repo/Centos-7.repo
sed -i -e '/mirrors.cloud.aliyuncs.com/d' -e '/mirrors.aliyuncs.com/d' /etc/yum.repos.d/CentOS-Base.repo
wget -O /etc/yum.repos.d/epel.repo http://mirrors.aliyun.com/repo/epel-7.repo
yum makecache
yum -y install redis
源码包安装
安装gcc
yum -y install gcc
下载安装包
wget http://download.redis.io/releases/redis-3.2.12.tar.gz
解压
tar xf redis-3.2.12.tar.gz -C /usr/src
ln -s /usr/src/redis-3.2.12/ /usr/local/redis
编译安装
cd /usr/local/redis/
make
make PREFIX=/usr/local/redis install
如果没有指定安装位置PREFIX=/usr/local/redis，则make install会把redis安装到/usr/local/bin/目录下
将配置文件复制到/usr/local/redies/etc，便于管理
mkdir /usr/local/redis/etc
cp -a ./redis.conf /usr/local/redis/etc/
修改配置文件
vim /usr/local/redis/etc/redis.conf
创建命令连接文件
ln -s /usr/local/redis/bin/* /usr/local/bin/
查看配置文件非空行和非注释行
egrep -v "^$|^#" redis.conf|head
启动服务
redis-server /usr/local/redis/etc/redis.conf
必须指定配置文件位置，否则会提示警告
检测netstat -anpt
6739端口开启即可证明成功
客户端连接redis
redies-cli
客户端停止链接停止
redies-cli shutdown
pkill -9 redis
配置文件详解
绑定本地ip地址
bind 127.0.0.1 192.168.1.10
protected-mode no
是否开启保护模式，默认开启。要是配置里没有指定bind和密码,开启该参数后，redis只会本地进行访问，拒绝外部访问。一般修改为NO
port 6379
绑定端口
timeout 0
客户端闲置多长时间后关闭连接，如果指定为0，表示关闭该功能
tcp-keepalive 300
TCP保持时间
daemonize yes
修改为yes,以守护进程模式运行
pidfile /var/run/redis_6379.pid
指定PID文件位置
loglevel notice
指定日志级别
logfile /var/log/redis/redis.log
指定日志文件位置
databases16
指定redis默认使用的数据库数量，默认是db0
save 900 1
save 300 10
save 60 10000
900秒有一个key变化，就做一个保存
300秒有10个key变化，就做一个保存
60秒有10000个key变化就做一个保存
rdbcompression yes
是否对rdb持久化文件进行压缩，会消耗一定的CPU资源
rdbchecksum yes
是否使用CRC64对rdb持久化文件进行检测
dbfilename dump.rdb
rdb持久化文件名称
dir /var/lib/redis
rdb持久化位置Redis客户端基本操作
全局操作命令
redis-cli
客户端登陆命令
常用选项:
-h指定主机地址
-p指定端口号
-a指定密码
-n指定登陆的数据库，默认登陆到db0
keys *
查看所有的键，十分危险的命令
dbsize
查看键的总数，计算键总数时不会遍历所有键,而是直接获取Redis内置的键总数变量.
exists 键名
查看键是否存在，存在返回1，不存在返回0
expire key seconds
设置键过期时间
ttl key
查看键过期时间，-1键没有设置过期时间，-2没有该键
del key
删除指定的键
type key
判断键的类型
persist 键名
取消键过期时间
select 数据库编号
切换数据库，默认在db0
string类型及操作
string是最简单的类型，一个key对应一个value，string类型是二进制安全的。redis的string可以包含任何数据
命令：
set：设置key对应的值为string类型
set name 张三
setnx：设置key对应的值为string类型，如果key已经存在，返回0且不修改原来的值，nx是not exist的意思
get：获取key对应的string值，如果key不存在返回nil
mset&mget同时设置和获取多个键值对
INCR命令将字符串值解析成整型.将其加1,最后结果保存为新的字符串
incrby：对key的值做加（指定值）操作，并返回新的值
也可以使用decr和decrby减少
del：删除一个已创建的key
hash类型及操作
Redis hash是一个string类型的field（字段）和value的映射表；相较于将对象的每个字段存成单个string类型，将一个对象存储在hash类型中会占用更少的内存，并且可以更方便的存取整个对象。
可以理解为先创建一个表，表可以包含多个键值对
hset：设置hash field 为指定值，如果key不存在，则先创建；hget：获取（同样只能设定和获取单个域）
hmset，hmget设置和获取多个域
hdel：删除指定表中的某一个键值对
hgetall 表名：列出表中的所有键值对
列表list类型及操作
list是一个链表结构，主要功能是push、pop、获取一个范围内的所有值等等，操作中key理解为链表的名字，一个key可以有多个值，而不是一一对应
结构图
LPUSH：在key对应list的头部添加字符串元素
LRANGE：从指定链表中获取指定范围的元素，0 -1：范围代表第一个到最后一个元素，意为从头到尾
lpop、rpop：指定从链表中头部或尾部删除
添加删除模型
lrem key count value删除键中指定的值，count是删除次数
Set类型及操作
set是集合，他是string类型的无序集合。Set是通过hash table实现的，对集、交集、差集。通过这些操作我们可以实现社交网站中的好友推荐和blog的tag功能。集合不允许有重复值
sadd：添加一个或多个元素到集合中
smembers：获取集合里面所有的元素
srem：从集合中删除指定的一个或多个元素
spop：随机从集合中删除一个元素，并返回
scard：获取集合里面的元素个数
sdiff：返回集合1与集合2的差集。以集合1为主
zset类型及操作
zset是set的一个升级版本，它在set的基础上增加了一个顺序属性，这一属性在添加修改元素的时候可以指定
排序规则
zadd：向一个指定的有序集合中添加元素，每一个元素会对应的有一个分数。分数的值必须是一个表示数字的字符串。
zadd zset 2 zhangsan 1 lisi 1 wangwu
zrange：返回有序集合中，指定区间内的成员。其中成员按照score（分数）值从小到大排序。具有相同score值的成员按照字典顺序（ASCII）来排列。
zcard：返回有序集合元素的个数
zrem：删除有序集合中指定的值
其他相关命令
keys：按照键名查找指定的键。支持通配符（*?等）
exists：确认一个键是否存在（0表示不存在1表示存在）
expire：设置一个键（已存在）的过期时间，如果键已经过期，将会被自动删除
ttl：以秒为单位，返回指定键的剩余有效时间
key 不存在时，返回-2
key 存在但没有设置剩余生存时间时，返回-1
select：选择一个数据库，默认连接的数据库是0，可以支持共16个数据库。在配置文件中，通过databases 16 关键字定义
选择数据库1
move：将当前数据库的键移动到指定的数据库中
将jihe移到数据库1中
type：返回键的类型
dbsize：返回当前库中键的数量（所有类型）
save：保存所有的数据，会阻塞所有的客户端的请求，很少在生产环境直接使用
获取服务器的详细信息
config get：获取redis服务器配置文件中的参数。支持通配符
flushdb：删除当前数据库中所有的数据
flushall：删除所有数据库中的所有数据
Redis配置高级应用
安全
密码防护
redis默认开启了保护模式，只允许本地回环地址登录并访问数据库；
禁止protected-mode
protected-mode yes/no（保护模式，是否只允许本地访问）
配置文件中增加requirepass{password}，登陆时需要验证:
vim /usr/local/redis/etc/redis.conf
重启
redis-cli shutdown
redis-server /usr/local/redis/etc/redis.conf
登陆测试
redis-cli登录后认证
可以直接选择登陆时认证
安全加固
1、确定Redis部署位置，确定访问人员权限设置。
2、确保环境安全配置正确，不允许其他部署干扰Redis。
3、同时启用TLS与密码身份验证。
4、密切注意命令执行情况，如debugsegfault和monitor。
5、正确网络分段。防止Redis应暴露在其他不受信任的环境中。
6、不要在前端开发中使用Redis。
任务队列模式
生产者消费者模型
在生活中，其实有很多的例子，都类似消息队列。比如：工厂生产出来的面包，交给超市，商场来出售，客户通过超市，商场来买面包，客户不会针对某一个工厂去选择，只管从超市买出来，工厂也不会管是哪一个客户买了面包，只管生产出来之后，交给超市、商场来处理。
消息队列（MessageQueue）是一种应用间的通信方式，消息发送后可以立即返回，有消息系统来确保信息的可靠专递，消息生产者只管把消息发布到MQ中而不管谁来取，消息消费者只管从MQ中取消息而不管谁发布的，这样发布者和使用者都不用知道对方的存在。
为什么要使用消息队列
消息队列是一种异步的工作机制，通过消息队列，来实现业务的解耦，最终数据的一致性，广播，错峰流控等等，从而完成业务的逻辑。
生产者将需要处理的任务放入任务队列中，而消费者则不断地从任务独立中读入任务信息并执行。
四大特点：解耦、提速、广播、削峰
常见的消息队列产品
1）rabbit-MQ（最初起源于金融系统，用于分布式系统中存储转发消息，OpenStack）
2）Zero-MQ（SaltStack）
3）Kafka（JAVA）
4）redis（key:value非关系型数据库，缓存，消息队列）
redis具备任务队列模式
发布订阅模式(publish-subscriber)
1）Subscriber：收音机，可以收到多个频道，并以队列方式显示
2）Publisher：电台，可以往不同的FM频道中发消息
3）Channel：不同频率的FM频道
模式：
一个发布者多个订阅者
主要应用：通知、公告
多发布者一个订阅者
主要应用：排行榜、投票、计数。
多发布者多订阅者模型
主要应用：群聊、聊天。
实验：
订阅qq频道，此时会进入阻塞状态，等待发布者发送信息:
开启一个ssh渠道
客户端在执行订阅命令之后进入了订阅状态，只能接收subscribe、psubscribe、unsubscribe、punsubscribe四个命令。开启的订阅客户端，无法收到该频道之前的消息，因为Redis不会对发布的消息进行持久化。和很多专业的消息队列系统（例如Kafka、RocketMQ、RabbitMQ）相比，Redis的发布订阅略显粗糙。
数据持久化
redis是一个支持持久化的内存数据库，也就是说需要经常将内存中的数据同步到磁盘来保证持久化。
RDB(默认模式)
RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储。是默认的持久化方式。这种方式是将内存中数据以快照的方式写入到二进制文件中，默认的文件名为dump.rdb。这种持久化方式被称为快照snapshotting（快照）
触发RDB持久化可以分为手动触发和自动触发
手动触发机制:
save命令：阻塞当前Redis服务器，直到RDB过程完成为止，对于内存比较大的实例会造成长时间的阻塞，不建议使用；
bgsave命令：redis进程执行fork创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段。
自动触发模式
核心配置：
在配置文件中使用save相关的配置，自动触发bgsave
过了900秒并且有1个key发生了改变就会触发save动作
过了300秒并且有10个key发生了改变就会触发save动作
过了60秒并且至少有10000个key发生了改变也会触发save动作
从节点执行全量复制操作时，主节点自动执行bgsave生成RDB文件并发送给从节点
默认执行shutdown命令时，如果没有开启AOF则自动执行bgsave;
bgsave触发RDB持久化流程:
流程图：
1.执行bgsave命令，Redis父进程判断当前是否有子进程正在执行，如RDB/AOF子进程，如果存在bgsave返回；
2.父进程执行fork操作创建子进程，fork操作过程中父进程会阻塞，通过infostats命令查看latest_fork_usec选项，可以获取最近一个fork操作的耗时，单位为微秒；
3.父进程fork完成后，bgsave命令会返回“Background saving started”信息并不再阻塞父进程，可以继续响应其他命令；
4.子进程创建RDB文件，根据父进程内存生成临时快照文件，完成后对原有文件进行原子替换。执行lastsave命令可以获取最后一次生成RDB的时间，对应info统计的rdb_last_save_time选项（时间戳显示）；
查看执行状态
优点和缺点
RDB持久化优点:
RDB是一种表示某个即时点的Redis数据的紧凑文件。
RDB非常适合于灾难恢复，作为一个紧凑的单一文件，可以被传输到远程的数据中心。
RDB最大化了Redis的性能，因为Redis父进程持久化时唯一需要做的是启动(fork)一个子进程，由子进程完成所有剩余工作。父进程实例不需要执行像磁盘IO这样的操作。
RDB在重启保存了大数据集的实例时比AOF要快。
概括：速度快，适合于用作备份，主从复制也是基于RDB持久化功能实现的。
RDB持久化缺点
RDB快照是一次全量备份，存储的是内存数据的二进制序列化形式，存储上非常紧凑。当进行快照持久化时，会开启一个子进程专门负责快照持久化，子进程会拥有父进程的内存数据，父进程修改内存子进程不会反应出来，所以在快照持久化期间修改的数据不会被保存，可能丢失数据。
概括：会有数据丢失、导致服务停止几秒
注：
在redis.conf文件中dir ./定义了数据库文件的存放位置，默认是当前目录。所以每次重启redis服务所在的位置不同，将会生成新的dump.rdb文件；建议服务器搭建完成时先修改快照文件保存位置
vim /etc/redis.conf
AOF（append-only file）模式
AOF（appendonly file）只追加文件，记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据集。AOF文件中的命令全部以Redis协议的格式来保存，新命令会被追加到文件的末尾。
使用AOF 会让你的Redis更加耐久: 你可以使用不同的持久化策略：每次写的时候备份、每秒备份、无备份。使用默认的每秒备份策略,Redis的性能依然很好(备份是由后台线程进行处理的,主线程会尽力处理客户端请求),一旦出现故障，你最多丢失1秒的数据。
AOF工作流程
1、所有写入命令会追加到aof_buf(缓冲区)中；
2、AOF缓冲区根据对应策略写入本地磁盘；
3、随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩的目的；
4、当Redis服务器重启后，可以加载AOF文件进行数据恢复。
AOF为什么把命令追加到aof_buf,而不直接写入磁盘?
Redis使用单线程响应命令，如果每次写AOF文件命令都直接追加到磁盘，那么Redis的性能完全取决于磁盘负载。先写入缓冲区aof_buf中，还有一个好处在于可以设计多种缓冲区同步到磁盘的策略，在性能上和安全性方面做出平衡。
redis同步策略
Redis提供多种AOF缓冲区同步硬盘策略，由参数appendfsync控制
always模式
1、fsync针对单个文件操作（比如AOF文件），做强制硬盘同步，fsync将阻塞直到写入硬盘操作完成后返回，保证了数据持久化
everysec方式：
2、write操作会触发延迟写操作（delayedwrite）机制。Linux内核提供页缓冲区用来提高硬盘的IO性能。write操作在写入系统缓冲区后直接返回。同步硬盘操作依赖于系统调用机制，例如：缓冲区页空间写满或达到特定的时间周期。同步文件之前，如果此时系统故障宕机，缓冲区内数据将丢失；
重写机制
随着命令的不断写入AOF文件，文件会越来越大，为了解决该问题，Redis中设计了AOF重写机制压缩文件体积。AOF文件重写是把Redis进程中的数据转化为写命令同步到新AOF的过程。
AOF重写除了解决AOF文件占用过多空间以外，还有一个原因是AOF文件越小，Redis重新加载的速度越快；
问题:重写后AOF文件为什么会变小?
1、进程内已经过期的键不再写入文件；
2、旧的AOF文件中含有无效命令，重写使用进程内数据直接生成，这样新的AOF文件保留最终数据的写入命令。
3、多条写入命令可以进行合并；为了防止单条命令过大造成客户端缓冲区溢出，对于list,set,zset,hash等类型的操作，以64个元素为界拆分为多条
重写机制的触发:
手动触发:直接使用bgrewriteaof命令
自动触发:根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发机制；
auto-aof-rewrite-min-size:表示AOF文件达到最小体积时触发重写，默认64M
auto-aof-rewrite-percentage:表示AOF文件空间和上一次重写后AOF文件空间的比值
查看状态
重写流程:
1、执行AOF重新请求，如果当前进程正在执行AOF重写，请求不执行
2、父进程执行fork创建子进程，开销等同于bgsave过程。
3、主进程fork操作完成后，继续响应其他命令。所有的修改操作仍然写入aof_buf中并根据同步策略写入硬盘，保障原有AOF机正确性，由于fork操作运用写时复制技术，子进程只能共享fork操作时的内存数据。由于父进程依然响应命令，Redis使用“AOF重写缓冲区”保存这部分新的数据，防止新AOF文件生成期间丢失这部分数据。
4、子进程根据内存快照，安装命令合并规则写入新的AOF文件中，每次批量写入磁盘数量由参数aof-rewrite-incremental-fsync控制，默认32MB，防止单次刷盘数据过多造成硬盘阻塞；
5、新AOF文件写入完成后，子进程发送信号给父进程，父进程更新统计信息。（infopersistence）
6、父进程把AOF重新缓冲区的数据写入新的AOF文件；
7、使用新的AOF文件替换旧AOF文件，完成AOF重写。
重新加载流程
AOF工具：
AOF文件由于异常或损坏会造成启动失败。此时可以对AOF文件先进行备份，然后采用命令redis-check-aof --fix文件名进行修复，修复后使用diff-u对比数据差异，找出丢失的数据，有些可以人工修复；
AOF文件可能由于某些原因导致文件不完整，比如服务器突然宕机导致AOF尾部文件命令写入不全。Redis为我们提供了aof-load-rruncated配置来兼容这种情况，默认开启
总结：
优点：
可以选择不同的fsync策略：无fsync，每次请求时fsync和每秒fsync，追加文件，不需要定位，断电不存在损坏，可以使用修复工具，可以最大程度保证数据不丢失
AOF文件里面包含一个接一个的操作，以易于理解和解析的格式存储。易于恢复数据
缺点：
对同样的数据集，日志记录量级比较大，AOF文件通常要大于等价的RDB文件。
在很大的写负载情况下，AOF不如RDB能提供能好的最大延迟保证。
核心配置
appendonly yes #是否打开aof日志功能
appendfsync always #每1个命令,都立即同步到aof
appendfsync everysec #每秒写1次
appendfsync no 写入工作交给操作系统,由操作系统判断缓冲区大小,统一写入到aof
实验
生成appendonly.aof配置
vim /etc/redis.conf
appendonly no默认不使用AOF持久化（450行）将no改成yes。
修改之后配置文件中默认每秒进行一次保存
add：
appendfsync always有写操作，就马上写入磁盘。效率最慢，但是最安全
appendfsync no：不进行AOF备份，将数据交给操作系统处理。最快，最不安全
重启
redis-cli -a 123 shutdown
redis-server /usr/local/redis/etc/redis.conf
测试
redis-cli -a 123
set name 111
set sex man
退出进入备份文件目录
cd /usr/local/redis/datadir;ls
cat appendonly.aof
多实例部署
Redis单线程架构导致无法充分利用CPU多核特性，通常的做法是在一台机器上部署多个Redis实例。多实例的实现主要利用配置文件中设置监听端口不同实现。
实验：
创建配置文件目录，日志文件目录，pid文件目录。数据文件目录
mkdir -pv /etc/redis/{6379,6380,6381}/{conf,log,pid,data}
修改第一个配置文件
echo "$(egrep -v "^#|^$" /etc/redis/6379/conf/redis.conf;vim /etc/redis/6379/conf/redis.conf
将配置文件中的数据加入到其余配置目录下的配置文件中
for i in {6380..6381};do echo "$(egrep -v "^#|^$" /etc/redis/6379/conf/redis.conf)" >/etc/redis/$i/conf/redis.conf; sed -i "s/6379/$i/g" /etc/redis/$i/conf/redis.conf;done
修改数主和属组
chown -R redis:redis /etc/redis
如果不修改会报这个错误
以redis身份运行：更加安全（也可以不用）
su redis -s /bin/bash -c "redis-server /etc/redis/6379/conf/redis.conf "
切换身份，给一个bash环境，指定配置文件
su redis -s /bin/bash -c "redis-server /etc/redis/6380/conf/redis.conf "
su redis -s /bin/bash -c "redis-server /etc/redis/6381/conf/redis.conf "
netstat -anput|grep redis
当多实例开启AOF重写后，彼此之间会产生CPU和IO竞争
主从同步
复制功能是高可用Redis的基础,后面的哨兵和集群都是在复制的基础上实现高可用的。
主从复制按拓扑结构可以分为：一主一从，一主多从，树状主从结构等。
每个从节点只能有一个主节点,主节点可以有多个从节点。
传输延迟
主从节点一般部署在不同机器上，复制时，网络延迟就成为需要考虑的问题，redis提供了repl-disable-tcp-nodelay参数用于控是否关闭TCP_NODELAY，默认关闭
关闭时，主节点参数的命令数据无论大小都会及时的发送给从节点，这样主从之间延迟会变小，但是增加了网络带宽的消耗。适用于主从之间网络环境良好的场景，如同机架或同机房部署；
开启时，主节点会合并较小的TCP数据包从而节省带宽。默认发送时间间隔取决于Linux的内核，一般默认为40ms。这种配置节省了带宽但是增大了主从之间的延迟。适用于主从网络环境复杂，或带宽紧张的场景，如跨机房部署。
Redis主从复制过程：
1.保存主节点信息
执行slaveof命令后从节点只保存主节点的地址信息便直接返回。
2.从节点内部通过每秒运行的定时任务维护复制相关的路径，当定时任务发现存在主节点后，会尝试建立网络连接。从节点会建立一个socket套接字，专门用于接收主节点发送的复制命令。如果从节点无法与主节点建立连接，定时任务会无限尝试与主节点进行连接，直到连接成功
3.发送ping命令
连接建立成功后从节点发送ping命令请求首次通讯，ping请求的主要目的为,检测主从之间的套接字是否可用。检测主节点当前是否可接受处理命令。
发送ping命令，从节点没有收到主节点的pong回复或者超时，比如网络超时或者主节点处于阻塞状态无法响应命令，从节点会断开复制连接，下次定时任务会重新发起连接请求。（每个1秒轮询重试一次）
4.权限验证
如果主节点设置了requirepass参数，则需要密码验证，从节点必须配置masterauth参数保证与主节点密码相同才能通过验证；如果验证失败复制将终止，从节点重新发起复制流程；
5.同步数据集
主从复制连接正常通信后，对于首次建立复制场景，主节点会把所有的数据全部发送给从节点，这部分操作是耗时最长的。
6.命令持续复制
当主节点把当前的数据同步给从节点后，便完成了复制建立流程。接下来主节点会持续的把写命令发送给从节点，保证主从数据一致性。
配置复制的方式有三种:
1.在配置文件中加入slaveof {masterHost} {masterPort}随后redis启动生效
2.在redis-server启动命令后加入—slaveof {masterHost} {masterPort}生效
3.直接使用命令:slaveof {masterHost} {masterPort}生效
查看复制状态信息命令
info replication
启动后加入实验
准备一台slave（这里我们使用从节点6380），并搭建redis
在从节点客户端输入
slaveof 192.168.1.10 6379
从节点查看
主节点查看
测试
主节点
从节点
断开复制
slaveof no one
断开复制主要流程:
1.断开与主节点复制关系
2.从节点晋升为主节点
从节点断开复制后不会抛弃原有数据,只是无法再获取主节点上的数据变化
切主操作流程如下:
1.断开与旧主节点的复制关系
2.与新主节点建立复制关系
3.删除从节点当前所有数据
4.对新主节点进行复制操作
线上操作一定要小心,因为切主后会清空之前所有的数据
配置文件加入实验
vim /etc/redis/6380/conf/redis.conf
重启
redis-cli -p 6380 shutdown
su redis -s /bin/bash -c "redis-server /etc/redis/6380/conf/redis.conf "
重启测试
重启登录
redis-cli -p 6379 shutdown
su redis -s /bin/bash -c "redis-server /etc/redis/6379/conf/redis.conf "
redis-cli -p 6379
从节点进入配置文件
测试：登录6379
心跳
主从节点建立复制后，它们之间维护着长连接并彼此发送心跳命令。
主从节点建立复制后，它们之间维护着长连接并彼此发送心跳命令。
1.主从节点彼此都有心跳检测机制，各自模拟成对方的客户端进行通信，通过client list命令查看复制相关客户端信息。
2.主节点默认每隔10s对从节点发送ping命令，判断从节点的存活性和连接状态。可以通过repl-ping-slave-period控制发送频率。
3.从节点在主线程中每隔1秒发送replconfack {offset}命令，给主节点上报自身当前的复制偏移量。
replconf命令作用:
实时监测主从节点的网络状态；
上报自身复制偏移量，检查复制数据是否丢失，如果从节点丢失，再从主节点复制缓冲区中拉取丢失数据。
实现保证从节点的数量和数据延时性功能，通过min-slaves-to-write、min-slaves-max-lag参数配置定义。
replconf命令作用:
实时监测主从节点的网络状态；
上报自身复制偏移量，检查复制数据是否丢失，如果从节点丢失，再从主节点复制缓冲区中拉取丢失数据。
实现保证从节点的数量和数据延时性功能，通过min-slaves-to-write、min-slaves-max-lag参数配置定义。
主节点根据replconf命令判断从节点超时时间，info replication中的lag表示与从节点的最后一次通信延迟的秒数，正常延迟应该在0与1之间。如果超过repl-timeout配置的值（默认60秒）则判断从节点下线并断开复制客户端连接，即使主节点判断从节点下线后，如果从节点恢复，心跳检测会继续进行。
异步复制
主节点不但负责数据读写，还负责把写命令同步给从节点。写命令的发送过程是异步完成，也就是说主节点自身处理完写命令后直接返回给客户端，并不等待从节点复制完成。
主从复制运维中的问题
读写分离
1、对于很多读占比高的场景，可以通过把一部分读请求分给从节点，来减轻主库压力，同时注意只能对主节点进行写操作。
主从配置不一致常见原因
1、没有开启AOF
2、当配置的max memory从节点小于主节点时，如果复制的数据量超过从节点的max memory时，它会根据maxmemory-policy策略进行内存溢出控制，此时从节点数据已经丢失，但主节点依旧正常工作。
运维注意：
规避全量复制
全量复制过于耗费系统资源。第一次建立复制或者节点运行IP不匹配时会进行全量复制，此时就要挑选Redis压力不大时进行。
规避复制风暴
复制风暴是指大量从节点对同一主节点或者对同一台机器多个主节点短时间内发起全量复制。复制风暴对发起复制的主节点或者机器造成大量开销，导致CPU、内存、带宽消耗。
解决方案：
单节点复制风暴一般发生在一主多从架构场景，所以减少从节点或者使用树状结构复制
应该把主节点尽量分散在多台机器上，避免在单台机器上部署过多的节点。当主节点所在机器故障后提供故障转移机制，避免机器恢复后进行密集的全量复制。发布者：LJH，转发请注明出处：https://www.ljh.cool/6773.html
