Redis开发运维实践高可用和集群简述

本文涉及的产品
云数据库 Redis 版,社区版 2GB
推荐场景:
搭建游戏排行榜
简介:

10.1 概念

在本文档中,高可用主要指的是解决尽可能在不丢失数据的前提下不间断服务问题,由于redis是异步复制,因此不保证数据完全不丢失,在这个场景下并不实现动态横向扩容,只能进行纵向扩容,你只要加内存,启动redis,设置maxmemory即可。而分片(Sharding)主要指的是解决在线动态横向扩容缩容问题,当然为了稳定也进行高可用部署配置,即包含成对的主从关系。


10.2 高可用主要场景和对应思路

适用于redis非重度用户,内存占用不大,总体内存大小的增长趋势可预估,有一定停机时间的系统——纵向扩容即可满足,可以对全库进行主从复制即满足需求而不需要做分片,一般针对单个小型项目的cache 等场景。一般采用一主多从的sentinel方案进行部署。


10.3 分片主要场景和对应思路

分片是为了应对业务增长带来的数据增长,需要对动态横向扩容有一定要求时采用。对于一般的分片采用一致性哈希,它极大的优化机器增删时带来的哈希目标漂移问题。同时对于Hash目标漂移时产生的严重的数据倾斜,可以利用虚拟节点来优化。基本上,物理节点有了一定规模后,只要不是同时挂多个节点,或者同时扩容多个节点,数据分片不会有太大的扰动。穿透过Cache的请求后端存储可以抗住即可。

稍微复杂的方案是可以使用“预分片(Pre-Sharding)”的方案,也称为按“桶”进行数据划分,即分配一个相当大的集合,对Key哈希的结果落在这个集合中,集合的每个元素又与具体的物理节点存在多对一的路由映射关系,这张路由表由一个配置中心进行维护。其实,一致性哈希中的虚拟节点,实际上也可以归类到Pre-Sharding方案中。换句话说,只要是key经过两次哈希,第一次Hash到虚拟节点,第二次Hash到物理节点,都可以算作Pre-Sharding。只不过区别在于,一致性哈希的第二次Hash其路由表是按照算法固定的,而分桶的第二次Hash其路由表是第三方可配的。


10.4 适用场景对比列表

--- 动态扩容能力 系统复杂度 开发复杂度 运维复杂度
主从复制+Sentinel No 简单 简单 简单
Twemproxy No 简单 简单 稍微复杂
3.0 Cluster Yes 简单 简单 复杂
Codis Yes 复杂 简单 复杂
应用层面presharding Yes 复杂 复杂 视开发的水平而定

本文为《Redis开发运维实践指南》内容,该书作者为黄鹏程,已授权云栖社区转载。

相关实践学习
基于Redis实现在线游戏积分排行榜
本场景将介绍如何基于Redis数据库实现在线游戏中的游戏玩家积分排行榜功能。
云数据库 Redis 版使用教程
云数据库Redis版是兼容Redis协议标准的、提供持久化的内存数据库服务,基于高可靠双机热备架构及可无缝扩展的集群架构,满足高读写性能场景及容量需弹性变配的业务需求。 产品详情:https://www.aliyun.com/product/kvstore     ------------------------------------------------------------------------- 阿里云数据库体验:数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库 ECS 实例和一台目标数据库 RDS实例。跟着指引,您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接,领取免费ECS&RDS资源,30分钟完成数据库上云实战!https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
相关文章
|
11天前
|
负载均衡 监控 NoSQL
Redis的几种主要集群方案
【5月更文挑战第15天】Redis集群方案包括主从复制(基础,读写分离,手动故障恢复)、哨兵模式(自动高可用,自动故障转移)和Redis Cluster(官方分布式解决方案,自动分片、容错和扩展)。此外,还有Codis、Redisson和Twemproxy等工具用于代理分片和负载均衡。选择方案需考虑应用场景、数据量和并发需求,权衡可用性、性能和扩展性。
188 2
|
11天前
|
存储 监控 负载均衡
保证Redis的高可用性是一个涉及多个层面的任务,主要包括数据持久化、复制与故障转移、集群化部署等方面
【5月更文挑战第15天】保证Redis高可用性涉及数据持久化、复制与故障转移、集群化及优化策略。RDB和AOF是数据持久化方法,哨兵模式确保故障自动恢复。Redis Cluster实现分布式部署,提高负载均衡和容错性。其他措施包括身份认证、多线程、数据压缩和监控报警,以增强安全性和稳定性。通过综合配置与监控,可确保Redis服务的高效、可靠运行。
183 2
|
11天前
|
NoSQL API Redis
最佳实践|如何使用c++开发redis module
本文将试着总结Tair用c++开发redis module中遇到的一些问题并沉淀为最佳实践,希望对redis module的使用者和开发者带来一些帮助(部分最佳实践也适用于c和其他语言)。
76317 0
|
6天前
|
运维 网络协议 Linux
2024年最全CentOS8 Consul微服务架构安装(1)_agent(1),Linux运维开发面试
2024年最全CentOS8 Consul微服务架构安装(1)_agent(1),Linux运维开发面试
|
9天前
|
运维 监控 关系型数据库
【Zabbix 6(1),Linux运维组件化开发教程
【Zabbix 6(1),Linux运维组件化开发教程
|
11天前
|
存储 NoSQL Redis
Redis源码、面试指南(5)多机数据库、复制、哨兵、集群(下)
Redis源码、面试指南(5)多机数据库、复制、哨兵、集群
230 1
|
11天前
|
监控 NoSQL Redis
Redis源码、面试指南(5)多机数据库、复制、哨兵、集群(上)
Redis源码、面试指南(5)多机数据库、复制、哨兵、集群
279 0
|
11天前
|
存储 监控 NoSQL
Redis哨兵&分片集群
Redis哨兵&分片集群
34 0
|
11天前
|
NoSQL 算法 Java
深入浅出Redis(八):Redis的集群模式
深入浅出Redis(八):Redis的集群模式
|
11天前
|
NoSQL Redis
透视Redis集群:心跳检测如何维护高可用性
Redis心跳检测保障集群可靠性,通过PING命令检测主从连接状态,预防数据丢失。当连接异常时,自动触发主从切换。此外,心跳检测辅助实现`min-slaves-to-write`和`min-slaves-max-lag`策略,避免不安全写操作。还有重传机制,确保命令无丢失,维持数据一致性。合理配置心跳检测,能有效防止数据问题,提升Redis集群的高可用性。关注“软件求生”获取更多Redis知识!
158 10
透视Redis集群:心跳检测如何维护高可用性