欢迎大家前往 腾讯云+社区 ，获取更多腾讯海量技术实践干货哦~
本文由 腾讯云数据库 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的情况。
