memcache&redis构建缓存服务器

一、缓存服务器：

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

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：

主从状态发生变化：