背景考虑这么一个问题：对于大型网站的异地复制，公司存在多个数据中心，每个数据中心拥有全量数据，读均为本地读。那么写应该怎么实现？一致性应该如何取舍？ 对于以上背景，Spanner 和 Facebook/Memcached 已经给出了他们自己的解决方案： Spanner： 线性一致性。 通过 Paxos 和 2PC 实现分布式写事务。 写入需要等待 quorum 的数据中心返回 ack，性能较低

背景本篇论文由 Facebook 2013 年在 NSDI 上发表，其系统地介绍了 Facebook 公司内部对于大规模缓存系统的使用实践。 这篇论文没有太多新的想法，但却传达了一个很重要的理念：不同的场景有不同的系统需求。在成本有限的情况下，并不一定线性一致性就是最好的，对于有些场景，最终一致性带来的收益远超我们的想像。 对于大部分 2C 应用，随着用户数量的逐渐增加，其后台数据存储系统大致是如

相关背景2008 年，中本聪设计出了比特币和区块链。在今天，区块链成为了热门的技术，其通过分布式账本技术和共识机制，构建了低成本互信机制。 区块链三个根本特性是去中心化、实现点对点的价值传递和低成本信任机制。 介绍区块链是一个划时代的技术，其使得我们能够不假装相信一个中央机构而实现可信的交易。 下面简单讨论一下一些设计要点： 首先，在公网的 P2P 系统中，我们必须设计出支持拜占庭容错的共识算法。

相关背景Google Spanner 是 Google 一篇跨时代的论文，开启了 NewSQL 时代的序幕。 其主要有三点特色： 2PC + 共识组来避免 2PC 的无限超时阻塞。 GPS 原子钟同步技术以支持快速的只读事务。 支持 ACID 的全球型 NewSQL 数据库。 介绍暂仅搬运一些资料，之后有时间再补。 6.824 讲义 6.824 视频 论文 Spanner 白皮书 Spann

相关背景Fram 结合了乐观事务和硬件优势，在保证可串行化的基础上实现了高性能的分布式事务框架。虽然其系统仅是一个原型系统，但其思想十分具有指导意义。 其主要利用了三点硬件特性： NV RAM：减少磁盘 IO 对性能的影响。（一次 RAM 写大致需要 200ns，一次 SSD 写大致需要 100us，一次 HDD 写大致需要 100ms） Kernal Bypass：本地应用直接与网卡交互，无系

前言事务是作为单个逻辑工作单元执行的一系列操作。一个逻辑工作单元必须有四个属性，称为原子性、一致性、隔离性和持久性 (ACID) 属性。分布式事务则是尝试在多节点的环境下实现这些语义。 分布式事务涉及的知识内容较多，本篇博客并没有将其彻底整理清楚，只是简单记录了一下 6.824 课程所学。 内容对于分布式事务，可以将其细化为并发控制和原子提交两个子问题。前者是在说如何保证并发事务的串行隔离性，后者

相关背景Amazon Aurora 是一种与 MySQL 和 PostgreSQL 兼容的关系数据库，专为云而打造，既具有传统企业数据库的性能和可用性，又具有开源数据库的简单性和成本效益。 Amazon Aurora 的速度最高可以达到标准 MySQL 数据库的五倍、标准 PostgreSQL 数据库的三倍。它可以实现商用数据库的安全性、可用性和可靠性，而成本只有商用数据库的 1/10。 关于 A

前言Frangipani 是一篇很古老的分布式存储论文，其设计思想在今天看来有很多已经过时了，但也有一定的参考意义。 该论文主要介绍了三个方面的工作： cache coherence distributed transactions distributed crash recovery 内容具体内容可以参考此 博客 和 6.824 课程的 讲义，后者较为详细。 有关后两个工作可以直接参考以上博

前言对于 raft、paxos 这类共识算法，leader 节点需要将客户端的写请求编号并发送给所有 follower 以期望达成共识，这一定程度上导致写性能无法随节点个数线性增长，因为 leader 同步的数据量会随着节点数的增长而增长，从而使得主节点承载着更大的压力，往往成为了瓶颈。 2004 年，Chain Replication （之后简称 cr）方案被提出，其也能够保证多副本间的线性一致

前言Zookeeper 作为一个划时代的分布式协调服务，是 Hadoop 技术栈的重要组件。 本篇博客将讨论一些 zk 论文的知识点。 内容最近比较忙，没多少时间总结了，论文内容概要可以参考这篇 博客，更详细的细节可以参考这篇 博客。 讨论zk or etcd?同为分布式协调服务和元数据存储服务的产品：老大哥 zk 伴随 NoSQL 运动崛起，坐拥 hadoop 技术栈孤独求败；后起之秀 etcd