|
|
如何评价开源数据库lealone的分布式事务模型？
关注者
509
被浏览
61,754
4 个回答
我先给你理理这个设计的思路，然后再来说这个设计的问题。
事务有原子性要求，分布式事务可能会涉及到多个机器，原子性如何保证? 在这点上，该方案也是采用了传统两阶段提交的思路，也是coordinator给各个参与者发请求，让他们做prepare，然后各个参与者内部的存储对于每个key也是存储多版本，只不是这个版本号是一个以1递增的计数器产生的(这里有问题，后面再说)，然后coordinator手机到各个参与者返回的事务号(由机器id和一个整数组成)，然后进入commit阶段，把收到的参与者的事务号list发给所有的参与者，然后参与者接到commit消息后，从本地计数器拿一个id作为这个本地事务(分布式事务的一部分)的提交时间戳，然后进行写写冲突检测(乐观锁机制)，如果无冲突，则提交，提交其实就是往一张事务状态表中插入如下信息:
这个本地事务的提交时间戳是啥，并且这个本地事务所属的分布式事务涉及到的所有本地事务的id
以上是写流程。结合下面的读流程就知道问题在哪
读流程：和原文一样，只说读单个key的问题。一个读请求到一台机器，从这个key的高版本到低版本依次扫描(只要prepare成功，则会产生一个更大的版本)，直到找到一个成功提交的key。什么叫做成功提交?对于分布式事务来说，如果分布式事务成功了，那么所有涉及到的操作都是成功提交。原文检测成功提交的方法是用版本和机器id还原出本地事务id，然后去事务状态表中找出当初执行这个本地事务id所属的分布式事务的状态，如果发现，分布式事务成功提交了，那么就认为key的这个版本是成功提交的，那么对用户可见。返回给用户。
原文的设计就是这些。
性能问题先不说，就一个大问题，如何支持快照读?
从读的角度，如何支持快照读? 数据库在运行的过程中，客户端发起一个快照读请求，那么对于这个客户端来说，无论数据库的数据如何变化，那么这个客户端看到的数据始终是不变的。原文压根就没有分布式事务版本号这个概念，那么如何实现快照读? 没有版本号，那么一个快照读事务可以读哪些版本不可以读哪些版本如何获知?
平时工作中看到的问题在一些不明确的限制条件下得到的解决办法， 思考力但是不能算作一般意义上的分布式事务。多client之间对数据的交叉修改，clientA 扫描clientB未commit的数据，此时是维护全局状态表呢还是向B询问？client挂了又到哪里查状态表？回滚一定能做成功？