Lamp架构(4))
Redis
Redis介绍:
Redis（Remote Dictionary Server）远程字典服务
开源、使用 ANSI C 编写的 键值对（Key-Value）内存数据库。
常被称为缓存数据库，但不只是缓存。
基于内存读写，性能极高
支持多种数据结构（不只是字符串）
可选持久化，防止断电数据丢失
支持网络访问，C/S 架构
定位：NoSQL、内存数据库、缓存中间件、消息队列
核心特点:
高性能
数据主要存放内存，单线程处理命令（6.x 后支持多线程 IO），单机轻松 10 万 + QPS。
丰富的数据类型
String 字符串
List 列表（双向链表）
Set 无序集合
ZSet 有序集合
Hash 哈希（对象存储）
Stream、BitMap、HyperLogLog、Geo
两种持久化机制（防止内存数据丢失）
RDB：定时全量快照，二进制文件，恢复速度快
AOF：记录每条写命令日志，安全性更高
高可用方案:
主从复制（Master-Slave）
Sentinel（哨兵）：自动故障转移
Redis Cluster（集群）：分片 + 高可用，横向扩容
典型使用场景:
热点数据缓存（最常用）
减轻 MySQL 压力，查询先查 Redis，未命中再查数据库。
会话存储 Session
分布式系统共享登录会话。
计数器、限流
访问量统计、接口频率限流（INCR 命令）。
排行榜
ZSet 有序集合实现热度榜单。
消息队列
List 简易队列、Stream 可靠队列。
分布式锁
SETNX + 过期时间实现分布式锁。
地理位置计算 Geo
附近的人、距离计算。
Redis 重要架构:
1. 主从复制（Replication）
一主多从，主节点负责写，从节点负责同步数据、承担读请求
异步复制；从节点默认只读
缺点：主宕机无法自动切换，需要哨兵
2. 哨兵 Sentinel
独立进程，监控主从节点
自动检测节点下线
主节点故障时，自动选举新主，修改其他从节点指向新 master
对外提供统一访问地址
3. Redis Cluster 集群（分片集群）
一共 16384 个哈希槽，数据按槽分配到不同主节点
每个主节点搭配从节点实现高可用
支持水平扩容，解决单机内存上限问题
优缺点:
✅ 优点
速度极快
数据结构丰富
功能齐全，生态成熟
部署简单，运维资料多
❌ 缺点
内存成本高，大量数据存放内存开销大
持久化有一定性能损耗
不适合海量冷数据长期存储
集群事务支持有限（不支持跨槽事务）
Redis部署:
首先对四台主机进行清理的处理为了良好的实验环境
下载redis安装包并make并make install
进入until/里面有redis脚本若直接执行则会提示本系统不合适
因此进入脚本然后注释掉相关内容
此时执行脚本不会报错
此时通过脚本自动安装成功并自动配置路径等属性
此时可以观察到端口已经成功连接
进入配置文件进行编辑
之后重启服务然后查看端口, 允许所有IP访问并且默认登录本机
Info查看整个redis的信息
redis常用指令：
config get * //查看配置
select 1 //选择数据库
flushdb //清空当前数据库
flushall //清空所有数据库
set name wxh //设置key的值
move key 1 //移动key
del key //删除
rename oldkey newkey //改名
expire key 10 //设置过期时间
persist key //设置持久化
keys user* //查询
exists key //判断是否存在
redis主从复制
核心概念:
Redis 主从复制：一个主节点（master）负责写，多个从节点（slave/replica）同步主节点数据，实现读写分离、数据热备份。
核心作用:
读写分离：主节点处理写操作，从节点处理读操作（默认只读），分担主节点压力。
数据备份：从节点实时复制主节点数据，避免单节点故障导致数据丢失。
高可用基础：结合哨兵（Sentinel）或集群（Cluster），可实现主节点故障时自动切换到从节点。
角色分工:
Master：接收写命令，持久化数据，向从节点同步数据
Replica（从库）：默认只能读、禁止写入，持续同步 master 数据
主从复制缺陷:
主从复制本身不具备自动故障转移
master 宕机，不会自动提升从库为主；需要配合 Sentinel 哨兵 实现自动切换
异步复制
默认 master 写完立刻返回客户端，不等待从库同步完成；存在数据丢失风险
单主压力瓶颈：所有写压力集中在 master
和 Mysql 主从简易对比
Redis：基于命令日志（复制缓冲区）；MySQL 基于 binlog
Redis 增量同步依靠 PSYNC；MySQL GTID
Redis 主从没有内置自动故障转移（依赖哨兵）；MGR 内置容错
完整流程:
首先server2上是没有redis的,因此rsync server1的redis-6-4目录到server2并启动安装脚本文件,成功安装redis
进入配置文件改变监听端口为本机所有并重启服务
进入配置文件设置master为192.168.81.135 端口为6379
在server2上重启服务并info查看replication,角色为slave,此时在sever1上也可以查看到master状态
测试在server1端创建name user1,此时可以在server2上get到
此时相同的将server1的redis 复制到server3 makeinstall之后安装
修改配置文件加入master
重启服务并查看replication
也可以继续在server1上查看master的replication
redis高可用
Redis 高可用核心要解决：
故障检测、主从切换、数据备份、自动恢复。
方案 | 核心组件 | 能力 | 适用场景 |
主从复制（Replication） | 主库 master、从库 slave | 数据备份、读负载均衡；无自动故障转移 | 基础环境、学习；主库挂掉需要人工切换 |
Sentinel 哨兵 | 1 主 N 从 + 3 个哨兵进程 | 自动故障转移、监控、通知 | 中小型业务，标准高可用，无分片 |
Redis‑Cluster 集群 | 多组主从哈希分片 | 分片 + 高可用，支持海量数据 | 大数据量，需要横向分片扩容 |
主从复制（Replication）
基础底座，只做数据备份，没有故障自动转移，不算是完整高可用
主节点 (master)：接收写请求，数据变更同步给从节点；可以读写。
从节点 (slave/replica)：复制 master 全部数据，默认只能读，不能写。
复制模式：
全量同步：初次建立复制，master 生成 RDB 发给从库，全量加载。
增量同步：复制偏移量 offset，主库的复制积压缓冲区，同步后续新增命令。
缺点：master 挂掉，不会自动选新主，需要人工干预，无法实现故障自动切换。
作用：读写分离、数据备份。
哨兵 Sentinel（真正实现故障自动转移，主从 + 哨兵）
在主从复制之上，引入哨兵进程，实现监控、自动故障转移、客户端服务发现
三大核心功能
监控（Monitor）：哨兵持续检测 master、slave 节点是否存活。
主观下线 SDOWN：单个哨兵认为节点无响应，单方面判定故障。
客观下线 ODOWN：超过 quorum（法定票数）个哨兵共同判定 master 故障，才确认真故障。
故障转移（Failover）
从 slave 中挑选一台升级为新 master；
其余从节点重新指向新 master；
旧 master 恢复后，降级为新 master 的从节点。
配置中心 / 服务发现：客户端连接哨兵，自动获取当前 master 地址，不需要硬编码 IP。
⚠️哨兵本身也需要集群：哨兵至少部署3 个实例，防止哨兵单点故障；奇数节点用于投票选举。
局限：哨兵模式写操作仍然只有 1 个 master，无法横向扩容写能力，只能扩容读。数据存储上限受单机内存限制。
Redis‑Cluster 集群（分片集群，高可用 + 数据分片）
Redis 3.0 之后官方分布式集群，既做高可用，又做数据分片，解决单机内存上限。
哈希槽 slot：一共 16384 个槽。key 通过 CRC16 (key)%16384 计算映射到 slot。
主分片（master）：每个 master 负责一部分哈希槽；可以写数据。
副本（slave）：每个 master 配置若干 slave，做备份。当 master 宕机，slave 提升为主节点接管槽位，实现故障转移。
客户端重定向：访问的 key 不在当前节点，返回 MOVED 重定向，客户端去正确节点读写。ASK 用于迁移槽位的临时重定向。
集群最小部署：至少3 主 3 从，保证故障转移条件。
集群两大限制
key 不能跨事务、不支持多 key 复杂操作（跨槽不支持）；
槽迁移为手动 / 自动迁移实现扩容。
完整流程:
复制文件sentinet并编辑使其监控master端
在sentinel服务启动前将文件复制到server2 server3因为启动后会自动写入文件
在三个节点启动sentinel服务
此时再开一台server1终端,然后关闭redis-cli服务
三个节点状态,此时他们选举出一个master server3节点
此时ssh登录server3可以查看master状态
此时sshserver1使server1 上线可以查看slave状态
redis集群
Twemproxy概念:
Twemproxy（也称为 nutcracker）是 Twitter 开源的一款 Redis/Memcached 代理服务器，主要用于解决 Redis 集群的客户端连接管理、负载均衡和简化集群运维等问题。它通过在客户端与 Redis 服务器之间增加一层代理，实现了对多个 Redis 实例的统一接入和管理。
核心功能:
数据分片：支持哈希分片、一致性哈希，把 key 分散到后端多台 Redis，实现数据拆分，解决单 Redis 内存上限。
协议兼容：兼容 Redis、Memcached 协议，原有客户端几乎不用修改代码。
连接池管理：复用后端 Redis 连接，减少大量客户端直连 Redis 带来的连接压力。
请求路由：根据 key 计算分片，把命令转发到对应后端 Redis 节点；支持读写。
失败剔除：后端节点挂掉，可以配置自动剔除该分片节点，但不能自动主从切换。
两种分片算法:
hash（普通取模）
key hash 之后对节点数取模。增减节点，大部分 key 会发生迁移，大量缓存失效。
ketama 一致性哈希（推荐）
虚拟环，增加 / 删除节点，只影响一小部分 key，缓存抖动更小。
优缺点:
优点
轻量，性能高，C 语言开发，性能损耗很小。
应用层几乎无改动，客户端只访问代理。
实现 Redis 水平拆分，突破单实例内存限制。
缺点
本身无高可用，单点风险，必须额外 Keepalived + 虚 IP 做双主。
不支持 Redis 复杂命令：多 key 命令如 mget、mset，如果 key 落在不同分片节点，会报错，不能跨节点操作。
不自动故障转移：后端 Redis 挂了，只能剔除分片，不会自动切换它的从库，需要运维手动处理。
不支持数据迁移、重分片：节点扩容缩容需要手动处理数据，不能在线平滑扩缩容。
不支持 Redis 集群原生 cluster 协议，和 Redis‑Cluster 是两套方案。
对比项 | Twemproxy | Redis‑Cluster |
角色 | 第三方代理中间件 | Redis 官方内置集群 |
分片实现 | 代理层做分片 | Redis 节点自身分片 |
高可用 | 无，依赖外部 Keepalived | 内置主从 + 故障转移 |
多 key 命令 | 跨分片不支持 | 支持部分 hash‑tag 多 key |
扩缩容 | 不能在线平滑迁移 | 支持在线 reshard 迁移数据 |
单点风险 | 代理是单点 | 无中心，无单点 |
版本依赖 | 任意 Redis 版本 | Redis3.0+ |
和 Redis‑Cluster、哨兵 (Sentinel) 区别
Sentinel 哨兵：只做主从高可用故障转移，不做分片；所有数据全量存在主库，从库备份，不能拆分数据。
Twemproxy：做分片，不做故障转移；数据拆分多实例，高可用需要外部组件。
Redis‑Cluster：分片 + 内置故障转移，官方方案。
Redis cluster
和Twemproxy 区别：分片逻辑在 Redis 节点内部完成，不需要第三方代理，客户端直接和 Redis 节点通信。
概念:
Redis Cluster（Redis 集群）是 Redis 官方提供的分布式解决方案，专为解决大规模场景下的数据分片、高可用和水平扩展问题而设计。它通过去中心化架构，将数据分散到多个节点，同时提供自动故障转移能力，适合数据量大、访问频繁的生产环境。
Redis3.0 之后官方推出的分布式分片集群方案，实现数据分片 + 内置高可用故障转移，无中心代理。
把整个集群一共划分 16384 个哈希槽 (slot)，所有 slot 分配给集群中的主节点；key 通过 hash 运算映射到 slot，key 存到持有该槽的主节点上。
架构组成:
Master 主节点：负责读写，持有一部分哈希槽。
Slave 从节点：对应主节点的副本，不分配槽，只做备份。当主宕机，从自动升级为主，接管槽，实现故障转移。
Gossip 协议：集群节点之间互相通信，交换节点状态、槽分配、故障信息。
哈希槽 slot:
总槽位：16384（0‑16383）
每个主节点分配一部分连续 / 离散 slot
CRC16(key) % 16384 计算 key 属于哪个槽
key 必须存到该槽归属的 master；客户端可以任意连接节点，节点会返回‑MOVED重定向，指引客户端访问正确节点
hash‑tag
用{tag}，例如 {user100}:name，大括号内部内容参与 hash 计算。
多个 keytag 相同，映射到同一个 slot，可以支持 mget/mset 多 key 操作。
优缺点
✅优点
官方原生，无第三方代理，无单点故障。
分片 + 高可用一体化，主宕机从自动切换。
支持在线 reshard，平滑扩缩容。
Gossip 协议维护集群元数据。
❌缺点
至少需要 3 主 3 从，资源消耗多。
不支持跨 slot 多 key 命令，除非使用 hash‑tag。
集群模式下部分 Redis 命令受限。
客户端必须支持 cluster 协议，普通单机 redis‑client 不能直接使用。
集群脑裂风险，需要配置cluster‑require‑full‑coverage yes，槽不全拒绝写入。
方案 | 分片能力 | 故障转移 | 是否有单点 | 定位 |
Sentinel 哨兵 | ❌不分片，全量数据 | ✅自动主从切换 | 无（哨兵多实例） | 只做高可用，不能拆分数据 |
Twemproxy | ✅代理层分片 | ❌不自动切换后端 | ✅代理单点，需 Keepalived | 第三方代理分片 |
Redis‑Cluster | ✅节点内 slot 分片 | ✅内置故障转移 | ❌无中心 | 官方分片 + 高可用 |
流程:
在server1上先停止redis服务,然后查看并启动脚本,启动后会自动生成数据和日志
创建cluster时将16383个哈希平均发到3个子节点
输入yes后自动匹配哈希
获取集群状态
连接30001
写入数据并查询
此时如果挂掉30002则30005成为了master
再次运行脚本,则会启动30002
添加集群节点
新添加的节点没有hash槽，角色时是master
[root@server1 create-cluster]# redis-cli --cluster add-node 127.0.0.1:30007 127.0.0.1:30001
添加slave节点
[root@server1 create-cluster]# redis-cli --cluster add-node 127.0.0.1:30008 127.0.0.1:30001 --cluster-slave --cluster-master-id 2cfe812f247254aa593f07bcc5e15291b77ecef6
迁移hash槽
