在解决OLTP数据库系统的横向扩展能力方面，Oracle提供了RAC集群，可以实现到Multi-Master的多主节点扩展，但由于各种架构的因素，通常只能扩展到十多个服务器节点。云数据库基于云平台的数据资源池，可以实现相对灵活的扩展能力。但由于数据库并非原生分布式架构，扩展依然受到限制，如AWS Aruroa做多只能扩展到16节点，只能实现一写多读的架构，无法实现横向Multi-Master。

这里比较难解决的问题有两个。一个是跨多服务器后，分布式事务管理难，传统模式下2PC提交架构需要中心的全局事务或时钟节点协助事务一致性控制，延迟高容易导致瓶颈。因此，大多数数据库国内数据库厂商，及国内为云数据库厂商的主流方案都是通过一写多读的架构实现扩展性。部分实现了「原生分布式」能力的数据库，又大多只提供单一的SQL接口，无法同时支持包括SQL和NoSQL在内的多种计算实例类型。

另一个问题是故障切换难，不知道有多少读者有过配置Oracle、MySQL、PostgreSQL等数据库的高可用集群经历。在发现故障需要切换时，我们往往需要检查很多数据库状态，以确保切换后的事务及数据完整性问题。想要做到全自动切，需要十分繁琐配置，同时由于机制复杂，故障诊断也十分繁杂。

为解决这两个问题，SequoiaDB实现通过自有专利的 「STP逻辑时钟协议」 ，及 「无状态」 的计算实例层为用户解决扩展性问题，并大大简化集群管理的难度。

首先来看看「STP逻辑时钟协议」，如前面提及的问题，我们知道在分布式数据库架构下要保障事务一致性必须借助分布式事务，而为了保证分布式数据一致性，大多数厂商通过“全局事务服务器/全局时钟服务器”提供统一的事务ID或时钟服务，以进行2PC两阶段提交。由于每次分布式事务操作都需要跨服务器进行，随着服务器规模的扩展，中心节点的处理能力及事务延迟都将放大，导致系统扩展能力受到极大限制。当然，也有一些友商放弃2PC提交模式，转而使用1PC加业务补偿策略，但在严格的事务一致性需求场景下将无法应用。

针对于此巨杉数据库基于自有专利技术，构建「STP逻辑时钟协议」，各STP Server之间通过Raft保证逻辑时钟的强一致性。每个数据库节点通过本地的STP Client与主STP Server保持逻辑时钟一致性，并通过专利技术确保逻辑时钟持续向前推进，不会出现时间戳冲突。各数据库节点需要进行分布式事务处理时，只需要通过本地获取时钟即可，大大降低了延迟。通过此技术，当前SequoiaDB已经可以支持超过4096节点，数十PB级别的海量存储。

在降低管理难度方面， SequoiaDB提供「无状态」的计算实例层。 在 《引擎级多模 | SequoiaDB让研发和DBA和谐共处》 一文中我们提到，SequoiaDB底层的存储引擎实际上就是一个完整的分布式数据库，具备完整的事务一致性、排序过滤、下推计算等能力。 而上层计算实例层只承担SQL或API解析及业务计算的工作，所以不同引擎下发的操作，事务一致性在分布式引擎层进行控制。 计算实例并不承担数据一致性及数据存储的工作，每个计算节点不管是SDB   API、MySQL、PostgreSQL、MongoDB还是Spark实际上只是一个「无状态」的计算程序。 因此任何计算节点故障，只需要通过 通用的F5/LVS等负载均衡工具进行重新路由，或是挑选新的计算节点进行重新启动 即可恢复。 「无状态」的计算实例，无须复杂的状态监测工作，易于进行批量管理，同时也大大简化企业级分布式应用的开发难度。 开发可以通过F 5/LVS 提供的统一 VIP入口，即可享受读写均可横向扩展的原生分布式数据库架构。