笔记 MIT6.824 Lecture 14: Optimistic Concurrency Control
目录
前言
主要讲了乐观锁在分布式事务中的应用,重点在于理解paper的Figure4
一、FaRM
1.1 对比spanner
FaRM的速度比spanner快很多(提升了100倍),FaRM的bottleneck是CPU time
FaRM在90台机器下能达到100million每秒的素的,是非常impressive的
1.2 setup
- 所有数据都在data center
- 一个primary对应一个backup
1.3 how to get high performance
有硬件以及特殊网络Protool的支持
- 分库多severs 90台
- 使用内存没有disk的读写
- 网络通讯获取data的时候可以直接读取内存
1.4
NVRAM (non-volatile RAM)
数据保存在内存,有断电保护(battery)
这样可以减少了写操作带来的花销
传统的网络传输过程
传统的网络传输有各种分层,会导致RPC难以超过100000/second
于是FaRM使用了两个改进的方法
- Kernel bypass
- RDMA
Kernel bypass
新的bypass就是可以通过NIC直接跟别的server通信,避免了中间层对速度的影响
RDMA
直接跟内存通信,也就是sender provides memory addreses, and remote CPU is not involved.
二、Optimistic Concurrency Control (OOC)
2.1 原因
OCC lets FaRM read using one-sided RDMA reads server needn’t actively participate (no lock, due to OCC)
FaRM transaction API (simplified):
txCreate()
o = txRead(oid) -- RDMA
o.f += 1
txWrite(oid, o) -- purely local
ok = txCommit() -- Figure 4
what’s an oid?
<region #, address>
region # indexes a mapping to [ primary, backup1, … ]
target RDMA NIC uses address directly to read or write RAM
Server 内存的layout
三、commit的过程
这个跟hibernate的commit挺像的,就是当你commit的时候对比version number,不一样的就返回false
Validate
有一个refetch的过程,为了提速用的,会比lock+commit快。原理就是one-sided RDMA reads 去re-fetch objects version number and lock flag does not set the log
例子分析
例子A
T1 ReadX LockY ValidateX Commit
T2 ReadY LockX ValidateY Commit
在Vx以及Vy的时候都会看到Lock,所以两个都是abort
例子B
T1 ReadX LockY ValidateX Commit
T2 ReadY LockX ValidateY Commit
对于T1来说是可以的,对于T2来说,在Validate Vy的时候,如果Comimit没有happen,就看到Lock,如果Commit已经happen,则Object id不一致,所以是abort
总结
FaRm就速度来讲是非常快的,可以说是impressive,但是,最好在没有太多conflict,因为乐观锁的缘故,同时也需要额外软件/硬件上的支持新的网络协议以及内存读取。但是可以看出,乐观锁在速度上会比更有优势
上一篇: 辽宁首笔跨境金融区块链业务落地