redis主从、哨兵、集群

redis概念

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

1.1系统缓存

1.1.1buffer与cache：

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

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

1.2 缓存保存位置及分层结构

互联网应用领域,提到缓存为王

• 用户层: 浏览器DNS缓存,应用程序DNS缓存,操作系统DNS缓存客户端
• 代理层: CDN,反向代理缓存
• Web层: Web服务器缓存
• 应用层: 页面静态化
• 数据层: 分布式缓存,数据库
• 系统层: 操作系统cache
• 物理层: 磁盘cache, Raid Cache

1.2.1 DNS缓存

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

1.2.2 应用层缓存

Nginx、PHP等web服务可以设置应用缓存以加速响应用户请求，另外有些解释性语言，比如：

PHP/Python/Java不能直接运行，需要先编译成字节码，但字节码需要解释器解释为机器码之后才能执

行，因此字节码也是一种缓存，有时候还会出现程序代码上线后字节码没有更新的现象。所以一般上线

新版前,需要先将应用缓存清理,再上线新版。

另外可以利用动态页面静态化技术,加速访问,比如:将访问数据库的数据的动态页面,提前用程序生成静态

页面文件html 电商网站的商品介绍,评论信息非实时数据等皆可利用此技术实现。

1.2.3数据层缓存

• 分布式缓存服务

Redis

Memcached

• 数据库

MySQL 查询缓存

innodb缓存、MYISAM缓存

1.2.4 硬件缓存

• CPU缓存(L1的数据缓存和L1的指令缓存)、二级缓存、三级缓存
• 磁盘缓存:Disk Cache
• 磁盘阵列缓存: Raid Cache,可使用电池防止断电丢失数据

2 redis基础：

2.1.1 关系型数据库和 NoSQL 数据库

数据库主要分为两大类：关系型数据库与 NoSQL 数据库。

关系型数据库，是建立在关系模型基础上的数据库，其借助于集合代数等数学概念和方法来处理数据库

中的数据。主流的 MySQL、Oracle、MS SQL Server 和 DB2 都属于这类传统数据库。

NoSQL 数据库，全称为 Not Only SQL，意思就是适用关系型数据库的时候就使用关系型数据库，不适

用的时候也没有必要非使用关系型数据库不可，可以考虑使用更加合适的数据存储。主要分为临时性键

值存储（memcached、Redis）、永久性键值存储（ROMA、Redis）、面向文档的数据库（MongoDB、CouchDB）、面向列的数据库（Cassandra、HBase），每种 NoSQL 都有其特有的使用场景及优点。

Oracle，mysql 等传统的关系数据库非常成熟并且已大规模商用，为什么还要用 NoSQL 数据库呢？

主要是由于随着互联网发展，数据量越来越大，对性能要求越来越高，传统数据库存在着先天性的缺

陷，即单机（单库）性能瓶颈，并且扩展困难。这样既有单机单库瓶颈，却又扩展困难，自然无法满足

日益增长的海量数据存储及其性能要求，所以才会出现了各种不同的 NoSQL 产品，NoSQL 根本性的优

势在于在云计算时代，简单、易于大规模分布式扩展，并且读写性能非常高。

（一）、关系型数据库
关系型数据库是一个结构化的数据库，创建在关系模型 (二维表格模型) 基础上，一般面向于记录。
SQL语句 (标准数据查询语言) 就是一种基于关系型数据库的语言，用于执行对关系型数据库中数据的检索和操作。
主流的关系型数据库包括Oracle、MySQL、SQL Server、Microsoft Access、DB2等。

（二）、非关系型数据库
NoSQL (NoSQL=NotOnlySQL)，意思是“不仅仅是SQL”，是非关系型数据库的总称。
除了主流的关系型数据库外的数据库，都认为是非关系型。
主流的 NoSQL 数据库有Redis、 MongBD、 Hbase、 Memcached 等。

（三）、关系型数据库和非关系型数据库区别
(1)、数据存储方式不同
关系型和非关系型数据库的主要差异是数据存储的方式。关系型数据天然就是表格式的，因此存储在数据表的行和列中。数据表可以彼此关联协作存储，也很容易提取数据。
与其相反，非关系型数据不适合存储在数据表的行和列中，而是大块组合在一起。非关系型数据通常存储在数据集中，就像文档、键值对或者图结构。你的数据及其特性是选择数据存储和提取方式的首要影响因素。
① 关系型：依赖于关系模型E-R图，同时以表格式的方式存储数据
② 非关系型：除了以表格形式存储之外，通常会以大块的形式组合在一起进行存储数据

(2)、扩展方式不同
SQL和NoSQL数据库最大的差别可能是在扩展方式上，要支持日益增长的需求当然要扩展。
要支持更多并发量，SQL数据库是纵向扩展，也就是说提高处理能力，使用速度更快速的计算机，这样处理相同的数据集就更快了。因为数据存储在关系表中，操作的性能瓶颈可能涉及很多个表，这都需要通过提高计算机性能来克服。虽然SQL数据库有很大扩展空间，但最终肯定会达到纵向扩展的上限。
而NoSQL数据库是横向扩展的。因为非关系型数据存储天然就是分布式的，NoSQL数据库的扩展可以通过给资源池添加更多普通的数据库服务器 (节点) 来分担负载。
① 关系：纵向（天然表格式）
② 非关：横向（天然分布式）

(3)、对事务性的支持不同
如果数据操作需要高事务性或者复杂数据查询需要控制执行计划，那么传统的SQL数据库从性能和稳定性方面考虑是最佳选择。SQL数据库支持对事务原子性细粒度控制，并且易于回滚事务。
虽然NoSQL数据库也可以使用事务操作，但稳定性方面没法和关系型数据库比较，所以它们真正闪亮的价值是在操作的扩展性和大数据量处理方面。
① 关系型：特别适合高事务性要求和需要控制执行计划的任务
② 非关系：此处会稍显弱势，其价值点在于高扩展性和大数据量处理方面

（四）、非关系型数据库产生背景
可用于应对Web2.0纯动态网站类型的三高问题。
(1) High performance-------对数据库高并发读写需求
(2) HugeStorage--------------对海量数据高效存储与访问需求
(3) High Scalability && High Availability------- 对数据库高可扩展性与高可用性需求

关系型数据库和非关系型数据库都有各自的特点与应用场景，两者的紧密结合将会给Web2.0的数据库发展带来新的思路。让关系数据库关注在关系上，非关系型数据库关注在存储上。例如，在读写分离的MySQL数据库环境中，可以把经常访问的数据存储在非关系型数据库中，提升访问速度。
Mysql 高热数据——》redis
web ——》redis ——》mysql
CPU——》内存/缓存 ——》磁盘

总结：
关系型数据库：
实例–>数据库–>表(table)–>记录行(row)、数据字段(column)——》存储数据

非关系型数据库：
实例–>数据库–>集合(collection) -->键值对(key-value)
workdir=/usr/local/mysql

非关系型数据库不需要手动建数据库和集合(表)。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ozq1QN7D-1640749101296)(C:\Users\think\AppData\Roaming\Typora\typora-user-images\image-20211206220718697.png)]

2.1.2redis特性

• 速度快: 10W QPS,基于内存,C语言实现
• 单线程
• 持久化
• 支持多种数据结构
• 支持多种编程语言
• 功能丰富: 支持Lua脚本,发布订阅,事务,pipeline等功能
• 简单: 代码短小精悍(单机核心代码只有23000行左右),单线程开发容易,不依赖外部库,使用简单
• 主从复制
• 支持高可用和分布式

2.1.3 redis 典型应用场景

• Session 共享：常见于web集群中的Tomcat或者PHP中多web服务器session共享
• 缓存：数据查询、电商网站商品信息、新闻内容
• 计数器：访问排行榜、商品浏览数等和次数相关的数值统计场景
• 微博/微信社交场合：共同好友,粉丝数,关注,点赞评论等
• 消息队列：ELK的日志缓存、部分业务的订阅发布系统
• 地理位置: 基于GEO(地理信息定位),实现摇一摇,附近的人,外卖等功能

安装redis

[root@localhost ~]# systemctl stop firewalld.service 
[root@localhost ~]# setenforce 0
环境设置 关闭防火墙

yum install -y gcc gcc-c++ make
#安装前依赖包

#将redis-5.0.7.tar.gz 压缩包上传到/opt 目录中
tar zxvf redis-5.0.7.tar.gz -C /opt/

cd /opt/redis-5.0.7/
make
make PREFIX=/usr/local/redis install
cd /opt/redis-5.0.7/utils 
./install_server.sh       
.......          #一直回车.
Please select the redis executable path [/usr/local/bin/redis-server] /usr/local/redis/bin/redis-server
#需要手动修改为 /usr/local/redis/bin/redis-server    注意要一次性正确输入
#/usr/local/redis/bin/redis-server
-------------------------------------------------------------------------------------
Selected config:
Port               : 6379                               #默认侦听端口为6379
Config file        : /etc/redis/6379.conf               #配置文件路径
Log file           : /var/log/redis_6379.log            #日志文件路径
Data dir           : /var/lib/ redis/6379               #数据文件路径
Executable         : /usr/local/redis/bin/redis-server  #可执行文件路径
Cli Executable     : /usr/local/redis/bin/redis-cli     #客户端命令工具
-------------------------------------------------------------------------------------
ss -natp |grep redis
#查看是否启动
vim /etc/redis/6379.conf
70 bind 127.0.0.1 192.168.32.108
#70 行加入自己的IP地址


/etc/init.d/redis_6379 restart
ss -natp |grep redis
#再查看下

#把redis的可执行程序文件放入路径环境变量的目录中便于系统识别
ln -s /usr/local/redis/bin/* /usr/local/bin/

redis主从复制

1.主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(Master)，后者称为从节点(Slave)；数据的复制是单向的，只能由主节点到从节点。

默认情况下，每台Redis服务器都是主节点；且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点。
2.redis主从复制的作用
数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。

故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。

负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。

高可用基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。

3.redis主从复制流程

若启动一个Slave机器进程，则它会向Master机器发送一个“sync command" 命令，请求同步连接。

无论是第一次连接还是重新连接，Master机器 都会启动一个后台进程，将数据快照保存到数据文件中(执行rdb操作) ，同时 Master 还会记录修改数据的所有命令并缓存在数据文件中。

后台进程完成缓存操作之后，Master 机器就会向 Slave 机器发送数据文件，Slave 端机器将数据文件保存到硬盘上，然后将其加载到内存中，接着 Master 机器就会将修改数据的所有操作一并发送给 Slave 端机器。若 Slave 出现故障导致宕机，则恢复正常后会自动重新连接。

Master机器收到 Slave 端机器的连接后，将其完整的数据文件发送给 Slave 端机器，如果 Mater 同时收到多个 Slave 发来的同步请求，则 Master 会在后台启动一个进程以保存数据文件，然后将其发送给所有的 Slave 端机器，确保所有的 Slave 端机器都正常。

搭建主从复制

[root@localhost ~]# systemctl stop firewalld.service 
[root@localhost ~]# setenforce 0
环境设置 关闭防火墙

master节点：192.168.32.99
slave1节点：192.168.32.108
slave2节点：192.168.32.105

yum install -y gcc gcc-c++ make
#安装前依赖包

#将redis-5.0.7.tar.gz 压缩包上传到/opt 目录中
tar zxvf redis-5.0.7.tar.gz -C /opt/

cd /opt/redis-5.0.7/
make
make PREFIX=/usr/local/redis install
#由于Redis源码包中直接提供了Makefile 文件，所以在解压完软件包后，不用先执行./configure 进行配置，可直接执行make与make install命令进行安装

#执行软件包提供的 install_server.sh 脚本文件设置Redis服务所需要的相关配置文件
cd /opt/redis-5.0.7/utils 
./install_server.sh       
.......          #一直回车.
Please select the redis executable path [/usr/local/bin/redis-server] /usr/local/redis/bin/redis-server
#需要手动修改为 /usr/local/redis/bin/redis-server    注意要一次性正确输入
#/usr/local/redis/bin/redis-server
-------------------------------------------------------------------------------------
Selected config:
Port               : 6379                               #默认侦听端口为6379
Config file        : /etc/redis/6379.conf               #配置文件路径
Log file           : /var/log/redis_6379.log            #日志文件路径
Data dir           : /var/lib/ redis/6379               #数据文件路径
Executable         : /usr/local/redis/bin/redis-server  #可执行文件路径
Cli Executable     : /usr/local/redis/bin/redis-cli     #客户端命令工具
-------------------------------------------------------------------------------------
ss -natp |grep redis
#查看是否启动
vim /etc/redis/6379.conf
70 bind 127.0.0.1 192.168.32.99
#70 行加入自己的IP地址


/etc/init.d/redis_6379 restart
ss -natp |grep redis
#再查看下

#把redis的可执行程序文件放入路径环境变量的目录中便于系统识别
ln -s /usr/local/redis/bin/* /usr/local/bin/

主从服务器操作

[root@localhost ~]#vim /etc/redis/6379.conf 
70 bind 0.0.0.0
#将监听端口改为任意端口
137 daemonize yes
#开启守护进程
172 logfile /var/log/redis_6379.log
#指定日志文件目录
264 dir /var/lib/redis/6379
#指定工作目录
700 appendonly yes
#开启AOF持久化功能

[root@localhost ~]#/etc/init.d/redis_6379 restart
#重启服务

从服务器操作

[root@localhost ~]#vim /etc/redis/6379.conf 
70 bind 0.0.0.0
#将监听端口改为任意端口
137 daemonize yes
#开启守护进程
172 logfile /var/log/redis_6379.log
#指定日志文件目录
264 dir /var/lib/redis/6379
#指定工作目录
288  replicaof 192.168.91.100 6379
#指定主节点的ip 和端口
701 appendonly yes
#开启 AOF持久化

验证效果：

redis哨兵模式

哨兵的核心功能:在主从复制的基础上，哨兵引入了主节点的自动故障转移。

1.1哨兵模式原理：

哨兵(sentinel):是一个分布式系统，用于对主从结构中的每台服务器进行监控，当出现故障时通过投票机制选择新的Master并将所有Slave连接到新的 Master。所以整个运行哨兵的集群的数量不得少于3个节点。

哨兵们监控整个系统节点的过程
1.首先主节点的信息是配置在哨兵(Sentinel)的配置文件中

2.哨兵节点会和配置的主节点建立起两条连接命令连接和订阅连接
PS:Redis发布订阅(pub/sub)是- -种消息通信模式:发送者(puB)发送消息，订阅者(sub) 接收消息。

3.哨兵会通过命令连接每10s发送一次INFO命令，通过INFO命令，主节点会返回自己的run_id和自己的从节点信息

4.哨兵会对这些从节点也建立两条连接命令连接和订阅连接

5.哨兵通过命令连接向从节点发送INFO命令，获取到他的一 些信息:
run id (redis服务器id)、role（职能）
从服务器的复制偏移量offset
其他

6.通过命令连接向服务器的sentinel:he11o频道发送一 条消息，内容包括自己的ip端口、run id、 配置(后续投票的时候会用到)等

7.通过订阅连接对服务器的sentinel:hello频道做了监听，所以所有的向该频道发送的哨兵的消息都能被接受到

8.解析监听到的消息，进行分析提取，就可以知道还有那些别的哨兵服务节点也在监听这些主从节点了，更新结构体将这些

9.向观察到的其他的哨兵节点建立命令连接----没有订阅连接

1.2哨兵模式作用

• 监控:哨兵会不断地检查主节点和从节点是否运作正常。
• 自动故障转移:当主节点不能正常工作时，哨兵会开始自动故障转移操作，它会将失效主节点的其中一个从节点升级为新的主节点，并让其他从节点改为复制新的主节点。
• 通知提醒：哨兵可以将故障转移的结果发送给客户端。

1.3 哨兵结构组成

• 哨兵节点：哨兵系统由一个或多个哨兵节点组成，哨兵节点就是特殊的redis节点，不存储数据
• 数据节点：主节点和从节点都是数据节点。

哨兵的启动依赖于主从模式，所以须把主从模式安装好的情况下再去做哨兵模式，所有节点上.都需要部署哨兵模式，哨兵模式会监控所有的Redis工作节点是否正常，当Master出现问题的时候，因为其他节点与主节点失去联系，因此会投票，投票过半就认为这个Master的确出现问题，然后会通知哨兵间，然后从Slaves中选取一个作为新的 Master。

需要特别注意的是，客观下线是主节点才有的概念:如果从节点和哨兵节点发生故障，被哨兵主观下线后，不会再有后续的客观下线和故障转移操作。

1.4 哨兵模式配置

master节点：192.168.32.99
slave1节点：192.168.32.108
slave2节点：192.168.32.105

修改哨兵模式的配置文件（所有节点操作）

[root@localhost ~]#vim /opt/redis-5.0.7/sentinel.conf
#修改配置文件
17  protected-mode no
#关闭保护模式
21 port 26379
#端口号 26379
26 daemonize yes
#开启后台运行
36 logfile "/var/log/sentinel.log
#指定日志目录
65 dir "/var/lib/redis/6379"
#数据文件
84 sentinel monitor mymaster 192.168.32.99 6379 2
#改变master节点地址
113 sentinel down-after-milliseconds mymaster 30000
#可以修改时间
146 sentinel failover-timeout mymaster 180000
#故障切换时间



[root@localhost ~]#scp sentinel.conf 192.168.32.108:/opt/redis-5.0.7



启动时先启动master 再启动slave
[root@localhost 6379]#cd /opt/redis-5.0.7/
[root@localhost redis-5.0.7]#redis-sentinel sentinel.conf &
#后台启动服务
[root@localhost redis-5.0.7]#ss -ntap |grep 6379

[root@localhost redis-5.0.7]#redis-cli -p 26379
127.0.0.1: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=192.168.32.99:6379,slaves=2,sentinels=3

启动时先启动master 再启动slave
[root@localhost 6379]#cd /opt/redis-5.0.7/
[root@localhost redis-5.0.7]#redis-sentinel sentinel.conf &
#后台启动服务
[root@localhost redis-5.0.7]#ss -ntap |grep 6379

[root@localhost redis-5.0.7]#redis-cli -p 26379
127.0.0.1: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=192.168.91.100:6379,slaves=2,sentinels=3

1.5模拟故障

redis集群模式

1.集群模式的作用
数据分区：数据分区(或称数据分片) 是集群最核心的功能。 集群将数据分散到多个节点，一方面突破了 Redis 单机内存大小的限制，存储容量大大增加；另一方面每个主节点都可以对外提供读服务和写服务，大大提高了集群的响应能力。 Redis 单机内存大小受限问题，在介绍持久化和主从复制时都有提及；例如，如果单机内存太大，bgsave 和 bgrewriteaof的 fork 操作可能导致主进程阻塞，主从环境下主机切换时可能导致从节点长时间无法提供服务，全量复制阶段主节点的复制缓冲区可能溢出。

高可用：集群支持主从复制和主节点的自动故障转移(与哨兵类似) ；当任一节点发生故障时，集群仍然可以对外提供服务。

2.集群模式的数据分片
Redis集群引入了哈希槽的概念

Redis集群有 16384 个哈希槽( 编号0-16383)

集群的每个节点负责一部分哈希槽

每个Key 通过 CRC16 校验后对16384取余来决定放置哪个哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作
…(img-edkCntJn-1640749101308)]

[外链图片转存中…(img-d7sml0Xh-1640749101308)]

[外链图片转存中…(img-5eFQyMxN-1640749101308)]

redis集群模式

1.集群模式的作用
数据分区：数据分区(或称数据分片) 是集群最核心的功能。 集群将数据分散到多个节点，一方面突破了 Redis 单机内存大小的限制，存储容量大大增加；另一方面每个主节点都可以对外提供读服务和写服务，大大提高了集群的响应能力。 Redis 单机内存大小受限问题，在介绍持久化和主从复制时都有提及；例如，如果单机内存太大，bgsave 和 bgrewriteaof的 fork 操作可能导致主进程阻塞，主从环境下主机切换时可能导致从节点长时间无法提供服务，全量复制阶段主节点的复制缓冲区可能溢出。

高可用：集群支持主从复制和主节点的自动故障转移(与哨兵类似) ；当任一节点发生故障时，集群仍然可以对外提供服务。

2.集群模式的数据分片
Redis集群引入了哈希槽的概念

Redis集群有 16384 个哈希槽( 编号0-16383)

集群的每个节点负责一部分哈希槽

每个Key 通过 CRC16 校验后对16384取余来决定放置哪个哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作