共计 5446 个字符，预计需要花费 14 分钟才能阅读完成。
欢迎大家前往腾讯云 + 社区，获取更多腾讯海量技术实践干货哦~
本文由腾讯云数据库 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 集群版的情况下我们可以考虑通过分片的扩展来提升写性能，通过添加副本来提高读性能。所以这块也是我们经历过的一些思考。
相关阅读【每日课程推荐】机器学习实战！快速入门在线广告业务及 CTR 相应知识
