FaRM Optimistic Concurrency Control

结构

image-20221025095206167

数据分片之间使用链式备份

High Performance

  • Sharding

    分片的数据独立,就可以提升性能

  • RAM储存数据

  • NVRAM

    非易失RAM,解决突然断电问题

  • RDMA

    通过网卡NIC直接读写服务器数据

    Kernel Bypass 不经过内核,直接访问

NVRAM

解决供电故障

FaRM数据保存在RAM中。由于FaRM是放在同一个数据中心的,所以如果当地停电,就会使所有的服务器挂掉。

FaRM使用普通RAM,但是备用应急电源,断电时启用备用应急电源,然后提示FaRM停止工作,并且在这段时间内把数据写入磁盘。

传统的数据包发送

image-20221025105139967

内核旁路

image-20221025105931180

通过内核的放行,使得应用程序能够直接控制网卡,网卡也能直接对应用程序使用的内存进行DMA。

就可以不经过内核进行网络传输。

这需要先进的网卡支持

而应用程序需要代替内核,进行TCP/IP协议栈的操作,比如拥塞控制,CheckSum等。使用了DPDK这个工具包。

RDMA

image-20221025110515279

通过RDMA网卡, APP可以直接控制网卡,对远程主机上的响应的内存空间进行直接访问,并且写到本机对应的空间。远程主机上的CPU和应用程序完全不用知道这个操作的发生,也不需要对此进行什么响应。

RDMA也使用了类似TCP的可靠sequenced protocol,不过是在同一个数据中心,所以可能不需要那么复杂

论文叫做 one-sided RDMA

可以利用RDMA给incoming queue增加一条数据会追加日志条目

只用RDMA能够就实现分布式事务?

FaRM并没有这么做,目前的一致性协议等都需要服务端去参与,比如锁的实现

使用乐观锁并发控制来支持事务

Optimistic Concurrency Control

  • Pessimiic Concurrency Control

    数据使用前要持有锁

    没锁要阻塞 blocks

  • Optimistic Concurrency Control

    image-20221025112735946

读的时候不会去获取锁

写入不是直接写入,而是写入到buffer

在提交前判断,如果读到的的数据是旧的,那么就是数据冲突,abort

如何Validation

image-20221025191046427

内存结构

image-20221025192302674

数据的开头放着锁标识位和版本号

同时不同的机器会有专门用于log的队列和用于RPC的消息队列,RDMA可以直接访问修改

事务提交过程

image-20221025194022139

查看版本号和锁操作锁原子操作

客户端此时充当了TC

  1. LOCK阶段

    会把所有的对象发给Primary

    Primary首先要读取锁标志位,如果目前上锁,则返回失败

    如何不上锁,会比较获取时版本号时候一致,若一致则返回成功

  2. VALIDATE阶段

    是对只读型事务的优化,只读型事务可以通过RDMA直接读取HEADER

    检查HEADER中锁标志位和版本号

  3. COMMIT BACKUP阶段

  4. COMMIT PRIMARY阶段

    客户端通知PRIMARY提交,PRIMARY会释放对应资源的锁

  5. TRUNCAIT阶段

    客户端通知各个节点事务结束,可以丢掉这个事务中间信息了

比如

image-20221025195617878

可能的一种结果

image-20221025200016279

image-20221025200251653

image-20221025200513989

读取时不用通过锁,可以通过RDMA直接读,速度很快

验证阶段的例子

image-20221025201643175

Q.E.D.