给我10分钟，无感知搞定Redis集群扩缩容( 三 ) 一、背景携程Redis集群规模和数

加强大key的检测逻辑，对于超过512M的key会有告警邮件告知所有者。 V2中所有实例的maxmemory在分拆之前不设置限制，统一都调到60G ，防止V2中key分配不均导致key驱逐。水平扩缩容后，在V1和V2切换过程中，检测V2中的实例是否发生过驱逐，如果有则默认分拆失败，不进行切换。2）mget扩容后会导致性能下降
对于极个别的场景，我们还发现， mget请求耗时会有明显上升，主要原因还是在于，扩容之前mget需要访问的实例数少，而分拆后访问的实例数变多。一般这种情况，我们建议业务控制单次mget的key的数量，或者将string类型改造为hash类型，通过hmget来访问数据，保证每次只会访问到一个实例，这样扩容后其吞吐量是随着分片数量线性增加，而延迟不会有增加。
四、总结和未来规划
1、Xpipe支持
目前水平扩缩容和漂移以及二次调度等一系列治理工具和策略组成了一个比较完善的闭环，有效地支撑了生产几千台宿主机，几万带超分能力Redis实例的运维治理。
但目前受制于xpipe的架构，对于接入了xpipe的集群，必须先扩缩容后再将DR端的xpipe人工补齐，自动化程度还不足，而补齐xpipe的时间比较长，比如之前是就近读本机房的Redis集群的APP ，在扩缩容后可能一段时间里只能跨机房读取，必然导致延迟上升。而这种延迟上升又会影响我们对于水平扩缩容逻辑是否正确，是否需要回退的判断。因此后续我们会针对xpipe集群，也做到和普通集群一样，也就是V2集群在扩缩容写流量之前就是带DR架构的集群。
2、持久化KV存储的支持
除了Redis本身受业务欢迎使用广泛外，我们还发现有些业务需要相比Redis更可靠的KV存储方式，比如数据保存在磁盘上而不是保存在内存里，再比如业务需要支持一些增减库存逻辑，对某个key的独占访问，实现语义近似INCRBY操作，但实际上是对于一些字符串进行merge操作。此外数据可靠性要求更高， master宕机不能丢失数据等。针对这些需求目前我们已经也有一些实践经验，将在后续文章中分享。
作者丨布莱德，携程技术专家；向晨，携程数据库专家；骋成，携程技术专家；小峰，携程高级软件工程师。
来源丨公众号：携程技术（ID：ctriptech）
dbaplus社群欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn