vlambda博客
学习文章列表

省却成本，缩短产品上市时间，减少运维与开发团队之间的摩擦是 Serverless 最核心的所在，从 AWS 发布「Lambda」让「Serverless」越来越多地为开发者所知到今天，已经过去了 6 年的时光，Serverless 也正当时地引起了非常多的企业及开发团队的青睐与跟进。

不久前，腾讯云发布了国内第一款 Serverless 数据库 —— PostgreSQL for Serverless（ServerlessDB），在业界受到众多数据库开发者的广泛关注，它基于 PostgreSQL 数据库实现按需分配资源，能够做到安全隔离、弹性扩容、按需付费、原生 SQL 支持。在本文中，腾讯云 ServerlessDB 产品负责人从租户隔离技术、快速扩缩容能力、连接池管理等方面，详细解密这款数据库背后的设计细节，希望能够为所有开发者带来启发。

如何实现真正的自动扩缩容？

相比较于传统数据库，云数据库的弹性扩缩容和按量计费能够帮助用户按需使用云资源，避免资源浪费的同时大幅节省了成本。在系统实现原理上，目前云数据库提供的这类“弹性方案”本质上是一种策略上的弹性，即开发者需要先行预估自己的产品负载量，例如一款游戏什么阶段玩家特别多，什么时候人潮回落，在设定好数据库需求的方案后，对应进行手动的容量调整。

预估得越精细，这种“弹性”就越接近“按需分配”。要想通过弹性扩缩容最大限度降低成本，就需要做到精细化的预估和自动分配，这对绝大多数开发者提出了挑战。

精细化预估理论上要求用户的扩缩容对内存资源、CPU 资源、IO 资源、网络资源等各种资源做全位一体的判断。当用户访问请求上涨时，数据库针对用户请求的特点使用不同的系统资源，而这些资源需要动态的响应，且不会受到服务器限制。不同资源的扩缩容粒度需要小到一个数据块——CPU 核心。当前普通的云数据库实例扩缩容相对粗放，若要提升 CPU 性能，顺带还必须扩展内存大小。

手动调控也是一个挑战，一旦用户请求上涨，则需要扩容，但是对于不可预估的业务场景来说，上涨和降低是随机的，越是精细的预判越会导致频繁的扩缩容，而如能实现细粒度的自动调控，会大大提升整体效率。

腾讯云 ServerlessDB 的推出就完全克服了目前的挑战，其最大优势就是在技术层面上可以实现天然、精确、不需要人为干预的弹性扩缩容。

上图是这款数据库的技术架构，在腾讯云 ServerlessDB 架构中，客户端访问数据库是通过 Proxy 层进行转发至数据库中的，且数据库可以缩容，也可以进行扩容。腾讯云 ServerlessDB 采用租户隔离扩缩容以及连接池管理技术，从而实现了技术层面上真正的弹性扩缩容。

租户隔离技术

了解数据库的应该知道，PostgreSQL 可以创建多个数据库 Database，多个数据库之间的数据是可以互相访问的。而 PostgreSQL 的 Serverless 化破除了数据库之间可以互相访问的能力，将单个数据库摘出来独立成为一个实例对外提供服务，这与 Oracle 12C 里面的 PDB 类似，但是腾讯云 ServerlessDB 在技术层面的优化远不止于此。

不同用户共享一组数据库实例时要保证用户访问不会出现越界的情况，所以需要对用户进行隔离这就涉及到对 PostgreSQL 内核进行改造。腾讯云 ServerlessDB 在 PostgreSQL 内核中加入了租户的概念，一个租户除了只能管理一个数据库外，其他的和正常数据库使用没有区别，一样可以拥有多个用户。相当于一个用户拥有自己的一套命名空间，每一个租户维护自己的元数据信息。为了避免互相影响，系统表也进行了隔离，每个租户的信息进行单独存放。

这就是腾讯云 ServerlessDB 的租户隔离，可以通过上图看到，将实例作为一个容器，其中将数据库独立成一个个单独的租户，每个租户之间都是隔离状态。数据库实例负责公共操作，比如日志读写、配置文件读取、控制文件刷新等，租户维护数据文件以及临时文件，其中包括本租户的元数据信息、租户类型等操作，同实例可以扩展多个租户数据库。

这就相当于传统 PostgreSQL 实例以前是一栋大别墅，里面有多个房间（database）供一家人使用。那么 Serverless 化后，改建为一座占地 100 亩的大公寓，里面有很多房间供用户使用。

快速扩缩容能力

在租户隔离技术避免了不同租户之间的访问越界问题后，在扩缩容方面，ServerlessDB 是如何保证对用户进行细粒度控制的呢？

首先 ServerlessDB 将服务器计算资源分为 3 个区域，分别是系统全局区、数据库全局区和资源池，每个区域都是互相隔离的。

其中系统全局区的计算资源用于处理操作系统本身的任务；数据库全局区负责处理数据库共享的任务，如 autovacuum，刷日志，归档日志等；租户资源区负责剩余的租户类的操作，如工作进程都按照租户打包，一个租户只占用一个资源区。

若租户没有任何连接访问数据库，对于该租户就没有任何资源响应，也就不会占用资源池的计算资源。当租户建立了数据库连接后，管控就会自动给该租户分配一个最小资源区单元。一旦该用户对计算资源访问达到了此资源区单元的 80%，后端管控将自动调整资源区的可使用的计算资源上限，以提高扩容的阈值，此时的扩容是完全无感知的，资源响应也是实时的。当用户对资源利用率低于 20%的时候，租户资源区将自动降低其可以使用的计算资源上限，空余出来的计算资源将重新流通到资源池当中，供其他租户调用。这就是计算资源实现 CPU 和内存的快速伸缩。

连接池管理

当前这种实现形式带来了另外一个问题：一个连接会新增一个进程，而多租户模式会导致服务器新建大量进程来消耗掉租户的资源，多个租户的连接数提升时很快会把服务器资源打爆，怎么办呢？

ServerlessDB 引入了连接池概念，当一个租户的多个连接访问到连接池后，将同一租户的连接通过一个连接捆在一起建立起数据库的连接，这样就保证了一个租户到数据库侧只有一个连接，相当于 N：1。在数据库侧建立的连接均通过租户间的资源隔离技术将其分离，避免不同租户产生影响，这样就解决了连接池管理的问题。

因为其是无状态的，即使连接池性能达到了瓶颈之后，用户也可以横向扩容，将请求进行负载均衡，这样可以避免因为连接池性能瓶颈导致整体的服务不可用。

回到刚刚举的例子，传统 PostgreSQL 数据库是一座别墅时，每来一个客人都需要单独提供一个车库（会话进程）给他们，访客增多时会出现车位不够用的问题。改建成公寓后专门修建了一个地下停车场（连接池），每一个租户有一个独门独户的电梯，所有访问同一个租户的访客，都可以通过这一座电梯直达房间。如果访问同一个租户的访客数量激增到一个电梯不够用，就会为其专修一座电梯来避免单租户的访问量太大而无法负载的问题。

应用场景与实践

其实，Serverless 概念的核心价值在于快速部署和降低使用成本。从这两点来看，ServerlessDB 最主要应用场景就是小程序，对于一些简单应用，甚至连后台都无需开发。

疫情期间，各大平台纷纷推出了自己的疫情监控功能，基于 Serverless 架构可以快速实现疫情监控。PostgreSQL 数据库提供丰富的插件扩展，比如招牌特色的 PostGIS 插件，支持丰富的空间地理类型据，可以根据人群定位，自动避开风险区域。

Serverless 只是产品形态与使用上的改变，数据库本身的功能没有发生变化。用户在使用这款数据库的过程中，把数据库的底层能力当作了一个 Serverless 化的服务来进行使用，无需关心数据库底层的运维等操作。

【END】