前几天我突然在想，其实咱们平时玩的手机、用的电脑里头，藏着一个大家伙叫数据库，虽然平时看不见摸不着，但买票付款、聊天发朋友圈这些事儿全靠它顶着呢。咱们得回头看看那时候的事儿，想当年还是磁带倒带的时代，要想弄点数据出来可太难了，统计完数据还得锁在抽屉里。一直到后来有了磁盘，计算机才第一次拥有了“随机访问”的能力，想查哪条记录指针一划就能定位了。 还记得第一块硬盘吗？大得像微波炉那么沉，装满也就3.75 MB。后来它就缩水到巴掌大了，再后来全是闪存接管的事儿。不管怎么变，“高速算力”加上“快速定位”，这两件事凑一块儿了，售票系统、银行核心、航空订座这些实时的活儿才变得可能。 为了把散乱的数据管理、查询修改这些麻烦事整合成好用的东西，DBMS（数据库管理系统）就冒出来了。它专门给大家解决四大难题：用户不用操心硬盘上放哪儿；用SQL语句就能搞定复杂的查询；多步操作锁死成一个原子块；系统不会随便宕机影响业务。 但想要用起来顺溜也不容易，核心就是得解决故障恢复和并发控制这两大麻烦事儿。故障恢复就是得给硬盘写本“流水账”，要是硬盘坏了、机房被水淹了，只要日志还在，数据就丢不了。OceanBase就把日志切成小块儿分散在三个地方五个中心，用Paxos协议保证只要有两个地方写成功了就能提交，哪怕一个城市全停电也不怕丢数据。 并发控制呢？就是要让CPU和硬盘都忙起来。单用户肯定安全但太浪费硬件了；多用户又容易弄混数据。OceanBase搞了个行级锁加上MVCC（多版本并发控制），读和读随便读多少遍都没事；写和写互斥着来；读和写分开干活互不干扰。这样既能榨干硬件又能保证数据不乱套。 说到分布式事务就更让人头大了，单机响应快得像纳秒计的事儿一旦跨机房就慢成了微秒级。尤其是同一台机器的内存访问和另一台机器的磁盘访问差了2000倍呢。 OceanBase想了个招儿叫ReadVersion替代ReadView，以前那种维护全局列表的法子扩展性太差了。它每台服务器同一时间取个时间戳聚合起来再提交，就算是每秒做15亿笔TPC-C交易（这可是个天文数字），时间戳服务照样稳得像老狗一样。 再看看CockRoachDB的HLC（混合逻辑时钟），虽然没了单点问题但只能保证单行的线性一致性。要是两行分在不同的表里先后顺序就乱套了。举个极端的例子：用户下单后先改支付状态再通知发货系统改状态；要是这俩系统分属不同的表，HLC可能会让查询瞬间看到“已发货”却看不到“已支付”，这就逼着业务方不停地写代码做防抖和重试。 经典的两阶段提交流程太复杂了得问三次话才能确认好提交成功。OceanBase把中间两步全砍掉了只留一次日志同步确认。要是出了故障大家互相看看日志齐不齐——只要有人缺页就直接回滚不把半成品留给用户用。 为了保证高可用OB搞了多副本和Paxos这套组合拳：把副本跨交换机放；故障交换机以外的多数副本重新选主；服务IP自动漂移到新节点上去对外透明。一句话交换机坏了业务停顿的时间连眨眼都不够。 最后还得说现在的Intel至强处理器厉害啊能把内存当持久化磁盘用还能跑事务；开发者用内存做缓存的时候也能享受原子性和隔离性的好处。 这事儿的趋势很明显啊：把复杂的系统留给专业的人去做就行了；简单的业务逻辑让业务方自己去搞就行了——这就是OceanBase一直坚持的原则啊！这也是所有分布式数据库未来的方向嘛！