一、Redis简介与部署方式概览
Redis可以说是当前后端开发中不可或缺的核心组件之一。作为一个高性能的键值存储系统，它支持字符串、列表、哈希等多种数据结构，在缓存、消息队列、分布式锁等应用场景中扮演着至关重要的角色。
不过，Redis的具体部署方式其实颇有门道。根据对可用性、扩展性和性能的不同需求，业界主要形成了四种部署模式：
- 单机部署：简单直接，适合开发测试环境快速验证。
- 主从部署：数据具备冗余能力，同时支持读写分离，读性能显著提升。
- 哨兵部署：在主从基础上引入自动故障转移，可用性大幅提高。
- 集群部署：数据分片结合高可用机制，是大规模、高并发场景下的首选方案。
接下来，我们将从头到尾逐一梳理每种部署方式的安装、配置与操作步骤。
二、环境准备（通用步骤）
2.1 系统要求
- Linux操作系统，建议使用CentOS 7+ 或 Ubuntu 18.04+
- GCC编译环境必须提前安装（Redis采用C语言编写，需编译安装）
- 主从、集群各节点之间网络需保持互通
2.2 安装GCC
# 先检查gcc是否已安装gcc --version# 若未安装，直接用包管理器安装yum install gcc -y # CentOSapt install gcc -y # Ubuntu
2.3 关闭防火墙（测试环境建议）
systemctl stop firewalld.servicesystemctl disable firewalld# 或者使用firewall-cmd放行所需端口也可
这部分配置虽然基础，但不少人在前期就卡在这些细节上。
三、单机部署
3.1 下载与编译
mkdir -p /opt/software/rediscd /opt/software/redis# 获取最新稳定版本wget https://download.redis.io/redis-stable.tar.gztar -xzf redis-stable.tar.gzcd redis-stable# 编译并安装make install
3.2 检查安装
ll /usr/local/bin/redis-*
安装成功后，应能看到以下几个关键文件：
redis-server：服务端核心程序redis-cli：客户端，日常操作的主要工具redis-sentinel：哨兵程序redis-benchmark：性能压测工具
3.3 配置与启动
编辑 redis.conf 文件，这是Redis的灵魂配置文件：
vim redis.conf
配置项看似简单，但有几处细节务必注意：
bind * -::* # 允许所有IP连接，生产环境需谨慎protected-mode no # 关闭保护模式daemonize yes # 后台运行，避免窗口一直挂起logfile /opt/software/redis/redis-stable/redis.logdir /opt/software/redis # 持久化文件存放目录requirepass 1qaz@WSX # 设置密码，强烈建议生产环境配置
启动服务：
redis-server redis.confredis-cli -a 1qaz@WSX # 带密码连接测试
3.4 常用命令
keys * # 查看所有键，生产环境谨慎使用auth 密码 # 认证登录quit # 退出连接redis-cli shutdown # 关闭服务，先shutdown再kill
单机部署本身难度不高，但它是后续所有复杂模式的基础。熟练掌握配置文件和启动方式，后面会更顺畅。
四、主从部署（Master-Slave）
4.1 架构说明
主从模式在实际项目中非常普遍，其核心逻辑是：
- 一个主节点负责写入操作，多个从节点同步数据并提供读取服务
- 主节点可写，从节点默认只读
- 若主节点宕机，需要人工切换——这是主从与哨兵方案最大的区别
4.2 配置从节点
在从节点的 redis.conf 中添加以下两行：
replicaof 192.168.75.129 6379 # 指定主节点IP和端口masterauth 1qaz@WSX # 如果主节点设置了密码，此处必须填写正确
4.3 查看主从信息
在主节点上执行：
redis-cli -a 1qaz@WSX info replication
输出中可以看到 connected_slaves 的数值，以及各从节点的详细信息。若该数值为0，说明配置存在问题，需回头检查网络连通性和密码设置。
主从配置的关键点，简而言之就是从节点必须明确“我去哪里找主节点”以及“主节点的密码是什么”。
五、哨兵部署（Sentinel）
5.1 哨兵作用
主从模式解决了读写分离与数据冗余的问题，但人工切换主节点在生产环境中堪称噩梦。哨兵的引入正是为了消除这一痛点：
- 持续监控主从节点的健康状态
- 当主节点宕机时，自动从从节点中选举出一个“新主节点”
- 将新主节点的地址通知给客户端
5.2 哨兵配置
编辑 sentinel.conf 文件，哨兵的配置比Redis主配置更简洁：
protected-mode noport 26379daemonize yeslogfile /opt/software/redis/redis-stable/sentinel.logdir /opt/software/redis# 监控的主节点，最后的2表示至少需要2个哨兵达成一致才判定主节点下线sentinel monitor mymaster 192.168.75.129 6379 2sentinel down-after-milliseconds mymaster 30000sentinel failover-timeout mymaster 180000
5.3 启动哨兵
redis-sentinel sentinel.conf
5.4 查看哨兵状态
redis-cli -p 26379 info sentinel
5.5 故障模拟与恢复
光说不练假把式。可以尝试手动停止主节点：
- 观察哨兵日志，查看它如何发现故障、发起选举并选出新主节点
- 重新启动原主节点，会发现它已自动变为新主节点的从节点
这就是“自动故障转移”，在生产环境中依靠它来保证服务不中断。
不过，哨兵模式也存在一个潜在风险：如果写入的数据尚未同步到从节点，切换过程中这部分数据可能会丢失。因此，对数据一致性要求极高的场景，还需要额外的设计来保障。
六、集群部署（Cluster）
6.1 集群特点
当数据量过大，单机内存已无法支撑，或并发量极高导致单机CPU满载时，集群就派上了用场。集群将数据分散到多个节点，每个节点只负责一部分数据：
- 数据分片：总共16384个哈希槽，每个节点管理一部分槽位
- 高可用：每个分片可配置一个从节点，实现自动故障转移
- 水平扩展：增加机器即可扩容，无需停机
6.2 集群配置（三主三从示例）
这里使用三台机器，每台机器运行两个Redis实例：一个主节点（6379端口），一个从节点（6380端口）。当然，也可以将三主三从分布在六台机器上，效果更佳。
配置文件示例 redis_6379.conf，与单机模式相比，关键区别在于开启了集群支持：
bind * -::*protected-mode noport 6379daemonize yescluster-enabled yescluster-node-timeout 5000dir /opt/software/redis/clusterappendonly yeslogfile "/opt/software/redis/redis-stable/cluster/redis6379.log"cluster-config-file nodes-6379.conf
同理，为6380端口准备一份配置文件，只修改端口和文件名即可。
6.3 启动所有节点并创建集群
# 依次启动所有节点redis-server ./cluster/redis_6379.confredis-server ./cluster/redis_6380.conf# 创建集群，--cluster-replicas 1 表示每个主节点配一个从节点redis-cli --cluster create \ --cluster-replicas 1 \ 192.168.75.129:6379 192.168.75.129:6380 \ 192.168.75.131:6379 192.168.75.131:6380 \ 192.168.75.132:6379 192.168.75.132:6380
6.4 集群常用命令
redis-cli cluster info # 查看集群整体状态redis-cli cluster nodes # 列出所有节点及角色redis-cli -c # 以集群模式连接，自动处理数据重定向
6.5 故障转移测试
尝试停止某个主节点，观察其从节点是否会在一段时间后自动晋升为主节点。之后再将原主节点重新加入集群，它会自动作为从节点重新接入。
集群部署的每一步都环环相扣，端口规划、配置文件路径、节点间的网络互通，任何一处出错都可能导致集群创建失败。最常见的问题包括端口未放行以及配置文件中目录写错导致日志文件无法生成。
七、配置文件与命令汇总
7.1 核心配置文件路径
不同模式使用的配置文件不同，切勿混淆：
- 单机/主从：
/opt/software/redis/redis-stable/redis.conf - 哨兵：
/opt/software/redis/redis-stable/sentinel.conf - 集群：
/opt/software/redis/redis-stable/cluster/redis_{port}.conf
7.2 常用命令速查
# 服务管理redis-server xxx.confredis-cli shutdownps aux | grep redis# 集群操作redis-cli --cluster create ...redis-cli cluster nodesredis-cli -c# 数据操作keys *set/get/delauth 密码info replication
这些命令非常实用，但请牢记：keys * 在生产环境的线上数据库上切勿随意执行，数据量大时会直接阻塞服务。
八、部署建议与注意事项
选择哪种部署模式，最终取决于业务的具体需求。下表可助您快速决策：
| 部署方式 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 单机 | 开发、测试 | 简单快捷 | 无高可用，性能受限 |
| 主从 | 读多写少，数据备份 | 读写分离，数据冗余 | 故障需人工干预 |
| 哨兵 | 高可用，自动故障转移 | 自动切换，客户端透明 | 配置复杂，数据可能丢失 |
| 集群 | 大数据量，高并发，高可用 | 数据分片，水平扩展 | 部署复杂，运维成本高 |
8.1 安全建议
安全问题是老生常谈，但真正出事的往往就是忽略了这些基础细节：
- 生产环境中密码必须设置，不要心存侥幸
- 使用防火墙严格限制允许访问Redis的IP范围
- 定期备份RDB或AOF文件，数据无价
8.2 性能调优建议
部署只是开始，合理使用才是关键：
- 根据内存容量与业务场景选择持久化方式——RDB适合备份，AOF适用于高数据完整性要求
- 合理设置
maxmemory和内存淘汰策略，防止OOM导致进程崩溃 - 监控慢查询日志与内存碎片，及时进行优化和重写
九、总结
Redis的部署方式虽然多样，但选择并不复杂，核心是从业务场景出发：
- 学习与开发阶段，单机即可满足，不必为了炫技而上集群
- 小型项目，主从加哨兵是最经典、性价比最高的组合
- 中大型高并发系统，集群才是正解
从单机到集群，不仅是配置文件的增加，更是对可用性、扩展性和运维成本的全面权衡。希望本文能帮助您将Redis部署从“能跑”提升到“跑稳”的水平。
