首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

Redis内存又不够用了?教你几种集群方案轻松甩掉存储难题

Redis,一款技术研发者们耳熟能详的内存数据库。作为数据库,存储数据的容量都是有限的,不能超过主机内存的大小。通常而言,一台主机服务器的内存只有十几G,较大可达100G或200G。

为了解决Redis存储瓶颈问题,各大企业纷纷开始寻找解决方案,将数据分片(sharding)存储在多个Redis实例之中,每一个分片就是一个Redis实例,然后实现多个Redis实例协同运行。这就是Redis集群原理。本篇将围绕Redis集群方案展开重点介绍。

Redis集群实现方式:

  • 分区,将数据分割划分到多个Redis实例中去,然后保证每个实例只保存key的一个子集;
  • 通过多台计算机的内存和值构造更大的数据库;
  • 通过多台计算机扩展计算能力;
  • 通过多台计算机机和网络适配,扩展网络宽带。

集群的实现方式:

  • 客户端分片
  • 基于代理的分片
  • 路由查询

下面我们对三种实现方式展开介绍:

客户端分片

客户端分片就是将分片工作放在业务程序端实现,程序代码根据Redis客户端预先定义好的路由规则,直接对不同的Redis实例进行分布式访问,最终再把结果汇集在一起。

这种方案的优势就在于所有逻辑都是可以控制的,没有第三方中间件干预,开发人员很清楚如何实现分片及路由规则,实现方法完全由自己掌控。

但是客户端分片方案的弊端也是令开发者也是十分懊恼的。由于客户端分片方案是一种静态的分片方案,无论是增加或是减少Redis实例的数量,都必须要开发者手动调整分片程序,对开发者的依赖很强;其次在运维上,该方案运维性较差,一旦集群数据出现问题,就需要开发人员和运维人员共同解决,在不同的客户端程序中,维护相同的分片逻辑成本很大,需要消耗巨大的开发成本才能保证两套业务系统分片逻辑一致。所以,客户端分片方案并不适合中小型的企业使用。

基于代理的分片

基于代理分片就是客户端发送请求到一个代理,由代理来解析客户端的数据,再将请求转发到正确的节点,最终将结果回复给客户端。常用的基于代理的分片方案有两种,Twemproxy、codis。

Twemproxy

Twemproxy是一款由Twitter开源的redis proxy方案,在Twitter、Yahoo都有使用。当Twemproxy工作时,Redis客户端会把请求发送到Twemproxy,Twemproxy会使用一致性hash算法,根据路由规则发送正确的Redis实例,最后Twemproxy再把结果返给客户端,从而实现Redis集群。

由于Twemproxy是单线程方案,所以只能使用单核cpu,如果前端含keepalive或haproxy相关代理,可以为Twemproxy做1+1准备。

当Twemproxy应用于多台Redis服务器时,那么实现的性能只能达到单台Redis服务器80%,剩余20%性能损耗。Redis-Sentinel是Redis官方推荐的一种高可用性解决方案,当用Redis做Master-slave的高可用方案时,如果Master宕机了,Twemproxy会订阅Sentinel,完成主备切换。由于Redis-sentinel本身是一个独立运行的进程,它能监控多个master-slave集群,发现master宕机后可以进行自动切换。

Twemproxy优点:

  • 支持Redis和memcached两种集群代理;
  • 后端Redis和memcached无需任何改动,只需要提供IP和端口给Twemproxy即可,操作简单;
  • 支持无效Redis实例的自动删除;
  • 支持状态监控......

Twemproxy不足:

  • 无法动态扩容,如果需要扩容功能,必须研发人员手动迁移,比较繁琐;
  • 由于Redis客户端的请求都需要经过Twemproxy才能到达Redis服务器,期间难免会产生性能损失;
  • 无法平滑地扩容/缩容,对于运维人员来说,如果业务需要增加Redis实例,工作量会非常大......

Codis

Codis是由豌豆荚于2014年11月在GitHub上开源,基于Go和C语言,支持平滑增加Redis实例的集群解决方案。使用Codis时,设置好下属的Redis实例,在需要连接Redis的地方改为连接Codis,之后Codis会以一个代理的身份接受请求,并使用一致性hash算法,将请求转接到具体Redis,最后再将结果返回到Codis。作为基于代理的分片,功能与Twemproxy类似。

Codis主要包含四大组件Codis Proxy(codis proxy)、Codis Manager(codisconfig)、Codis Redis(codis-server)和ZooKeeper,每一个组件都可以进行动态扩容。

Codis Proxy:客户端连接到Redis代理服务,本身已实现了Redis协议,Redis客户端连接到Codis Proxy可以进行各种操作。Codis Proxy是无状态的,一个业务可以通过Keepalived等负载均衡软件部署多个Codis Proxy;

Codisconfig:Codisconfig是Codis的管理工具,支持添加/删除Redis节点、添加/删除Proxy节点、发起数据迁移等操作。另外Codisconfig自带http server,里面集成一个管理界面,运维人员可以在浏览器上观察Codis集群的运行状态并进行相关操作;

Codis Redis:Codis Redis基于 redis-2.8.21 分支开发,是Codis项目维护的一个Redis分支,其中加入了slot支持和原子数据迁移指令;

ZooKeeper:Codis通过ZooKeeper来存放数据路由表和Codis Proxy节点的原信息,Codisconfig发起的命令都会通过ZooKeeper同步到各存活的Codis Proxy节点。

路由查询

路由查询是指将任务请求发送到任意节点,接收到请求的节点会将查询请求发送到正确的节点上执行任务。在Redis集群方案中使用的路由查询方案有Redis cluster。

Redis Cluster由Redis官方推出,是一种服务器Sharding技术,3.0版本开始正式提供,可线性扩展到1000个节点。在Redis Cluster中,Sharding将所有Key映射到slot中,slot个数一共16384个。Redis集群中,每个节点都会负责16384个slot中的一部分。当动态添加或减少节点时,需要将16384个slot重做分配,slot中对应的Key也要做迁移。这项工作目前是需要人工介入手动操作的。在使用Redis Cluster时,要确保16384个slot对应节点都能正常工作,如果有一个节点发生故障,整个集群都会无法工作。

为了增加集群的可访问性,Redis官方推荐将节点配置成主从结构(一个master主节点挂多个salve从节点)如果主节点失效,Redis Cluster会根据选举算法从slave节点中选择一个上升为主节点,整个集群继续对外提供服务。

使用Redis cluster时,由于官方并未提供图形管理工具,所以运维比较复杂。而且集群管理与数据存储上存在耦合,一旦集群管理出现问题,整个Redis都需要升级整合。Redis Cluster自2015年发布以来,成功使用的企业还并不是很多。

  • 发表于:
  • 原文链接http://news.51cto.com/art/201907/600247.htm
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券