之前我给自己提了一个巨大的命题:海量数据实时CRUD的事务性如何保证?
这几天我一直在搜索和研究现有的大数据事务的解决方案,当然,最著名的就是谷歌的Percolator了,算是鼻祖的地位了吧。
Percolator激发了一波又一波又一波的人的灵感,使得他们写出了其它的大数据事务的解决方案。
我看了Percolator对于ACID的实现,可以发现它的解决方案主要为:
- 使用Snapshot Isolation
- 只防止写冲突(write-write conflict)
- 提供一个全局的时间戳服务
- 没有全局的锁服务,而是把锁信息和数据存在一起
- 两阶段提交
- 采用了一种被动方式来清理事务失败遗留的锁
- 使用了Chubby lockservice和wall time来判断一个事务所在的进程是否死了或者没响应了,这对于分布式系统来说,是很必要的。
Percolator可以在一个事务中支持成千上万条数据的更新,但因为时效性的问题,不太适合实时性要求高的场景。
话说Percolator的时代还没有ZooKeeper,从36726.pdf中描述中看,貌似ZooKeeper完全可以取代Chubby lockservice。为啥要说这个呢,因为我们无法获取到Chubby lockservice的源码,但是ZooKeeper是开源的,所以如果想要照着Percolator来实现自己的海量数据操作ACID逻辑,可以考虑用ZooKeeper取代Chubby lockservice。
由于博客的篇幅有限,更详细的说明在这里,Percolator,谷歌如何实现大数据的事务【15页】