云计算下如何平衡扩展性和稳定性SLA

云计算环境下，企业和个人通过开启云服务，即可以得到所需的软件功能、计算资源、存储空间，并按实际使用量付费。在业务量逐步上涨的过程中，用户需要不断提升计算和存储资源来满足业务需要。因此，扩展性是云原生服务非常重要的服务指标。

PolarDB的共享存储架构带来了最优的扩展性。当用户计算资源不足时，可以在不影响业务的情况下，动态扩充计算节点规格和数量。新增加的节点，直接访问共享的数据副本，不需要做任何数据拷贝，所以扩充节点的耗时可以达到1分钟内，而与数据量无关。PolarDB同时内置Proxy能力，可以将负载均衡到各个节点，使得加减节点操作对业务透明。在存储层，所有用户共享一个规模巨大的存储集群。存储集群可以动态添加新的存储资源，因此PolarDB理论上可以做到无限的存储容量扩展。

除了扩展性，稳定性也是云原生服务的核心指标。稳定性由RPO、RTO等指标定义。为了保障稳定性，在靠近用户业务的计算层，PolarDB尽量让用户独享资源，用户间进行强隔离；在网络和存储层，采用多租户形式。为了达到更好的稳定性和性能，PolarDB采用了全用户态的存储链路。在存储层，将每个用户的数据充分打散到多个存储节点，充分利用节点的空余资源，并保障IO访问的延迟和带宽。在部分存储节点出现热点数据、资源紧张时，PolarDB会自动迁移部分数据到其他节点。采用独有的Parallel-Raft技术，每份数据会有三个副本，每次IO都保证至少有两个副本落盘，保障了RPO。由于是共享存储架构，节点间状态接近于完全同步，当一个计算节点故障时，可以快速切换到其他节点，保障了RTO。在Proxy的协同下，甚至可以做到节点切换对应用无感知

传统分布式架构与存储计算分离架构对比

分布式数据库其实已经有了不短的历史，早期的分布式数据库，在整体架构上可以分为share nothing和share disk两大类。

share disk通过扩展底层的SAN来提升IOPS以及存储容量， 但是SAN的扩展性较差，成本也非常高， 因此此类架构往往被用于解决多活的高可用问题。

share nothing的数据库是过去分布式数据库架构的首选，被诸多互联网公司所采用。

share nothing架构的分布式数据库， 每一个节点拥有独立的计算和存储资源，每一个节点都有各自的计算引擎和存储引擎，计算存储绑定。 这种类型的架构好处显而易见， 数据Sharding的方式让数据存取以及处理可以并行化，计算存储本地化最大化提升了数据读写的带宽以及延时。在过去网络IO还是一大瓶颈的年代， 分布式系统设计以及优化的一大原则就是尽量使得计算存储本地化， 避免昂贵的网络开销。 然而share nothing架构对于跨分片的数据访问不是很友好， 比如事务，比如全局索引，实现起来十分复杂， 效率也要打上折扣，并且因为计算资源和存储资源是绑定的，因此数据几乎是在所有节点上是均匀分布，在集群扩展时，计算和存储要一起扩展，会存在资源浪费的情况，并且share nothing架构的数据库在存储扩展的过程中要做数据重分配，这种记录级别的迁移需要耗费大量的计算资源，会导致迁移过程中服务性能的显著下降。并且因为数据无法共享，因此这样的数据库系统往往会形成数据的孤岛，很难做一些跨库跨应用的计算。

存储计算分离是近年来分布式系统设计架构的潮流， 从2001年开始Google的GFS开创先河地开始使用了普通X86服务器和硬盘搭建了大规模的存储， 虽然受限于当时网络的传输速度，和机器间的带宽，还是需要耦合计算和存储节点的分布。 但是随着底层硬件和网络的不断发展，存储计算分离的趋势越来越明显，计算节点通过网络来访问存储的系统瓶颈也逐渐从IO变成了CPU。 当前的数据中心已经有了25G，50G和100G的网络， 系统瓶颈也逐渐变成了资源使用率。随着云的概念不断发展，公有云厂商使用基于网络的块存储逐步代替了单机的本地存储，在这样的基础架构下计算和存储耦合的架构已经变得不透明不合理，此时存储计算分离的架构的优势体现了出来，存储计算分离，分布式存储系统使用高密度，低功耗的服务器来解决存储容量的水平扩展问题， 计算集群使用高主频，多CPU，大内存的机型解决计算能力扩展的问题，模组之间互相解耦，独立按需扩展，提供了更好的弹性以及整体资源利用率。同时存储计算分离架构在扩展存储时因为不再是记录级别的迁移，不需要过多考虑数据库系统诸如事务完整性、一致性等问题，过程中耗费的计算资源相比share nothing架构的数据库系统大幅下降。 可以说存储计算分离是云时代数据库产品的事实主流架构， 无论是OLAP还是OLTP的系统， 越来越多的系统地已经采用了此架构或者是正在向着此方向演进发展。

分布式事务与集中式事务的优劣

事务处理是数据库保证ACID语义的核心功能，因为数据库系统需要处理大量的并发事务，为了保证并发事务能够尽可能高效的并发执行而又互不干扰，发展出若干种技术，比如多版本并发处理(MVCC)，乐观并发处理(OCC)，这些技术的关键在于多个事务同时读写相同的数据记录时，如何调度事务的执行顺序（等待或是回滚）保证结果符合预期。

在事务集中在单个节点处理时，事务提交的顺序是单个时钟的顺序，是很好确定的，这也是集中事务处理的好处，容易保证严格的外部一致性。在分布式数据库中，同样也可以采用这种模式，将事务集中在一个节点处理，而这限制了事务处理的扩展能力，系统能处理的事务操作的数据范围受限于单个节点所能访问的数据范围，事务处理能力也受限于单个节点的处理能力。