基础架构

StarliteDB 是京东自研的云原生分布式数据库，主要改动集中在存储层。

与传统的单机数据库相比， StarliteDB 具有以下优势：

• 云原生分布式架构，拥有良好的扩展性，支持秒级弹性的扩缩容

• 支持 SQL，对外暴露 MySQL 的网络协议，并兼容大多数 MySQL 的语法，在大多数场景下可以直接替换 MySQL

• 默认支持高可用，数据库本身能够自动进行故障转移，对业务透明

• 支持 ACID 事务，对于一些有强一致需求的场景友好，例如：银行转账

• 在内核设计上， StarliteDB 分布式数据库将整体架构拆分成了多个模块，各模块之间互相通信，组成完整的 StarliteDB 系统。对应的架构图如下：

• compute ：计算节点、SQL 层，对外暴露 MySQL 协议的连接 endpoint，负责接受客户端的连接，执行 SQL 解析和优化，最终生成分布式执行计划。compute 层本身是无状态的，实践中可以启动多个 compute 实例，通过负载均衡组件（如 LVS、HAProxy 或 F5）对外提供统一的接入地址，客户端的连接可以均匀地分摊在多个 compute 实例上以达到负载均衡的效果。compute 本身并不存储数据，只是解析 SQL，将实际的数据读取请求转发给底层的存储节点。

• coordinate ：协调节点，整个 StarliteDB 集群的元信息管理模块，负责存储每个 storage 节点实时的数据分布情况和集群的整体拓扑结构，提供 StarliteDB Dashboard 管控界面，并为分布式事务分配事务 ID。 coordinate 不仅存储元信息，同时还会根据 storage 节点实时上报的数据分布状态，下发数据调度命令给具体的 storage 节点，可以说是整个集群的“大脑”。此外，建议部署奇数个 coordinate 节点。

• storage ：存储节点，负责存储数据，从外部看 storage 是一个分布式的提供事务的 Key-Value 存储引擎。存储数据的基本单位是 Region，每个 Region 负责存储一个 Key Range（从 StartKey 到 EndKey 的左闭右开区间）的数据，每个 storage 节点会负责多个 Region。 storage 的 API 在 KV 键值对层面提供对分布式事务的原生支持，默认提供了 SI (Snapshot Isolation) 的隔离级别，这也是 StarliteDB 在 SQL 层面支持分布式事务的核心。 StarliteDB 的 SQL 层做完 SQL 解析后，会将 SQL 的执行计划转换为对 storage API 的实际调用。所以，数据都存储在 storage 中。另外， storage 中的数据都存储在CFS之上，CFS自身可做到存储可靠、故障自动转移与恢复。