由于 Redis 出众的性能,其在众多的移动互联网企业中得到广泛的应用。Redis 在 3.0 版本前只支持单实例模式,
虽然现在的服务器内存可以到 100GB、200GB 的规模,但是单实例模式限制了 Redis 没法满足业务的需求(例如新
浪微博就曾经用 Redis 存储了超过 1TB 的数据)。Redis 的开发者 Antirez 早在博客上就提出在 Redis 3.0 版本中加
入集群的功能,但 3.0 版本等到 2015 年才发布正式版。各大企业在 3.0 版本还没发布前为了解决 Redis 的存储瓶颈,
纷纷推出了各自的 Redis 集群方案。这些方案的核心思想是把数据分片(sharding)存储在多个 Redis 实例中,每一
片就是一个 Redis 实例。
下面介绍 Redis 的集群方案。
1.客户端分片
客户端分片是把分片的逻辑放在 Redis 客户端实现,通过 Redis 客户端预先定义好的路由规则,把对 Key 的访问
转发到不同的 Redis 实例中,最后把返回结果汇集。这种方案的模式如图 1 所示。
图
1
客户端分片的模式
客户端分片的好处是所有的逻辑都是可控的,不依赖于第三方分布式中间件。开发人员清楚怎么实现分片、路由
的规则,不用担心踩坑。
客户端分片方案有下面这些缺点。
这是一种静态的分片方案,需要增加或者减少 Redis 实例的数量,需要手工调整分片的程序。
可运维性差,集群的数据出了任何问题都需要运维人员和开发人员一起合作,减缓了解决问题的速度,增加了跨
部门沟通的成本。
在不同的客户端程序中,维护相同的分片逻辑成本巨大。例如,系统中有两套业务系统共用一套 Redis 集群,一
套业务系统用 Java 实现,另一套业务系统用 PHP 实现。为了保证分片逻辑的一致性,在 Java 客户端中实现的分
评论1
最新资源