干货 | 携程持久化KV存储实践

作者简介

 

布莱德，携程软件技术专家；蔚浩，携程资深软件工程师；小董，携程技术培训生。

一、背景

过去几年，携程技术保障部门在Redis治理方面做了很多工作，解决了运营上的问题，在私有云上也积累了丰富的经验。后又通过引入Kvrocks，在公有云上实现降本增效的目的，从而支撑了公司的国际化战略。

与此同时，国内业务部门存在降低基础建设成本的客观需要，有些业务方期望提供一种非传统关系数据库来解决某些高性能海量空间的业务需求，并在此基础上支持特殊定制化以面对后疫情时代的挑战。这些变化使我们开始思考，是不是可以参考公有云上的思路，在私有云上构建一种持久化数据库，来满足业务方对高性能、低成本、海量、持久化的需求。

二、面对的问题

回顾之前在公有云上的方案，目的明确。因为公有云的内存较贵，我们将Redis的数据存在SSD上来降低成本，选型了Kvrocks，并自研实现支持Redis的复制协议，将公有云上的成本降低了60%（图1）。

图1

随着业务发展和Redis集群的日益增长，需求更加多样化，需要在私有云上同样能有一种持久化的KV存储系统来提供服务，包括：

1）KV存储和读写的场景，Redis能提供的存储上限过低，需要有大容量的KV存储系统；

2）数据持久化，而不是像Redis那样重启数据即丢失；

3）节约Redis的使用成本，毕竟私有云上的Redis集群非常庞大；

4）提供类似selectforudpate的语义来实现库存之类字段的扣减，而不是依赖外部的一些组件，比如分布式锁；

5）数据能提供相比Redis更高的一致性，比如支持同步复制。

我们仔细分析业务需求和业界可选的方案，以期望找到一种持久化的KV数据库，能兼容Redis满足大容量和成本降低的需求，而又不局限于Redis，能提供更多样化的能力来支撑业务的诉求。

三、调研和选择

我们调研了业界大部分的NoSQL/NewSQL数据库，主要考虑以下几个方面。

是否为业界主流

主流有两层含义：第一，是否流行，比如github上的star数，是否是顶级开源基金的项目，或是否有大厂背书；第二，其理念是否主流，如现在使用最广的关系型数据库mysql，以及newsql TIDB，其相关概念如半同步复制，GTID，raft，计算存储分离等概念都比较深入人心。

是否有成熟的中间件

中间件成熟是非常重要的一种能力，一旦选择了一种不合适的数据库，中间件相关的路由，打点，监控，降级，熔断，DR切换等每一项都需要投入大量的人力物力来做，此外稳定的中间件也是需要长时间打磨才能被业务方信赖，如果能复用现有中间件的大部分能力，能节约大量人力物力。

集群运维治理配套是否完善

选择一种KV数据库，除了中间件外，治理相关的如集群扩容，缩容，实例的迁移，资源利用率等一样要考虑进来。无论哪种数据库，部署后的运维治理相关，能复用现有的能力最好，如果不能复用，需要考虑：扩容到10倍需要多久时间，是否可以缩容？是否好迁移，对业务透明？大规模部署后，资源利用率是否可以提升？

性能是否满足要求，是否支持10X的扩展

上面说的这几点，如果都满足，但性能不满足或者不支持10X扩展，那也将一票否决。性能也是重要考量的一块，希望找到一种性能优异的KV数据库。

是否可以二次开发，独立演进

对于携程这样体量或相似体量的公司来说，持久化KV的数据库大多有自研的或基于开源二次开发的数据库，比如美团的Cellar，饿了么的Tidis，360的pika等，我们同样需要选择一种易于二次开发或方便扩展的数据库，来开发自定义的特性支撑业务。

调研的过程受制于篇幅限制，不再一一展开，最终我们继续选择了Kvrocks来作为治理演进的对象，其他的NoSql/NewSql有各种不足，而Kvrocks受益于Redis运维治理的成熟，可以复用现有的大部分Redis中间件和运维治理的能力，在携程与Redis几乎无差异的部署/使用方式，当下无疑是最适合的一种持久化KV数据库。

四、从Kvrocks到TRo