选择 KV 数据库最重要的是什么？

经常有客户提到 KV 数据库，但却偏偏“不要 Redis”。比如有个做安全威胁分析平台的客户，他们明确表示自己对可靠性要求非常高，需要的不是开源 Redis 这种内存缓存库，而是 KV 数据库。虽然最后我也没问清楚他们业务存啥（推测是这块业务数据比较机密），但确实业务本身对可靠性要求非常高，开源 Redis 自身的可靠性无法满足他们的要求，最终该用户选择使用 GaussDB(for Redis)数据库，当前数据量已经是 2TB 规模，一直稳定运行中。

真正的 KV 数据库，业界有好几项开源的项目，云厂商也纷纷推出自家产品，比如华为云 GaussDB(for Redis)。使用方在调研选型 KV 数据库的时候，由于要存储百 GB 甚至数十 TB 级的重要数据，首先关注的是数据库是否稳定可靠，同时懂行的客户一般也会聊到自建开源 Redis 的“不靠谱”问题，例如：

问题 1：自建开源 Redis 有丢数据和数据不一致的风险

广告竞价和推荐等大数据业务将海量数据存放在 KV 数据库，开源 Redis 是将全量数据存在内存中，虽然有 RDB 和 AOF 的备份机制，但那只是普通的文本文件，可靠性很低，只能作为兜底手段，关键数据该丢还是会丢。

另外，开源 Redis 主备节点采用异步复制的机制，故障倒换的时候有可能出现明显的数据不一致，像是分布式锁这类场景就会很尴尬：

问题 2：“Cache+DB”的业务架构复杂

电商和游戏等互联网业务采用 Redis 缓存+持久化数据库的架构，通过缓存加速来提升业务的使用体验，业务需要设计缓存的淘汰机制，还需要解决缓存与持久化数据库之间的数据一致性问题，业务架构复杂。

问题 3：开源 Redis 分片故障不能提供服务，故障场景对业务影响比较大

金融、财经和电商等业务对可靠性要求极高，开源 Redis 单个数据分片存放在主备两个节点上，如果两个节点都出现故障，则整个分片的数据不可访问，应对极端故障场景的能力不足。

社区开源的项目一般都引入了 RocksDB 存储引擎（这东西深的很），其实能把上层 KV 业务变得稳定许多，通过持久化存储介质替代内存的方式来弥补开源 Redis 的不足。但它们无法完美解决性能、兼容性和扩容的问题，更无法保证数据库的稳定可靠，还需要投入专门的人力进行搭建维护、调优等……最终综合算下来，成本并不低。

云厂商的 KV 数据库由于进行了技术创新与优化，一般比较给力，以 GaussDB(for Redis)为例，下面从以下几个角度解释如何把一款产品做到“靠谱”：

企业级特性 1：采用内存+NVMe 的存储方案，全量数据三副本持久化存储

GaussDB(for Redis)在存储池中有三副本落盘到 NVMe 存储池中，宕机不会丢数据，也不会存在主从同步的问题。因此，客户可以直接拿 GaussDB(for Redis)当做持久化数据库使用，一库顶多库，业务架构变得简单，也减轻了多套数据库的运维成本。

企业级特性 2：采用存算分离的架构，支持 3AZ 部署和 N-1 故障的超高可用

GaussDB(for Redis)支持 3AZ 部署计算节点，均匀分布在 3 个不同的可用区，如果遇到 1 个或 2 个可用区出现网络、制冷、电力等突发故障，剩余可用区的节点能接管故障节点的数据分片，还能继续支撑业务访问全量数据。

同样得益于存算分离的架构，GaussDB(for Redis)将全量数据落盘到分布式存储池，最多支撑 N-1 故障，哪怕只剩下一个节点正常，也能通过接管所有分片，继续支撑业务运行。

企业级特性 3：双活解决方案支持极致稳定可靠，灵活组网

如果遇到大规模网络故障、电力故障、火灾或自然灾害，导致整个数据库实例不可用，甚至整个 Region 都不可用，GaussDB(for Redis)也在这些极端场景下保证业务的连续性。

GaussDB(for Redis)支持给两个跨 region 的实例建立双活关系，支持数据的同步，如果其中一个实例故障，另一个实例能接管业务，持续提供可靠的数据库服务。双活解决方案已在华为内部 ERP 中稳定部署运行，为 ERP 业务的持续运行提供强有力的保障。

总结

综上所述，GaussDB(for Redis)提供了全量数据三副本持久化存储，支持 3AZ 部署和 N-1 故障的超高可用，双活解决方案支持极致稳定可靠，灵活组网，稳定性和可靠性远超开源 Redis，是一款真正能让企业核心业务放心上云的 KV 数据库。

所以，如果你的业务需要一款稳定可靠的 KV 数据库，可以试试 GaussDB(for Redis)