CentOS 编译安装 Redis 6.2.1 并部署多实例（单服务器）

一、前言

本文基于 CentOS 系统，完整记录 Redis 6.2.1 手动编译安装过程（解决 jemalloc 编译报错），并实现单服务器部署两个独立 Redis 实例（6379/6380），无需创建多个 Linux 系统，核心是通过「配置隔离」实现实例独立运行。

二、环境准备

  • 系统：CentOS（7/8 均可）
  • 权限：root 用户
  • 依赖：GCC 编译工具（Redis 基于 C 语言开发）

三、Redis 6.2.1 编译安装（解决 jemalloc 报错）

3.1 下载并解压 Redis 安装包

# 1. 创建安装目录（自定义，本文用 /root/lamp） mkdir -p /root/lamp && cd /root/lamp # 2. 安装 wget（若未安装） yum install -y wget # 3. 下载 Redis 6.2.1 源码包 wget http://download.redis.io/releases/redis-6.2.1.tar.gz # 4. 解压压缩包 tar -zxvf redis-6.2.1.tar.gz && cd redis-6.2.1

3.2 安装 GCC 编译工具

yum install -y gcc

3.3 编译安装（解决 jemalloc 报错）

直接make可能出现以下报错：

In file included from adlist.c:34:
zmalloc.h:5B:31: warning: jemalloc/jemalloc.h: No such file or directory
zmalloc.h:55:2: error: #error "Newer version of jemalloc required"
make: *** [adlist.ol Error 1

解决方法：清理编译残留 + 指定系统 malloc 编译

# 1. 清理之前的编译残留 make distclean # 2. 重新编译（指定使用系统 libc 代替 jemalloc） make MALLOC=libc # 3. 执行安装（将 redis-server/redis-cli 等命令安装到系统路径） make install

3.4 验证安装

# 检查 redis-server 路径 which redis-server # 输出：/usr/local/bin/redis-server # 检查版本 redis-server -v # 输出：Redis v6.2.1

四、部署两个独立 Redis 实例（6379/6380）

核心思路：为每个实例配置「独立端口、配置文件、数据目录、日志文件」，实现隔离运行。

4.1 创建实例隔离目录

# 创建实例1（6379）、实例2（6380）的配置/数据/日志目录 mkdir -p /root/lamp/redis_instance/{6379,6380}/{conf,data,log} # 复制默认配置文件到实例目录 cp /root/lamp/redis-6.2.1/redis.conf /root/lamp/redis_instance/6379/conf/redis_6379.conf cp /root/lamp/redis-6.2.1/redis.conf /root/lamp/redis_instance/6380/conf/redis_6380.conf

4.2 修改实例配置文件（核心：隔离关键参数）

4.2.1 实例 1（6379）配置：/root/lamp/redis_instance/6379/conf/redis_6379.conf

编辑文件，修改以下关键项（其余保持默认）：

# 端口（默认6379） port 6379 # 守护进程启动（后台运行，避免终端关闭停服务） daemonize yes # 数据存储目录 dir /root/lamp/redis_instance/6379/data # 日志文件路径 logfile "/root/lamp/redis_instance/6379/log/redis_6379.log" # PID文件（避免冲突） pidfile "/var/run/redis_6379.pid" # 关闭保护模式（测试环境，生产环境建议设密码） protected-mode no # 可选：设置访问密码 requirepass "redis6379"

批量替换脚本：

#无身份校验 sed -i -e 's/^port .*/port 6379/' -e 's/^daemonize .*/daemonize yes/' -e 's/^dir .*/dir \/root\/lamp\/redis_instance\/6379\/data/' -e 's/^logfile .*/logfile "\/root\/lamp\/redis_instance\/6379\/log\/redis_6379.log"/' -e 's/^pidfile .*/pidfile "\/var\/run\/redis_6379.pid"/' -e 's/^protected-mode .*/protected-mode no/' /root/lamp/redis_instance/6379/conf/redis_6379.conf

替换前建议先备份：

# 备份6379配置 cp /root/lamp/redis_instance/6379/conf/redis_6379.conf /root/lamp/redis_instance/6379/conf/redis_6379.conf.bak

检查替换结果：

# 验证6379实例配置 grep -E 'port|daemonize|dir|logfile|pidfile|protected-mode|requirepass' /root/lamp/redis_instance/6379/conf/redis_6379.conf
4.2.2 实例 2（6380）配置：/root/lamp/redis_instance/6380/conf/redis_6380.conf

核心修改端口和路径，其余同实例 1：

# 端口改为6380（唯一） port 6380 daemonize yes # 实例2数据目录 dir /root/lamp/redis_instance/6380/data # 实例2日志文件 logfile "/root/lamp/redis_instance/6380/log/redis_6380.log" # 实例2 PID文件 pidfile "/var/run/redis_6380.pid" protected-mode no # 实例2密码（可不同） requirepass "redis6380"

批量替换脚本：

# 6380实例配置自动替换脚本 sed -i -e 's/^port .*/port 6380/' -e 's/^daemonize .*/daemonize yes/' -e 's/^dir .*/dir \/root\/lamp\/redis_instance\/6380\/data/' -e 's/^logfile .*/logfile "\/root\/lamp\/redis_instance\/6380\/log\/redis_6380.log"/' -e 's/^pidfile .*/pidfile "\/var\/run\/redis_6380.pid"/' -e 's/^protected-mode .*/protected-mode no/' /root/lamp/redis_instance/6380/conf/redis_6380.conf

替换前建议先备份：

# 备份6380配置 cp /root/lamp/redis_instance/6380/conf/redis_6380.conf /root/lamp/redis_instance/6380/conf/redis_6380.conf.bak

检查替换结果：

grep -E 'port|daemonize|dir|logfile|pidfile|protected-mode' /root/lamp/redis_instance/6380/conf/redis_6380.conf

4.3 启动两个 Redis 实例

# 启动实例1（6379） redis-server /root/lamp/redis_instance/6379/conf/redis_6379.conf # 启动实例2（6380） # 方式1：新开终端（Alt+F2 切换到 tty2）执行 redis-server /root/lamp/redis_instance/6380/conf/redis_6380.conf # 方式2：直接在当前终端后台启动（推荐） redis-server /root/lamp/redis_instance/6380/conf/redis_6380.conf

4.4 验证实例运行状态

4.4.1 查看 Redis 进程
ps -ef | grep redis-server
4.4.2 连接实例测试隔离性

  • 连接 6379 实例：

    redis-cli -p 6379 127.0.0.1:6379> auth redis6379 # 输入密码（若设置） OK 127.0.0.1:6379> set test6379 "hello6379" OK 127.0.0.1:6379> get test6379 "hello6379"

  • 连接 6380 实例：

    redis-cli -p 6380 127.0.0.1:6380> auth redis6380 OK 127.0.0.1:6380> get test6379 # 查不到6379的键，隔离成功 (nil) 127.0.0.1:6380> set test6380 "hello6380" OK

五、常用操作命令

5.1 停止实例

# 停止6379实例 redis-cli -p 6379 -a redis6379 shutdown # 停止6380实例 redis-cli -p 6380 -a redis6380 shutdown

5.2 重启实例

先停止实例，再重新执行启动命令：

# 重启6379实例 redis-server /root/lamp/redis_instance/6379/conf/redis_6379.conf

六、总结

单台 CentOS 服务器部署多个 Redis 实例的核心是「配置隔离」，无需重复编译安装 Redis，只需为每个实例分配独立端口、配置文件和数据目录即可。本文从编译安装到多实例部署全程实操，解决了常见的 jemalloc 编译报错，适合 Redis 入门学习者参考。

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.mzph.cn/news/1028150.shtml

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

PY可拓展计算机（自用）

PY可拓展计算机（自用）

前言进来一段时间，偶尔会遇到一些需要特殊计算的常见，比如计算mm转mil，比如给螺旋线的高度匝数半径，计算螺旋线长度等，一次一次输数字手算是绝对不可能，一般简单点比如单位转化都是直接问AI，复杂…
阅读更多...
2025年Go加密安全爆料：你的系统真的安全吗？量子威胁早就来了！

2025年Go加密安全爆料：你的系统真的安全吗？量子威胁早就来了！

开头：震撼现实 想象一下，有人现在就在录制你的加密通信，用来等待未来的量子计算机。这不是科幻小说，这是真实发生的 “现在记录，未来解密” 攻击——密码学中最恐怖的威胁。 2025年对Go开发者来说是个转折点：NIST终于敲定了后量子密码标准。Go 1.24刚刚把ML-KEM（量子抗…
阅读更多...
图像生成的新拐点：谷歌Nano Banana Pro的四大革命性突破与战略价值

图像生成的新拐点：谷歌Nano Banana Pro的四大革命性突破与战略价值

谷歌的最新图像生成模型 Nano Banana Pro (NBP) 的发布，标志着 AI 图像生成技术正式跨越了从“创造艺术”到“创造实用价值”的门槛。它不仅仅是一个出图工具，更是谷歌在 AI 时代对效率、专业控制和生态整合发起的一次战略性挑战。 我们将从四个核心维度…
阅读更多...
基于C# WinForm实现的仿微信打飞机游戏

基于C# WinForm实现的仿微信打飞机游戏

一、游戏架构设计 1. 分层架构模型 // 游戏主框架 public class GameForm : Form {private GameEngine engine;private SpriteManager spriteManager;protected override void OnLoad(EventArgs e) {engine new GameEngine(this);spriteManager new SpriteManager();Initiali…
阅读更多...
论文翻译：Understanding Oversquashing in GNNs through the Lens of Effective Resistance

论文翻译：Understanding Oversquashing in GNNs through the Lens of Effective Resistance

论文逐段翻译 详细讲解（含公式 / 图表作用） 摘要（Abstract） 翻译 消息传递图神经网络（GNN）是处理图结构数据的热门学习架构。然而，GNN 存在一个问题 —— 过挤压（oversquashing&…
阅读更多...
团队冗余与人员精简策略

团队冗余与人员精简策略

团队冗余是指组织中存在超出业务实际需求的、低效或错配的人力资源；而人员精简（Downsizing）则是应对这种冗余的战略性管理手段。其核心目的并非“裁员”本身，而是通过“去脂增肌”的组织重构，使团队恢复敏捷、聚焦核心…
阅读更多...
实验作业5

实验作业5

实验任务1 代码 publisher.cpp#include <iostream> #include <string> #include "publisher.hpp"// Publisher类：实现 Publisher::Publisher(const std::string &name_): name {name_} { }…
阅读更多...
Docker容器化实践：从开发到生产的完整流程

Docker容器化实践：从开发到生产的完整流程

前言 "在我电脑上能跑啊&#xff01;"这句话曾经是我们团队的口头禅。环境不一致导致的问题层出不穷&#xff0c;直到我们引入了Docker。 这篇文章分享我们的Docker实践经验。 一、为什么选择Docker&#xff1f; 1.1 传统部署的痛点 bash # 开发环境 Python 3.8 …
阅读更多...
Python+Vue的校园自助洗衣服务管理系统 Pycharm django flask

Python+Vue的校园自助洗衣服务管理系统 Pycharm django flask

收藏关注不迷路&#xff01;&#xff01;需要的小伙伴可以发链接或者截图给我 项目介绍 本系统共有管理员,用户2个角色&#xff0c;具体功能如下&#xff1a; 1.管理员角色的功能主要包括管理员登录&#xff0c;用户管理&#xff0c;洗衣机分类管理&#xff0c;洗衣机管理&…
阅读更多...
Vosk开源语音识别：50MB离线神器，树莓派到手机全搞定

Vosk开源语音识别：50MB离线神器，树莓派到手机全搞定

文章概要 Vosk是一款由阿尔汉格尔斯克国立技术大学团队开发的开源、离线优先语音识别工具包。其核心优势在于模型轻量、支持多语言且完全本地运行&#xff0c;无需网络连接。本文将解析Vosk如何在嵌入式设备和隐私敏感场景下&#xff0c;以极低的资源占用成为云端服务的替代方案…
阅读更多...
大头针AI爆火背后：音乐创作平民化与华语乐坛的算法革命

大头针AI爆火背后：音乐创作平民化与华语乐坛的算法革命

近期&#xff0c;由酷狗音乐阿波罗声音实验室打造的AI虚拟歌手“大头针”凭借翻唱经典歌曲在抖音等平台爆火&#xff0c;单月涨粉超38万。其现象级传播不仅展示了生成式AI在音乐领域的强大能力&#xff0c;更引发了关于创作门槛崩塌、版权归属模糊及人类歌手价值存疑的深层争议…
阅读更多...
模型推理 单多轮推理，gpu推理，lora推理和vllm(附代码示例)

模型推理 单多轮推理，gpu推理，lora推理和vllm(附代码示例)

模型推理 单多轮推理&#xff0c;gpu推理&#xff0c;lora推理和vllm 一、大语言模型推理基础 1. 推理与训练的核心差异 维度 模型训练 模型推理 硬件需求 需强大GPU集群、海量存储 硬件需求较低&#xff0c;支持CPU/GPU 计算逻辑 反向传播梯度下降&#xff0c;计算量大 仅前…
阅读更多...
为什么Anthropic说：AI的未来是Skills不是Agent？

为什么Anthropic说：AI的未来是Skills不是Agent？

随着AI智能体&#xff08;Agent&#xff09;技术的快速演进&#xff0c;当前开发领域普遍存在一种认知偏差&#xff1a;针对不同细分场景和具体用例&#xff0c;开发者倾向于从零开始创建独立的Agent。 Anthropic公司的Barry Zhang与Mahesh Murag在近期演讲中颠覆了这一传统思…
阅读更多...
A7.4.8 Response signaling

A7.4.8 Response signaling

1. 原子操作完成的可见性定义 规则： 写响应（B通道）表明原子操作的结果已对所有必需观察者可见。 对于包含读响应的原子操作（AtomicLoad/Swap/Compare），从接收到第一个读数据项时起，操作结果就可见。 管理器可使用读响应或写响应中的任意一个作为操作完成的指示。 举例…
阅读更多...
AXI-A7.4.9 Atomic transaction dependencies

AXI-A7.4.9 Atomic transaction dependencies

这些规则定义了在执行AtomicLoad、AtomicSwap和AtomicCompare事务时，管理器（Master）和从设备（Subordinate）之间握手信号（VALID和READY）的时序约束。其核心目标是在保证原子操作正确性的前提下，最大限度地维持AXI协议的流水线化和通道独立性优势。 信号依赖关系核心原则…
阅读更多...
AXI-A7.4.10 Support for Atomic transactions(1)

AXI-A7.4.10 Support for Atomic transactions(1)

Atomic_Transactions 属性是一个简单的布尔标志，用于明确声明一个AXI接口组件（可以是管理器、从设备或互连组件）是否支持原子事务扩展功能。其核心规定如下： 属性值： True：该组件完全支持原子事务。 False：该组件不支持原子事务（此为默认值）。 关键要求：如果一个组…
阅读更多...
AXI-A7.4.10 Support for Atomic transactions(2)

AXI-A7.4.10 Support for Atomic transactions(2)

Manager support 该部分描述了AXI协议中，管理器（Manager，如CPU、DMA等主设备）对原子事务的一种向后兼容性支持机制。其核心在于，即使一个管理器本身具备发起原子事务的能力，它也可以被配置为不发起这类事务，以确保在不支持原子操作的旧系统中能正常工作。这是通过一个可…
阅读更多...
关于xml动态sql的思路

关于xml动态sql的思路

要灵活使用动态sql&#xff0c; 除了掌握sql的语法&#xff0c;还要掌握&#xff0c;如何灵活使用动态sql的时机。 我们来看看这个xml&#xff0c;提供了哪几类机制 条件控制&#xff1a;, // 结构优化&#xff1a;, , 集合遍历&#xff1a; 变量绑定&#xff1a; ok&#xff…
阅读更多...
【JS】JS进阶--编程思想、面向对象构造函数、原型、深浅拷贝、异常处理、this处理、防抖节流

【JS】JS进阶--编程思想、面向对象构造函数、原型、深浅拷贝、异常处理、this处理、防抖节流

文章目录一、编程思想1. 面向过程编程2. 面向对象编程3. 面向过程 vs 面向对象二、构造函数与原型4. 构造函数实现面向对象5. 构造函数的内存问题三、原型系统6. 原型对象概念7. 原型中的 this 指向8. 扩展内置对象原型9. constructor 属性10. 对象原型 __proto__11. 原型继承1…
阅读更多...
一文学会设计模式之行为型模式及最佳实现

一文学会设计模式之行为型模式及最佳实现

设计模式概述 1. 创建型模式 (Creational Patterns) 关注点&#xff1a;对象的创建过程 核心思想&#xff1a;将对象的创建与使用分离&#xff0c;避免紧耦合 解决的问题&#xff1a;如何创建对象&#xff0c;使系统更灵活、可扩展 特点&#xff1a;隔离对象的创建和使用&#…
阅读更多...
最新文章

Copyright @ 2022~2023