当数据库遇到分布式，你会怎么做？

两阶段提交2PC(two-phase commit)是一种用于实现跨多个节点的原子事务提交的算法。可以在数据库内部使用，也可以以XA事务的形式对应用可用。

两阶段提交引入了协调者的角色，整体分为两个阶段，具体的过程如下：

当应用想要启动一个分布式事务时，它向协调者请求一个全局唯一的事务ID。

应用在每个参与者启动单节点事务，每个单节点事务都带上这个全局事务ID。所有的读写都是在单节点事务中各自完成的。如果这个阶段出现任何问题，则协调者或任何参与者都可以中止。

当应用准备提交时，协调者向所有参与者发送一个准备请求，并带上全局事务ID。如果任意一个请求失败或超时，则协调者向所有参与者发送针对该事务ID的中止请求。

参与者收到准备请求时，需要确保在任何情况下都的确可以提交事务。这包括所有事务数据写入磁盘(出现故障，电源故障，或磁盘空间不足都不能是稍后拒绝提交的理由)以及检查是否存在任何额冲突或违反约束。一旦作出承诺，就不允许反悔。

当协调者收到所有准备请求的答复时，会就提交或中止事务作出明确的决定(只有所有参与者赞成的情况下才会提交)。协调者必须吧这个决定写到磁盘的事务日志中。

一旦协调者的决定落盘，提交或放弃请求会发送给所有参与者。如果请求超时或失败，协调者必须永远保持重试。

两阶段提交固有的成本：由于崩溃恢复所需的强制刷盘以及额外的网络往返，另外整个过程会进行资源的锁定。

Percolator

Percolator是由Google公司开发的、为大数据集群进行增量处理更新的系统，主要用于google网页搜索索引服务。使用基于Percolator的增量处理系统代替原有的批处理索引系统后，Google在处理同样数据量的文档时，将文档的平均搜索延时降低了50%。

Percolator 是一个无中心化(没有协调者)的两阶段提交，基于BigTable的单行事务，实现了跨行的事务引擎。另外借助BigTable的多时间戳版本，可以实现快照隔离级别。

Percolator依赖中心的授时器，没有单点 Coordinator 的角色，交由所有客户端来协调上锁协议，但是赶上崩溃锁会泄露。Percolator 选择了惰性地回收泄露的锁：其他客户端在 Get() 到这行数据时，如果遇到锁，则选择等待退避重试，或者清理锁。

但是由于Percolator使用乐观锁检测机制，对于热点数据的并发更新不友好。我觉得这一点可以通过在Percolator之上实现悲观锁机制来解决。

分区

分区(partitions)也叫分片(sharding)，是将数据集进行拆分成多个分区，每个分区存储在不同的机器上，扩展了整体的存储量，提高了写入和读取的性能。但也带来了新的困难，数据库要支持跨分区的写入和读取。

分区方式

分区的目标是将数据和查询负载均匀的分布在各个节点上。如果分区是不公平的，或者没有考虑热点数据，那么一些分区比其他分区有更多的数据或查询，我们称之为偏斜(skew)。数据分区通常基于Key进行拆分，在考虑数据偏斜的情况，要根据数据库的特定的分区算法，特别注意Key的设计。

根据Key的范围分区 为每个分区指定一块连续的Key范围，分区Key的边界一般由数据库自动选择。好处是范围扫描非常简单。但是如果Key的设计不合理，会到热点数据，影响查询效率。

根据Key的散列分区 通过一个散列函数对Key进行计算后，再进行分区。这样可以消除偏斜和热点的风险，但是失去了原有Key的范围查询的属性。

有些数据库，如Cassandra，采取了折中的策略，使用多个列组成的复合主键来声明。键中只有第一列会作为散列的依据，而其他列则被用作Cassandra的SSTables中排序数据的连接索引。尽管查询无法在复合主键的第一列中按扫描扫表，但如果第一列已经指定了固定值，则可以对该键的其他列执行有效的范围扫描。组合索引的方法为一对多关系提供了一个优雅的数据模型。

索引构建

上面我们讨论了主键的分区策略，实际情况上辅助索引/二级索引也是很有必要的，特别是在关系模型中。

辅助索引的构建方式有两种：本地索引和全局索引

（编辑：PHP编程网 - 黄冈站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!