TaurusMM

开头点明文章逻辑：
* 单节点更新性能有瓶颈，需要拓展到多节点
* 协调多节点更新会导致网络负载比较高。（猜测是读remote page，lock page什么的，应该相当于多节点的MESI协议）
* 云环境下，网络由多个tenant共享，所以网络负载的问题变得更加严重

MultiMaster的好处：
* 多节点写入，吞吐不受限制
* 可用性提高。（单主的系统在切主的时候可能会有抖动，需要比较多工作来优化这个抖动点）

这里他把一些分片的系统也认为是MultiMaster了，我就不提了

SharedStorage下的multi master：
* Amazon Aurora Multi-Master: Scaling out database write performance 2019
* Shared cache-the future of parallel databases (Oracle RAC)
* IBM white paper. 2009. Transparent application scaling with IBM DB2 pureScale

文章中先介绍了下他的一些优化，vector-scalar clock和lock manager，个人感觉不算很重要，就自上而下的说一下

有两个中心化的节点，GLM和GSM。

• GSM管理slice，taurus中的page是属于slice的，读取page/新建page的时候，需要分配对应的slice。每个slice就是一个page的集合，10G划分
• GLM管理page lock以及row lock
  • 一个master获取page的X锁之后，就允许处理Row X-Lock的请求，本地处理即可，避免对GLM造成压力
  • master获取page的S锁时，允许处理Row S-Lock 请求，也是本地

一个txn只会在一个master上执行，生成对应的log record并写入到log store中，每个master有一个逻辑时钟，用来分配LSN。
* 每个master会下刷log buffer到log store中
* 对于一个page上的写入，因为有X Latch的存在，写入是串行的，所以对应的log record的lsn也一定是递增的。那么在page store/RO上回放的时候，一个page内的数据顺序回放即可。
* 对于多个page上的写入，可能出现因果依赖，比如节点A发生了SMO，修改了parent page，然后节点B继续写入了。此时如果节点C在读取的时候，如果他只读到了节点B的log buffer，会发现Btree的结构出现不一致，因为SMO还未回放。所以他需要先回放节点A的log buffer，再回放节点B的log buffer。
* 这个先后顺序就是因果依赖，需要一些算法来追踪。比如vector clock，节点B的log buffer会带上节点A的version，那么在节点C apply 节点B的log buffer的时候，发现自己没有满足节点A的条件，就会等待
* 这里他做的一个优化是，只有这种log buffer的回放可能有因果依赖，为了避免vector clock的开销，搞了一个混合的版本。部分情况下才需要使用vector clock，平常使用逻辑时钟即可。这就是文章中的vector scalar clock
* 这个优化已经有很多类似的文章了，比如之前的GentleRain，直接在消息中传vector clock的最大值也是可以的

在做btree的读取的时候，对于single master的节点，会选取MTR边界作为一致性位点，去做多版本的读取。对于多个master来说也是一样的，不过有个特别的需要注意的点就是本地的时钟变成vector clock了。所以在做可见性判断的时候也是使用的vector clock