下载掌阅APP，畅读海量书库
立即打开
云原生数据库在架构设计上最显著的特点，是将原本一体运行的数据库拆解，让计算、存储资源完全解耦，使用分布式云存储替代本地存储，将计算层变成无状态（Serverless）。云原生数据库将承载每层服务的资源池化，独立、实时地伸缩资源池的大小，以匹配实时的工作负载，使得资源利用率最大化。
如图3-1所示，客户端发送的SQL请求会经过一层代理服务器进行分发，这层代理一般是一个简单的负载均衡服务，可以直接转发给计算服务层中的任意节点处理。计算服务层负责解析SQL请求，并转化为物理执行计划，物理执行计划的执行，涉及事务处理和数据存取的部分，由存储服务层执行。存储服务层负责数据缓存管理与事务处理，如同第1章中提到的，以数据页面的方式管理和组织数据，保证数据页的更新和读取符合事务的ACID语义。在实现中不一定是物理分离的，可能一部分集成在计算服务层，一部分集成在共享存储层中。
图3-1 云原生数据库分层设计架构
共享存储层负责数据页的持久化存储，并保证数据库数据的高可用。通常，共享存储层实现采用分布式文件系统，利用多副本、分布式一致性协议保证数据的一致性与可靠性。存储和计算分层的架构好处显而易见，各层可以独立弹性伸缩，达到资源理论上的最优配置。再者，得益于共享存储设计，所有计算节点看到的数据视图都是完整的，计算能力的扩展可以做到实时生效，无须像其他采用大规模并行处理（Massively Parallel Processing，MPP）架构的数据库一样进行大量数据搬迁。但这同样带来一个问题，如果存储服务层每个节点都处理写事务，那么必然会有概率产生数据冲突，而跨节点的数据冲突处理需要大量网络通信和复杂的处理算法，会产生较高的处理代价，所以一些云原生数据库在实现时为了简化实现，往往指定其中一个节点为更新节点，其他作为只读节点。只读节点需要根据事务隔离的语义提供一致性数据页面的读取。共享存储层不等同于一般意义上的分布式文件系统，如Google文件系统（Google File System，GFS）、Hadoop分布式文件系统（Hadoop Distributed File System，HDFS），更多的是为适应数据库的段页式结构来设计的。数据块大小的选择会更多地考虑数据库的I/O模式，更重要的是共享存储层里集成了数据的日志回放逻辑，利用分布式能力增加并发度，提升页面更新的性能。
不同的云原生数据库使用的分层逻辑会有所不同。大部分云原生数据库将SQL语句解析、物理计划执行、事务处理等都放在一层，统称为计算层。而将事务产生的日志、数据的存储放在共享存储层，统称为存储层。在存储层，数据采用多副本确保数据的可靠性，并通过Raft等协议保证数据的一致性。