支付宝背后的数据库那些事儿，聊聊它到底用的啥和怎么深挖

说到支付宝的数据库，很多人第一反应可能就是问：“它用的是不是Oracle？” 这事儿得从头说起，根据阿里技术团队自己分享的文章（来源：阿里技术公众号《OceanBase诞生背后：一个天才程序员的故事》），在支付宝早期，特别是“双十一”还没那么夸张的时候，他们确实和当时很多大银行一样，用的是IOE架构——也就是IBM的小型机、Oracle的数据库、EMC的存储设备，这套东西稳定是稳定，但有个致命问题：太贵了，而且扩展性差,像是给业务增长套上了紧箍咒。

转折点发生在2010年，那一年，阿里决定“去IOE”，说白了就是要用便宜又好用的普通PC服务器，取代那些天价的专有设备，数据库也要换成自己能掌控的开源或者自研的，一开始，他们尝试了开源的MySQL，搞了分库分表（就是把一个巨大的数据库拆分成很多个小数据库，分散到不同的服务器上），这在当时解决了不少问题（来源：阿里云数据库团队技术分享），但很快，随着“双十一”的支付笔数像坐火箭一样往上冲，MySQL这种主要面向在线交易处理（OLTP）的数据库，在应对超大规模、且要求绝对数据一致性的金融场景时，开始显得力不从心,跨多个分片的数据一致性保证就非常复杂。

正是在这种被逼到墙角的情况下，支付宝的兄弟公司——蚂蚁集团——决定自己动手，丰衣足食，走上了自研数据库的道路，这就是后来名声大噪的OceanBase（来源：OceanBase官网介绍及多次公开技术演讲），直接回答“支付宝现在用什么数据库”这个问题，核心答案就是：它用自己的OceanBase数据库。

那OceanBase到底有啥特别的呢？我们可以用大白话来聊聊它怎么“深挖”技术护城河的。

它不怕机器坏掉，金融系统最怕的就是数据丢失或出错，OceanBase用了类似“多数派”的机制，比方说，你付一笔钱，这个数据不会只存在一台机器上，它会同时写在三台机器上，只要超过半数的机器（比如三台里的两台）说“写成功了”，那这笔交易就算成了，哪怕随后有一台机器突然宕机，数据在另外两台机器上还有备份，系统照样能正常运转，等你修好那台坏机器，数据会自动同步过去,这叫高可用和高可靠。

它能轻松“长大”。“双十一”零点的流量是平时的几百上千倍，数据库必须能瞬间扩容，OceanBase的设计很巧妙，它把一个大的数据库集群分成很多个小的功能单元（他们叫“Zone”），每个单元都包含完整的数据副本，需要扩容时，不是去折腾现有的机器，而是直接加入一批新的PC服务器组成新单元，系统会自动把一部分数据和服务迁移过去，实现平滑扩展，这就像玩乐高积木,随时可以加几块进来扩大规模。

它把“会计记账”的那套逻辑用在了数据库内核里，金融交易要求ACID，特别是其中的原子性（Atomicity）和隔离性（Isolation），也就是一笔交易要么全成功，要么全失败，并且中间状态不能互相干扰，OceanBase通过一个全局统一的时间戳发生器，给每一笔交易都打上唯一的时间标签，这样就能清晰地定义出交易的先后顺序，确保不会出现“账户扣了钱但对方没收到”这类乱子，这套机制让它能处理混合负载，即同时处理海量的实时交易（OLTP）和复杂的分析查询（OLAP）,这也是它比传统数据库强的地方。

作为我们普通人或者技术爱好者，如何去“深挖”和理解支付宝数据库的这些门道呢？

最直接的办法，就是关注源头，蚂蚁集团的OceanBase数据库早已经开源，并且成立了开源社区，你可以直接访问OceanBase的官方网站或者它在GitHub上的开源项目页面，那里有最一手的技术文档、设计论文、部署指南和源码，你可以下载下来，在自己的电脑上搭个简单的环境跑一跑，亲身感受一下它的架构和操作,这比读任何二手文章都来得深刻。

多看蚂蚁集团和阿里云的技术博客、公众号以及他们在国内外技术大会（如ATF、DTCC等）上的分享视频，这些内容通常由一线的工程师或架构师撰写和讲解，他们会用比较具体的案例，如何用OceanBase扛住某年双十一的峰值”、“在某次容灾演练中OceanBase的表现”等，来透露很多设计细节和实战经验,这些是理解其技术精髓的宝贵材料。

可以对比着学，把OceanBase和其他的主流数据库，比如传统的Oracle，开源的MySQL、PostgreSQL，或者NewSQL领域的TiDB等，放在一起对比，看看在同样的业务场景下，比如高并发支付、分布式事务、数据一致性等方面，它们各自的解决方案有什么异同，通过这种对比，你不仅能更深入地理解OceanBase的设计取舍,也能对整个数据库技术发展的脉络有更清晰的把握。

支付宝的数据库之路，是从依赖国外商业软件，到拥抱开源，再到最终自主研发出一条符合自身极端金融级需求的道路，深挖它的故事和技术，其实就是观察一家顶级互联网公司如何通过技术驱动,解决世界级难题的绝佳样本。