redis一体机方案设计—redis私有云平台
- 格式：doc
- 大小：669.50 KB
- 文档页数：7
redis一体机方案设计—redis私有云平台
0 目标
交付Redis部署方案；搭建可高效运维、高可用、高利用率的redis管理平台。
图一：redis私有云设计方案架构图
1 redis简介
1.1 redis的特性
特性 优势 劣势
快 官方数字读写10万/秒 ——
单线程 预防了多线程可能产生的竞争问题 阻塞风险
简单稳定 简单稳定 ——
Redis是典型的单线程架构，所有的读写操作都是在一条主线程中完成的。当Redis用
于高并发场景时，这条线程就变成了它的生命线。 如果出现阻塞，哪怕是很短时间，对于
应用来说都是噩梦。
1.2使用场景
场景 推荐指数
缓存 ☆☆☆☆☆
排行榜系统 ☆☆☆☆☆
计数器应用 ☆☆☆☆☆
消息队列 ☆☆
不是万金油，适合小规模数据、热数据的场景。
2、部门redis现状梳理
略。
图二redis私有云平台特点
3、redis统一使用方案设计
3.1目标
交付Redis架构方案；
搭建可高效运维、高可用、高利用率的redis管理平台；
3.2 官方架构方案选择
部署方式 特点 是否高可用 其他
alone 单机单实例 简单 否 ——
单机多库 简单但适用场景很少 否 ——
单机多实例 简单高效，CPU、IO竞争 否 最常见的部署方式
主从 切换需要借助脚本实现高可用 否 ——
sentinel+主从 高可用方案 是 以下简称为sentinel
推荐至少5个节点
集群（cluster） 分布式高可用高性能方案 是 推荐至少6个节点
3.2.1 alone
类型 特性 应用频率 共同点 客户端
单机单实例 Redis单线程架构导致无法充分利用CPU多核特性。 —— 非高可用架构 最简单
单机多库 Redis是单线程的。如果使用多个数据库，数据库仍然是使用一个CPU，彼此之间还是会受到影响的。 适用场景很
少
单机多实例 当多个实例开启AOF重写后，彼此之间会产生对CPU和IO的竞争，要利用外部程序防止出现多个子进程执行重写操作。 最常见的部
署场景；在后
续的主从、
cluster均
可应用多实
例。
客户端接入
3.2.1 sentinel
Sentinel结合主从复制实现sentinel高可用架构。Sentinel节点集合可以监控一个或多个
主节点。可以实现故障发现、故障自动转移、配置中心和客户端通知。Redis Sentinel 的
节点数量要满足 2n+1(n>=1)的奇数个。
Sentinel26380Sentinel26381Sentinel
26382
Master6380Master6390Slave6391Slave
6381
监控监控
复制复制监控监控监控host1host2host3host5host4业务A
业务B
sentinel监控1个2实例主从
Sentinel26380Sentinel26380Sentinel
26380
Master
6380
Slave
6381
host1host2
监控
监控
监控监控
监控
复制
业务A
Master
6380
Slave
6381
host3host4
复制
业务B
监控
监控
host5host6host7
sentinel监控2个单实例主从
客户端接入
1、 遍历Sentinel节点集合获取一个可用的Sentinel节点
2、 通过sentinel的API获取redis-master,并验证。
3、 保持与Sentinel节点集合的 “联系”，时刻获取redis-master的变化
3.2.3 cluster
Cluster分布式解决方案，主要用于寻求高性能。
业务 Master Slave
业务A IP1:16379 IP2:16380
IP3:16381 IP4:16382
IP5:16383 IP6:16384
业务B IP1:26379 IP2:26380
IP3:26381 IP4:26382
IP4:26383 IP5:26384
3.2.4架构方案规划
多应用复用VS各用个的
多应用复用 各用个的
最大优势 节约资源，方便分配 稳定性强、方便运营
隐患 中心化风险，一个有问题拖累其他 资源浪费
隐患对应措施 每个实例设置maxmemory 根据使用率调整资源分配
架构规划
适用场景 性能要求（内存） 架构 是否多应用复用
缓存 排行榜系统 计数器应用 会话共享 中、低（单机可满足，小于16G） 3个sentinel节点+1主1从 可尝试
高 Cluster（3节点或6节点） 否
3.3 维护平台
3.3.1为什么使用维护平台
1、当Redis达到了一定规模， 使用命令会运维管理变得捉襟见肘，通过平台化的工具
统一监控和管理将极大地提升开发和运维人员工作效率。
2、无论是redis sentinel还是redis cluster，它们都需要客户端的额外支持，这很不利
于redis业务使用方，因为不仅需要客户端额外支持，更重要的是业务方需要知道redis
服务是如何部署的，到底是redis sentinel维护的高可用还是用的redis cluster。redis
节点和sentinel节点本身都是有状态的服务，直接将有状态的服务暴露给使用者通常都不
是一个好的选择。
3.3.2维护平台选择
CacheCloud CacheEasy
项目背景 搜狐视频 CacheCloud于2014年9月在搜狐视频正式上线，期间每天的平均命令调用量约为200亿次，有1000个以上的Redis节点，100台以上的机器， 服务着公司几十个项目 暂未了解
角色定位 非代理 代理
用户量 多 暂未了解
优势 自动部署、解决Redis实例碎片化现象、提供完善统计、监
控、运维功能、减少运维成本和误操作，提高机器的利用率，
提供灵活的伸缩性，提供方便的接入客户端。
缺点 1、 客户端启动的时要从cachecloud服务端获取appId，而
它本身是单点；
2、 不支持redis带密码；
3、 项目不再活跃
4、安全设计
Redis的设计目标是一个在内网运行的轻量级高性能键值服务，对于安全方面没有做太多的
工作， Redis只提供了简单的密码机制，并且没有做用户权限的相关划分。
1、非默认端口
2、防火墙,IP白名单
3、设置密码
4、定期备份
5、使用非root用户启动
5、redis平台计划
先分配3个sentinel节点+1主1从的架构给短信系统改造使用，并尝试多应用复用。并继
续研究确定合适的redis私有云平台软件。
附件
1、 redis的安装
tar xzf redis-3.0.7.tar.gz
ln -s redis-3.0.7 redis
cd redis
make
make install
环境变量
vi ~/.bash_profile
export REDIS_HOME=/root/redis-3.0.7
export PATH=$PATH:$REDIS_HOME/src
source ~/.bash_profile
2、 redis-sentinel的安装配置
3、 cachecloud
