今年是“双11”十周年。
2011年11月11日，当时的淘宝商城（天猫前身）举办首次线上促销活动，当天销售额达5000万元； 2011年双11，天猫、淘宝总交易额1亿元，创造25.6万元。
每秒新支付峰值数和数据库处理峰值数达到每秒10000次。
双11开始后7分23秒，支付宝支付笔数突破1亿，相当于五年前双11全天支付笔数！对于阿里巴巴来说，每年的双11都是一个超级工程，明年的双11将会打破上一年的记录。
因此，双11实际上是一个不断“膨胀”的无限工程。
支撑双11的核心数据库是今年以来一直在建设的金融级分布式数据库OceanBase。
OceanBase的目标是成为新一代商业关系数据库，其差异化优势在于底层的分布式技术。
之前的OceanBase 1.0成功支撑了双11的支付高峰，现在OceanBase 2.0已经正式上线，迎接即将到来的新支付高峰。
OceanBase 2.0有哪些新特性？ 1.0版本做了哪些优化？能否支持未来双11无限扩容？ OceanBase团队的两位专家杨传辉和韩福生解读了2.0版本的特点。
两位专家都强调OceanBase 2.0的设计可以支持百万甚至无限的支付峰值，并且在不增加服务器的情况下“承受”2020年新的峰值。
另外，OceanBase 2.0在全面兼容MySQL之后，还增强了对Oracle数据库的兼容性。
OceanBase仍在以最大的精神打磨自己的软件，挑战世界一流的基础软件。
进一步完善分布式架构 今年以来，国内云服务商陆续推出了自己的分布式数据库。
杨传辉强调，OceanBase是唯一走通用数据库路线的产品。
其特点是分布式架构对用户透明，不需要业务修改。
OceanBase的技术定位为通用的金融级分布式商业数据库，从支持金融行业开始，然后逐步扩展到支持各个行业。
蚂蚁金服研究员杨传辉表示，与1.0版本相比，OceanBase 2.0在分布式架构上又向前迈进了一步。
OceanBase 1.0已经让用户无感知机器故障，即在多台机器上部署数据库。
无论哪台机器宕机，都可以在30秒内无损切换，这就是所谓的高可用性。
OceanBase 2.0进一步让用户在多机部署数据库时无感知数据分布。
这就是数据库层面的自动分片和自动负载均衡。
OceanBase 2.0支持在线数据分片。
当某个数据分片的数据量或者访问量过大时，会在线上切分为多个分片。
整个过程不会对服务产生任何影响。
分布式数据库的数据分片是指将数据集划分为若干子集，然后分布到不同的机器上，以达到分布均匀、负载均衡、扩缩容时数据迁移较少的目的。
杨传辉强调，一台服务器上数据分片的数量说明了底层数据库的技术能力，因为更多的分片意味着更大的系统开销。
数据分片必须足够小，才能满足整个集群的负载。
精细控制和快速数据恢复。
外部基于MySQL的解决方案单机分片数量可以达到几十个，而OceanBase 2.0可以支持单机10万到1万个分片，从而实现无限扩展。
在实现用户对机器故障和数据分布无感知后，OceanBase 2.0还改进了分布式事务。
OceanBase 1.0已经支持分布式事务，2.0版本进一步实现了全局快照和全局索引。
所谓全局快照是指当一条SQL语句涉及多台机器时，全局快照保证每台机器的强一致读取。
OceanBase2.0在全局快照读取的基础上，实现了全局索引，真正让用户对多机环境无感知。
另外，由于全局快照的出现，为了提高本地租户级数据一致性，OceanBase 2.0在全局时钟的基础上引入了租户级时钟，保证单个租户的数据一致性，而无需频繁引用全局时钟。
钟。
这样就避免了全局时钟成为整个系统的瓶颈。
增强对Oracle数据库的兼容性 除了日益强大的分布式架构之外，OceanBase 2.0相比OceanBase 1.0最大的功能亮点在于为用户提供了全新的Oracle兼容模式。
众所周知，MySQL是互联网场景中最流行的数据库，但从市场规模和功能齐全程度来看，Oracle仍然是商业数据库中的绝对领先者。
OceanBase的Oracle兼容模式可以让传统企业应用平滑迁移到OceanBase，在不改变业务代码的情况下充分享受分布式数据库在可扩展性、可用性和系统成本方面的优势。
MySQL到Oracle的兼容不仅仅是SQL语法、数据类型、函数等方面的变化，更重要的是从专用数据库到商业数据库的全面功能升级，而这一切都是基于OceanBase的全面提升它自己的内核。
掌握。
例如，在迁移传统数据库应用时，支持存储过程是一个不可避免的问题。
OceanBase 2.0在兼容Oracle存储过程各种复杂灵活的语法和功能的同时，还通过编译执行（Just-in-Time Compilation）等技术进一步提高其在特定场景下的执行效率和实用性。
同时，OceanBase 2.0还提供了自定义函数、窗口函数、分层查询、dblink、临时表、序列等一系列丰富的数据库功能。
Oracle兼容模式的另一个体现是数据库内核能力的增强。
例如，为了更好地处理复杂查询，OceanBase 2.0全面升级了分布式查询的优化和执行引擎，增强了对复杂业务的支持；为了实现更精准的查询优化，OceanBase 2.0实现了直方图以及实时统计信息更新机制；同时，OceanBase2.0实现了基于用户参数的计划选择机制，增强了系统对大小混合查询场景的支持。
等等，OceanBase 2.0在SQL引擎中引入了大大小小的数十种内核优化方法，向成熟的商用数据库又迈出了一大步。
数据库应用和数据的平滑迁移是升级过程中的重要考虑因素。
OceanBase 2.0数据迁移平台支持Oracle业务一键平滑迁移到OceanBase 2.0，为用户系统升级铺平道路。
OceanBase 2.0刚刚兼容Oracle，还有很长的路要走。
杨传辉表示，相信在整个团队的不断努力下，OceanBase将不断降低用户使用数据库的门槛，全面解放和赋能用户生产力。
挑战百万支付新高峰 2017年双11支付峰值峰值为25.6万笔/秒，因此全年及以后的支付峰值目标将是百万笔/秒甚至更高。
这么高的目标能实现吗？这就是OceanBase 2.0的目的：今年双11的交易支付全部升级为OceanBase 2.0，从而挑战百万支付新高峰。
在支持更高的支付峰值方面，OceanBase 1.0不再能够在不影响上层业务的情况下进一步拆分数据。
OceanBase 2.0的目标是在用户不知情的情况下将数据拆分到无限数量的机器上。
无需上层业务改造即可支持百万级以上支付峰值。
OceanBase作为基础软件，是整个支付业务绩效的基石。
OceanBase一直将性能视为核心功能，始终为企业提供最具性价比的数据库服务。
OceanBase 2.0版本继续努力，在性能上实现了跨越式发展。
在线事务处理能力（即处理OLTP类业务的能力）提升50%。
为了完成今年的双11，不会增加额外的服务器来支撑新的业务高峰。
目标提供了坚实的基础。
负责性能优化工作的韩福生详细介绍了OceanBase 2.0的各项改进。
OceanBase 2.0在三个层面下了很大的功夫。
首先是数据库架构层面的创新；二是制度实施层面的细化；三是数据库运行环境整体优化。
蚂蚁金服高级技术专家韩福生 OceanBase 2.0对交易提交流程进行了大幅重构，大幅降低了交易提交流程的开销。
支付业务是典型的在线交易处理类别，主要以短交易为主，交易提交和执行的频率特别高。
事务的提交通常是数据库中最耗时的部分。
OceanBase 2.0打通了日志服务和事务服务，将原来分布式事务两阶段提交的多条日志优化为每个分区只有一条日志，同时仍然保证了对事务原子性和一致性的良好支持。
日志条目数量的减少简化了提交流程，不仅提高了系统处理能力，还显着减少了事务提交所需的时间。
OceanBase 2.0 的预算还注重哪些地方呢？事实上，OceanBase 2.0的整个请求处理路径都经过了精心的优化。
以内存分配器为例。
当OceanBase数据写入Memtable时，在数据存储和索引更新过程中会多次分配内存。
内存分配器很容易成为系统的瓶颈。
解决这个问题的通常方法是让分配器预先分配大量内存。
然而，在OceanBase分布式多分区架构下，预先分配大量空闲分区意味着大量空闲内存无法得到有效利用。
OceanBase 2.0启用自适应内存分配算法，只为写入量大的分区预先分配内存，有效平衡空间使用和系统性能。
数据库一般是对操作系统压力最大的进程，经常会触及操作系统的各种限制。
当OceanBase2.0在实际生产环境中高压运行时，我们还发现了Linux内核的一个bug。
这个bug在内核3.1版本开始出现。
目前3.1也是业界在生产环境中常用的版本。
在内核专家的支持下，我们发现了 Linux 调度系统中的一个缺陷，导致 CPU 无法得到充分利用。
仅解决这个bug就给系统带来了7%的性能提升。
为什么OceanBase如此注重系统性能呢？这是因为制作软件时要处理两大成本，一是开发成本，二是运营成本。
有些系统非常注重开发成本，尤其是频繁变更的业务系统。
良好的开发效率是系统迭代的关键。
但数据库等底层系统在注重开发效率的同时，也更注重运营成本或者运营效率。
为什么要关注运营效率？对于商业数据库来说，运行在数千台机器上，一点点运行效率的提高可以带来计算资源的巨大节省。
例如，OceanBase 2.0将在线处理服务的性能提升了50%。
如果原来运行在10000台机器上，通过性能提升可以节省三分之一的机器。
“越是基础的软件，其性能就越关键。
一个小小的改变就会为业务节省大量资源。
持续的系统优化是必须的。
”韩福生说道。
安全、升级和迁移 OceanBase 2.0还进行了更多方面的优化，包括数据安全和质量、软件系统和迁移的优化。
在数据安全方面，OceanBase 2.0实现了商业数据库的一个重要功能，即数据闪回。
数据闪回之所以特别有用，是因为一旦发现操作错误，就可以闪回到前段时间的数据状态。
OceanBase 2.0支持数据的多版本存储，即内存中的数据存储到磁盘时，并发的多版本以及历史版本信息会根据用户需求存储到磁盘中。
如何实现OceanBase 1.0到2.0的平滑过渡？一方面，为了保证业务的平滑过渡，OceanBase提供灰度切换和业务双写。
灰度切换是指将数据流量按照一定比例逐步切换到新系统。
一旦出现问题，您可以回滚。
至于业务双写，即业务系统同时使用1.0和2.0两个版本。
两组数据库并行工作并进行数据比较。
长时间运行后，确保开关没有问题，然后按比例一点点开关。
此次切换过程中依然采用灰度控制，从而保证了1.0到2.0的平滑升级。
兼容性也是OceanBase团队提供的1.0到2.0版本升级中的一个重要保障机制。
OceanBase支持同一业务下同时运行1.0版本和2.0版本。
“在一个集群中，两个大版本的数据库同时运行，技术难度很大。
”杨传辉强调。
首先是不同版本数据库之间的协议兼容性。
即当1.0版本将1.0协议发送到2.0版本，2.0版本将2.0协议发送到1.0版本时，两者是兼容的。
另外，在数据格式方面，由于2.0版本对底层做了比较大的改动，因此2.0在兼容1.0的数据格式方面也做了细致的工作。
更困难的是功能兼容性。
在2.0版本中，很多功能都发生了较大的改变，所以每个修改的功能的兼容性都需要一一处理。
在迁移工具方面，OceanBase支持阿里巴巴和蚂蚁金服系统内的数据迁移工具，例如阿里云平台上的数据传输服务DTS。
蚂蚁金服开发了MySQL到OceanBase的一键迁移平台。
企业无需修改一行代码即可从MySQL切换到OceanBase。
OceanBase 2.0在其他方面也做了更多的优化。
在底层优化方面，OceanBase 2.0将实现存储与计算的分离，相当于在数据库底层形成了一个分布式存储系统。
在自治数据库方面，OceanBase的整个产品愿景一直在朝着这个方向发展，尽可能减少人工干预。
OceanBase 2.0的正式发布，代表着OceanBase产品化的又一新里程碑，也是OceanBase数据库产品商用之路上的重要节点。
OceanBase的不断发展和优化过程，体现了基于云计算的分布式计算时代中国基础软件的新机遇。
虽然要走传统IOE软件走过的基础软件优化之路，但基于云计算的分布式计算环境却给了中国基础软件划时代的机遇。