腾讯重磅开源DCache 分布式NoSQL存储系统

当你在电商平台秒杀商品或者在社交网络刷热门话题的时候，可以很明显感受到当前网络数据流量的恐怖，几十万商品刚开抢，一秒都不到就售罄；哪个大明星出轨的消息一出现，瞬间阅读与转发次数可以达到上亿。作为终端用户的我们可能会思考，服务系统是怎么在这样严峻的流量环境中存活下来的。

其实，服务系统的架构中有许多巧妙的设计来应对这样的问题，而在这其中，通常系统都会架设缓存系统，用以缓解海量访问请求与数据带来的冲击，实现高性能访问需求。

同时，随着微服务与云等技术的发展，分布式架构的需求变得越来越普遍，再加上今天 Web 上的数据类型已经不再单一，而且数据量也呈爆发式增长，传统的结构化存储方案已经跟不上脚步，对数据库的 SQL 操作不再满足要求，于是 NoSQL 出现。

将这几种技术方案整合起来，我们可以设计出分布式NoSQL缓存系统，当前这一类系统有一些比较强大的开源方案，比如 Memcached 和 Redis，它们对整个服务系统的可用性、可扩展性与性能起到至关重要的作用。

听说最近腾讯开源了一个分布式NoSQL存储系统DCache，它的典型应用场景就在分布式缓存。根据官方介绍，DCache 基于 TARS 微服务治理方案，它支持 k-v、k-k-row、list、set 与 zset 多种数据结构，数据基于内存存储，同时支持后接 DB 实现数据持久化。DCache 具备快速水平扩展能力，同时配套有 Web 运维平台实现高效的运维操作。

我们第一时间采访了DCache研发团队成员山宝银，希望对项目的研发背景与相关技术细节有进一步了解。

当前开源的分布式缓存系统中，Memcached 与 Redis 是很普遍的选择，腾讯此次为什么要自己造一个系统呢？

山宝银介绍，虽然 Memcached 与 Redis 本身都拥有极其强大的能力，但是存在运维困难、缺乏集群化方案与无法应对微服务趋势带来的挑战等问题。

举个例子，当前微服务是一大趋势，大家都在说要做微服务，它可以让计算与存储之间解耦，实现轻量级通信。微服务不需要管理生命同期，而作为系统组件的 Redis 则不然，“我们做服务架构设计时希望把逻辑层和数据层分离开来，但是如果使用 Redis 做缓存，缓存与 DB 之间的数据一致性问题，以及缓存不命中如何解决等问题都需要使用者在业务逻辑中做相关处理，这增加了一定的复杂度和难度，也增加了逻辑层和数据层的耦合度。”

另一方面，山宝银介绍，起初面对海量数据和高性能访问需求，腾讯内部各个团队其实都开发了各自的缓存系统，然而这些系统之间协议不统一、服务模型多样化、不具有通用性容错、扩展能力也参差不齐，所以团队就着手研发了 DCache 这一套通用 Cache 系统，希望整体去解决业务、开发、运维和监控面临的各种挑战。

所以也可以看到，目前 DCache 已经应用于腾讯内部多个业务上，包括 QQ 浏览器、应用宝、腾讯地图、腾讯电脑管家、手机管家与腾讯游戏等。

SQL、分布式与 NoSQL 的取舍

SQL 是指数据库的结构化查询语言，它是数据库的操作命令集，传统的关系型数据库都使用标准的 SQL 语句操作处理数据。分布式是软件系统的一种架构模式，在分布式系统中，多个硬件或软件组件分布在不同计算机上，彼此之间通过消息传递进行通信，对外表现为一个整体，提供统一化的服务。

有一种普遍的观点是，数据库 SQL 与分布式之间存在天然对立性，山宝银的理解是：“分布式系统因为数据分散在不同的节点，所以像 SQL 的联表、事务等操作需要全局的锁保护，这样处理起来比较复杂，并且影响性能。”

SQL 还有与 NoSQL 的取舍问题，NoSQL 是指一类数据库，主要用于高性能处理超海量数据，它的一大特点是数据结构简单，以 key-value 为主，数据之间非关联，容易做水平扩展。

从字面上看，NoSQL 似乎是与 SQL 对立的，做 NoSQL 似乎就意味着放弃 SQL，然而实际上 NoSQL 本意是 Not Only SQL，它不仅仅是 SQL，那么也就可以包含 SQL 的能力。

“NoSQL 也不是一定就得放弃 SQL，其实在代理层可以增加 SQL 的解析、计算逻辑来实现 SQL 操作，但这样会影响性能，所以还是看应用场景和业务需求。”

山宝银为我们简单分析了 DCache “分布式 NoSQL”的意义。在 SQL 处理方面，分布式似乎存在劣势，然而分布式意味着可以联结更多的廉价计算机，充分运用算力，以低成本的方式应对高强度的并发访问请求，此外分布式架构还有不少优势，比如避免系统单点问题导致的整体故障，实现高可用。

而另一方面，山宝银也说到：“DCache 因为主要的目标就是高性能，SQL 操作并不是主要想解决的问题，所以 DCache 没有实现 SQL 的功能。”

DCache 分布式策略与能力

DCache 对外提供服务的粒度是 group，一个 group 负责一部分的数据分片，至于每个 group 服务哪些数据，是根据数据的 key 做 hash 映射后所处的范围来确定的。

DCache 会把数据的 key 通过 hash 算法映射到 0～4294967295 (unsigned int) 范围内，然后把 0～4294967295 范围均匀划分到不同的 group 上。例如有两个 group，key 做 hash 后的值在 0～2147483647 范围就分发到 group1，在 2147483648～4294967295 范围就分发到 group2。

在一个 group 内，采用主备架构，只有主节点接收读写请求，所以数据一致性是可以保证的，而当主机不可用时，会触发主备自动切换，保证服务持续可用。

DCache 架构

我们疑惑DCache似乎强依赖于etcd与TARS等中间件，那它本身的核心特性与能力体现在哪里？

山宝银解释，DCache 并不强依赖 etcd，“etcd 只涉及了路由服务 RouterServer 的选主，如果 RouterServer 部署单点也是可用的，而且 RouterServer 的宕机不会影响到数据的读写访问，因为所有的 Proxy 与 Cache 服务都有本地的路由缓存”，关于 TARS 的采用，他说：“因为 TARS 是一个非常优秀的服务开发框架，它屏蔽了底层的网络通信细节，且自带了名字服务等很多服务化需要的功能，对于 DCache 来说，使用已有的 TARS 框架可以更好地做到服务化，我们没有必要去重复的造轮子。”

至于 DCache 本身的能力，山宝银介绍：“DCache 自身的存储引擎具有很高的性能，而且支持后接 DB，对使用者来说，不需要再关心 DB 和缓存之间的数据一致性，以及缓存不命中带来的一系列问题。”

具体来说，DCache 持久化与 Redis 不一样，后者只是把内存中的数据在本地磁盘做一个备份，保证 Redis 重启之后做数据恢复。

“Redis 持久化主要是为了数据备份。DCache 后端有了 DB 以后，业务的逻辑与后台的数据可以完全隔开，DCache 自身会处理缓存与 DB 之间的数据一致性问题。

DCache 会不断地将 Cache 中的数据落地后端 DB，如果 Cache 中存储空间不够，会将已经落地 DB 的冷数据淘汰掉。在数据查询的过程中，如果查询 Cache 不命中，会从 DB 读取并重新存到 Cache，以此来保证 Cache 中数据的热点性和命中率，同时 DB 与 Cache 的穿透问题也得到解决。

另外，数据持久化到后端 DB 的能力对于一些需要做离线数据分析的业务场景也比较方便。总之你完全不用关心数据的东西，只需要把数据写到 Cache，后端的落地由 DCache 处理。”

DCache 特性

此外，DCache 的分布式集群化、异地镜像部署、容灾容错能力在实际线上应用中都会提供非常高的价值。

用武之地

作为一个分布式存储系统，DCache 的应用场景没有限制在缓存上，山宝银介绍，对于有高性能 NoSQL 存储需求的场景，都可以使用 DCache，而且因为 DCache 具备容量淘汰与过期自动清理数据的功能，对于需要存储热点数据（如热门文章）与临时数据（如有时效性的聊天记录）的场景也可以提供很好的支持。

山宝银也提供了 DCache 的性能数据：

目前腾讯内部包括 QQ 浏览器、应用宝、腾讯地图、腾讯电脑管家、手机管家与腾讯游戏在内的近百个业务都接入了 DCache，这些业务的体量之大可以想象，山宝银补充：“除了提供的这一组简单的数据，DCache 在高效可靠地支撑着近百个业务的运转，日均调用量过万亿次，这也从侧面说明了 DCache 在生产环境的性能与稳定性。”

而除了系统本身高性能、高扩展、高可用与数据安全的设计外，Web 可视化的高效运维平台也成了 DCache 不可或缺的重要能力。基于内存的 NoSQL 存储系统在运维上会产生巨大的额外开销，它需要对相关技术进行深入理解，并且在紧要关头果断做出正确决策。

DCache 基于 TARS 开发，所以运维平台将 DCache 与 TARS 的服务管理统一做在了一个模块上，山宝银介绍该运维平台将大大提高效率，同时降低了运维门槛，关于服务的部署、上线、迁移、扩容、监控与配置这些操作都可以轻松实现。