1.创建公共配置文件 所有配置文件添加到以下目录: /xxxx/redis-slave-master 创建公共的redis配置文件,直接使用redis的默认配置文件,修改以下配置项: bind 127.0.0.1 daemonize yes 后台启动 requirepass 123456 登录密码 2.创建master服务的配置文件 在 /xxxx/redis-slave-master 目录中创建redis-master.conf文件,并添加以下配置内容: ## 公共配置配置相关 include /xx
源代码(可从https://github.com/eyjian/redis-tools下载):
Redis已经大量应用于各种互联网架构场景中,其优异的性能,良好的操作性,以及大量的场景应用案例,使得Redis备受瞩目。本文作者向大家介绍了一种Redis在非大集群分布式应用场景下的灾备解决方案。一起来品读一下吧~
Redis是一个高性能的key-value非关系型数据库,由于其具有高性能的特性,支持高可用、持久化、多种数据结构、集群等,使其脱颖而出,成为常用的非关系型数据库。 此外,Redis的使用场景也比较多。
如果你用 redis 缓存技术的话,肯定要考虑如何用 redis 来加多台机器,保证 redis 是高并发的,还有就是如何让 redis 保证自己不是挂掉以后就直接死掉了,即 redis 高可用。
Keepalived 实现VRRP(虚拟路由冗余)协议,从路由级别实现VIP切换,可以完全避免类似heartbeat脑裂问题,可以很好的实现主从、主备、互备方案,尤其是无状态业务,有状态业务就需要额外花些功夫了。既然Mysql可以使用Keepalived很好的做到主从切换,那么Redis自然可以使用这种方式实现高可用。 Redis主从实现完全没有Mysql成熟,仅仅是可用而已,经过测试主从也不是那么完全不靠谱,主要问题在于同步连接断开之后需要重新全量同步,如果频繁进行会对主服务带来很大性能影响。 但现实中主
Redis is an open-source, in-memory, data structure store with optional disk writes for persistence. It can be used as a key-value database, or as a cache and message broker. Redis features built-in transactions, replication, and support for a variety of data structures such as strings, hashes, lists, sets, and others. Redis can be made highly available with Redis Sentinel and supports automatic partitioning with Redis Cluster.
如果你用redis缓存技术的话,肯定要考虑如何用redis来加多台机器,保证redis是高并发的,还有就是如何让Redis保证自己不是挂掉以后就直接死掉了,redis高可用
在Redis复制的基础上(不包括Redis Cluster或Redis Sentinel作为附加层提供的高可用功能),使用和配置主从复制非常简单,能使得从 Redis 服务器(下文称 slave)能精确得复制主 Redis 服务器(下文称 master)的内容。每次当 slave 和 master 之间的连接断开时, slave 会自动重连到 master 上,并且无论这期间 master 发生了什么, slave 都将尝试让自身成为 master 的精确副本。
当启动一个slave node的时候,它会发送一个PSYNC命令给master node
Redis 中的事务 在我们平常的程序中,不是多个客户端同时处理数据时,程序都会稳定的执行,但是我们都会遇到多个客户端访问的情况,这样就会容易出现数据错误的情况。为了防止这个情况我们才有了事务这一说。那么什么是事务呢? 事务是一个单独的隔离操作:事务中的命令都会序列化、按照顺讯的执行,并在在执行过程找那个不会被其他客户端发送过来的命令所打断。 事务是原子性的操作,命令要么是全部执行,要么是全部都不执行。 使用事务 为了方便我们在程序中使用Redis的事务,在Redis中有一个EXEC命
对于性能来说,单主用来写入数据,单机几万QPS,多从用来查询数据,多个从实例可以提供每秒 10w 的 QPS。
Redis 2.4之后的版本开始集成了Sentinel,用于监控redis集群中 Master状态的工具,是Redis的高可用性解决方案。
RDB全称Redis Database Backup file(Redis数据备份文件),也被叫做Redis数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。当Redis实例故障重启后,从磁盘读取快照文件,恢复数据。快照文件称为RDB文件,默认是保存在当前运行目录。
虽然说单机的Redis性能很好,也有完备的持久化机制,那如果你的业务体量真的很大,超过了单机能够承载的上限了怎么办?不做任何处理的话Redis挂了怎么办?带着这个问题开始我们今天的主题-「Redis高可用」,由于篇幅原因,本章就只聊聊主从复制。
Redis在日常部署的时候,可以有多种部署模式:单机、主从、哨兵、集群(分区分片),因此本文将对上面这四种模式进行详细的讲解,特别是集群模式将进行最细致的讲解(现行普遍使用的方式)。
Redis 集群模式有三种:主从模式(Redis 2.8 版本之前)、哨兵模式(Redis 3.0 之前)、集群模式(Redis 3.0 之后)。
Redis Replication是一种 master-slave 模式的复制机制,这种机制使得 slave 节点可以成为与 master 节点完全相同的副本,可以采用一主多从或者级联结构。架构如下:
前面已经学习了Redis的持久化方式,接下来开始学习Redis主从架构的原理,来看看Redis如何利用主从架构来保证高并发的。
为了提升数据检索的效率,有时候我们会在数据库前加一层缓存,Redis就是常见的一种缓存组件,他的全称是REmote DIctionary Server,是一个由Salvatore Sanfilippo写的key-value存储系统,而且是可以跨平台的非关系型数据库。
Redis 在我的项目中,主要用作缓存和消息队列。小的项目可以使用单机版,大点的项目或者稍微注重高可用的时候可以考虑使用Redis 集群。
redis-cluster是近年来redis架构不断改进中的相对较好的redis高可用方案。本文涉及到近年来redis多实例架构的演变过程,包括普通主从架构(Master、slave可进行写读分离)、哨兵模式下的主从架构、redis-cluster高可用架构(redis官方默认cluster下不进行读写分离)的简介。同时还介绍使用Java的两大redis客户端:Jedis与Lettuce用于读写redis-cluster的数据的一般方法。再通过官方文档以及互联网的相关技术文档,给出redis-cluster架构下的读写能力的优化方案,包括官方的推荐的扩展redis-cluster下的Master数量以及非官方默认的redis-cluster的读写分离方案,案例中使用Lettuce的特定方法进行redis-cluster架构下的数据读写分离。
redis.conf是Redis的核心配置文件,默认docker运行的redis是不存在配置文件的,这里可以先从官网下载:
派大星:因为Redis基于reactor模式开发了网络事件处理器,这个事件处理器叫做:文件事件处理器(File Event Handler),这个文件事件处理器是单线程的,从而Redis才叫做单线程的模型。采用IO多路复用机制同时监听多个socket,根据socket上的事件来选择对应的事件处理器来处理这个事件。
本篇文章专注于讲解redis在windows环境下使用Redis Sentinel(哨兵)实现高可用方案。
Redis中的主从复制,也就是Master-Slave模型,其实现相对比较简单,一般使用在多个Redis实例间的数据同步以及Redis集群中用的比较多。
主从复制:Redis虽然读取写入的速度都特别快,但是也会产生读压力特别大的情况。为了分担读压力,Redis支持主从复制,Redis的主从结构可以采用一主多从或者级联结构,Redis主从复制可以根据是否是全量分为全量同步和增量同步。下图为级联结构。
主从复制模式就是,部署多台 Redis 节点,其中只有一台节点是主节点(Master),其他的节点都是从节点(Slave),也叫备份节点(Replica)。只有 Master 节点提供数据的事务性操作(增删改),Slave 节点只提供读操作。所有 Slave 节点的数据都是从 Master 节点同步过来的
Master节点在平时提供服务,另外一个或多个Slave节点在平时不提供服务(或只提供数据读取服务)。当Master节点由于某些原因停止服务后,再人工/自动完成Slave节点到Master节点的切换工作,以便整个Redis集群继续向外提供服务。
二、主从复制(读写分离) redis的主从复制功能非常强大,一个master可以拥有多个slave,而一个slave又可以拥有多个slave,如此下去,形成了强大的多级服务器集群架构.可以避免redis单点故障,构建读写分离架构,满足读多写少的应用场景. 1、主从复制原理
主从复制,是指将一台Redis服务器的数据,复制到其他的Redis服务器。前者称为主节点(master/leader),后者称为从节点(slave/follower) ; 数据的复制是单向的,只能由主节点到从节点。Master以写为主,Slave以读为主。
本文将演示使用kubernetes系统基于 kubeguide相关的镜像文件创建基于php和Redis的留言板系统,因为系统资源有限,kubernetes集群只有一个master节点和slave节点。
上个礼拜,我搭建了一个mongo分片集群,发现分布式系统保证高可用和高性能的套路都差不多。高性能就是做分片(可以类比为分库分表,将数据分到不同服务器上),在Kafka中叫分区,在mongodb中叫shard,在HDFS上叫DataNode。而保证高可用的方式就是做交叉备份。然后我很好奇Redis是怎么部署的。
在主从复制模式的集群里,主节点一般是一个,从节点一般是两个或多个,写入主节点的数据会被复制到从节点上,这样一旦主节点出现故障,应用系统能切换到从节点去读写数据,这样能提升系统的可用性。而且如果再采用主从复制模式里默认的读写分离的机制,更能提升系统的缓存读写性能。所以对性能和实时性不高的系统而言,主从复制模式足以满足一般的性能和安全性方面的需求。
1、Sentinel 哨兵 Sentinel(哨兵)是Redis 的高可用性解决方案:由一个或多个Sentinel 实例 组成的Sentinel 系统可以监视任意多个主服务器,以及这些主
Redis-Sentinel是Redis官方推荐的高可用性(HA)解决方案。实际上这意味着你可以使用Sentinel模式创建一个可以不用人为干预而应对各种故障的Redis部署。
sentinel是一个分布式系统,可以在一个架构中运行多个sentinel进程,这些进程使用流言协议(gossip protocols)来接收关于rdis主服务器是否下线的信息,并使用投票协议(agreement protocols)来决定是否执行自动故障迁移,以及选举哪个从服务器成为新的主服务器。
出于学习目的,您可以很轻松地在docker环境下运行redis的单个实例,但是如果您需要在生产环境中运行它,那么必须将Redis部署为HA(High Avaliable)模式。
如果你在使用 Redis 时,也遇到过以下这些「诡异」的场景,那很大概率是踩到「坑」了:
上一节中介绍了master-slave模式,在最小配置:master、slave各一个节点的情况下,不管是master还是slave down掉一个,“完整的”读/写功能都将受影响,这在生产环境中显然不能接受。幸好redis提供了sentinel(哨兵)机制,通过sentinel模式启动redis后,自动监控master/slave的运行状态,基本原理是:心跳机制+投票裁决 每个sentinel会向其它sentinal、master、slave定时发送消息,以确认对方是否“活”着,如果发现对方在指定时间(可
如果你用redis缓存技术的话,肯定要考虑如何用redis来加多台机器,保证redis是高并发的,还有就是如何让Redis保证自己不是挂掉以后就直接死掉了。
如果一个master挂了,那么剩余的2个master会发起投票选举,从挂了的master对应的slave中选举出一个新的master,发生故障的master不会参与投票,这个要注意。
又很久很久没有更新博客了,也很久很久没有做云计算了,前期做了一段时间的游戏,现在又回归到常规运维的岗位,最近接触到redis这玩意,也就简单配置了下,至少要熟悉下常规的配置,才能做到运维支撑嘛。现在也没有很多时间完善博客格式什么的,就把一些笔记贴进来,方便自己后期查看,如果可以,希望对新学者有所帮助吧。
项目中因为并发不是很高一直偷懒用的单节点 Redis ,但是有很多大 key 写入的场景,这样会影响读性能,于是准备做主从复制,顺便做一下哨兵模式。
整合了商品名称、价格、图片、简介的商品详情页就是典型的场景,可以把通过复杂操作耗时查询出来的结果,确定短时间内不会频繁更新变化,但是对这个数据会有大量读请求,这个时候就可以直接把结果存放在缓存中,后面的请求就直接读取缓存即可。
单机的 redis,能够承载的 QPS 大概就在上万到几万不等。对于缓存来说,一般都是用来支撑读高并发的。因此架构做成主从(master-slave)架构,一主多从,主负责写,并且将数据复制到其它的 slave 节点,从节点负责读。所有的读请求全部走从节点。这样也可以很轻松实现水平扩容,支撑读高并发。
在开发测试环境中,我们一般搭建Redis的单实例来应对开发测试需求,但是在生产环境,如果对可用性、可靠性要求较高,则需要引入Redis的集群方案。虽然现在各大云平台有提供缓存服务可以直接使用,但了解一下其背后的实现与原理总还是有些必要(比如面试), 本文就一起来学习一下Redis的几种集群方案。
领取专属 10元无门槛券
手把手带您无忧上云