Redis实践之HA方案

本文原创自 http://blog.csdn.net/voipmaker  转载注明出处。

Redis的HA 目的是当主节点挂掉后,从节点自动升级为主节点。

目前的方案有如下几种:

(1)   Redis-cluster内置HA功能,redis 3.0实现了cluster功能,内置HA.

此功能需要在集群模式下才支持,master挂掉后,slave会自动升级为master,对客户端是隐藏的。

(2)通过keepalived,虚拟ip方案

传统HA方案,利用keealived 监控redis进程状态,master挂掉后slave同步master的数据库(persistent), 然后接管master.需要编写脚本实现此过程。

(3)通过redis-sentinel实现

Redis官方实现的HA方案,通过redis-sentinel进程监控master状态,当master挂掉后自动把slave升级为master.  需要redis客户端支持sentianel,当发生HA时,客户端通过查询sentianel,获得当前的master节点访问信息。

时间: 2024-08-06 11:54:31

Redis实践之HA方案的相关文章

Redis 实践之集群方案

本文原创自 http://blog.csdn.net/voipmaker  转载注明出处. Redis集群的目的是实现数据的横向伸缩,把一块数据分片保存到多个机器,可以横向扩展数据库大小,扩展带宽,计算能力等. 实现数据分片(集群)方式大致有三种: (1)     客户端实现数据分片 即客户端自己计算数据的key应该在哪个机器上存储和查找,此方法的好处是降低了服务器集群的复杂度,客户端实现数据分片时,服务器是独立的,服务器之前没有任何关联.多数redis客户端库实现了此功能,也叫sharding

节约内存:Instagram的Redis实践(转)

add by zhj:本文只翻译了一部分,更多分析要参考英文原文 译文:节约内存:Instagram的Redis实践 英文原文:Storing hundreds of millions of simple key-value pairs in Redis Instagram可以说是网拍App的始祖级应用,也是当前最火热的拍照App之一,Instagram的照片数量已经达到3亿,而在Instagram里,我们需要知道每一张照片的作者是谁,下面就是Instagram团队如何使用Redis来解决这个问

节约内存:Instagram的Redis实践(转)

一.问题: 数据库表数据量极大(千万条),要求让服务器更加快速地响应用户的需求. 二.解决方案: 1.通过高速服务器Cache缓存数据库数据 2.内存数据库 三.主流解Cache和数据库对比: 从以上各数据可知,对于我们产品最可行的技术方案有两种: 1.Memcached         内存Key-Value Cache 2.Redis                     内存数据库 四,节约内存:Instagram的Redis实践 Instagram可以说是网拍App的始祖级应用,也是当

Redis缓存集群方案

由于单台Redis服务器的内存管理能力有限,使用过大内存的Redis又会使得服务器的性能急剧下降,一旦服务器发生故障将会影响更大范围业务,而Redis 3.0 beta1支持的集群功能还不适合生产环境的使用.于是为了获取更好的Redis缓存性能及可用性,很多公司都研发了Redis缓存集群方案.现对NetFlix.Twitter.国内的豌豆荚在缓存集群方面的解决方案进行一个汇总,以供读者参考,具体内容如下: 1.NetFlix对Dynamo的开源通用实现Dynomite Dynomite是NetF

Redis sentinel 集群方案

Redis sentinel 集群方案--部署 公司新项目需要使用redis集群,综合考虑了一些方案,最后选择了Redis sentinel, 先在虚拟机部署测试环境如下: sentinel 2台 redis 实例 3个 部分配置如下,采用的默认配置,记得开启认证及最大内存限制,即使是测试环境也要开启认证, 好的习惯是安全生产第一步. ip:192.168.162.130 redis-6380: bind 192.168.162.128 protected-mode yes port 6380

Redis学习笔记(11)——Redis缓存集群方案

由于单台Redis服务器的内存管理能力有限,使用过大内存的Redis又会使得服务器的性能急剧下降,一旦服务器发生故障将会影响更大范围业务,而Redis 3.0 beta1支持的集群功能还不适合生产环境的使用.于是为了获取更好的Redis缓存性能及可用性,很多公司都研发了Redis缓存集群方案.现对NetFlix.Twitter.国内的豌豆荚在缓存集群方面的解决方案进行一个汇总,以供读者参考,具体内容如下: 1.NetFlix对Dynamo的开源通用实现Dynomite Dynomite是NetF

hadoop2.x通过Zookeeper来实现namenode的HA方案以及ResourceManager单点故障的解决方案

我们知道hadoop1.x之前的namenode存在两个主要的问题:1.namenode内存瓶颈的问题,2.namenode的单点故障的问题.针对这两个问题,hadoop2.x都对它进行改进和解决.其中,问题1中对namenode内存瓶颈的问题采用扩展namenode的方式来解决.对于问题2中的namenode的单点故障问题hadoop2.x采用的是HA的解决方案.apache hadoop 官方网站上提供了两种解决HDFS High Availability Using the Quorum

ActiveMQ笔记(3):基于Networks of Brokers的HA方案

上一篇介绍了基于ZK的ActiveMQ HA方案,虽然理解起来比较容易,但是有二个不足: 1)  占用的节点数过多,1个zk集群至少3个节点,1个activemq集群也至少得3个节点,但其实正常运行时,只有一个master节点在对外响应,换句话说,花6个节点的成本只为了保证1个activemq master节点的高可用,太浪费资源了. 2)  性能下降太明显,比起单节点的activemq,性能下降了近1个数量级. 这一篇将介绍基于networks of brokers的HA方案,不需要借助zk等

12.redis 的并发竞争问题是什么?如何解决这个问题?了解 redis 事务的 CAS 方案吗?

作者:中华石杉 面试题 redis 的并发竞争问题是什么?如何解决这个问题?了解 redis 事务的 CAS 方案吗? 面试官心理分析 这个也是线上非常常见的一个问题,就是多客户端同时并发写一个 key,可能本来应该先到的数据后到了,导致数据版本错了:或者是多客户端同时获取一个 key,修改值之后再写回去,只要顺序错了,数据就错了. 而且 redis 自己就有天然解决这个问题的 CAS 类的乐观锁方案. 面试题剖析 某个时刻,多个系统实例都去更新某个 key.可以基于 zookeeper 实现分