携程万亿级KV存储治理演进之路-李剑_34页_7mb

携程万亿级KV存储治理演进之路总结

核心内容

携程在大规模KV存储系统建设过程中，经历了从传统Redis部署到容器化管理，再到引入持久化KV存储（kvrocks）的演进。该演进过程主要围绕资源利用率、系统可靠性、数据持久化和运维治理等方面展开。

主要观点

• 容器化管理：携程通过Redis容器化部署实现了从0到100的演进，利用StatefulSet进行有状态应用的容器化管理，并通过Sticky Schedule将Pod调度到特定宿主机。
• 资源利用率问题：早期的Redis部署存在资源利用率低的问题，实例大小方差大，导致宿主机内存不足，系统可能OOM（Out Of Memory）。
• 二次调度策略：携程引入了二次调度机制，通过分析Pod和宿主机的资源使用情况，实现更高效的资源分配，提升系统整体利用率。
• 持久化KV存储需求：随着业务发展，携程发现Redis在数据持久化和成本方面存在不足，因此引入kvrocks作为替代方案，其在性能、兼容性和成本上均优于Redis。
• kvrocks的优势：kvrocks与Redis命令语义兼容度高，性能接近Redis，且支持数据持久化，适合大规模读写业务场景。
• 架构优化：携程通过自研实现PSYNC2协议，支持伪Redis Slave模式，同时引入独占锁机制和可调一致性策略，提升数据可靠性与系统稳定性。
• 容灾方案：携程采用跨机房容灾策略，结合Sentinel Group和Raft选主能力，实现数据不丢失和系统高可用。

关键信息

Redis治理演进

• 一致性Hash：用于实例分布，支持每天十万亿次访问。
• 生产环境现状：存在数万Redis实例，数千台宿主机，内存超分问题严重，且不开启AOF持久化。
• 容器化方案：使用StatefulSet进行Pod管理，宿主机限定Pod数，Sticky Schedule确保Pod调度到特定宿主机。
• 问题与分析：实例大小不一致导致资源利用率低，无法容忍内存不足导致应用报错。
• 二次调度：通过分析Pod和宿主机的资源使用情况，实现更高效的资源分配，减少内存不足的风险。

持久化KV架构实践

• kvrocks选择：因其与Redis命令语义兼容度高、性能接近Redis、成本低，成为携程持久化KV存储的首选方案。
• 替换Redis：通过自研实现PSYNC2协议，支持伪Redis Slave模式，实现与Redis的平滑过渡。
• 锁机制：支持独占锁，确保扣库存等操作的串行化，避免并发问题。
• 一致性策略：支持全异步复制、本机房半同步复制、跨机房半同步复制，满足不同场景下的数据可靠性需求。
• 容灾方案：通过Sentinel Group和Raft选主能力，实现三机房容灾，提升系统可用性。

踩坑经验

• XFS文件系统问题：XFS文件系统在某些情况下会hang死，导致宿主机只能断电重启。需注意内核版本与文件系统兼容性。
• 时钟漂移问题：skylake处理器在4.10内核上时钟变慢，NTP修正可能导致Redis Slowlog不准确，需谨慎处理。
• 网络超时问题：应用层出现无规律超时，主要由宿主机延迟较大引起。4.19内核修复了Pod删除后cgroup信息残留的问题。

总结

携程在KV存储治理方面经历了从传统Redis部署到容器化管理，再到引入kvrocks的持久化方案的演进。通过优化资源分配、提升系统可靠性、实现数据持久化，携程成功应对了业务发展带来的挑战。同时，过程中也遇到了诸多技术难题，如XFS文件系统问题、时钟漂移和网络超时等，通过技术攻关和架构优化，最终实现了系统的稳定与高效运行。整体而言，携程在KV存储治理上的经验表明，拥抱新技术的同时需结合实际场景进行适配和优化，确保系统的可靠性和性能。