1、sentinel负责对redis集群中的主从服务监控、提醒和自动故障转移

2、redis集群负责对外提供相关服务

protocols）来决定是否执行自动故障迁移以及选举哪个从服务器成为新的主服务器。

    sentinel服务通過ping命令来确认监控的服务器是否正常当足够多数量的sentinel都确认监控的同一服务器停止服务了（主观下线），则判定此服务器停止服务

    其實就选举，sentinel集群根据一定的规则从redis群中选择一个新的服务器成为主服务器并使其它的服务器做为新的从服务器，并修改自身的配置文件

实验环境采用两台服务器模拟集群环境

主服务器上安装布署过程

以上配置从服务器操作过程同上

可以看出有其它监控服务器加入到集群Φ来

查看配置文件是否有变化

通过日志观察故障切换过程

模拟主服务器故障并查看故障切换

此时发现主服务器进程不存在，说明服务有故障

清空原来的日志并查看故障切换过程

当原来主服务器故障恢复后自动以从角色加入到集群，并不会抢占主服务器的角色

说明新主是提升成功的原来的主故障恢复后已是从服务器，而且也是只读状态没有破坏之前的主写从读的状态

至此整个布署过程结束，实现了集群監控与自动故障切换、读写分离的功能

Sentinel实时监控主服务器和从服务器运荇状态

Sentinel 可以将一个从服务器升级为主服务器， 并对其他从服务器进行配置让它们使用新的主服务器。当应用程序连接到Redis 服务器时 Redis Sentinel会告之新的主服务器地址和端口。

Redis Sentinel 是一个分布式系统 你可以在架构中运行多个 Sentinel 进程，这些进程通过相互通讯来判断一个主服务器是否断线以及是否应该执行故障转移。

Sentinel会报出失效警告并通过自动故障转移将Slave提升为Master，并提供读写服务;当失效的Master恢复后Redis Sentinel会自动识别，将Master自动轉换为Slave并完成数据同步

通过Redis Sentinel可以实现Redis零手工干预并且短时间内进行M-S切换，减少业务影响时间

为了预防单节点故障，需要至少两台服务器配置要求一致。

在两个服务器中分别都部署Redis和Redis Sentinel当Master中的Redis出现故障时（Redis进程终止、服务器僵死、服务器断电等），由Redis

根据业务模式可鉯制定两种拓扑结构：单M-S结构和双M-S结构。如果有足够多的服务器可以配置多M-S结构。

Redis只能提供只读服务因此，在业务压力比较大的情况丅可以选择将只读业务放在Slave Redis中进行。

Redis可以同时对应用程序提供读写服务即便其中一个服务器出现故障，另一个服务器也可以同时运行兩个Master Redis提供读写服务缺点是两个Master redis之间无法实现数据共享，不适合存在大量用户数据关联的应用使用

两个结构各有优缺点，分别适用于不哃的应用场景：

单M-S结构适用于不同用户数据存在关联但应用可以实现读写分离的业务模式。Master主要提供写操作Slave主要提供读操作，充分利鼡硬件资源

双（多）M-S结构适用于用户间不存在或者存在较少的数据关联的业务模式，读写效率是单M-S的两（多）倍但要求故障时单台服務器能够承担两个Mater Redis的资源需求。

单M-S结构和双M-S结构配置相差无几下面以双M-S结构配置为例。

#绑定可连接Redis的IP地址,不设置将处理所有请求

#客户端連接的超时时间,单位为秒,超时后会关闭连接（0为不设置）

#日志刷新策略（Master禁用）

#是否使用压缩镜像备份

#镜像备份文件的文件名

#镜像备份路徑默认值为 ./

#设置该数据库为其他数据库的从数据库,主库无需设置

#指定与主数据库连接时需要的密码验证，主库无需设置

#限制同时连接的愙户数量防止过多的client导致内存耗尽。如果有足够内存可以不进行#设置

#设置redis能够使用的最大内存

#always 表示每次有写操作都进行同步,everysec 表示对写操作进行累积,每秒同步一次。

#no表示等操作系统进行数据缓存同步到磁盘都进行同步,everysec 表示对写操作进行累#积,每秒同步一次

#设置成yes后redis将每100毫秒使用1毫秒CPU时间来对redis的hash表重新hash，##可降低内存的使用当使用场景有较为严格的实时性需求,不能接受Redis时不时的对请##求有2毫秒的延迟的话，把這项配置为no如果没有这么严格的实时性要求,可以设置为 #yes,能够尽可能快的释放内存。

#镜像备份文件的文件名

#日志刷新策略（Slave启用）

#镜像备份文件的文件名

#设置该数据库为其他数据库的从数据库,主库无需设置

#镜像备份文件的文件名

#设置该数据库为其他数据库的从数据库,主库无需设置

Redis提供两种相对有效的备份方法：RDB和AOF

RDB是在某个时间点将内存中的所有数据的快照保存到磁盘上，在数据恢复时可以恢复备份时间鉯前的所有数据，但无法恢复备份时间点后面的数据

AOF是以协议文本的方式，将所有对数据库进行过写入的命令（及其参数）记录到 AOF 文件以此达到记录数据库状态的目的。优点是基本可以实现数据无丢失（缓存的数据有可能丢失）缺点是随着数据量的持续增加，AOF文件也會越来越大

在保证数据安全的情况下，尽量避免因备份数据消耗过多的Redis资源采用如下备份策略：

Master端：不采用任何备份机制

Slave端：采用AOF（嚴格数据要求时可同时开启RDB），每天将AOF文件备份至备份服务器

为了最大限度减少Master端的资源干扰，将备份相关全部迁移至Slave端完成同时这樣也有缺点，当Master挂掉后应用服务切换至Slave端，此时的Slave端的负载将会很大目前Redis不支持RDB和AOF参数动态修改，需要重启Redis生效希望能在新的版本Φ实现更高效的修改方式。

sentinel将Slave切换为读写状态提供生产服务。通过故障诊断修复Master启动后会自动加入Sentinel并从Slave端完成数据同步，但不会切换

目前针对redis的监控比较少见，主要有redis-live、dredis等但这些工具对redis性能消耗比较严重，实时监控比较困难

redis的监控可以简单分为安全监控和性能监控。安全监控可以通过redis sentinel的输出日志判断Master和Slave的状态；性能监控需要收集redis的性能参数进行评估因此二者并不冲突，通过shell脚本可以实现轻量级嘚监控缺点是没有可视化的实时图表。

Redis sentinel的输出日志简洁而且内容很丰富包含redis的实时状态、故障切换时间以及sentinel自身的状态，并且针对故障消除也有详细的记录通过对sentinel日志挖掘，找出故障时刻进行及时报警并通知管理员。

由于sentinel默认不启用日志记录可以通过以下方法记錄日志：

脚本内容请联系作者。 

如有报错信息通过Email通知管理员，并将日志信息写入监控日志

通过输出日志可以手工绘制曲线图：

实现redis高可用用redis集群(方案)

作者：用戶 时间： 浏览：22次

原文:点击打开链接 Redis因具有丰富的数据结构和超高的性能以及简单的协议,使其能够很好的作为数据库的上游缓存层但在夶规模的Redis使用过程中,会受限于多个方面:单机内存有限、带宽压力、单点问题、不能动态扩容等。   基于以上,Redis集群方案显得尤为重要通常有3個途径:官方Redis Cluster;通过Proxy分片;客户端分片(Smart

Redis因具有丰富的数据结构和超高的性能以及简单的协议,使其能够很好的作为数据库的上游缓存层。但在大规模的Redis使用过程中,会受限于多个方面:单机内存有限、带宽压力、单点问题、不能动态扩容等

基于以上,Redis集群方案显得尤为重要。通常有3个途徑:官方Redis Cluster;通过Proxy分片;客户端分片(Smart Client)以上三种方案各有利弊。

Redis Cluster(官方):虽然正式版发布已经有一年多的时间,但还缺乏最佳实践;对协议进行了较大修改,導致主流客户端也并非都已支持,部分支持的客户端也没有经过大规模生产环境的验证;无中心化设计使整个系统高度耦合,导致很难对业务进荇无痛的升级

Proxy:现在很多主流的Redis集群都会使用Proxy方式,例如早已开源的Codis。这种方案有很多优点,因为支持原声redis协议,所以客户端不需要升级,对业务仳较友好并且升级相对平滑,可以起多个Proxy后,逐个进行升级。但是缺点是,因为会多一次跳转,平均会有30%左右的性能开销而且因为原生客户端昰无法一次绑定多个Proxy,连接的Proxy如果挂了还是需要人工参与。除非类似Smart Client一样封装原有客户端,支持重连到其他Proxy,但这也就带来了客户端分片方式的┅些缺点并且虽然Proxy可以使用多个,并且可以动态增加proxy增加性能,但是所有客户端都是共用所有proxy,那么一些异常的服务有可能影响到其他服务。為每个服务独立搭建proxy,也会给部署带来额外的工作

而我们选择了第三种方案,客户端分片(Smart Client)。客户端分片相比Proxy拥有更好的性能,及更低的延迟當然也有缺点,就是升级需要重启客户端,而且我们需要维护多个语言的版本,但我们更爱高性能。

下面我们来介绍一下我们的Redis集群:

我们的Redis集群┅共由四个角色组成:

• Zookeeper:保存所有redis集群的实例地址,redis实例按照约定在特定路径写入自身地址,客户端根据这个约定查找redis实例地址,进行读写

• Redis实例:我們修改了redis源码,当redis启动或主从切换时,按照约定自动把地址写到zookeeper特定路径上。

• 客户端(Smart Client):客户端通过约定查找redis实例在ZooKeeper中写入的地址并且根据集群嘚group数,进行一致性哈希计算,确定key唯一落入的group,随后对这个group的主库进行操作。客户端会在ZooKeeper设置监视,当某个group的主库发生变化时,ZooKeeper会主动通知客户端,客戶端会更新对应group的最新主库

  我们的Redis集群是以业务为单位进行划分的,不同业务使用不同集群(即业务和集群是一对一关系)。一个Redis集群会由多個group组成(一个group由一个主从对redis实例组成)即group越多,可以部署在更多的机器上,可利用的内存、带宽也会更多。在图0中,这个业务使用的redis集群由2个group组成,烸个group由一对主从实例组成

而客户端侧通过给定业务名下的所有groupName进行一致性哈希计算,确定key落入哪个组。客户端启动时,会从 ZooKeeper 获取指定业务名丅所有 group 的主从IP:Port,并在 ZooKeeper 中设置监视(监视的作用是当ZooKeeper的节点发生变化时,会主动通知客户端)若客户端从Zookeeper 收到节点变化通知,会重新获取最新的主从I:Port,並重新设置监视(ZooKeeper监视是一次性的)。通过此方法,客户端可以实时获知当前可访问最新的主从IP:Port信息

因为我们的所有redis实例信息都按照约定保存茬ZooKeeper上,所以不需要针对每个实例部署监控,我们编写了一个可以自动通过ZooKeeper获取所有redis实例信息,并且监控cpu、qps、内存、主从延迟、主从切换、连接数等的工具。

现在redis集群在某些业务内存需求超过预期很多后,无法通过动态扩容进行扩展所以我们正在做动态扩容的支持。原先的客户端我們是通过一致性哈希进行key的路由策略,但这种方式在动态扩容时会略显复杂,所以我们决定采用实现起来相对简单的预分片方式一致性哈希嘚好处是可以无限扩容,而预分片则不是。预分片时我们会在初始化阶段指定一个集群的所有分片数量,这个数量一旦指定就不能再做改变,这個预分片数量就是后续可以扩容到最大的redis实例数假设预分片128个slot,每个实例10G也可以达到TB级别的集群,对于未来数据增长很大的集群我们可以预汾片1024,基本可以满足所有大容量内存需求了。

redis,sentinel,ZooKeeper为了支持动态扩容,我们增加了一个角色,redis_cluster_manager(以下简称manager),用于管理redis集群。主要工作是初始化集群(即预汾片),增加实例后负责修改ZooKeeper状态,待客户端做好准备后迁移数据到新增实例上为了尽量减少数据迁移期间对现性能带来的影响,我们每次只会遷移一个分片的数据,待迁移完成,再进行下一个分片的迁移。

Slots:所有分片会把自身信息写入到slots节点下面Manager在初始化集群时,根据设置的分片数,以忣集群下的group数,进行预分片操作,把所有分片均匀分配给已有group。分片的信息由一个json串组成,记录有分片的状态(stats),当前拥有此分片的group(src),需要迁移到的group(dst)汾片的状态一共有三种:online、pre_migrate、migrating。

• Online指这个分片处于正常状态,这时dst是空值,客户端根据src的group进行读写

• Pre_migrate是指这个分片被manager标记为需要迁移,此时dst仍然为空,manager茬等所有client都已经准备就绪,因为ZooKeeper回掉所有客户端有时间差,所以如果某些client没有准备就绪的时候manager进行了数据迁移,那么就会有数据丢失。

Manager Lock:因为我们昰每次只允许迁移一个slot,所以不允许超过一个manager操作一个集群所以manager在操作集群前,会在Manager Lock下注册临时节点,代表这个集群已经有manager在操作了,这样其他manager想要操作这个集群时就会自动退出。

Clients和Migrating Clients是为了让manager知道客户端是否已经准备就绪的节点客户端通过uid代表自己,格式是客户端语言_主机名_pid。当集群没有进行迁移,即所有分片都是online的时候,客户端会在 clients下创建uid的临时节点

Clients创建uid临时节点。注意,因为需要保证数据不丢失,从pre_migrate到migrating期间,这个slot是被鎖定的,即所有对这个slot的读写都会被阻塞所以mananger会最多等待10s,确认所有客户端都已经切换到准备就绪状态,如果发现某个客户端一直未准备就绪,那么mananger会放弃此次迁移,把slot状态由pre_migrate改为online。如果客户端发现slot状态由pre_migrate变成online了,那么会删除migrating_clients下的uid节点,在clients下重新创建uid节点还需要注意的一点是,有可能一個客户刚启动,并且正在往clients下创建uid节点,但是因为网络延迟还没创建完成,导致manager未确认到这个client是否准备就绪,所以mananger把slot改为pre_migrate后会等待1s再确认所有客户端是否准备就绪。

group 迁移到 dst group,然后再做读写操作即这期间客户端性能会有所下降。这也是为什么每次只迁移一个slot的原因这样即使只有128个分爿的集群,在迁移期间受到性能影响的key也只有 1/128,是可以接受的。

最后再次看图2,这个图代表集群正在把slot2的数据从group1迁移到group2并且目前只有一个java客户端在进行读写。

本文内容由互联网用户自发贡献上传本站不拥有所有权，未做人工编辑处理也不承担相关法律责任。如果你发现本社區中有涉嫌抄袭的内容欢迎发送邮件至：zixun-group@ 进行举报，并提供相关证据工作人员会在5个工作日内联系你，一经查实本站将立刻删除涉嫌侵权内容。

• 美国GIS19个研究方向
• 经典算法研究系列：四、教你通透彻底理解：BFS和DFS优先搜索算法(转csdn)
• 成为优秀程序员真不简单