Redis数据库云端最佳技术实践

1,091 阅读15分钟

欢迎大家前往腾讯云+社区,获取更多腾讯海量技术实践干货哦~

本文由腾讯云数据库 TencentDB发表于云+社区专栏

邹鹏,腾讯高级工程师,腾讯云数据库Redis负责人,多年数据库、网络安全研发经验。在网络、计算、存储、安全等领域有深入的研究和丰富的产品化经验。 在Redis、MySQL等数据库的高可用、高可靠和中间件方面有丰富的实践经验。

img

这次过来主要是和大家分享一下,腾讯云上个月正式上线的Redis4.0集群版的相关内容,跟大家分享我们在做集群版的时候有哪些思考,我们怎么去设计整个系统架构,最终我们做了哪些东西。大概会有三个点,第一个点是说Redis的使命,我们看Redis是什么产品,为什么这么火,第二块就是腾讯云Redis4.0集群设计经历了哪些思考,最终做成什么样子,最后是2018年年初,登录到腾讯云的自研兼容Redis协议的CKV引擎,他是怎么样的一个架构设计。

img

我觉得每个伟人都是带着使命来的,Redis也是一样的,每个时代都有每个时代的明星,Redis是移动互联网的时代数据库明星,Memcached诞生在Mysql无法满足业务高并发低时延需求的时代,但是Memcached在使用体验,业务场景的支持方面太过简单,所有就有了Redis的诞生,Redis是一个高性能、低延迟、支持复杂数据结构的瑞士军刀。

img

我们接下来看一下这个属于Redis数据库的时代,今天是一个什么样的情况,这是这个月刚刷新的数据,Redis的排名已经超过了ES了,已经位列第七了,而且一直持续增长,越来越热,这个背后还隐藏了一个数据,Redis的官网现在有65%的流量来自中国大陆,全球都在用,但是中国的程序员用得最6。这里可能是跟国情有关,咋们国家人多,所以要求高并发,现在服务类最火,服务质量第一要求就是快,可以看我们现在都快递、打车、外卖这些场景,第一体验都是快,这是Redis的优势。

这块是Redis标签的一个排名,我们可以看到第一个是Performance,性能包括高并发低时延,我们来看下Redis在并发上面能做到多少,Redis能做到单核每秒跑10万次请求,还可以在5万并发的时候做到99%的请求在1毫秒内返回。in-memory cache,用Redis不用建表,这对程序员来说,我觉得确实是开发者给我们的礼物,所以Redis能够满足这个时代的要求,能够笼络我们这帮开发者,能够成为这个时代的明星。其实Redis已经有10年的发展历史,但是我们可以看到这两年在我们云上还在持续快速的增长,Redis主要场景还是在于缓存,从我们现在的数据来看,如果抛开游戏的场景不说,80%的场景都是缓存,所以它还是缓存数据库,下面还有很多标签,我们总结下来Redis是一个非常快非常简单好用的内存数据库,这就是Redis简单的画像。

进入到今天的正题,我来跟大家分享一下我们做了接近半年腾讯云的Redis4.0Cluster版本的情况,我们基于社区4.0版本+自研的Proxy打造的分布式缓存数据库,我们先认识一下官方Cluster是什么样的一个数据库,相对于主从版的话,在逻辑层面上多了管理层,官方Cluster有数据层面和管理层面,我们可以看一下这两个层面的东西,第一层面是在集群这里有一个逻辑在里面,负责把数据Sharding到不同分片,把数据打散,第二块是自治管理。另外一块就是做了平滑迁移的支持,在新增版里面加了两个命令,如果数据没在这个分片上可以告诉你在别的分片上,再加上智能客户端的配合,就算数据搬了之后,也不会访问失败,总有一个地方能找到它,这是数据层面的情况。另外就是下层管理平面的内容,管理平面是完全自治的管理系统,基于gossip协议,一个无中心化的方案,不需要第三方组建,无节点管理完全是靠大家商量,这个人究竟还活不活着,大家商量出来的,不需要第三方参与的。另外一块就是高可用,会有完整的一套检测逻辑以及投票把它判死的逻辑,集群版做了两大块特征,这是官方源生的情况。

我们认为Redis Cluster一定要有一个Proxy,第一原生集群版必须有一个智能客户端支持,刚才说了在集群版里面新增了几个命令,你访问的时候如果这个数据没在这个分片,会告诉你到别的地方取,原来不需要处理这种命令,当迁移到集群版遇到这种命令就傻了,没办法跑了。这个时候你需要智能客户端的支持。另外的情况是你的客户端需要感知后端的架构,把所有信息同步到客户端,然后客户端做分片。对运维比较简单,但对于我们开发者是极其不友好的,在云上,IP资源很珍贵,我们现在有一个电商的大客户,现在用128片集群版,用的是一组两从,所有节点要128×3,就400多个IP,一个C网都不够,这种用法用起来对客户端太不友好。为什么必须要Proxy,在某些层面上要丰富某些功能,在集群方面的监控做的不够,比如说数据倾斜,因为是无中心化设计,没有统管全局,我们要做流量隔离,要做热Key监控、访问监控,要么改变Redis-server代码要么用中间件实现。做云的时候云上的客户太多了,会有很多客户,很多需求,很多功能要上,都去改Redis的代码,Redis的代码很难维护,最简单的办法就是做一个Smart Proxy,它相当于一个智能客户端。我们把这块Sharding的逻辑下沉到中间件。

我们看一下如果要选一个Proxy有什么可选的?应该大家这些都很熟悉,Twemproxy是一个老古董了,代理组件最大的硬伤是无法支持扩容和缩容,你在业务增长的时候重新搬数据根本受不了。另外就是Codis,国内的大牛spinlock开发的,Codis做了一套完整的方案提供给大家,系统很大很复杂。确实没有官方做的优雅,同时也改了Redis Server的代码,还有一个硬伤是没有官方血统。这是主流我们能看到的比较常见的方案,云上我们是没办法直接搬的,因为无法在云上顾到成千上万的用户的需求的。

img

看我们腾讯云做的方案,后面是官方源生的Cluster,完全是自治的版本,我们做了少部分的优化。再往前是智能客户端,会完成代理转发,做大量定制化监控以及数据Sharding。再往前面就是LB,主要是为了提供VIP,这样对开发者来说看到一个IP就行了,像单机版用它就OK了,这种是比较优雅的方案,所有的东西都屏蔽到后端,我们只需要写和读就可以了,这是咱们最终的方案。

Redis集群版本身数据操作层面是很简单很稳定的,在做集群版的时候我们在两个地方做了很大的努力,第一个是数据迁移,我们看一下哪些场景会有数据迁移的需求?

听众:老师,你好,我是一个初级人员,我们公司现在也在用Redis集群,如果想用你们腾讯云的话,这个步骤能解决你刚刚说的代理,这些东西由你们管理吗?之前都是我们自己百度搭了百度官方的集群方案在用。

邹鹏:你们现在数据在哪里?

听众:放在自己的本地,我们有意向购买腾讯云的Redis。

邹鹏:你们现在有数据,业务上云之后数据要上来,我们有DTS的平台,只要你把网络打通,我们工具就能连到你们的Redis,数据就可以传过来。

听众:谢谢老师。

邹鹏:云计算的优势在于你如果想要立马就能有,整个云在SAAS层PASS层,国内都已经很完善了。如果大家以后创业,把这些辛苦的事交给我们就行了。

接下来回到这个话题,数据迁移,集群版谈到稳定性,最大的挑战就是数据迁移,哪些场景下会有数据迁移呢?扩容,比如说扩容的话,可以看到我们的场景,三个维度,横向分片数,128片,垂直维度从4G到32G维度可以调整,还有副本数5个副本,10万写,50万读。这种情况下都会产生扩容和缩容的场景。咱们业已在初期的时候少买一点,之后可以横向或者纵向扩。我们花了很大的代价做这块,还有一块集群版,这个东西难免产生数据倾斜,假如你的Key设计的不合理,就会出现你数据基本上都是打在某分片上,这个时候数据倾斜了就要要涉及数据迁移。

有个比较难的地方,迁移过程中比较平滑,极端情况下访问某个Key正在迁移的时候,会等几个周期,具体原理可以下来或者我们交流,现在的情况,比如原来搬数据的话肯定会断连接,现在集群版的支持,加上我们中间有一个PROXY可以屏蔽掉,在你业务跑的时候不需要停服就可以进行扩容或者缩容,不过还是建议在业务的低峰期做,我们指定时间升级,比如定时到凌晨三点钟做这个事情就妥妥的。Redis有两大痛,第一是大Key,第二是热Key。如果我们现在比如说遇到大Key的问题,我们数据迁移的时候是搬这个大Key还是其他的Key?

分析大Key要做RDB分析,这个过程很慢,我们在云上每天都做备份,我们在这里做了一个异步懒惰扫大Key的事情,在搬迁之前挨个把Key都扫一下遍,然后就结合数据的算法,哪里有大Key就知道了,我们就避开大Key 进行搬迁。现在至少遇到大Key不会让你的Redis卡住。

听众:你们搬迁的话对前面的数据有影响吗?

邹鹏:搬迁本身设计就考虑到业务不用感知,不用非要挂靠停服,这块我们也是想可用性做到极致。

我们需要在Proxy做全局监控,怎么炸干Proxy的价值呢?1、访问监控;2、Key分析;3、指标监控;4、慢查询;5、告警配置;6、流量隔离。

我们会分析实例哪些Key,告诉你在Redis里面放了什么Key,然后前缀分别是什么,还有就是大Key,准确的大Key是通过RDP分析做的。上面提的大Key情况是数据搬迁的时候我们要实时看一下,也是异步扫的过程。有时候想看一下开发究竟写了什么数据在里面,可以通过这些数据了解到你的Key的情况,还有常见的指标监控,流量、命中率这种,很重要,缓存、可以通过命中率看到,这个时候10%5%的时候是有问题的,这个指标很关键,能够帮助我们及时看到异常的问题,容量、流量、还有命中以及查询miss的情况。

慢查询不是特别多,但是会有。还是整个腾讯云有完整的监控系统,所有指标都是接入云监控的,配置一个指标,触碰阈值就能发告警。很容易出现大Key,会影响到你其他的实例,这个时候我们必须要对流量做隔离,我们在Proxy做隔离,每个规格对应哪些流量,保证业务的可用性。

这就是最终的版图,从服务器对应下面4.0的集群,这是三层的情况,这边是周边的支撑系统,比如说监控、资源管理、备份。源生有分布式自治,我们还会做更细层面的,比较主机层,最大的保证可用性。

这是跨可用和高可用的问题,现在都怕挖挖机,我们会提供跨可用和高可用的方案,比如你在广州一区,买了一个集群4.0,我会复制到集群到别的可用区,在每个区提供不同的IP,都可以访问和写,只不过在同时访问的时候,写再返回到主可用区。异常情况发生的时候,整个可用区不可访问,你的业务调到可用区二区还可以用,就是这么一个架构保证在可用性方面做到地域级别的可用性。

img

另外介绍一下18年初登录腾讯云的兼容Redis协议的自研CKV引擎,CKV名字很简单很朴素,一看就是做研发人员取的名字,不会说牵牛星织女星的名字。这块是整体的情况, 2009年开始立项,最大的背景就是QQ空间,那个时候就起来了,2013年访问量10亿,去年年底我们就基本完成了兼容Redis协议的开发,然后上腾讯云,之前是私有协议,所以这块上云,大家接受不了,去年做的重点事情是兼容Redis协议,在今年年初我们就正式上线了,大家到时候也可以在我们的官网上能看到,

img

为什么这里要单独提一下这块的设计,没有Proxy集群不叫优雅的集群版,但CKV确实没有Proxy,但是它也确实很优雅。Proxy有很多好处,但有一个问题就是费钱,成本很高。我们就用另外的方案,就是CKV最早的方案,没有Proxy,请求会随机打到任意一个分片,每个分片会有全局的slot信息,如果发现这个请求不能在当前分片处理能够转发到目的节点去处理,每个节点都可以是Proxy,好处是省钱,时间更低。这边是逻辑的概念图,比如说CVM到LB到数据节点,假如你的请求达到从节点,这个从节点点会把请求放到主节点,主节点把数据返回完成之后再返回从节点,这是CKV不一样的方案,是源生分布式的。另外在网络上突破了单线程,Redis的消耗是Key的操作还有网络的操作,像QPS5-10万的时候,网络占比很大,我们把网络收发变成多线程,既保证数据一致性,又把性能提升,最高单位节点能够跑到30万+,比如说你需要事务的支持,但是需要事务支持的时候很难用集群版的,这个时候可以考虑这种模式去支持,既要突破10万QPS的,又要做到数据无分片的情况。更多数据库前沿技术可关注 我们公众号:腾讯云数据库CDB

img

Q & A

Q:你好,我问一下Redis跟Mysql的占比分别是多少?

A:我很好奇,你问这个问题的背景是啥?

Q:MySQL使用的占比会比你这个大很多。

A:你可以看这张图,实际情况大概是这样子,大概10:1的样子。

Q:在单节点的时候,考虑过Redis怎么实现高分组吗?我们是不是可以考虑通过DPDK吗?

A:咱们也尝试过这样的思路,投入产出比不会特别高,现在技术圈流行一个概念就是去OS,去FS,去协议栈,但是这块的成本说实话特别的高,,投入特别的大,TCP很慢很老很保守,但是跑了那么多年,如果新做一套成本会特别的高,投入产出比很低,真正单个线程要写特别大乐得场景不会特别多,在有Redis 集群版的情况下我们可以考虑通过分片的扩展来提升写性能,通过添加副本来提高读性能。所以这块也是我们经历过的一些思考。

相关阅读 【每日课程推荐】机器学习实战!快速入门在线广告业务及CTR相应知识

此文已由作者授权腾讯云+社区发布,更多原文请点击

搜索关注公众号「云加社区」,第一时间获取技术干货,关注后回复1024 送你一份技术课程大礼包!

海量技术实践经验,尽在云加社区