原文地址：Spanner: Google’s Globally-Distributed Database
中文翻译版下载：Google Spanner 中文版
PPT演示文档：spanner-osdi2012.pptx
讲解视频：
标签归档： 分布式数据库
Google Spanner 全球分布式数据库
(4.75分 - 12票) 
Loading ...Google 公布了分布式关系数据库F1的设计论文
该分布式关系型数据库基于Spanner，F1针对AdWords业务设计，兼具NoSQL的高可用性和扩展性，主要用来替代MySQL的集群。早期的时候已经有F1的介绍文档：幻灯片 F1 – The Fault-Tolerant Distributed RDBMS Supporting Google’s Ad Business
这一次，Google公布了其设计文档，阅读链接：
二阶段提交及相关学习笔记
在分布式数据库中，处理分布式事务是比较重要的技术。分布式事务的处理保证了数据的一致性。二阶段提交在可用性和一致性性上面做到了最好的折中。是一种基本的事务处理机制或者协议。
对于二阶段提交的准确解释可以参考维基百科词条：http://zh.wikipedia.org/wiki/%E4%BA%8C%E9%98%B6%E6%AE%B5%E6%8F%90%E4%BA%A4
理解二阶段提交关键是要结合redo、undo日志，日志可以固化到DB中，也可以回滚即丢弃，基于此，才能做到预提交与实际提交的分离。
在分布式系统中，一般来说不止是1个协调者与2～3个参与者之间交互，当考虑容错性时，通常会考虑如下场景：
协调者在完成了一阶段的预提交过程后，得出了本事务的执行结论，在本地日志中记录了结论，正待向参与者发出结论时，宕机，这样除了协调者本身之外，就没有人知道该事务的结论。因此必须等待协调者恢复之后才能继续该事务，在此之前所有参与者都将阻塞。各个阶段所获取的资源一直不释放，可能导致整个集群业务受阻。
解决该问题的办法是将第二阶段（正式提交阶段）再变为两个阶段，先让集群中若干个参与者知道自己将要提交结论，而不是记录本地日志，这样该协调者无论在哪个阶段宕机，都可以由新选出的协调者通过查询各个参与节点的状态来判断当前处于哪个阶段，从而继续后面的各个阶段的操作。也就是三阶段提交了，这样参与者与协调者的交互步骤增加，实际操作起来也变得复杂很多，因此实用性不强。
[分享]百度分布式数据库
很老的视频了，感觉讲得不错，百度09年都已经SSD了，我们却还在挣扎着怎样精简流程来节省元数据的访问。右边是视频中用于讲解的PPT。
