UpdateServer(UPS) 是OceanBase 的写入单点，一个集群中只有一台UPS服务器，所有的写都写入到这台机器。OceanBase采用基于静动态数据分离的机制，静态数据存储在静态数据服务器ChunkServer(CS)磁盘上，动态数据存储在UPS的内存中，导致一次读请求需要将静态和动态数据合并才能得到完整的数据，从而读也要访问UPS。OceanBase作为一个支持事务的分布式关系型数据库，UPS是实现事务的核心组件。单独看UPS，它是一个内存数据库，存储模型类似于LSM，写入操作写入内存，持久化通过写操作日志来保证，宕机后通过回放操作日志恢复数据，同时将对磁盘的随机写转换成顺序写。在事务的支持上，UPS实现Read Committed隔离级别。UPS在设计之初只考虑小事务，所以不需要传统关系型数据库中的UNDO，不支持像insert 1TB 这种大事务。操作日志中只有commit操作，没有rollback操作，所以操作日志更适合叫commitlog或者叫REDO LOG。实现上，读写互不影响，采用MVCC，写写冲突需要使用行锁。下面详述UPS的事务机制。
UPS的存储引擎使用的是一颗BTree，原理看这 和 这。这颗BTree是内存BTree，是一个聚簇索引，Key是表的主键，Value指向对这行的增量修改，如下图所示：
如图所示，对同一行的修改通过链表挂在BTree的Value上。对一行的每一次修改对应其中一个节点，TransID标识了提交这次修改的事务ID。当一个事务开启还没有提交时，事务的修改存在事务局部，事务提交的时候才会将事务的修改串到BTree的Value链表上。redo log buffer是一个内存block 的ring buffer，每个block 2MB。事务提交时，多个事务抢redo log buffer中的偏移和大小，抢在前的事务先提交，也就是说先串事务局部的修改链表到BTree的Value链表上。磁盘上，每个commitlog 64MB。
事务ID
和Oracle一样，事务ID是个时间戳。事务提交时抢到redo log buffer中的偏移时，事务ID根据当前时间和事务在redo log block的相对事务号来计算出事务ID，随后事务ID会被回填到事务局部链表中。
MVCC
由于OceanBase没有UNDO，MVCC相对来说实现比较简单。UPS全局维护一个publish_trans_id，表示最后一个成功提交的事务ID。每个事务开始时，获取publish_trans_id，相当于一个快照点，从而这个事务只能读取在这个事务之前开始的事务提交的修改，在这个事务开始之后开始的事务提交的修改时读不到的。读事务拿着事务开始时获取到的publish_trans_id，找到相应的行后，顺着链表读，只能读取TransID小于等于publish_trans_id的增量修改。每次刷redo log到磁盘后，会将这批redo log对应的最新的事务ID更新到publish_trans_id。写盘采用libaio+dio。由此看来，OceanBase的MVCC更像行级多版本。为了避免行链表过长，影响读的latency，在写的时候如果发现一行太长，会对链表进行合并。
写写冲突需要通过行锁来解决。采用两阶段锁，对需要修改的行加写锁，提交回滚的时候统一释放锁。
CheckPoint
由于OceanBase UPS实际上是一个内存数据库，存储模型类LSM，在内存不够时，会dump memtable到磁盘上形成SSTable，dump时会切换一个commitlog文件，这个commitlog的文件名就是OceanBase的checkpoint。在checkpoint上，传统关系型数据库比如MySQL在这点就比较好，以Innodb为例，checkpoint本质上是redo log的一个偏移量，由于它是个基于磁盘的存储引擎，数据是以Page进行组织的，只要Buffer Pool中的已经提交的事务修改的脏页刷新到磁盘了，那么相应的redo log就可以重用，checkpoint就可以向前推进。