面对大促等活动期间的流量洪峰，集中型数据库的容量和性能非常容易遇到瓶颈，导致调用失败、操作异常等问题频繁出现。对于大家常用的MySQL，它有一个技术痛点，弹性有限。因为 MySQL 的主备结构，如果要扩容的话，是要更换机器的。而换机器就必然要经过主备切换，此时应用就会发生闪断，影响比较大。为了避免这种情况，往往需要常态化维持业务高峰级别的流量。比如说，大部分时间可能一个 8C 就足够，但是因为在业务高峰有 16C 的要求，所以必须长期保持 16C。OceanBase 具备快速弹性扩容的能力，从而让你可以在需要的时候设置规格，不需要的时候就降下来，通过数据库弹性伸缩能力节省很多成本。
OceanBase 的多级数据库弹性伸缩能力可以随业务的发展，动态、随时地调整集群的资源，费用也可以根据用户的需求进行灵活的动态调整，给运维提供了非常大的灵活性。OceanBase 的弹性能力分为三个层次：租户级、机器规格级、机器数量级。
第一级数据库弹性伸缩：租户规格调整
OceanBase 作为分布式数据库，内部把多台机器统一规划为一个资源池，资源池中又可以进一步划分一个个隔离的资源组，每个资源组就形成了一个租户的概念。租户的存在，带来多级数据库弹性伸缩的第一级。因为租户是 OceanBase 内部资源的划分，对租户规格的调整不涉及物理层面的资源调整，完全由 OceanBase 内核完成。这就使得 OceanBase 租户规格的调整，可以秒级生效，整个过程对应用完全无感知。
运维人员在数据库操作过程中，可以在任意时间（比如白天正常业务进行时），调整租户的 CPU 核数和内存大小，整个租户的极限 TPS 就可以得到平滑提升，实现数据库弹性伸缩。
第二级数据库弹性伸缩：机器规格调整（垂直扩缩容）
面对相对较大的业务流量，简单调整租户规格可能还无法满足业务需要，这时候就需要扩大机器规格。比如，把集群从 30C 的规格扩容至 62C，来应对业务大流量。由于 MySQL 的扩容过程就是一个主备切换的过程，会对业务有闪断的影响。而 OceanBase 实现数据库弹性伸缩是通过 Paxos 协议进行节点间的数据同步，Paxos 协议核心点是自选举，一份数据的三个副本投票表决出谁来当选 leader，以及该日志是否提交。
这一点相比于 MySQL 主从复制，带来了两点数据库弹性伸缩的优势：
- OceanBase 的数据同步单位更小，带来更高的性能和灵活性。OceanBase 的 Paxos 组以分区为单位，相比于 MySQL 节点级日志同步，分区粒度更小，避免了 MySQL 为保证全局顺序带来的性能影响。并且 OceanBase 支持分布式事务的能力，还允许不同分区的 Leader 不在同一个节点上，比如上图中深蓝色的 Leader 节点就分布在三副本中，实现多点写入的能力，可以充分利用多机性能，并支持下面增加节点的扩展方式，保证数据库弹性伸缩。
- OceanBase 的同步日志更轻量，代价更小。OceanBase 的 Paxos 协议同步的日志为 OceanBase 内部的物理日志 clog。 而 MySQL 的流程是主生产逻辑日志binlog，binlog 同步给备机后转化成 relay log，再执行的过程。而作为为数据库弹性伸缩提供的另一层技术保障，OceanBase 的 clog 更轻量，更高效，配合 Paxos 分区级的同步粒度，OceanBase 不会有 MySQL 令人头疼的主备时延问题。
体现在数据库弹性伸缩操作中，更换机器规格时，OceanBase 也需要先挂载一台机器同步数据，但切换时 OceanBase 只需要进行一次 Paxos 的有主选举，也就是 leader 完成自己最后一个日志提交后，主动放弃 leader 身份，然后主动投票给另一个节点，完成平滑切换。相比于需要闪断的 MySQL 主备切换，OceanBase 升配的整个过程对应用基本透明无感知。
第三级数据库弹性伸缩：机器数量调整（水平扩缩容）
这是 MySQL 主备架构做不到的一点，因为 OceanBase 是原生的分布式数据库，支持分布式事务，所以可以做到数据库弹性伸缩上无感知的横向扩展。更直观的说，就是OceanBase 集群增加机器，业务流量就会自动迁移到新增的机器中。并且在这个过程中，应用是没有感知的，可以像使用一个单机 MySQL 那样继续使用这个有多台机器的集群，这一点在很多工程实践中，被证实了是分库分表方案的更优解。
2012 年，OceanBase 原生分布式数据库从淘宝转战支付宝，并于 2014 年“双11”承受住了原计划1%，实际 10% 交易流量的终极大考。此后连续十年，OceanBase 平稳助力支付宝在“双11”期间捷报频传，一往无前，将继续帮助企业更轻松应对业务流量洪峰的同时，实现数据库弹性伸缩，提升资源利用率。
