RedisRedis介绍:RedisRemote 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-SlaveSentinel哨兵自动故障转移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 //移动keydel 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 基于 binlogRedis 增量同步依靠 PSYNCMySQL GTIDRedis 主从没有内置自动故障转移依赖哨兵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的replicationredis高可用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 是两套方案。对比项TwemproxyRedis‑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 ClusterRedis 集群是 Redis 官方提供的分布式解决方案专为解决大规模场景下的数据分片、高可用和水平扩展问题而设计。它通过去中心化架构将数据分散到多个节点同时提供自动故障转移能力适合数据量大、访问频繁的生产环境。Redis3.0 之后官方推出的分布式分片集群方案实现数据分片 内置高可用故障转移无中心代理。把整个集群一共划分 16384 个哈希槽 (slot)所有 slot 分配给集群中的主节点key 通过 hash 运算映射到 slotkey 存到持有该槽的主节点上。架构组成:Master 主节点负责读写持有一部分哈希槽。Slave 从节点对应主节点的副本不分配槽只做备份。当主宕机从自动升级为主接管槽实现故障转移。Gossip 协议集群节点之间互相通信交换节点状态、槽分配、故障信息。哈希槽 slot:总槽位163840‑16383每个主节点分配一部分连续 / 离散 slotCRC16(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[rootserver1 create-cluster]# redis-cli --cluster add-node 127.0.0.1:30007 127.0.0.1:30001添加slave节点[rootserver1 create-cluster]# redis-cli --cluster add-node 127.0.0.1:30008 127.0.0.1:30001 --cluster-slave --cluster-master-id 2cfe812f247254aa593f07bcc5e15291b77ecef6迁移hash槽