|
之前我给自己提了一个巨大的命题：海量数据实时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页】
| 
转播
