search

lealone / Lealone

比 MySQL 和 MongoDB 快10倍的 OLTP 关系数据库和文档数据库
Other
2.44k stars 513 forks source link

请教一个问题，关于lealone的事务机制 #70

Closed Frank-Jin closed 9 years ago

Frank-Jin commented 9 years ago

每个server在这一步严格按顺序做下面4件事:

1、增加本地计数器，为本地事务获得一个提交时间戳 2、按元素key进行写写冲突检测，只要当前本地事务的开始时间戳小于上一个事务的提交时间戳就表示发生了写写冲突 3、更新事务状态表，每个server都在事务状态表中插入一条类似下面表6中的记录 4、每个server缓存元素的key和提交时间戳(只是一个临时缓存，用于下一个事务的写写冲突检测)

如果提交阶段有冲突，那么感觉还要去清除同一个事务其他server的步骤4的数据；这个步骤感觉开销较大，而且对可靠性要求高。

Frank-Jin commented 9 years ago

不知道有没有好的方法。

codefollower commented 9 years ago

不需要清除的，因为只是一个临时缓存，大小是有限的，后面的数据会覆盖前面的数据。 再加上本地计数器是递增的，前面没有清除的数据不会对后面的事务有影响， 因为后面的事务的时间戳总是会大于未清除数据中的时间戳，所以就不会违反第2点。

codefollower commented 9 years ago

你可以看看CommitHashMap 这个类就是临时缓存，这个类的代码还保留了一点OMID这个项目中的代码痕迹。

lealone的事务模型的最初灵感就是来自于OMID项目。 之前在我的微博中有记录完整的灵感触发过程，可惜我把以往的微博清除了。

codefollower commented 9 years ago

以上4步的代码在Transaction.java

Frank-Jin commented 9 years ago

谢谢，另外，感觉读这一块的性能会比较低，每次都要进行分布式的有效性校验

codefollower commented 9 years ago

不是有cache的么，只是cache一个id值，不会浪费多少内存的， 在每个server缓存1000万个id值也才70多M。 只有第一次才进行分布式的有效性校验。

另一个很容易的改进点是：只要第一次校验成功了，就修改一下事务的成功标志， 下次读时都不用cache了，但是这种方案在第一次读时多了一次修改，所以第一次读的性能比较慢。