欢迎大家前往腾讯云+社区，获取更多腾讯海量技术实践干货哦~
本文由腾讯云数据库 TencentDB发表于云+社区专栏
邹鹏，腾讯高级工程师，腾讯云数据库Redis负责人，多年数据库、网络安全研发经验。在网络、计算、存储、安全等领域有深入的研究和丰富的产品化经验。 在Redis、MySQL等数据库的高可用、高可靠和中间件方面有丰富的实践经验。
这次过来主要是和大家分享一下，腾讯云上个月正式上线的Redis4.0集群版的相关内容，跟大家分享我们在做集群版的时候有哪些思考，我们怎么去设计整个系统架构，最终我们做了哪些东西。大概会有三个点，第一个点是说Redis的使命，我们看Redis是什么产品，为什么这么火，第二块就是腾讯云Redis4.0集群设计经历了哪些思考，最终做成什么样子，最后是2018年年初，登录到腾讯云的自研兼容Redis协议的CKV引擎，他是怎么样的一个架构设计。
我觉得每个伟人都是带着使命来的，Redis也是一样的，每个时代都有每个时代的明星，Redis是移动互联网的时代数据库明星，Memcached诞生在Mysql无法满足业务高并发低时延需求的时代，但是Memcached在使用体验，业务场景的支持方面太过简单，所有就有了Redis的诞生，Redis是一个高性能、低延迟、支持复杂数据结构的瑞士军刀。
我们接下来看一下这个属于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的代码，还有一个硬伤是没有官方血统。这是主流我们能看到的比较常见的方案，云上我们是没办法直接搬的，因为无法在云上顾到成千上万的用户的需求的。
看我们腾讯云做的方案，后面是官方源生的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，都可以访问和写，只不过在同时访问的时候，写再返回到主可用区。异常情况发生的时候，整个可用区不可访问，你的业务调到可用区二区还可以用，就是这么一个架构保证在可用性方面做到地域级别的可用性。
另外介绍一下18年初登录腾讯云的兼容Redis协议的自研CKV引擎，CKV名字很简单很朴素，一看就是做研发人员取的名字，不会说牵牛星织女星的名字。这块是整体的情况， 2009年开始立项，最大的背景就是QQ空间，那个时候就起来了，2013年访问量10亿，去年年底我们就基本完成了兼容Redis协议的开发，然后上腾讯云，之前是私有协议，所以这块上云，大家接受不了，去年做的重点事情是兼容Redis协议，在今年年初我们就正式上线了，大家到时候也可以在我们的官网上能看到，
为什么这里要单独提一下这块的设计，没有Proxy集群不叫优雅的集群版，但CKV确实没有Proxy，但是它也确实很优雅。Proxy有很多好处，但有一个问题就是费钱，成本很高。我们就用另外的方案，就是CKV最早的方案，没有Proxy，请求会随机打到任意一个分片，每个分片会有全局的slot信息，如果发现这个请求不能在当前分片处理能够转发到目的节点去处理，每个节点都可以是Proxy，好处是省钱，时间更低。这边是逻辑的概念图，比如说CVM到LB到数据节点，假如你的请求达到从节点，这个从节点点会把请求放到主节点，主节点把数据返回完成之后再返回从节点，这是CKV不一样的方案，是源生分布式的。另外在网络上突破了单线程，Redis的消耗是Key的操作还有网络的操作，像QPS5-10万的时候，网络占比很大，我们把网络收发变成多线程，既保证数据一致性，又把性能提升，最高单位节点能够跑到30万+，比如说你需要事务的支持，但是需要事务支持的时候很难用集群版的，这个时候可以考虑这种模式去支持，既要突破10万QPS的，又要做到数据无分片的情况。
Q & A
Q：你好，我问一下Redis跟Mysql的占比分别是多少？
A：我很好奇，你问这个问题的背景是啥？
Q：MySQL使用的占比会比你这个大很多。
A：你可以看这张图，实际情况大概是这样子，大概10：1的样子。
Q：在单节点的时候，考虑过Redis怎么实现高分组吗？我们是不是可以考虑通过DPDK吗？
A：咱们也尝试过这样的思路，投入产出比不会特别高，现在技术圈流行一个概念就是去OS，去FS，去协议栈，但是这块的成本说实话特别的高，，投入特别的大，TCP很慢很老很保守，但是跑了那么多年，如果新做一套成本会特别的高，投入产出比很低，真正单个线程要写特别大乐得场景不会特别多，在有Redis 集群版的情况下我们可以考虑通过分片的扩展来提升写性能，通过添加副本来提高读性能。所以这块也是我们经历过的一些思考。
相关阅读
此文已由作者授权腾讯云+社区发布，更多原文请点击
搜索关注公众号「云加社区」，第一时间获取技术干货，关注后回复1024 送你一份技术课程大礼包！
海量技术实践经验，尽在云加社区！
原文地址：https://www.cnblogs.com/qcloud1001/p/9914343.html