开发者学堂课程【Redis 入门及实战：Redis 架构及介质选择指引】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/777/detail/13652
Redis 架构及介质选择指引
内容介绍：
一、Redis 集群架构
二、Redis 存储介质
三、从社区到企业版
一、Redis 集群架构
本次课程主要从以下内容讲解第一个是 redis 集群架构，第二个是 redis 存储介质，第三个是 redis 从社区到企业版，主要是社区到企业的一个提升，主要是高可用和平滑扩缩容。
第一个内容是 redis 集群架构，主要是集群架构详解，proxy 与直连以及如何选型。
1、集群架构详解
集群架构里面的情况如下，redis 官方售卖平台上也会看到以下几种形态，首先两个大类就是一个是标准版，第二个就是非标准版，没有分片的一种显示，是原始的redis 单进程模式，在标准版里面会有双副本，大副本跟读写分离几个小类，然后在集群版里面有代理模式跟指点模式，代理模式实际上是为了兼容一些业务，从标准版牵引到集群版的时候，有一些认识秘密，在分布式的就是在激情版的情况下，是兼容，做一些金融，通过 policy 进行帮助版本。业务把这方面的命令任何问题进行解决，直连模式就是 redisclient 通过 rediscluster 模式去指点 redis 的节点，做到一个减少网络时延。提升一定的性能的一个目标，两种连接模式下也分别各自支持了双副本，跟单副本两种数据形态。
2、标准版
使用场景
-对 Redis 协议兼容性要求较高的业务。-单个 Redis 性能压力可控的场景。
- Redis 命令相对简单，排序和计算之类的命令较少的场景。
标准版就是下图中所显示两个，业务是 esc 通过 SLB 进入到后端 redis 节点，redis 节点也有两种模式，左端的进程 A 和右端的进程 B，一组一倍呢，进程 B 是一个热备的情况，主备之间是数据直接进行同步的，另外一种形态是冷背，就是右边的这种情况，只有在主节点挂掉以后，冷备才会被拉起，然后此时数据是空的，这两种形态，标准版使用场景是对业务对 rush 的协议，兼容性要求比较高的情况会对标准版命令要求最全的一个集合，业务最大的情况下通过 redis 的一个场景，具有横向扩展的能力，提供的吞吐能力是受限于单个 redis 进程的。
第三个使用场景是使用 redis 命令相对简单，排序和计算之类的命令较少的场景。产品因为也是受到倒计时，单进程的一个处理能力的限制，如果跑的命令比较复杂，想一下排序要计算或者如果脚本之类的话，如果把一个命令或者一个请求，把主进程打满的话，会对其他的请求造成影响。
3、标准版-双副本标准版-双副本模式采用主从 (master-replica) 模式搭建。主节点提供日常服务访问，备节点提供HA高可用，当主节点发生故障，系统会自动在30 秒内切换至备节点，保证业务平稳运行。特点-可靠性:采用双机主从 (master-replica) 架构，主从节点位于不同物理机。主节点对外提供访问，用户可通过 Redis 命令行和通用客户端进行数据的增删改查操作。当主节点出现故障，自研的HA 系统会自动进行主从切换，保证业务平稳运行。-数据可靠:默认开启数据持久化功能，数据全部落盘。支持数据备份功能，用户可以针对备份集回滚实例或者克隆实例，有效地解决数据误操作等问题。
同时，在支持容灾的可用区（例如杭州可用区 H+1 )创建的实例,还具备同城容灾的能力。
刚才讲了细分为两个种类，一个是双副本；另一个是单副本冷备类型。Redis 两个副本之间是实时同步的，是一个异步同步的实现，在主节点宕机的一个瞬间有一小部分节点是没有同步到备节点上的。
进行主备交换之后，B 节点上有一小部分节点是丢失的，或者相对于 A 节点有一部分节点延迟造成的丢失，在可靠性中虽然已经有主备两个节点，还可以进行数据的一个克隆，就是备份集，在后期需要的时候可以从备份集进行恢复，这是双副本的一个情况。
4、标准版-单副本标准版-单副本采用单个数据库节点部署架构，没有可实时同步数据的备用节点，不提供数据持久化和备份策略，适用于数据可靠性要求不高的纯缓存业务场景使用。特点-纯缓存类业务使用，单副本只有一个数据库节点，性价比高-阿里云自研 HA 高可用系统，异常 30 秒自动切换切换
一半，异常切换时间是 30 秒的一个切换的能力，在尝试单副本时，在使用上需要有一些注意点，就是在主备。
比如说主角就是节点 a，这个节点 a 挂掉以后，高考中节点切到 B，B 这个节点在被拉起的时候，是一个空的，里面的数据是空的一个状态，因为没有做数据，同步完拉起后，缓存相当于需要业务去关注的是。缓存冷的冷启动的一个问题需要去做一个缓存的预热，缓存的假数据，数据的加载。
就是标准版里面有单副本，单副本的形态是，采用三个数据节点部署，没有实时同步数据到一个是没有被劫的不提供。从数据持久化跟备份的策略就是，这种产品适用于数据可靠性，要求并不高，业务产品存款存的业务产品，特点的话就是在一些场景中使用的点，避免一些使用的点，切换以后缓存是没有数据的，这个在使用上是需要注意的。
5、读写分离针对读多写少的业务场景，云数据库 Redis 推出了读写分离版的产品形态，提供高可用、高性能、灵活的读写分离服务，满足热点数据集中及高并发读取的业务需求，最大化地节约运维成本。使用场景-读取请求 QPS 压力较大:适合读多写少型业务-对 Redis 协议兼容要求较高的业务建议与使用须知-非特殊需求不建议使用，QPS 压力大的业务建议使用集群版-当一个只读节点发生故障时，请求会转发到其他节点;如果所有只读节点均不可用，请求会全部转发到主节点，导致主节点压力过大。-只读节点发生异常时，高可用系统会暂停异常节点服务进行重搭恢复。不承诺只读节点的恢复时间指标。-只读节点数据旧于主节点且落后时间可能很长。
最初的这种分离的产品型单提供一样是提供高可用高性能灵活的读写分离服务，满足热点数据集中并且高并发读取的业务需求，最大的节约运维成本。
从右边这个图里面，红色的这条线，从事就是读，跟写就是写，读写主要是这里的写，会被路由到主节点的读读请求，蓝色的线会根据 proxy 节点，将读请求转发给其他的读节点，使得流量可以被分读，压力就可以被分开，其他的一些节点上减少组节点的压力，会减少主节点的压力嘛，使用产品的话就是读取的请求，QPS 比较大。第二个是 redis 写意兼容性比较高的一个业务。
第一个是只读节点发生故障的时候，请求会发生到其他节点，就是如果对 ready 的协议要求兼容性要求不是特别高的，比如说能接受在那个集群形式上使用，建议用户是使用集群模式，而不读写分离模式的，建议跟使用须知就是非特殊需求，还是不建议使用那个读写分离模式，而是使用集群版，在业务压力大的时候，最好还是使用集群版，而不是读写分离，那么为什么会有这个情况呢？
这第一个就是当一个只读节点发生故障。如果只读节点均不可用请求，会全部转发到主节点，这个时候就有可能导致主节点压力过大，因为原来比如说有多个读节点，帮主节点承担只读压力，但如果只读节点挂了以后这个请求还是也回到原节点上去访问那第二个，第三个就是只读节点发生异常，是高可用，系统是会暂停这个异常节点服务进行重搭的，但是这个重搭的时间是根据业务的那个使用。
能根据业务的数据量是有所变化的，如果说数据量比较大，那重搭的时候时间就会比较长，因为要恢复只读节点的数据，这个恢复的时间是不承诺的。第三个是只读节点数据是很有可能落后于主节点很长时间的。
6、集群版
使用场景
-数据量较大的场景。
- QPS 压力较大的场景。
-吞吐密集型应用场景。
集群版，就是通过一致性哈希码把数据分布到不同的绝对是节点上。提供一个数据容量跟访问能力的扩展，横向扩展的能力，那使用产品就是数据量，第一个就是如果数据量较大的话，建议选择集训版，第二个是 QPS，压力比较大的时候也是建议使用集群版，第三个是。那个吞吐密集型就是这里的冲突，就指的是，比如带宽就是网络带宽比较大，比如 PV 都是比较大的时候，也是建议使用集群版。集群版同时扩展了处理，容量和带宽这三种能力。
7、集群版-双副本
云数据库 Redis 版提供双副本集群版实例，可轻松突破 Redis 自身单线
程瓶颈，满足大容量、高性能的业务需求。集群版支持代理和直连两
种连接模式。
使用场景
-数据量大:相比 Redis 标准版，集群版可以有效地扩展存储量，最大
可达 4098 GB，能有效的满足业务扩展的需求。
- QPS 压力较大:标准版 Redis 无法支撑较大的 QPs，需要采用多分片的部署方式来突破 Redis 单线程的性能瓶颈
-吞吐密集型应用:相比 Redis 标准版，集群版的内网吞吐限制相对较
低，可以更好地支持热点数据读取、大吞吐类业务。
-对 Redis 协议不敏感的应用:集群版对 Redis 协议支持上相比标准版
本有一定的限制。
集群版也是有单副本或者双副本两种情况，是可以突破的解释单自身的单线程瓶颈，满足大容量，高性能的业务需求，急需满支持代理和直连两种连接模式，使用场景的话，一个是数据量。大的相对于人也是标准版，最大的集群版最大支持是T的一个容量，另外 QPS 的话，也是根据集群分片数，是一个线性扩展的一个情况。
8、集群版-双副本
云数据库 Redis 版提供双副本集群版实例，可轻松突破 Redis 自身单线
程瓶颈，满足大容量、高性能的业务需求。集群版支持代理和直连两
种连接模式。
特点
-代理模式因所有请求都需要通过代理服务器转发，代理模式在降低
业务开发难度的同时也会小幅度影响 Redis 服务的响应速度，如果业
务响应速度的要求非常高，可以选择直连模式，绕过代理服务器直
连后端数据分片，从而降低网络开销和服务响应时间。
另外一个需要在使用场景里面需要注意的是对 radius 协议建设幸福要求不敏感的应用，因为 redis 集群版在在写那个命令的支持上，相比标准版会有一定的限制。proceed，就是代理模式的一个集群码，以及直连模式，右边这个图里面对比上一张图，上一张图是有一个 procedure 代理的，这种模式直连模式下是用户直接通过 SD 卡是协议直接直连，后段数据节点有它的特点，直连的模式的特点是相比于代理模式，请求是。
可以直接到达数据节点，降低一跳代理网络时延跟，比较适合一些业务，对响应速度要求比较高的一些应用
9、集群版-命令限制不支持的命令- SWAPDB- CLIENT ID- sORT( BY 和 GET )受限的命令在集群模式下如果需要执行受限制的命令，需要使用 hash tag 确保所要操作的 key 在同个 hash slot 中,hash tag 的详细用法参见 Redis 官方文档 Lua 脚本使用限制-所有 key 都应该由 KEYS 数组来传递-所有 key 必须在同一个 slot 上-调用必须要带有 key-不支持发布订阅消息-不支持 UNPACK 函数其他限制
集群版，对逻辑使命兼容性上的一些差别，是命令上会有一些限制，第一个，支持一些命令，比如 swapDB 那个排序这个命令，这些命令是这三个命令是不支的，命令是受限的，受限的命令，在这个右边的这个表格里面，，详细的一些情况。
可以查看 redis2.0 官方文档，受限的命令都是一些多K的一些命令，为什么 key 的命令会受到限制，集群版会将数据根据一次性哈希分散到不同的数据节点上，涉及到多 key 的命令，如果经过一次性哈希之后发现放在不同的节点上，
第三点是在集群下面，lua 脚本有一些限制，不可能在一个单进程里面完成，这些命令直接会被返回错误，如果要使用这些 key 命令，需要是这些每个 key，被哈准确的话哈希到一个 slot 上， K 是可以添加一个哈希 tag，就是一个花括号里面指定一个哈希的一个，指定一个标识一个 tag，其是花括号里面内容相同的 K，就会被哈希到同一个 slot 上，在同一个 slot 里面的这些 case 可以支持的，些受限的命令是可以支持。
Lua 脚本里面不支持 pubsub 和 UNPACK 这个函数。
10、集群模式如何选型
-评估 QPS 和容量时一定要为未来留有余量
-不同架构间存在一定的兼容性问题,业务允许的情况下尽量使用不同架构命令支持集合的交集，以便后续架构切换.
在评估 QPS 跟容量的时候，一定是要为未来留有余量就是因为这个不同的集群模式，他们之间的切换是有一定的兼容性问题，跟一个切换上的代价的。所以尽量避免的是切换问题，如果是兼容性问题，就会有切换上的代价问题。
尽量避免后期因为容量增长以及 kps 导致的同样去切换，如果是兼容性的问题就需要用户去修改代码，就是不适用一些具有兼容性的命令，在命令上尽量去使用不同架构命令支持集合的交集，以便后续架构切换，交集的话就是命令的交集，是基本上在使用的时候就是使用集群命令的集合。
如何选型，QPS 有一个高低之分，一个 redis 进程是否能满足，如果 QPS 是比较低的时候，在一个进程里能轮流进行，阿里进程最大是 64db，但是还是推荐一个db 节点尽量不要超过 34db，不过以后会有一些符合 rohs 的一些问题，所以在这个容量，比如说小于 32G 的情况，PPS 又低的情况，选择标准版，如果 QPS 高或者是容量高，那么有一个高的话，建议使用集群版。
标准的情况下，再去看一下对数据的一个可靠性的要求，如果数据是单纯的作为一个缓存加速的，或者是数据可丢的一个情况的话，是可以选择单副本，这种就是标准把当副本这样子。
是可以那个降低成本就减少一半的成本。相当于双副本来说，可靠性是比较高的，要求数据在异常情况下不能全丢的时候，那么这个时候如果读写情况并没有一些明显的一个差异。读写能力都差不多的时候，可以选择双副本，然后只有在读特别多的时候再读的请求，能力超过了单个历史进程的时候，也可以进行读写分离，但是读写分离并不是一个特别好的选择，在选择读写分离的时候，建议还是尽量选择集群版。集群版，看一下业务对那个命令兼容性上的一个要求，假设是一种情况，原来在使用的，是一种标准版的，情况因为容量 QPS 上升了，要切换到集群版。
业务代码又想要太多做修改或者是不想修改的时候，这时兼容性要求较高。那这个时候就建议就是选择代理模式，跟那个兼容性的问题，由二零提供这个 proxy 去解决。如果对兼容性的要求比较低，本身业务就没有一些多 key 的使用，本就是按照集群新业务或者新开发的时候就已经按照集群的命令去书写。就可以选择直连模式。接着再看数据选择模式是低还是高，如果是低的话就选择单副本。就降低了一半成本，否则就选择双副本。
单副本虽然保证了单副本的高可用，在一个单副本挂了之后，就会进行修复。
二、Redis 存储介质
内存型持久内存型容量存储型
混合存储型
持久内存型
1、持久内存型 Redis 企业版持久内存型（简称持久内存型)基于 Intel 傲腾数据中心级持久内
存 (AEP)，为您提供大容量、兼容 Redis 的内存数据库产品。单实例成本对比
Redis 社区版最高可降低 30%，且数据持久化不依赖传统磁盘，保证每个操作持
久化的同时提供近乎 Redis 社区版的吞吐和延时，极大提升业务数据可靠性。
特点
-超高性价比:相同容量下对比阿里云 Redis 社区版本，价格降
低 30% 左右
-大规格优化:解决 AOF 的造成的性能开销，无需在性能和持久
化之间取舍
-掉电数据不丢失:每个写操作都同步持久化
-高兼容性:兼容现有阿里云 Redis 数据库体系
redis 的企业版企业版里面的持久内存型是基于英特尔的傲腾这种傲腾中数据库数据中心持久内存 APP 介质去做的，这提供了一个大容量并且兼容。月底是内存数据库的一个产品，就是单实例的成本将对于呃瑞驰社区版最高可降低 30%，就是这种存储介质的成本是内存器的历史的 30% 啊，最大是 31% 个降低，然后并且数据是持久化数据的持久化，是不依赖传统磁盘，直接在这个内存。持久内存里写下去就能保证每个内存的持久化，就能保持吞吐和延迟相对于社区版是近乎相似的。
那么特点的话，就是一个就是超高的一个性价比，就是相同容量下对比阿里云的Linux 社区版价格降低 30% 左右啊，大规格优化因为持久内存它本身有数据持久化的一个能力。
所以，就不需要有 AF 去做数据的持久化，就少了 FAF 造成了一个性能开销，在内存的形态下对吧，第三个就是掉电的时候数据是不丢失的。每个写都能长久持久化。内存显存内存行的话，双副本的形态，会做一个数据在两个数据节点间同步嘛，但是这个同步也是不，或者说没有进入到 AOF 中。APP19 内存行的话，操作是同步的话，在极端情况下，两个副本，拉电从一边拉起的话，数据是不会有丢失的情况。
2、容量存储型 Redis 企业版容量存储型（简称容量存储型）基于云盘 ESSD 研发，兼容 Redis 核心数据结构与接口，可提供大容量、低成本、强持久化的数据库服务。容量存储型在降低成本和提升数据可靠性的同时，也解决了原生 Redis 固有的 fork 问题而预留部分内存的问题。适用于兼容 Redis、需要大容量且较高访问性能的温冷数据存储场景。特点-兼容性:兼容大部分原生 Redis 命令-成本:最低为Redis 社区版的 15%
基于的是阿里云的 ESD 研发的兼容的 register 核心的数据结构跟接口，可提供大容量低成本强持久化的数据库服务，就是这里的大容量，就是相对于内存来说建议。
能售卖是建议有 64 这个 G 的规格，建议内存行的话就是要小于 32G 的，这样是一个比 archie 能够一个比较稳定的一个情况容量存储容量是可以达到 7GB, 通过的是 redis 进程，快造一份内存，redis 进程 fork 造成瓷板上做，为 fork 预留一部分内存，造成了资源的一部分浪费。兼容性的话是兼容了大部分的原生 redis 命令，是大部分，并不是所有命令都支持。成本的话是最低 redis 社区。最低是百分之十五的成本。相应的性能是有所降低的。
三、从社区到企业版
1、阿里云集群能力
集群能力对比 开源版 Redis 阿里云 Redis
迁移异常，丢失部分数据，需手动恢复
数据高可靠，迁移失败自动回滚可重试
高可靠 无中心化控制集群状态收敛慢
中心化控制迅速准确 高可用心跳探测准确性受慢查询影响，造
自研探测机制规避慢查询风险导致的误切换
高可用 高可用探测更准确 成故障切换时间过长或者切换不准确
故障切换时间平均 8 秒，SLA15 秒 怠机需手动进行重搭
管控 日常运维由系统自动完成 扩缩容需借助额外服务 大 Key 迁移影响服务 RT，严重时触发 HA
无感迁移
迁移平滑性 Lua 脚本丢失 无明显 rt 上涨 迁移期间多 key 命令失败
无新增错误 高 低
成本
集群模式有额外内存开销，大 key 小 value
支持细粒度扩缩容
场景内存容量接近翻倍
集群内存使用优化
跟开源版 redis 做一个对比，第一个维度是高可靠这方面开源的开源版，而且是在集群做数据迁移的时候迁移，发生异常就会丢失部分数据，而且不能正常回复，因为整个迁移是需要做一些设置，比如说需要，告诉不同的的的节点，这个 sort，当前在 a 节点需要切换到 B 节点，但是这个动作在开源版里面并没有做一个持久化，在迁移失败或者是有节点挂掉以后，这个整个迁移的状态会被丢失掉，对外提供服务的时候就会有部分数据就会读不到。
这是一个欠异常数据会丢失的一个情况，另外一个就是集群式，没有中心化控制的集群的状态，收敛会比较慢，再有集群里面有节点做 HPV。这个 redis 的话，数据是高可靠的，不管是迁移中迁移过程中失败，或者是迁移和滚。都是会保证数据的可靠的，且如果迁移失败了的话，会将整个数据迁移回滚，会将整个数据丢失掉。
第二个维度是高可用，就是开源版软件是高可用，它是通过心跳探测，准确性会受到慢查询的影响，造成故障切换时间过长或者切换不准确，是因为 redis 实现里面。心跳的频跟用户请求的查询是在同一个线程里面进行吗？如果有慢查询这个线程。拼的请求就会被延迟，这个时候就有可能造成误切换，因为慢查询造成的目前物切换，那么阿里云的话是自研的探测机制来规避慢查询风险导致的误切换，就是检测会更加准确，另外故障切换时间平均 18 秒呢。LV 至 15 秒啊，平均 18 秒。
第三个是管控，开源版 redis 是没有管控的，故障恢复，扩容都是需要借助额外的服务，或者自己通过命令去运营，那么阿里云在做这些运动的时候是业务可以做到。第一个是大 key 迁移影响服 RT，第二个点就是它的 lua 脚本，它会丢失，就是切换 2D 的，这个迁移是不切脚本的。比如说扩容或缩动，以后一些脚本在清洁点上，它就会没有掉这个时候。在实行 lua 脚本的时候就会报错，让用户重新加载 lua 脚本
第三个是迁移的时候多 key 命令是会失败的。它是按照 key 迁移的，对于阿里云redis 无感迁移，无明显 rt 上涨，并且没有新增错误。在整个运维的时候基本可以做到无感知。内存有些下降，成本就会比社区版内存减少接近一半。
2、开源 Redis 集群实现
所有 Redis 节点彼此相互心跳探活，使用内部的二进制协议优化传输速度和带宽。-节点 fail 是通过集群中超过半数节点探活协商确定失败-节点间数据迁移是按照 key 的粒度进行的，迁移过程中一个 slot 的数据会分布在两个节点上优点-使用 gossip 协议无中心控制，无额外控制节点缺点-无中心控制，集群状态更新，故障HA 慢-探活方式单一，受慢查询干扰，容易误切换-按 key 迁移，大 key 迁移造成服务卡顿-迁移异常中断，无法自动恢复-迁移期间多 key 命令失败-迁移依赖外部组件然后阿里群是怎么去解决这些问题的，开源的意思，就是这里的实现，细节就是所有的就是右边这个图一样，它是通过构思一个所有的节点之间，彼此相互心跳，然后做一个碳活跟集群状态的维护。那么再有节点异常的时候，是用通过集群中，超过半数节点炭火协商好确定失败了，如果集群的规模够大的时候，这个协商的过程会相应地会拉长。节点间数据迁移是按照 key 的粒度进行的。迁移中的数据主要会分布在两个节点，因为一个一个可以签的过程中，同一个 smart 里面的一些可以有可能有部分已经迁到新节点，一部分希望那就节点了，那这那么这种实现的优点就是使用 gossip 协议的话是没有中心的，不需要额外的控制节点来做这个节点的集群算法的微博，那么缺点就是没有中心控制节点。
集群状态那个维护会，收敛会比较慢，需要勾起过去收敛吗？然后另外就是故障切换很慢，第二个点就是他的迁移方式，是很单一的字。是通过聘心跳的方式去趟活，那这个时候刚刚也接触过，会受慢查询的干扰，容易造成误切换，明明这个节点再执行一个慢正常的一个慢查询操作，超时就会走。
可能就造成切化，第三个就是按照 key 迁移的方式，一个一个迁移的过程，需要再把这个K在源端先锁住，实际上力度更大，不是按 key 的力度去锁定一个 K，而是说在迁移 K 这个命令下发的时候，整个这个节点的请求就阻塞住了。只有等这个 K 在目的端成功，在每张恢复以后才会让这个源节点提供服务，那这个发送到目的端，在到目的端解包，那个存下来整个过程可能会耗时很长一段时间，这个时候就会造成服务器的抖动严重，可能还会触发 HV。
第四个点是，切换异常的时候是无法自动恢复的，因为可能迁移的过程中，有一部分可以已经迁移到新节点了，部分K还在老节点，那这个时候故障了以后，这些数据就是存在一个中间迁移就存在一个中间状态，需要人为的干预去把 QQ 从重新回滚回来，还是说继续原来的这个迁移，另外除了这个数据的问题要恢复以外，还有的集群这个迁移的状态，也要把它恢复出来，这个是无法做到自动化的。原来地方的命令就会被卖掉，然后迁移，害依然需要外部组件去做牵引，
第五个就是迁移期间多 key 命令会失败，虽然这些 key 已经被严格限制在了同一个 slot 里面，但是因为迁移的时候 slot 里面已经有部分被迁移走了。假如说多 key 命令涉及到 key 已经被潜移走了。
3、阿里云 Redis 集群实现
-中心控制节点采用自研的多因子进行准确的探活-数据迁移采用 slot 粒度 precopy的方式，迁移快速，异常可回滚优点-准确快速的探活，保障服务质量 (SLA<15s)-同时支持直连模式和代理模式-扩缩容业务无感知(大 key，多 key，Lua) ,不断连接-迁移流量在节点间直接传输，不需要外部组件中转管理跟数据的切换，实际上不使用 ghost 这种方式，是采用自研的，一个管控那个控制节点去维护集群的状态，控制节点是。采用了个自研的这个多因子进行准确的探活，不仅仅通过聘去这个三个因子，单个条件去判断节点生活正常，还会通过其他的一些因子去审判。还会通过其他方式准确判断排除节点是否准确运行，慢查询等原因造成了一个切换，在数据迁移方面，可以 copy 的方式去进行迁移，使得一个是千亿更快速，一茶匙可回滚。
precopy 的这种方式的话，就是说在签那个迁移的过程中，先做数据的拷贝，拷贝到新节点拷贝等拷贝完成的，最后阶段那个全部考完以后才做一个路由。
表的一个更新这样子的话，如果在数据拷贝的过程中，有数据有异常，比如说有节点挂了或者网络中断之类的。数据是还在原装饰依然是存在的，只要中断这个拷贝的过程，把迁移过程取消就行了，不影响数据的那个完整性。
优点，第一个就是准确快速地躺回，那么就可以做到这个 LLSL 在 15 秒那么平均，实际上可以做到八秒的时间就可以做到一个故障的故障切换的恢复，另外一次同时支持质量模式跟。那个代理模式就是扩缩容业务，无感知，不断连接，就是进行扩缩容的过程中，不受大 key，多 key，lua 这些进程的限制，这个就是相比于社区版来说的。
第四点就是迁移流量，在节点间直接传出，不需要外部流量，整个迁移都是迁移的发起，是中心控制节点发起的。
数据都是在节点间进行传输，就不需要外部组件中转，可以更加快速并且减少对外部组件的一个依赖。
