一、缓存服务器：
1、简介：
① 许多Web应用都将数据保存到RDBMS中，应用服务器从中读取数据并在浏览器中显示。 但随着数据量的增大、访问的集中，就会出现RDBMS的负担加重、数据库响应恶化、 网站显示延迟等重大影响。
● RDBMS：关系数据库管理系统(Relational Database Management System)，如Oracle Database、MySQL等。
② Memcached/redis 是高性能的分布式内存缓存服务器,通过缓存数据库查询结果，减少数据库访问次数，以提高动态Web等应用的速度、 提高可扩展性。
2、缓存服务器作用：
加快访问速度 缓解数据库压力
● NOSQL：Not Only SQL ，非关系型数据库的一种概念，以键值对的方式存储数据，产品有memcache、redis、mongoDB
二、memcache
1、特点：
① 内存存储：memcache 的存储方式是将数据存储在内存中。它不会将数据持久化到磁盘，因此在服务重启或重启之后，数据将丢失。因此，memcache 主要用于临时性数据缓存，而非持久化数据存储。
② 键值对存储：memcache 将数据存储为键值对。每个键都是唯一的，并且与一个值相关联。键是用于检索和存储数据的标识符，值则是实际的数据内容。
2、服务框架：
① 检查用户请求的数据是缓存中是否有存在，如果存在，只需要直接把请求的数据返回，无需查询数据库。
② 如果请求的数据在缓存中找不到，再去查询数据库。返回请求数据的同时，把数据存储到缓存中一份。
③ 当数据发生变化的时候，同步的更新缓存信息，确保用户不会在缓存取到旧的数据。
3、配置：
(1) 安装并修改配置文件：
yum install -y memcached
vim /etc/sysconfig/memcached
PORT="11211"
USER="memcached"
MAXCONN="1024"
CACHESIZE="1500"
OPTIONS=""
PORT：这个参数指定了 Memcached 服务监听的端口号；
USER：这个参数指定了运行 Memcached 服务的用户；
MAXCONN：这个参数定义了 Memcached 服务能够支持的最大并发连接数；
CACHESIZE：这个值决定了 Memcached 可以使用的内存量（单位：MB）
(2) 启动并测试
① systemctl start memcached.service
② yum install -y telnet
③ set name 0 900 5
设置名称为 name 的 key，0 是key的 id ；900 是缓存过期时间(s)，若设为0则表示永不过期 ；5 表示字符串的最大长度。
aaaaa 是 name 的值 ；STORED 表示存储成功
get name 可以查询 key 为 name 的值。
三、redis
1、简介：
redis 是一个开源的、使用C语言编写的、基于键值对的内存数据库。
(1) 特点：
① 丰富的数据结构：Redis 支持多种数据结构，如字符串、哈希表、列表、集合等；
② 支持持久化：Redis 提供了多种持久化方式，可以将内存中的数据定期写入磁盘，确保数据在重启或断电情况下不丢失；
③ 支持事务：Redis 支持事务，可以批量执行多个命令，并确保这些命令要么全部执行成功，要么全部失败。
④ 支持主从。
(2) redis相比memcached有哪些优势：
① memcached所有的值均是简单的字符串，redis作为其替代者，支持更为丰富的数据类型；
② redis可以持久化其数据。
2、redis 配置：
(1) 安装：
redis 官网：Download | Redis
tar zxvf redis-7.0.14.tar.gz
● Redis是基于c语言编写的需要安装依赖，需要安装gcc：yum install -y gcc-c++
● 编译：
cd redis-7.0.14/
make
(2) 配置开机启动：
mkdir /etc/redis
cp redis-7.0.14/redis.conf /etc/redis/6379.conf
cp redis-7.0.14/utils/redis_init_script /etc/init.d/redis
● 修改redis启动脚本：
vim /etc/init.d/redis
修改EXEC与CLIEXEC的路径：
授权：chmod +x /etc/init.d/redis
重载配置：systemctl daemon-reload
启动 redis：
3、redis 持久化：
(1) 概念：
redis 持久化是指将 redis 中的数据保存到磁盘上以防止数据丢失的过程，开启持久化功能后，重启redis，数据会自动通过持久化文件恢复。
持久化方式有：RDB、AOF
(2) RDB (Redis DataBase)：
① 概念：
在指定的时间间隔内生成数据的快照，并将快照保存到一个以.rdb为后缀的文件中，存储到磁盘上。
② 特点：
● 周期性
● 不影响数据写入：RDB会启动子进程，备份所有数据。 当前进程，继续提供数据的读写。 当备份完成，才替换老的备份文件
● 高效：一次性还原所有数据
● 完整性较差：故障点到上一次备份之间的数据无法恢复
③ 配置：
RDB 默认开启
vim redis-7.0.14/redis.conf
● dbfilename dump.rdb：持久化数据存储在本地的文件
● dir ./ ：持久化数据文件储存在本地的路径
● 触发持久化操作的条件：
save 900 1 ：900秒(15分钟)内至少发生1次写操作，就触发一次 RDB 持久化
save 300 10 ：300秒(5分钟)内至少发生10次写操作，就触发一次 RDB 持久化
save 60 10000 ：60秒内至少发生10000次写操作，就触发一次 RDB 持久化
● stop-writes-on-bgsave-error yes：在执行后台保存（bgsave）操作（即RDB持久化）出现错误，redis 会停止写入数据
● rdbcompression yes：在执行 RDB 持久化时对快照文件进行压缩处理，以减小磁盘上的存储空间。
④ 客户端使用命令进行持久化save存储：
前台进行存储：./redis-cli -h ip -p port save
后台进行存储：./redis-cli -h ip -p port bgsave
(3) AOF (Append Only File)：
① 概念：
以追加日志的方式记录 redis 服务器接收到的每个写操作，在下次 redis 重新启动时，只要把这些写指令从前到后再重复执行一遍，就可以实现数据恢复。
② 特点：
实时性：写操作会立即追加到AOF文件中
完整性较好
体积大：记录数据的指令，删除数据的指令都会被记录下来
③ 配置：
AOF 默认关闭
vim redis-7.0.14/redis.conf
● appendonly yes：启动 AOF 功能；
● appendfsync everysec：指定 AOF 文件同步策略
everysec：表示每秒同步一次 ；always：每次写入时都同步 ；no：从不同步
● no-appendfsync-on-rewrite no：在执行 AOF 重写期间，会继续执行 AOF 日志文件的同步操作，即在重写期间仍然同步写入新的操作到 AOF 文件中。
AOF 重写是为了解决 AOF 文件可能变得过大的问题，通过重写 AOF 文件，可以消除文件中的冗余命令，从而缩小文件的体积。
● 重写触发条件：
auto-aof-rewrite-percentage：这个参数定义了执行 AOF 重写的触发条件，以百分比表示。设置为100表示只有当前 AOF 文件的大小达到了上一次重写后文件大小的 100% 时，才会触发 AOF 重写。
auto-aof-rewrite-min-size：这个参数定义了 AOF 重写的最小文件大小。设置为 64MB 表示 即使达到了上一次重写后文件大小的指定百分比，但当前 AOF 文件大小未超过 64MB ，Redis 不会执行 AOF 重写。
4、redis 主从：
(1) 简介：
redis 配置主从结构，一是为了冗余备份，二是为了提升读性能。主从架构中，可以关闭主服务器的数据持久化功能，只让从服务器进行持久化，这样可以提高主服务器的处理性能。 同时从服务器通常被设置为只读模式，这样可以避免从服务器的数据被误修改。
(2) redis 主从同步原理：
① 全量同步（Initial Sync）：
● 当从节点连接到主节点时，它会发送同步命令（SYNC）来请求与主节点进行同步。
● 主节点接收到同步命令后，开始创建一个快照（snapshot），在创建快照期间，主节点继续处理写命令，但会将这些写命令缓存起来。
● 主节点生成快照的同时，将快照文件发送给从节点。
● 从节点接收到快照文件后，会加载这个快照文件并应用其中的数据，将自身数据初始化为主节点当前的状态。一旦快照加载完成，主从节点之间的初始全量同步就完成了。
② 增量同步（Incremental Sync）：
● 在初始同步后，主节点会继续处理客户端的写命令，主节点将这些写命令发送给所有连接的从节点。
● 从节点接收到主节点发送的写命令，然后在本地执行这些命令，使得从节点的数据与主节点保持同步。
● 从节点会记录每个命令的复制偏移量（replication offset），用于在中断后进行重新同步时确定接收的命令位置。
(3) 配置：
① 环境：
master:192.168.198.132
slave:192.168.198.133
② 主服务器配置：
vim /etc/redis/6379.conf
bind 0.0.0.0 ：redis 服务器监听本机所有地址
protected-mode no ：关闭保护模式
systemctl restart redis.service
③ 从服务器配置：
vim /etc/redis/6379.conf
replicaof <masterip> <masterport>
bind 0.0.0.0
protected-mode no
systemctl restart redis.service
④ 测试：
132：
133：
(4) redis常见性能问题和解决方案：
① Master最好不要做任何持久化工作，如RDB内存快照和AOF日志文件；
② 如果数据比较重要，某个Slave开启AOF备份数据，策略设置为每秒同步一次；
③ 为了主从复制的速度和连接的稳定性，Master和Slave最好在同一个局域网内；
④ 主从复制用单向链表结构更为稳定，即：Master(写) ← Slave1(读) ← Slave2(读) ← Slave3(读) ... 这样的结构方便解决单点故障问题，如果Master挂了，可以立刻启用Slave1做Master，其他不变。
5、redis-sentinel（哨兵模式）：
(1) 概念：
redis sentinel是 redis 分布式系统中用于实现高可用性的组件。它能够监控和管理Redis实例，确保Redis系统在出现故障或不可用情况时能够自动进行故障转移，保持系统的连续性和可用性。
(2) 作用：
① Master状态检测；
② 如果Master异常，则会进行Master-Slave切换，将其中一个Slave作为Master，将之前的Master作为Slave。
(3) 工作原理：
① 每秒发送PING命令：每个redis sentinel进程都会以每秒一次的频率向它所知道的主节点、从节点以及其他sentinel实例发送PING命令，验证节点的可达性和健康状态；
② 主观下线：当一个实例（如主节点或从节点）距离最后一次有效回复PING命令的时间超过了在配置中设置的 down-after-milliseconds 的值时，这个实例会被Sentinel标记为“主观下线”，即Sentinel认为这个实例可能出现了故障；
③ 确认主观下线状态：当一个Master节点被标记为主观下线时，所有监视这个Master的Sentinel都会以每秒一次的频率确认这个Master节点是否确实处于主观下线状态；
④ 客观下线：当有足够数量的Sentinel确认Master节点已经进入了主观下线状态时，Master会被标记为“客观下线”。这表示多数Sentinel节点都认为Master节点已经出现了故障，需要进行故障转移操作。
(4) 配置：
① 在主、从上修改 sentinel 配置文件：
vim redis-7.0.14/sentinel.conf
● sentinel monitor mymaster 192.168.198.132 6379 2
指定sentinel实例监控的节点名、ip和端口，2 表示至少需要2个Sentinel节点达成一致认为主节点失效，才会触发故障转移。
● sentinel down-after-milliseconds mymaster 3000
如果sentinel在3000ms后没有收到与主节点的PING响应，就会将该节点标记为主观下线。
● sentinel failover-timeout mymaster 10000
sentinel在10秒的时间内尝试完成整个故障转移操作
● protected-mode no
② 主、从服务器启动 sentinel 服务：
③ 停止主服务器，观察从服务器：
132：systemctl stop redis
133：
主从状态发生变化：
