随笔 - 2300&
文章 - 0&评论 - 0&trackbacks - 0
为了完成对数据的操作，企业应用经常要求并发访问在多个构件之间共享的数据。这些应用在下列条件下应该维护数据的完整性(由应用的商务规则来定义): 分布式访问一个单独的数据资源，以及从一个单独的应用构件访问分布式资源。 在这种情况，可能要求在(分布式)资源上的一组操作被当作一个工作单元(unit)。在一个工作单元中, 操作的所有部分一起成功或失败并恢复。在下面的情况下这个问题更加复杂: 通过一组分布式的、访问多个资源的数据的构件实现一个工作单元，和/或部分操作是被顺序执行的或在要求协调和/或同步的并行线程中。 在所有情况下, 都要求应用维护一个工作单元的成功或失败。在失败的情况下，所有资源要把数据状态返回到以前的状态 (比如说，工作单元开始前的状态)。 事务的概念和和事务管理器(或者一个事务处理服务)在一个工作单元中的维护数据完整性，这就简化了这样的企业级别分布式应用的构造。 一个事务是有下列属性的一个工作单元: 原子性(ATOMICITY): 一个事务要被完全的无二义性的做完或撤消。在任何操作出现一个错误的情况下，构成事务的所有操作的效果必须被撤消，数据应被回滚到以前的状态。 一致性(CONSISTENCY): 一个事务应该保护所有定义在数据上的不变的属性(例如完整性约束)。在完成了一个成功的事务时，数据应处于一致的状态。换句话说，一个事务应该把系统从一个一致-状态转换到另一个一致状态。举个例子，在关系数据库的情况下， 一个一致的事务将保护定义在数据上的所有完整性约束。 隔离性(ISOLATION): 在同一个环境中可能有多个事务并发执行，而每个事务都应表现为独立执行。串行的执行一系列事务的效果应该同于并发的执行它们。这要求两件事: 在一个事务执行过程中，数据的中间的(可能不一致)状态不应该被暴露给所有的其他事务。 两个并发的事务应该不能操作同一项数据。数据库管理系统通常使用锁来实现这个特征。 持久性(DURABILITY): 一个被完成的事务的效果应该是持久的。
****************************************************************************************************************************************************************************************************************************
&****************************************************************************************************************************************************************************************************************************
【考点】数据库事务基础知识。【出现频率】★★★☆☆【解答】事务提供了一种机制，可用来将一系列数据库更改归入一个逻辑操作。更改数据库后，所做的更改可以作为一个单元进行提交或取消。事务可确保遵循原子性、一致性、隔离性和持续性（ACID）这几种属性，以使数据能够正确地提交到数据库中。使用事务机制的好处非常明显，例如银行转账之类的交易操作中，事务有着重要的作用。事务的成功取决于事务单元帐户相互依赖的操作行为是否能全部执行成功，只要有一个操作行为失败，整个事务将失败。例如：客户A和客户B的银行账户金额都是10000元人民币，客户A需要把自己帐户中的5000元人民币转到客户B的账户上。这个过程看似简单，实际上涉及了一系列的数据库操作，可以简单地视为两步基本操作，即从客户A帐户的金额中扣除5000元人民币，以及将客户B帐户中金额添加5000元人民币。假设第1步数据库操作成功，而第二步失败的话，将导致整个操作失败，并且客户A帐户金额将被扣除5000元人民币。事务机制可以避免此类情况，以保证整个操作的完成，如果某步操作出错，之前所作的数据库操作将全部失效。【分析】事务是单个的工作单元。如果某个事务成功，则在该事务中进行的所有数据更改均会提交，成为数据库中的永久组成部分。如果事务遇到错误且必须取消或回滚，则所有数据更改均被清除。一个逻辑工作单元必须有ACID属性，只有这样才能成为一个事务。ACID属性有以下4个属性。1．原子性事务必须是原子工作单元。对于其数据修改，要么全都执行，要么全都不执行。2．一致性事务在完成时，必须使所有的数据都保持一致状态。在相关数据库中，所有规则都必须应用于事务的修改，以保持所有数据的完整性。事务结束时，所有的内部数据结构都必须是正确的。3．隔离性由并发事务所做的修改必须与任何其他并发事务所做的修改隔离。事务识别数据时数据所处的状态，或者是另一个并发事务修改它之前的状态，或者是第二个事务修改它之后的状态，事务不会识别中间状态的数据。这称为可串行性，因为它能够重新装载起始数据，并且重播一系列事务，以使数据结束时的状态与原始事务执行的状态相同。4．持久性事务完成之后，它对于系统的影响是永久性的。该修改即使出现系统故障也将一直保持。事务有以下3种运行模式。q & & &自动提交事务：每条单独的语句都是一个事务。q & & &显式事务：每个事务均以BEGIN TRANSACTION语句显式开始，以COMMIT或ROLLBACK语句显式结束。q & & &隐性事务：在上个事务完成时新事务隐式启动，但每个事务仍以COMMIT或ROLLBACK语句显式完成。说明：还有一种批处理级事务模式，该模式仅应用于多活动结果集（MARS），在MARS会话中启动的Transact-SQL显式或隐式事务变为批处理级事务。当批处理完成时没有提交或回滚的批处理级事务自动由SQL Server进行回滚。
阅读(...) 评论()Mycat 分布式事务的实现
小编说：Mycat已经成为了一个强大的开源分布式数据库中间件产品。面对企业应用的海量数据事务处理，是目前最好的开源解决方案。但是如果想让多台机器中的数据保存一致，比较常规的解决方法是引入“协调者”来统一调度所有节点的执行。
随着并发量、数据量越来越大及业务已经细化到不能再按照业务划分，我们不得不使用分布式数据库提高系统的性能。在分布式系统中，各个节点在物理上都是相对独立的，每个节点上的数据操作都可以满足 ACID。但是，各独立节点之间无法知道其他节点事务的执行情况，如果想让多台机器中的数据保存一致，就必须保证所有节点上的数据操作要么全部执行成功，要么全部不执行，比较常规的解决方法是引入“协调者”来统一调度所有节点的执行。
XA 规范X/Open 组织（即现在的 Open Group）定义了分布式事务处理模型。X/Open DTP 模型（1994）包括应用程序（AP）、事务管理器（TM）、资源管理器（RM）、通信资源管理器（CRM）四部分。事务管理器（TM）是交易中间件，资源管理器（RM）是数据库，通信资源管理器（CRM）是消息中间件。通常把一个数据库内部的事务处理看作本地事务，而分布式事务处理的对象是全局事务。全局事务是指在分布式事务处理环境中，多个数据库可能需要共同完成一个工作，这个工作就是一个全局事务。在一个事务中可能更新几个不同的数据库，此时一个数据库对自己内部所做操作的提交不仅需要本身的操作成功，还需要全局事务相关的其他数据库的操作成功。如果任一数据库的任一操作失败，则参与此事务的所有数据库所做的所有操作都必须回滚。XA就是X/Open DTP 定义的交易中间件与数据库之间的接口规范（即接口函数），交易中间件用它来通知数据库事务的开始、结束、提交、回滚等，XA 接口函数由数据库厂商提供，根据这一思想衍生出二阶段提交协议和三阶段提交协议。
二阶段提交所谓的两个阶段是指准备阶段和提交阶段。准备阶段指事务协调者（事务管理器）向每个参与者（资源管理器）发送准备消息，每个参与者要么直接返回失败消息（如权限验证失败），要么在本地执行事务，写本地的 redo 和undo日志但不提交，可以进一步将准备阶段分为以下三步。（1）协调者节点向所有参与者节点询问是否可以执行提交操作（vote），并开始等待各参与者节点的响应。（2）参与者节点执行询问发起为止的所有事务操作，并将 undo 信息和 redo 信息写入日志。（3）各参与者节点响应协调者节点发起的询问。如果参与者节点的事务操作实际执行成功，则它返回一个“同意”消息；如果参与者节点的事务操作实际执行失败，则它返回一个“中止”消息。提交阶段指如果协调者收到了参与者的失败消息或者超时，则直接向每个参与者发送回滚（Rollback）消息，否则发送提交（Commit）消息，参与者根据协调者的指令执行提交或者回滚操作，释放所有事务在处理过程中使用的锁资源。二阶段提交所存在的缺点如下。（1）同步阻塞问题，在执行过程中所有参与节点都是事务阻塞型的，当参与者占用公共资源时，其他第三方节点访问公共资源时不得不处于阻塞状态。（2）单点故障，由于协调者的重要性，一旦协调者发生故障，则参与者会一直阻塞下去。（3）数据不一致，在二阶段提交的第 2 个阶段中，当协调者向参与者发送 commit 请求之后发生了局部网络异常或者在发送 commit 请求的过程中协调者发生了故障，则会导致只有一部分参与者接收到了 commit 请求，而在这部分参与者在接收到 commit 请求之后就会执行commit操作，其他部分未接收到 commit 请求的机器则无法执行事务提交，于是整个分布式系统便出现了数据不一致的现象。由于二阶段提交存在诸如同步阻塞、单点问题、数据不一致、宕机等缺陷，所以，研究者们在二阶段提交的基础上做了改进，提出了三阶段提交。
三阶段提交三阶段提交（Three-phase commit，3PC），也叫作三阶段提交协议（Three-phase commitprotocol），是二阶段提交（2PC）的改进版本。三阶段提交把二阶段提交的准备阶段再次一分为二，这样三阶段提交就有 CanCommit、PreCommit、DoCommit 三个阶段。（1）CanCommit 阶段：三阶段提交的 CanCommit 阶段其实和二阶段提交的准备阶段很像，协调者向参与者发送 commit 请求，参与者如果可以提交就返回 Yes 响应，否则返回 No 响应。（2）PreCommit 阶段：协调者根据参与者的反应情况来决定是否可以记录事务的 PreCommit操作。根据响应情况，有以下两种可能。
-假如协调者从所有参与者那里获得的反馈都是 Yes 响应，则执行事务。-假如有任何一个参与者向协调者发送了 No 响应，或者等待超时之后协调者都没有接到参与者的响应，则执行事务的中断。
（3）DoCommit阶段：该阶段进行真正的事务提交，也可以分为执行提交、中断事务两种执行情况。执行提交的过程如下。
-协调者接收到参与者发送的ACK响应后，将从预提交状态进入提交状态，并向所有参与者发送doCommit请求。-事务提交参与者接收到doCommit请求之后，执行正式的事务提交，并在完成事务提交之后释放所有的事务资源。-事务提交完之后，向协调者发送ACK响应。-协调者接收到所有参与者的ACK响应之后，完成事务。中断事务的过程如下。-协调者向所有参与者发送abort请求。-参与者接收到 abort 请求之后，利用其在第 2 个阶段记录的 undo 信息来执行事务的回滚操作，并在完成回滚之后释放所有的事务资源。-参与者完成事务回滚之后，向协调者发送 ACK 消息。-协调者接收到参与者反馈的 ACK 消息之后，执行事务的中断。
Mycat 中分布式事务的实现Mycat在1.6版本以后已经完全支持 XA 分布式强事务类型了，先通过一个简单的示例来了解Mycat中XA的用法。用户应用侧（AP）的使用流程如下：（1）set autocommit=0在应用层需要设置事务不能自动提交；（2）set xa=on在 SQL 中设置 XA 为开启状态；（3）执行 SQLinsert into travelrecord(id,name) values(1,’N’),(6000000,’A’),(321,’D’),(,’C’),(59,’E’);（4）commit 或者 rollback对事务进行提交（提交成功或者回滚异常）。完整的流程图如图所示。Mycat 内部实现侧的实现流程如下：（1）set autocommit=0将 MysqlConnection 中的 autocommit 设置为 false；（2）set xa=on在Mycat中开启 XA 事务管理器，用 MycatServer.getInstance().genXATXID()生成 XID，用XA START XID 命令进行 XA 事务开始标记，继续拼装 SQL 业务（Mycat 会将上面的 insert 数据分片到不同的节点上），拼装 XA END XID，XA PREPARE XID 最后进行 1pc 提交并记录日志到 tm.log 中，如果 1pc 阶段有异常，则直接回滚事务 XA ROLLBACK xid。（3）在多节点 MySQL 中全部进行 2pc 提交（XA COMMIT），提交成功后，事务结束；如果有异常，则对事务进行重新提交或者回滚。Mycat 中的 XA 分布式事务的异常处理流程如下：（1）一阶段 commit 异常：如果 1pc 提交任意一个 mysql 节点无法提交或者异常，则全部节点的事务进行回滚，抛出异常给应用侧事务回滚。（2）Mycat Crash RecoveryMycat 崩溃以后，根据 tm.log 事务日志再进行重启恢复，mycat 启动后执行事务日志查找各个节点中已经 prepared 的 XA 事务，进行 commit 或者 rollback。
1. 相关类说明通过用户应用侧发送 set xa = SQL 开启 Mycat 内部 XA 事务管理器的功能，事务管理器将对 MySQL 数据库进行 XA 方式的事务管理，具体事务管理功能的实现代码如下：·MySQLConnection：数据库连接。·NonBlockingSession：用户连接 Session。·MultiNodeCoordinator：协调者。·CommitNodeHandler：分片提交处理。·RollbackNodeHandler：分片回滚处理。
2. 代码解析XA 事务启动的源码如下：
public class MySQLConnection extends BackendAIOConnection {
//设置开启事务
private void getAutocommitCommand(StringBuilder sb, boolean autoCommit) {
if (autoCommit) {
sb.append("SET autocommit=1;");
sb.append("SET autocommit=0;");
public void execute(RouteResultsetNode rrn, ServerConnection sc,boolean autocommit) throws UnsupportedEncodingException {
if(!modifiedSQLExecuted && rrn.isModifySQL()) {
modifiedSQLExecuted =
//获取当前事务 ID
String xaTXID = sc.getSession2().getXaTXID();
synAndDoExecute(xaTXID, rrn, sc.getCharsetIndex(), sc.getTxIsolation(),autocommit);
……//省略此处代码，建议读者参考 GitHub 仓库的 MyCAT-Server 项目的 MySQLConnection.java源码
用户应用侧设置手动提交以后，Mycat 会在当前连接中加入SET autocommit=0;将该语句加入到 StringBuffer 中，等待提交到数据库。用户连接 Session 的源码如下：
public class NonBlockingSession implements Session {
……//省略此处代码，建议读者参考 GitHub 仓库的 MyCAT-Server 项目的 NonBlockingSession.java 源码
SET XA = ON ;语句分析用户应用侧发送该语句到 Mycat 中，由 SQL 语句解析器解析后交由 SetHandle 进行处理c.getSession2().setXATXEnabled (true);调用 NonBlockSession 中的 setXATXEnable d 方法设置 XA 开关启动，并生成 XID,代码如下：
public void setXATXEnabled(boolean xaTXEnabled) {
LOGGER.info("XA Transaction enabled ,con " + this.getSource());
if (xaTXEnabled && this.xaTXID == null) {
xaTXID = genXATXID();
另外，NonBlockSession 会接收来自于用户应用侧的 commit, 调用 commit 方法进行处理事务提交的逻辑。在 commit()方法中，首先会 check 节点个数，一个节点和多个节点分为不同的处理过程，这里只讲下多个节点的处理方法 checkDistriTransaxAndExecute();该方法会对多个节点的事务进行提交。协调者的源码如下：
public class MultiNodeCoordinator implements ResponseHandler {
……//省略此处代码，建议读者参考 GitHub 仓库 MyCAT-Server 项目的 MultiNodeCoordinator.java 源码
在 NonBlockSession 的 checkDistriTransaxAndExecute()方法中， NonBlockSession 会话类会调用专门进行多节点协同的 MultiNodeCoordinator 类进行具体的处理，在 MultiNodeCoordinator类中，executeBatchNodeCmd 方法加入 XA 1PC 提交的处理，代码片段如下：
for (RouteResultsetNode rrn : session.getTargetKeys()) {
if (mysqlCon.getXaStatus() == TxState.TX_STARTED_STATE){
//recovery Log
participantLogEntry[started] = new
ParticipantLogEntry(xaTxId,conn.getHost(),0,conn.getSchema(),((MySQLConnection) conn).getXaStatus());
String[] cmds = new String[]{"XA END " + xaTxId,"XA PREPARE " + xaTxId};
if (LOGGER.isDebugEnabled()) {
LOGGER.debug("Start execute the batch cmd : "+ cmds[0] + ";" +cmds[1]+","+"current connection:"+conn.getHost()+":"+conn.getPort());
mysqlCon.execBatchCmd(cmds);
在 MultiNodeCoordinator 类的 okResponse 方法中，则进行 2pc 的事务提交
MySQLConnection mysqlCon = (MySQLConnection)
switch (mysqlCon.getXaStatus()){
case TxState.TX_STARTED_STATE:
if (mysqlCon.batchCmdFinished()){
String xaTxId = session.getXaTXID();
String cmd = "XA COMMIT " + xaTxId;
if (LOGGER.isDebugEnabled()) {
LOGGER.debug("Start execute the cmd :"+cmd+",current host:"+mysqlCon.getHost()+":"+mysqlCon.getPort());
//recovery log
CoordinatorLogEntry coordinatorLogEntry =inMemoryRepository.get(xaTxId);
for(int i=0; i&coordinatorLogEntry.participants.i++){
LOGGER.debug("[In MemoryCoordinatorLogEntry]"+coordinatorLogEntry.participants[i]);
if(coordinatorLogEntry.participants[i].resourceName.equals(conn.getSchema())){
coordinatorLogEntry.participants[i].txState =TxState.TX_PREPARED_STATE;
inMemoryRepository.put(session.getXaTXID(),coordinatorLogEntry);
fileRepository.writeCheckpoint(inMemoryRepository.getAllCoordinatorLogEntries());
//send commit
mysqlCon.setXaStatus(TxState.TX_PREPARED_STATE);
mysqlCon.execCmd(cmd);
分片事务提交处理的源码如下：
public class CommitNodeHandler implements ResponseHandler {
public void commit(BackendConnection conn) {
……//省略此处代码，建议读者参考 GitHub 仓库 MyCAT-Server 项目的 CommitNodeHandler.java源码
public void okResponse(byte[] ok, BackendConnection conn) {
……//省略此处代码，建议读者参考 GitHub 仓库的 MyCAT-Server 项目的 CommitNodeHandler.java 源码
在 Mycat 中同样支持单节点 MySQL 数据库的 XA 事务处理，在 CommitNodeHandler 类中就是对单节点的 XA 二阶段处理，处理方式与 MultiNodeCoordinator 类同，通过 commit 方法进行 1pc 的提交，而通过 okResponse 的方法进行 2pc 阶段的事务提交。分片事务回滚处理的源码如下：
public class RollbackNodeHandler extends MultiNodeHandler {
……//省略此处代码，建议读者参考 GitHub 仓库的 MyCAT-Server 项目的 RollbackNodeHandler.java 源码
在 RollbackNodeHandler 的 rollback 方法中加入了对 XA 事务的 rollback 处理，用户应用侧发起的 rollback 会在这个方法中进行处理。
for (final RouteResultsetNode node : session.getTargetKeys()) {
//support the XA rollback
MySQLConnection mysqlCon = (MySQLConnection)
if(session.getXaTXID()!=null) {
String xaTxId = session.getXaTXID();
mysqlCon.execCmd("XA END " + xaTxId + ";");
mysqlCon.execCmd("XA ROLLBACK " + xaTxId + ";");
conn.rollback();
同样，该方法会对所有的 MySQL 数据库节点发起 xa rollback 指令。
　　　　　　　　　　　　　 数据库客户端超时
在使用数据库客户端时，我们会使用数据库连接池，数据库连接池可以进行如下超时设置。
bean id=&dataSource& class=&org.apache.commons.dbcp...
小编说：本文从一个典型的案例入手来讲述Binlog中时间戳的原理和实践，通过本文你可以了解时间戳在Binlog中的作用及产生方法，以便在出现一些这方面怪异的问题时，做到心中有数，胸有成竹。本文选自《MySQL运维内参》 背景
管理员账号
小编说：Neo4j是一个NoSQL的图数据库管理系统，像其他NoSQL数据库一样具有高效的查询性能。同时，Neo4j还具有完全事务管理特性，完全支持ACID事务管理。Neo4j与其他数据库相比，具有哪些明显的优势呢？本文选自《Neo4...
管理员账号
版权所有& · 北京博文视点资讯有限公司 · All Rights Reserved
京ICP备号-1不妥协：分布式事务的一致性，可用性和性能 - 简书
不妥协：分布式事务的一致性，可用性和性能
本文是论文的读书笔记，水平有限，未能很好的读懂，惭愧。
本文是 Schedule: Spring 2016的第1课，前面课程内容可以在找到，更多详细资料可以到：查看。
如果事务具有强一致、高可用的特性，将大大的简化我们构建分布式应用的难度，但是在之前人们的认知中，分布式事务的设计一直表现的很糟糕，这就迫使在构建分布式系统的时候或者彻底不使用分布式事务，或者使用弱一致性，或者只使用单机事务，应用方通过数据分区来保证事务中的数据都落在一台机器上。
我想我们可以对上面的窘境说88了，在现代数据中心中，我们完全可以同时满足强一致、高可用、高性能。
本文会介绍FaRM（fast remote memory）系统，一个内存分布式计算平台。FaRM提供了如下的事务特性：
数据持久化
在90台机器4.9TB数据的情况下，在高峰时FaRM能达到1.4亿每秒的吞吐量（FaRM achieves a peak throughput of 140 million TATP transactions per second on 90 machines with a 4.9 TB database），并且能够在50ms内进行故障恢复。
而能达到如此性能的关键点是：
网络使用RDMA（Remote Direct Memory Access）
存储使用non-volatile DRAM
基于以上两个硬件上的改变，设计了全新的事务、数据复制和恢复协议。
我们希望分布式事务能达到的一个理想状态是：事务“在一台永不故障的机器上，事务的执行都是严格串行的”一样的效果。
但是之前的一些设计都存在缺陷，Dynamo和memcached为了提高性能要么是不支持事务，要么放弃了强一致，只提供弱一致的保证。另外一些设计则只能保证单机事务，跨机器的则无能为力。
本文提出的FaRM平台，通过使用
网络使用RDMA
存储使用non-volatile DRAM
解决了网络和存储的瓶颈，此时CPU的瓶颈出现了，FaRM在设计上遵循下面3条原则：
减少消息数量
使用RDMA进行数据的存取而不是消息
高效利用并发
FaRM允许数据分布在不同机器上，同时允许跨机器的分布式事务。FaRM通过使用vertical Paxos，而不是通过Paxos协议进行coordinators和数据的复制，此时副本是主-备，然后协调者是单个，不进行复制。FaRM使用4阶段的乐观提交协议（lock, validation, commit backup, and com- mit primary）。
FaRM通过使用RDMA来进一步减少CPU的负载，具体是：
在事务执行和验证阶段，通过RDMA进行读
coordinators通过RDMA将WAL(write-ahead logs)日志写入到副本中
因为使用RDMA不需要CPU参与，因此有效的减少了CPU的使用。
由于servers处理请求时不再需要CPU参与，因此传统的故障恢复（failure-recovery）协议不再适合FaRM，因为传统的租约模式需要server在收到请求后进行判断是否拒绝请求，但是现在请求直接通过网卡处理了，CPU无法干预了。
一个可能的解决方案是：precise membership，保证所有机器都在当前membership configuration上达成一致了，然后只会发送请求给组员。
另一个问题是FaRM不能再依赖于传统的2阶段提交中，prepare阶段需要participants对资源进行锁定，然后在commit阶段进行提交，因为此时servers写logs的时候不再经过CPU了。一个解决方案是：reservations，我们确保在提交之前，我们又足够的空间来存储commit的日志。
在FaRM中故障恢复策略快是因为有效的利用了并行。具体是FaRM将恢复的每个数据都均匀的分布上集群上，然后并行的对每台机器进行恢复。
另外，FaRM通过两点优化使得恢复过程中事务可以并行的执行：
只需等到几十毫秒的lock recovery阶段结束，就可以获取故障中的数据了，而无需花费几秒去等待lock recovery之后的恢复阶段
没有收到失败影响的事务无需等待直接执行
FaRM利用高速网络进行高频的心跳机制，实现了快速的失败探测，同时利用priorities 和 pre-allocation防止误判。
Largemain memory
Non-volatilememory
Fastnetwork with RDMA
编程模型和架构
Progamming Model
FaRM提供了如上图的一个抽象地址空间，在我们看来所有的数据都在一个全局的地址空间中，通过FaRM提供的API让我们能够透明的访问本地和远端的数据。
Distributedshared memory abstraction
FaRM APIprovides transparent access to local and remote objects
FaRM的编程模型总结起来，如下：
应用线程开启一个事务，同时变为协调者（coordinator）
在事务中，可以执行任何的逻辑：如read, write, allocate, and free objects
事务最后，告诉FaRM进行提交
FaRM Architecture
主备用户容错
配置管理器（configuration manager）：负责leases，detect failures， coordinate recovery
如何对地址进行寻址
前面提到FaRM将所有内存放到一起进行管理，那具体怎么操作呢？
内存以2GB进行划分，每个2GB称为一个region，然后每个region分布在一个primary，f个backup上
region到primary-backups关系保存在CM上
应用可以指定目标机器，新分配的region将在这些机器上
如何申请内存
CM通过2PC阶段和副本进行通信，申请region
在region可用前，mapping信息需要传递给所有副本
如何进行RAMD写
在读取上，每个机器都有一个ring buffer，实现了FIFO队列，在写的时候，sender通过RDMA直接写到尾部，然后NIC（网卡）直接给ACK，receiver周期性的从头部读取数据处理。
分布式事务和复制
前面的一篇论文提出的2PC提交会有一个问题，coordinate如果挂了或者participants挂了，会影响整个进程，因此一个想法就是进行primary-backup备份，保证高可用，于是就有下面的图：
这种主备的模式每次消息都需要和Primary和Backup同时交互，并且需要消耗CPU。
而FaRM在提交上使用：
one-sided RDMA进行操作
减少消息数量
使用OCC（乐观并发控制）
version number（用户读数据的版本验证）
整体流程：本地执行+锁写记录+验证读记录+提交并解锁
写lock record到写数据的primary上
primary尝试着锁住记录，然后进行回应
通过RDMA进行读，然后比较version是否改变了
Commit backups
通过RDMA写log到所有backups
coordinate等待所有backups回复
commit primaries
通过RDMA写commit-primary记录到每个primary
primary处理记录，然后unlock
只要coordinator收到一个primary的NIC回复，就认为成功，返回给应用
coordinator收到所有primary的回复后，进行truncate
在提交其他日志的时候，捎带上truncate
backups在truncation的时候，进行数据的更新操作
这是6.824: Distributed Systems的第11课，你的鼓励是我继续写下去的动力，期待我们共同进步。
专注大规模分布式系统开发，紧跟人工智能浪潮
本文由厦门大学计算机系教师林子雨翻译，翻译质量很高，本人只对极少数翻译得不太恰当的地方进行了修改。 【摘要】:Spanner 是谷歌公司研发的、可扩展的、多版本、全球分布式、同步复制数据库。它是第一个把数据分布在全球范围内的系统，并且支持外部一致性的分布式事务。本文描述了 ...
X399平台点睛之笔ZENITHEXTREME引爆性能狂潮 近期，X399平台的顶级性能浮出水面，各家媒体的全方位测试犹如一支强心剂，让PC玩家大呼过瘾。我们惊喜地发现，国内外各大科技媒体一致选用了ROGZENITH EXTREME这款主板。它是华硕目前最顶级的X399芯片...
分布式系统面临的第一个问题就是数据分布，即将数据均匀地分布到多个存储节点。另外，为了保证可靠性和可用性，需要将数据复制多个副本，这就带来了多个副本之间的数据一致性问题。大规模分布式存储系统的重要目标就是节省成本，因而只能采用性价比较高的PC服务器。这些服务器性能很好，但是故...
转载自己该篇文章的微信版本链接 文章摘要：原来大型分布式/微服务系统中解决数据一致性问题，居然是通过…… 一、为什么要使用分布式事务—2PC？ 传统事务是使用数据库自身的事务属性（ACID），而数据库自身的事务属性是局限于当前实例，不能实现跨库。而对于大型分布式/微服务集群...
从各个角度总结了电商平台中的架构实践，由于时间仓促，定了个初稿，待补充完善，欢迎大家一起交流。 转载请声明出处：http://blog.csdn.net/yangbutao/article/details/ 作者：杨步涛 关注分布式架构、大数据、搜索、开源技...
“本文参加#感悟三下乡，青春筑梦行#活动，本人承诺，文章内容为原创，且未在其他平台发表过。”
中国现代著名作家巴金说：“青春是美丽的东西，而且对我来说，它永远是鼓舞的源泉。”而中国著名小说家李准也说：“青春是一个不可思议的伟大力量。它催发着青年人的躯体，启迪着他们的...
于《奇葩说》，早有耳闻，前三季陆续看过几集，有共鸣，未特别关注。 这次，完全是因了瑜老板在《奇葩大会》的出场，捎带着看了前后几位”奇葩“或大家的各种高见，欲罢不能，也就把本季《奇葩大会》的两期看了个遍，知道了这个名字——蔡聪。 他的演说，我先把原话整理成文字稿辑录下来，再来...
在我的记忆中，最深刻的童年时光，是我在老家里读学前班的时候。那时候的我很不听话，在我七岁的时，我爸说要送我去上幼儿园，结果我却坚持回老家读学前班，想想还真的是挺有意思的，有着好的教育环境不去，却要回到那个小山村里。 只是，经历过后，我却不后悔自己的选择。如果我不回去，就经历...
日，奥田集成灶与湖南消费者如期相约湖南国际会展中心。此次，奥田不仅选择了湖南及华中地区规模最大、专业化、现代化、智能化的会展场馆，还与会展中心合作，承租了4500平米的大会场！ 奥田在会场中建立了产品展示区，休闲娱乐区，活动互动区等多个区域，并请来湖南当地...
属性动画，快速打造，练手用 预览图： 一、制作圆形图标 很方便地利用as自动生成圆形图标： 右击res，选择Image Asset: 选择Launcher Icons，然后选Square,其余自己调整： 现在，mipmap中有了相关图片~~当然，普通icon加个shape也...