开源分布式存储技术分享-施继成
达坦科技
sky computing 和 全球性分布式
左边是raft,右边是最开始的paxos
RRT=Round-Trip Time
如果leader和follower放在不同的数据中心，由于需要两个RRT，这个时间就更长了了，latency就更大了（2个RRT在同一个机房内，感觉不到，因为很快）
全球电商，国内的放在一个region里面，美国放在一个region。 and so on
那能不能用一个RRT来解决这个问题呢？
为什么需要两个RRT来做这个事情？
1、为所有的request排一个顺序，这个全局顺序就是在raft当中我们为每一个log提供一个slot，你来了我就放在log的末尾，一个新的request来了，再放到log的末尾，一个挨一个排下去，这样来说，随着log id的增加，就拿到了一个全局的顺序。
2、把request的数据分发到比较多的机器上，保证集群中少数机器fail，仍能从剩余机器中恢复数据。
发现第2个没办法丢弃，因为我么必须保证数据不丢失。
那能不能从第一条来着手，能不能不排全局顺序？
并发读写删改，操作同一个key
version可以类比git commit。你想看任意修改都是可以切换的。
在读和写同时发生的时候，各自正常进行，读就读当前最新版本，只要在读返回前，你的写没有完成，就可以让这个读正常返回。
刚好这个log id 跟mvvc这个version语义是差不多的，刚好可以拿来复用。
但是好像又走到了死胡同，我们想要做高的并发度，我们就要用MVCC，用了MVCC就要全局顺序。
我们再深层次的的想想这个问题。 其实还是有个空子可以钻的。想想我们为什么要这个version呢？
我们不就是要解决contention（竞争）的问题吗？
那假设，这个key，单一时间只有一个人访问，那不就没有竞争，那这个时候是不是可以不要这个versioned control。那是不是可以暂时不要全局的顺序，我就可以直接执行返回，就能解决这个问题了。
恰巧在2019年在NSDI 有一篇论文发表出来。
exploiting commutativity for practical fast replication
它的意思是如果我们有些操作是可以有这个交换顺序的，我们为什么要提前帮它做这个全局顺序排布呢？我们可以有一些取巧部分。
这个协议的精髓在于把我们的协议分为前半部分和后半部分。
前半部分，检测有没有冲突，如果没有冲突，就让你用一个RTT正常执行完，commit掉就OK了。
如果有冲突，后端直接对接一个raft或paxos。
它的好处，在我没有冲突的时候，速度就会快，有冲突的时候，也不会出错。
它虽然有leader，但是消息并不是由leader转发，而是由client发给了所有潜在的server
然后这些server做完前面这部分的冲突检测，给一份返回给client，client收集到大多数，最好情况是全部server回复，如果觉得部分觉得可以执行了，client就认定z=7这个操作已经被执行完了，已经被commit掉了，注意这里的commit和raft的commit有不一样的地方，这里的commit表示，这个request已经被执行了，已经被commit了，不会丢了，但是它在整个执行顺序，global的这个顺序还是不确定的，需要等待master把之前接收到的请求，一个一个的sync到backup里面去，才能够确定最终的顺序
细节可以分为上图三个部分：
1、如果witness没有探索到冲突，我们就会把取当前的请求保留下来，并且告知client没有冲突，
2、如果被witness发现有冲突，witness直接把这些请求扔了，这个反正是冲突的。到时候上面master会给我同步，我现在也不关心。
直接丢弃并且告知client有冲突。
3、master接收到任意请求，同步到后端协议。
协议核心部分是，通过一些可以交换的，不冲突的这些请求，能让它先执行，先不决定全局的顺序，这样的优化来达到了提高这个执行性能。
https://github.com/datenlord/Xline
把部分逻辑挪到client端， 由client端判断这条信息到底有没有被commit下来，只需发一次，收集一次，一个RTT
可以理解为读写都是quorum
写是quorum怎么解决写冲突？
冲突在如下图红色部分解决，举个例子，有两个client同时要对z进行写，假设第一个client先到达，那么它第一个RRT就成功了，第二个请求发过来的时候，发现有一个z的修改在里面，同时还没被后端协议给commit，它就会reject第二个请求， 这个时候client就知道这个request没办法走通快的路径，就等待，等待第二个请求保存到master，然后异步保存到backup的过程做完，再回复给client,这种情况，它的RRT就和正常的raft是一样的。
vertical paxos论文
FPGA 做一块加速的网卡，里面会有一些协议，服务与底层网络传输性能要求。
CRaft could save 66% of storage, reach a 250% improvement on write throughput and reduce 60.8% of write latency
CRaft: An Erasure-coding-supported Version of Raft for Reducing Storage Cost and Network Cost
https://www.usenix.org/conference/fast20/presentation/wang-zizhong
https://www.usenix.org/sites/default/files/conference/protected-files/fast20_slides_wang.pdf
标签：存储,顺序,这个,开源,client,冲突,commit,RRT,分布式 From： https://www.cnblogs.com/wade1010/p/17112159.html