精华内容
下载资源
问答
  • 2018-05-04 12:05:29

    这次在下介绍的是OLAP与OLTP的概念,以及它们为什么要分开。如有谬误,还请斧正。

    OLTP与OLAP的概念:

    我们平时使用的数据库是关系型数据库,也是一种操作型数据库。

    联机操作型数据库,是指利用网络连接不同地理位置的操作型数据库。

    联机事务处理(OLTP)系统,是指执行联机事务和查询处理的联机操作数据库系统。

    OLTP主要完成库存、记录、查询等事务。

    而另一方面,还存在一种数据库,它用于存储集成的、过往的、完整的历史数据,是企业战略决策的物理实现,这种数据库叫“数据仓库”,它能用不同的格式组织和提供数据,能满足用户复杂、多样的需求。

    这样的数据仓库系统,叫做联机分析处理(OLAP)系统。

    什么叫集成的数据呢,这是指从文件、操作型数据库、网页等外部数据源取出数据,统一格式,存入数据仓库。

    数据仓库中一般不存放最新数据,而是“历史数据”,其作用是被用来分析、预测未来趋势。OLAP系统一般是只读的。


    为什么不直接在操作数据库上进行联机分析处理?

    因为OLAP的查询通常非常复杂,需要在更高层做大量的汇总,例如我想知道上一个季度某产品在某地的销量相对于该季度历史销量平均值的变化如何(这个可能都还不算复杂吧),这些奇形怪状的需求对于善于处理已知查询事务的OLTP来讲,是很降低查询性能的,而且,如果将操作数据库系统的并发控制和恢复用于只读的OLAP操作,将会降低OLTP的吞吐量。

    另外很重要的一点就是,数据仓库和操作型数据库的结构、内容、用法不同,相对于维护了大量历史数据的百兆兆字节量级数据仓库,哪怕是存储了大量信息的操作型数据库,也是不足以用来决策的。

    更多相关内容
  • 事务处理:概念与技术

    热门讨论 2013-05-28 22:35:15
    事务处理广泛地应用于数据库和操作系统领域,并在现代计算机系统中监控、控制和更新信息。本书向读者展示了大型的、分布的、异构的计算机系统是如何进行可靠工作的。作者使用事务作为基本概念,说明了在有限的资金和...
  • 事务处理原理 第2版

    热门讨论 2012-12-30 10:49:38
    应用程序编程人员希望不受运行事务处理系统所要求的众多复杂的不同类型技术(如事务协议、消息协议、事务远程过程调用、持久性队列、多线程进程、资源池、会话管理和复制协议)的影响。应用程序编程人员的工作是理解...
  • 分布式系统常见的事务处理机制

    千次阅读 2017-04-14 00:11:46
    为保障系统的可用性、可靠性以及性能,在分布式系统中,往往会设置数据冗余,即对数据进行复制。举例来说,当一个数据库的副本...但同时,如何保障多个数据节点之间数据的一致以及如何处理分布式事务,将成为为一个复杂

    原文同步至https://waylau.com/distributed-system-transaction/

    为保障系统的可用性、可靠性以及性能,在分布式系统中,往往会设置数据冗余,即对数据进行复制。举例来说,当一个数据库的副本被破环以后,那么系统只需要转换到其他数据副本就能继续运行下去。另外一个例子,当访问单一服务器管理的数据的进程数不断增加时,系统就需要对服务器的数量进行扩充,此时,对服务器进行复制,随后让它们分担工作负荷,就可以提高性能。但同时,如何保障多个数据节点之间数据的一致以及如何处理分布式事务,将成为为一个复杂的话题。本文将介绍常用的事务处理机制。

    CAP 定理

    CAP 定理(也称为 Brewer 定理),是由计算机科学家 Eric Brewer 提出的,即在分布式计算机系统不可能同时提供以下全部三个保证:

    • 一致性(Consistency):所有节点同一时间看到是相同的数据;
    • 可用性(Availability):不管是否成功,确保每一个请求都能接收到响应;
    • 分区容错性(Partition tolerance):系统任意分区后,在网络故障时,仍能操作

    显然,为了保障性能和可靠性,我们将数据复制多份,分布到多个节点上,同时也带来了一个难点,那就是如何保持各个副本数据的一致性。换句话说,我们选择了 AP ,则必须要牺牲掉 C 了。

    但是,在实际的应用场景中,数据的一致性往往也是需要保证的。那么这是否违背了 CAP 定理呢?

    一致性模型

    其实,数据的一致性也分几种情况,大致可以分为:

    • Weak 弱一致性:当你写入一个新值后,读操作在数据副本上可能读出来,也可能读不出来。比如:某些存储系统,搜索引擎,实时游戏,语音聊天等,这些数据本文对完整性要求不高,数据是否一致关系也不大。
    • Eventually 最终一致性:当你写入一个新值后,并不一定能马上读出来,但在某个时间窗口之后保证最终能读出来。比如:DNS,电子邮件,消息中间件等系统,大部分分布式系统技术都采用这类模式。
    • Strong 强一致性:新的数据一旦写入,在任意副本任意时刻都能读到新值。比如:文件系统,RDBMS都是强一致性的。

    也就是说,在设计分布式系统时,我们并不一定要求是强一致性的,根据应用场景可以选择弱一致性或者是最终一致性。

    事务的作用

    事务有如下作用:

    • 保证执行结果的正确性
    • 保证数据的一致性
    • ACID

    常见的事务处理机制

    Master-Slave 复制

    Slave 一般是 Master 的备份。在这样的系统中,一般是如下设计的:

    • 读写请求都由 Master 负责。
    • 写请求写到 Master 上后,由 Master 同步到 Slave 上。

    这种机制的特点是:

    • 数据同步通常是异步的
    • 有良好的吞吐量,低延迟
      * 在大多数 RDBMS 中支持,比如 MySQL二进制日志
    • 弱/最终一致性

    这种机制的缺点是,如果 Master 挂了,Slave 只能提供读服务,而没有写服务。

    Master-Master 多主复制

    指一个系统存在两个或多个Master,每个Master都提供读写服务。这个机制是Master-Slave的加强版,数据间同步一般是通过Master间的异步完成,所以是最终一致性。 Master-Master的好处是,一台Master挂了,别的Master可以正常做读写服务,他和Master-Slave一样,当数据没有被复制到别的Master上时,数据会丢失。很多数据库都支持Master-Master的Replication的机制。

    这种机制的特点是:

    • 异步
    • 最终的一致性
    • 多个节点间需要序列化协议

    两阶段提交

    两阶段提交协议 (Two-phase commit protocol,2PC)的过程涉及到协调者和参与者。协调者可以看做成事务的发起者,同时也是事务的一个参与者。对于一个分布式事务来说,一个事务是涉及到多个参与者的。具体的两阶段提交的过程如下:

    第一阶段(准备阶段)

    • 协调者节点向所有参与者节点询问是否可以执行提交操作(vote),并开始等待各参与者节点的响应。
    • 参与者节点执行询问发起为止的所有事务操作,并将 Undo 信息和 Redo 信息写入日志。(注意:若成功这里其实每个参与者已经执行了事务操作)
    • 各参与者节点响应协调者节点发起的询问。如果参与者节点的事务操作实际执行成功,则它返回一个“同意”消息;如果参与者节点的事务操作实际执行失败,则它返回一个“中止”消息。

    第二阶段(提交阶段)

    如果协调者收到了参与者的失败消息或者超时,直接给每个参与者发送回滚(Rollback)消息;否则,发送提交(Commit)消息;参与者根据协调者的指令执行提交或者回滚操作,释放所有事务处理过程中使用的锁资源。(注意:必须在最后阶段释放锁资源)

    • 当协调者节点从所有参与者节点获得的相应消息都为“同意”时:
      • 协调者节点向所有参与者节点发出“正式提交(commit)”的请求。
      • 参与者节点正式完成操作,并释放在整个事务期间内占用的资源。
      • 参与者节点向协调者节点发送“完成”消息。
    • 如果任一参与者节点在第一阶段返回的响应消息为”中止”,或者 协调者节点在第一阶段的询问超时之前无法获取所有参与者节点的响应消息时:
      • 协调者节点向所有参与者节点发出”回滚操作(rollback)”的请求。
      • 参与者节点利用之前写入的Undo信息执行回滚,并释放在整个事务期间内占用的资源。
      • 参与者节点向协调者节点发送”回滚完成”消息。
      • 协调者节点受到所有参与者节点反馈的”回滚完成”消息后,取消事务。
      • 协调者节点受到所有参与者节点反馈的”完成”消息后,完成事务

    不管最后结果如何,第二阶段都会结束当前事务。

    二段式提交协议的优缺点:

    优点:原理简单,实现方便;

    缺点:

    • 同步阻塞问题。执行过程中,所有参与节点都是事务阻塞型的。
    • 单点故障。由于协调者的重要性,一旦协调者发生故障,参与者会一直阻塞下去。尤其在第二阶段,协调者发生故障,那么所有的参与者还都处于锁定事务资源的状态中,而无法继续完成事务操作。
    • 数据不一致。在阶段二中,当协调者向参与者发送 commit 请求之后,发生了局部网络异常或者在发送 commit 请求过程中协调者发生了故障,这回导致只有一部分参与者接受到了 commit 请求。而在这部分参与者接到 commit 请求之后就会执行 commit 操作。但是其他部分未接到 commit 请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据部一致性的现象。
    • 二阶段无法解决的问题:协调者再发出 commit 消息之后宕机,而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者,这条事务的状态也是不确定的,没人知道事务是否被已经提交。

    为了解决两阶段提交协议的种种问题,研究者们在二阶段提交的基础上做了改进,提出了三阶段提交。

    三阶段提交

    三阶段提交协议(Three-phase commit protocol,3PC),是二阶段提交(2PC)的改进版本。与两阶段提交不同的是,三阶段提交有两个改动点:

    • 引入超时机制。同时在协调者和参与者中都引入超时机制。
    • 在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的。

    即 3PC 把 2PC 的准备阶段再次一分为二,这样三阶段提交就有 CanCommit、PreCommit、DoCommit 三个阶段。

    CanCommit 阶段

    CanCommit 阶段其实和 2PC 的准备阶段很像。协调者向参与者发送 commit 请求,参与者如果可以提交就返回 Yes 响应,否则返回 No 响应。

    • 事务询问:协调者向参与者发送 CanCommit 请求。询问是否可以执行事务提交操作。然后开始等待参与者的响应。
    • 响应反馈:参与者接到 CanCommit 请求之后,正常情况下,如果其自身认为可以顺利执行事务,则返回 Yes 响应,并进入预备状态。否则反馈 No

    PreCommit 阶段

    协调者根据参与者的反应情况来决定是否可以记性事务的 PreCommit 操作。根据响应情况,有以下两种可能。

    • 假如协调者从所有的参与者获得的反馈都是 Yes 响应,那么就会执行事务的预执行。
      • 发送预提交请求:协调者向参与者发送 PreCommit 请求,并进入Prepared 阶段。
      • 事务预提交:参与者接收到 PreCommit 请求后,会执行事务操作,并将undo 和 redo 信息记录到事务日志中。
      • 响应反馈:如果参与者成功的执行了事务操作,则返回 ACK 响应,同时开始等待最终指令。
    • 假如有任何一个参与者向协调者发送了 No 响应,或者等待超时之后,协调者都没有接到参与者的响应,那么就执行事务的中断。
    • 发送中断请求:协调者向所有参与者发送 abort 请求。
    • 中断事务:参与者收到来自协调者的 abort 请求之后(或超时之后,仍未收到协调者的请求),执行事务的中断。

    doCommit 阶段

    该阶段进行真正的事务提交,也可以分为以下两种情况。

    • 执行提交
      • 发送提交请求:协调接收到参与者发送的 ACK 响应,那么他将从预提交状态进入到提交状态。并向所有参与者发送 doCommit 请求。
      • 事务提交:参与者接收到 doCommit 请求之后,执行正式的事务提交。并在完成事务提交之后释放所有事务资源。
      • 响应反馈:事务提交完之后,向协调者发送 ACK 响应。
      • 完成事务:协调者接收到所有参与者的 ACK 响应之后,完成事务。
    • 中断事务:协调者没有接收到参与者发送的 ACK 响应(可能是接受者发送的不是 ACK 响应,也可能响应超时),那么就会执行中断事务。
      • 发送中断请求:协调者向所有参与者发送 abort 请求
      • 事务回滚:参与者接收到 abort 请求之后,利用其在阶段二记录的undo 信息来执行事务的回滚操作,并在完成回滚之后释放所有的事务资源。
      • 反馈结果:参与者完成事务回滚之后,向协调者发送 ACK 消息
      • 中断事务:协调者接收到参与者反馈的 ACK 消息之后,执行事务的中断。

    在 doCommit 阶段,如果参与者无法及时接收到来自协调者的 doCommit 或者 rebort 请求时,会在等待超时之后,会继续进行事务的提交。即当进入第三阶段时,由于网络超时等原因,虽然参与者没有收 到 commit 或者 abort 响应,事务仍然会提交。

    三阶段提交不会一直持有事务资源并处于阻塞状态。但是这种机制也会导致数据一致性问题,因为,由于网络原因,协调者发送的 abort 响应没有及时被参与者接收到,那么参与者在等待超时之后执行了 commit 操作,这样就和其他接到 abort 命令并执行回滚的参与者之间存在数据不一致的情况。

    Paxos 算法

    Paxos 算法是 Leslie Lamport 于1990年提出的一种基于消息传递且具有高度容错特性的一致性算法。Paxos 算法目前在 Google 的 Chubby、MegaStore、Spanner 等系统中得到了应用,Hadoop 中的 ZooKeeper 也使用了 Paxos 算法。

    在 Paxos 算法中,分为4种角色:

    • Proposer :提议者
    • Acceptor:决策者
    • Client:产生议题者
    • Learner:最终决策学习者

    算法可以分为两个阶段来执行:

    阶段1

    • Proposer 选择一个议案编号 n,向 acceptor 的多数派发送编号也为 n 的 prepare 请求。
    • Acceptor:如果接收到的 prepare 请求的编号 n 大于它已经回应的任何prepare 请求,它就回应已经批准的编号最高的议案(如果有的话),并承诺不再回应任何编号小于 n 的议案;

    阶段2

    • Proposer:如果收到了多数 acceptor 对 prepare 请求(编号为 n)的回应,它就向这些 acceptor 发送议案{n, v}的 accept 请求,其中 v 是所有回应中编号最高的议案的决议,或者是 proposer 选择的值,如果回应说还没有议案。
    • Acceptor:如果收到了议案{n, v}的 accept 请求,它就批准该议案,除非它已经回应了一个编号大于 n 的议案。
    • Proposer 可以提出多个议案,只要它遵循上面的算法。它可以在任何时刻放弃一个议案。(这不会破坏正确性,即使在议案被放弃后,议案的请求或者回应消息才到达目标)如果其它的 proposer 已经开始提出更高编号的议案,那么最好能放弃当前的议案。因此,如果 acceptor 忽略一个 prepare 或者 accept 请求(因为已经收到了更高编号的 prepare 请求),它应该告知 proposer 放弃议案。这是一个性能优化,而不影响正确性。

    参考文献

    展开全文
  • SQLite的事务处理

    千次阅读 2019-05-23 11:30:25
    原文转载:SQLite事务(Transcation)/BUNOOB.COM 概述:SQLite事务(Transaction) ...重要的是要控制事务以确保数据的完整性和处理数据库错误。 将许多SQLite查询联合成一组,并作为事务的一部分进行执...

    原文转载:SQLite事务(Transcation)/BUNOOB.COM

    • 概述:SQLite事务(Transaction)
    1. 事务是一个对数据库执行工作单元,是以逻辑顺序完成的工作单位或序列,可以由用户手动操作完成,也可由数据库程序自动完成。
    2. 事务是指一个或多个更改数据库的扩展。重要的是要控制事务以确保数据的完整性和处理数据库错误
    3. 将许多SQLite查询联合成一组,并作为事务的一部分进行执行。
    • 事务的属性
    1. 原子性(Atomicity):确保工作单位内的所有操作都成功完成,否则,事务会在出现故障时终止,之前的操作也会回滚到以前的状态。
    2. 一致性(Consistency):确保数据库在成果提交的事务上正确的改变状态。
    3. 隔离性(lsolation):使事务操作相互独立和透明。
    4. 持久性(Durability):确保已提交事务的结果或效果在系统发生故障的情况下仍存在。
    • 事务控制指令
    1. BEGIN TRANSACTION:开始事务处理,会持续进行直到遇到下一个COMMIT或ROLLBACK命令。在数据库关闭或出现错误时,仍会回滚。
      BEGIN;
      
      OR 
      
      BEGIN TRANSCATION;

       

    2. COMMIT:保存更改,或者可以使用END TRANSACTION命令
      COMMIT;
      
      OR
      
      END TRANSCATION

       

    3. ROLLBACK:回滚所做的更改
      ROLLBACK;

       

    4. 事务控制指令只能和DML命令INSERT、UPDATA、DELETE结合使用。不能再创建表和删除表时使用,因为这些操作在数据库中是自动提交的。
    • 使用流程,简单的代码结构及与SQL的DML结合
      sqlite3* db;
      char* errMSG=0;
      int rc;
      rc=sqlite3_open("dt.db",&db);
      if(rc){
          ERROR BLOCK;
      }
      
      sqlite3_exec(db,"BEGIN;",0,0,&errMSG);        ///开启事务
      
      ///database MDL操作。
      
      
      if(MDL执行成功(flag))
      {
          sqlite3_exec(db,"COMMIT",0,0,0);        ///提交事务
      }else
      {
          sqlite3_exec(db,"ROLLBACK",0,0,0)        ///回滚
      }

     

     

     

     

    展开全文
  • 看到耗子叔这篇对于分布式事务处理的几种方式写的很清晰,原文:https://coolshell.cn/articles/10910.html 当我们在生产线上用一台服务器来提供数据服务的时候,我会遇到如下的两个问题: 1)一台服务器的性能不...

    看到耗子叔这篇对于分布式事务处理的几种方式写的很清晰,原文:https://coolshell.cn/articles/10910.html

    当我们在生产线上用一台服务器来提供数据服务的时候,我会遇到如下的两个问题:

    1)一台服务器的性能不足以提供足够的能力服务于所有的网络请求。

    2)我们总是害怕我们的这台服务器停机,造成服务不可用或是数据丢失。

    于是我们不得不对我们的服务器进行扩展,加入更多的机器来分担性能上的问题,以及来解决单点故障问题。 通常,我们会通过两种手段来扩展我们的数据服务:

    1)数据分区:就是把数据分块放在不同的服务器上(如:uid % 16,一致性哈希等)。

    2)数据镜像:让所有的服务器都有相同的数据,提供相当的服务。

    对于第一种情况,我们无法解决数据丢失的问题,单台服务器出问题时,会有部分数据丢失。所以,数据服务的高可用性只能通过第二种方法来完成——数据的冗余存储(一般工业界认为比较安全的备份数应该是3份,如:Hadoop和Dynamo)。 但是,加入更多的机器,会让我们的数据服务变得很复杂,尤其是跨服务器的事务处理,也就是跨服务器的数据一致性。这个是一个很难的问题。 让我们用最经典的Use Case:“A帐号向B帐号汇钱”来说明一下,熟悉RDBMS事务的都知道从帐号A到帐号B需要6个操作:

    1. 从A帐号中把余额读出来。
    2. 对A帐号做减法操作。
    3. 把结果写回A帐号中。
    4. 从B帐号中把余额读出来。
    5. 对B帐号做加法操作。
    6. 把结果写回B帐号中。

    为了数据的一致性,这6件事,要么都成功做完,要么都不成功,而且这个操作的过程中,对A、B帐号的其它访问必需锁死,所谓锁死就是要排除其它的读写操作,不然会有脏数据的问题,这就是事务。那么,我们在加入了更多的机器后,这个事情会变得复杂起来:

    1)在数据分区的方案中:如果A帐号和B帐号的数据不在同一台服务器上怎么办?我们需要一个跨机器的事务处理。也就是说,如果A的扣钱成功了,但B的加钱不成功,我们还要把A的操作给回滚回去。这在跨机器的情况下,就变得比较复杂了。

    2)在数据镜像的方案中:A帐号和B帐号间的汇款是可以在一台机器上完成的,但是别忘了我们有多台机器存在A帐号和B帐号的副本。如果对A帐号的汇钱有两个并发操作(要汇给B和C),这两个操作发生在不同的两台服务器上怎么办?也就是说,在数据镜像中,在不同的服务器上对同一个数据的写操作怎么保证其一致性,保证数据不冲突?

    同时,我们还要考虑性能的因素,如果不考虑性能的话,事务得到保证并不困难,系统慢一点就行了。除了考虑性能外,我们还要考虑可用性,也就是说,一台机器没了,数据不丢失,服务可由别的机器继续提供。 于是,我们需要重点考虑下面的这么几个情况:

    1)容灾:数据不丢、结点的Failover

    2)数据的一致性:事务处理

    3)性能:吞吐量 、 响应时间

    前面说过,要解决数据不丢,只能通过数据冗余的方法,就算是数据分区,每个区也需要进行数据冗余处理。这就是数据副本:当出现某个节点的数据丢失时可以从副本读到,数据副本是分布式系统解决数据丢失异常的唯一手段。所以,在这篇文章中,简单起见,我们只讨论在数据冗余情况下考虑数据的一致性和性能的问题。简单说来:

    1)要想让数据有高可用性,就得写多份数据。

    2)写多份的问题会导致数据一致性的问题。

    3)数据一致性的问题又会引发性能问题

    这就是软件开发,按下了葫芦起了瓢。

    一致性模型

    说起数据一致性来说,简单说有三种类型(当然,如果细分的话,还有很多一致性模型,如:顺序一致性,FIFO一致性,会话一致性,单读一致性,单写一致性,但为了本文的简单易读,我只说下面三种):

    1)Weak 弱一致性:当你写入一个新值后,读操作在数据副本上可能读出来,也可能读不出来。比如:某些cache系统,网络游戏其它玩家的数据和你没什么关系,VOIP这样的系统,或是百度搜索引擎(呵呵)。

    2)Eventually 最终一致性:当你写入一个新值后,有可能读不出来,但在某个时间窗口之后保证最终能读出来。比如:DNS,电子邮件、Amazon S3,Google搜索引擎这样的系统。

    3)Strong 强一致性:新的数据一旦写入,在任意副本任意时刻都能读到新值。比如:文件系统,RDBMS,Azure Table都是强一致性的。

    从这三种一致型的模型上来说,我们可以看到,Weak和Eventually一般来说是异步冗余的,而Strong一般来说是同步冗余的,异步的通常意味着更好的性能,但也意味着更复杂的状态控制。同步意味着简单,但也意味着性能下降。 好,让我们由浅入深,一步一步地来看有哪些技术:

    Master-Slave

    首先是Master-Slave结构,对于这种加构,Slave一般是Master的备份。在这样的系统中,一般是如下设计的:

    1)读写请求都由Master负责。

    2)写请求写到Master上后,由Master同步到Slave上。

    从Master同步到Slave上,你可以使用异步,也可以使用同步,可以使用Master来push,也可以使用Slave来pull。 通常来说是Slave来周期性的pull,所以,是最终一致性。这个设计的问题是,如果Master在pull周期内垮掉了,那么会导致这个时间片内的数据丢失。如果你不想让数据丢掉,Slave只能成为Read-Only的方式等Master恢复。

    当然,如果你可以容忍数据丢掉的话,你可以马上让Slave代替Master工作(对于只负责计算的结点来说,没有数据一致性和数据丢失的问题,Master-Slave的方式就可以解决单点问题了) 当然,Master Slave也可以是强一致性的, 比如:当我们写Master的时候,Master负责先写自己,等成功后,再写Slave,两者都成功后返回成功,整个过程是同步的,如果写Slave失败了,那么两种方法,一种是标记Slave不可用报错并继续服务(等Slave恢复后同步Master的数据,可以有多个Slave,这样少一个,还有备份,就像前面说的写三份那样),另一种是回滚自己并返回写失败。(注:一般不先写Slave,因为如果写Master自己失败后,还要回滚Slave,此时如果回滚Slave失败,就得手工订正数据了)你可以看到,如果Master-Slave需要做成强一致性有多复杂。

    Master-Master

    Master-Master,又叫Multi-master,是指一个系统存在两个或多个Master,每个Master都提供read-write服务。这个模型是Master-Slave的加强版,数据间同步一般是通过Master间的异步完成,所以是最终一致性。 Master-Master的好处是,一台Master挂了,别的Master可以正常做读写服务,他和Master-Slave一样,当数据没有被复制到别的Master上时,数据会丢失。很多数据库都支持Master-Master的Replication的机制。

    另外,如果多个Master对同一个数据进行修改的时候,这个模型的恶梦就出现了——对数据间的冲突合并,这并不是一件容易的事情。看看Dynamo的Vector Clock的设计(记录数据的版本号和修改者)就知道这个事并不那么简单,而且Dynamo对数据冲突这个事是交给用户自己搞的。就像我们的SVN源码冲突一样,对于同一行代码的冲突,只能交给开发者自己来处理。(在本文后后面会讨论一下Dynamo的Vector Clock)

    Two/Three Phase Commit

    这个协议的缩写又叫2PC,中文叫两阶段提交。在分布式系统中,每个节点虽然可以知晓自己的操作时成功或者失败,却无法知道其他节点的操作的成功或失败。当一个事务跨越多个节点时,为了保持事务的ACID特性,需要引入一个作为协调者的组件来统一掌控所有节点(称作参与者)的操作结果并最终指示这些节点是否要把操作结果进行真正的提交(比如将更新后的数据写入磁盘等等)。 两阶段提交的算法如下:

    第一阶段

    1. 协调者会问所有的参与者结点,是否可以执行提交操作。
    2. 各个参与者开始事务执行的准备工作:如:为资源上锁,预留资源,写undo/redo log……
    3. 参与者响应协调者,如果事务的准备工作成功,则回应“可以提交”,否则回应“拒绝提交”。

    第二阶段

    • 如果所有的参与者都回应“可以提交”,那么,协调者向所有的参与者发送“正式提交”的命令。参与者完成正式提交,并释放所有资源,然后回应“完成”,协调者收集各结点的“完成”回应后结束这个Global Transaction。
    • 如果有一个参与者回应“拒绝提交”,那么,协调者向所有的参与者发送“回滚操作”,并释放所有资源,然后回应“回滚完成”,协调者收集各结点的“回滚”回应后,取消这个Global Transaction。

    我们可以看到,2PC说白了就是第一阶段做Vote,第二阶段做决定的一个算法,也可以看到2PC这个事是强一致性的算法。在前面我们讨论过Master-Slave的强一致性策略,和2PC有点相似,只不过2PC更为保守一些——先尝试再提交。 2PC用的是比较多的,在一些系统设计中,会串联一系列的调用,比如:A -> B -> C -> D,每一步都会分配一些资源或改写一些数据。比如我们B2C网上购物的下单操作在后台会有一系列的流程需要做。如果我们一步一步地做,就会出现这样的问题,如果某一步做不下去了,那么前面每一次所分配的资源需要做反向操作把他们都回收掉,所以,操作起来比较复杂。现在很多处理流程(Workflow)都会借鉴2PC这个算法,使用 try -> confirm的流程来确保整个流程的能够成功完成。 举个通俗的例子,西方教堂结婚的时候,都有这样的桥段:

    1)牧师分别问新郎和新娘:你是否愿意……不管生老病死……(询问阶段)

    2)当新郎和新娘都回答愿意后(锁定一生的资源),牧师就会说:我宣布你们……(事务提交)

    这是多么经典的一个两阶段提交的事务处理。 另外,我们也可以看到其中的一些问题, A)其中一个是同步阻塞操作,这个事情必然会非常大地影响性能。 B)另一个主要的问题是在TimeOut上,比如,

    1)如果第一阶段中,参与者没有收到询问请求,或是参与者的回应没有到达协调者。那么,需要协调者做超时处理,一旦超时,可以当作失败,也可以重试。

    2)如果第二阶段中,正式提交发出后,如果有的参与者没有收到,或是参与者提交/回滚后的确认信息没有返回,一旦参与者的回应超时,要么重试,要么把那个参与者标记为问题结点剔除整个集群,这样可以保证服务结点都是数据一致性的。

    3)糟糕的情况是,第二阶段中,如果参与者收不到协调者的commit/fallback指令,参与者将处于“状态未知”阶段,参与者完全不知道要怎么办,比如:如果所有的参与者完成第一阶段的回复后(可能全部yes,可能全部no,可能部分yes部分no),如果协调者在这个时候挂掉了。那么所有的结点完全不知道怎么办(问别的参与者都不行)。为了一致性,要么死等协调者,要么重发第一阶段的yes/no命令。

    两段提交最大的问题就是第3)项,如果第一阶段完成后,参与者在第二阶没有收到决策,那么数据结点会进入“不知所措”的状态,这个状态会block住整个事务。也就是说,协调者Coordinator对于事务的完成非常重要,Coordinator的可用性是个关键。 因些,我们引入三段提交,三段提交在Wikipedia上的描述如下,他把二段提交的第一个段break成了两段:询问,然后再锁资源。最后真正提交。三段提交的示意图如下:

    三段提交的核心理念是:在询问的时候并不锁定资源,除非所有人都同意了,才开始锁资源

    理论上来说,如果第一阶段所有的结点返回成功,那么有理由相信成功提交的概率很大。这样一来,可以降低参与者Cohorts的状态未知的概率。也就是说,一旦参与者收到了PreCommit,意味他知道大家其实都同意修改了。这一点很重要。下面我们来看一下3PC的状态迁移图:(注意图中的虚线,那些F,T是Failuer或Timeout,其中的:状态含义是 q – Query,a – Abort,w – Wait,p – PreCommit,c – Commit)

    从上图的状态变化图我们可以从虚线(那些F,T是Failuer或Timeout)看到——如果结点处在P状态(PreCommit)的时候发生了F/T的问题,三段提交比两段提交的好处是,三段提交可以继续直接把状态变成C状态(Commit),而两段提交则不知所措

    其实,三段提交是一个很复杂的事情,实现起来相当难,而且也有一些问题。

    看到这里,我相信你有很多很多的问题,你一定在思考2PC/3PC中各种各样的失败场景,你会发现Timeout是个非常难处理的事情,因为网络上的Timeout在很多时候让你无所事从,你也不知道对方是做了还是没有做。于是你好好的一个状态机就因为Timeout成了个摆设

    一个网络服务会有三种状态:1)Success,2)Failure,3)Timeout,第三个绝对是恶梦,尤其在你需要维护状态的时候

    Two Generals Problem(两将军问题)

    Two Generals Problem 两将军问题是这么一个思维性实验问题: 有两支军队,它们分别有一位将军领导,现在准备攻击一座修筑了防御工事的城市。这两支军队都驻扎在那座城市的附近,分占一座山头。一道山谷把两座山分隔开来,并且两位将军唯一的通信方式就是派各自的信使来往于山谷两边。不幸的是,这个山谷已经被那座城市的保卫者占领,并且存在一种可能,那就是任何被派出的信使通过山谷是会被捕。 请注意,虽然两位将军已经就攻击那座城市达成共识,但在他们各自占领山头阵地之前,并没有就进攻时间达成共识。两位将军必须让自己的军队同时进攻城市才能取得成功。因此,他们必须互相沟通,以确定一个时间来攻击,并同意就在那时攻击。如果只有一个将军进行攻击,那么这将是一个灾难性的失败。 这个思维实验就包括考虑他们如何去做这件事情。下面是我们的思考:

    1)第一位将军先发送一段消息“让我们在上午9点开始进攻”。然而,一旦信使被派遣,他是否通过了山谷,第一位将军就不得而知了。任何一点的不确定性都会使得第一位将军攻击犹豫,因为如果第二位将军不能在同一时刻发动攻击,那座城市的驻军就会击退他的军队的进攻,导致他的军对被摧毁。

    2)知道了这一点,第二位将军就需要发送一个确认回条:“我收到您的邮件,并会在9点的攻击。”但是,如果带着确认消息的信使被抓怎么办?所以第二位将军会犹豫自己的确认消息是否能到达。

    3)于是,似乎我们还要让第一位将军再发送一条确认消息——“我收到了你的确认”。然而,如果这位信使被抓怎么办呢?

    4)这样一来,是不是我们还要第二位将军发送一个“确认收到你的确认”的信息。

    靠,于是你会发现,这事情很快就发展成为不管发送多少个确认消息,都没有办法来保证两位将军有足够的自信自己的信使没有被敌军捕获。

    这个问题是无解的两个将军问题和它的无解证明首先由E.A.Akkoyunlu,K.Ekanadham和R.V.Huber于1975年在《一些限制与折衷的网络通信设计》一文中发表,就在这篇文章的第73页中一段描述两个黑帮之间的通信中被阐明。 1978年,在Jim Gray的《数据库操作系统注意事项》一书中(从第465页开始)被命名为两个将军悖论。作为两个将军问题的定义和无解性的证明的来源,这一参考被广泛提及。

    这个实验意在阐明:试图通过建立在一个不可靠的连接上的交流来协调一项行动的隐患和设计上的巨大挑战。

    从工程上来说,一个解决两个将军问题的实际方法是使用一个能够承受通信信道不可靠性的方案,并不试图去消除这个不可靠性,但要将不可靠性削减到一个可以接受的程度。比如,第一位将军排出了100位信使并预计他们都被捕的可能性很小。在这种情况下,不管第二位将军是否会攻击或者受到任何消息,第一位将军都会进行攻击。另外,第一位将军可以发送一个消息流,而第二位将军可以对其中的每一条消息发送一个确认消息,这样如果每条消息都被接收到,两位将军会感觉更好。然而我们可以从证明中看出,他们俩都不能肯定这个攻击是可以协调的。他们没有算法可用(比如,收到4条以上的消息就攻击)能够确保防止仅有一方攻击。再者,第一位将军还可以为每条消息编号,说这是1号,2号……直到n号。这种方法能让第二位将军知道通信信道到底有多可靠,并且返回合适的数量的消息来确保最后一条消息被接收到。如果信道是可靠的话,只要一条消息就行了,其余的就帮不上什么忙了。最后一条和第一条消息丢失的概率是相等的。

     两将军问题可以扩展成更变态的拜占庭将军问题 (Byzantine Generals Problem),其故事背景是这样的:拜占庭位于现在土耳其的伊斯坦布尔,是东罗马帝国的首都。由于当时拜占庭罗马帝国国土辽阔,为了防御目的,因此每个军队都分隔很远,将军与将军之间只能靠信差传消息。 在战争的时候,拜占庭军队内所有将军必需达成一致的共识,决定是否有赢的机会才去攻打敌人的阵营。但是,军队可能有叛徒和敌军间谍,这些叛徒将军们会扰乱或左右决策的过程。这时候,在已知有成员谋反的情况下,其余忠诚的将军在不受叛徒的影响下如何达成一致的协议,这就是拜占庭将军问题。

    Paxos算法

    Wikipedia上的各种Paxos算法的描述非常详细,大家可以去围观一下。

    Paxos 算法解决的问题是在一个可能发生上述异常的分布式系统中如何就某个值达成一致,保证不论发生以上任何异常,都不会破坏决议的一致性。一个典型的场景是,在一个分布式数据库系统中,如果各节点的初始状态一致,每个节点都执行相同的操作序列,那么他们最后能得到一个一致的状态。为保证每个节点执行相同的命令序列,需要在每一条指令上执行一个「一致性算法」以保证每个节点看到的指令一致。一个通用的一致性算法可以应用在许多场景中,是分布式计算中的重要问题。从20世纪80年代起对于一致性算法的研究就没有停止过。

    Notes:Paxos算法是莱斯利·兰伯特(Leslie Lamport,就是 LaTeX 中的”La”,此人现在在微软研究院)于1990年提出的一种基于消息传递的一致性算法。由于算法难以理解起初并没有引起人们的重视,使Lamport在八年后1998年重新发表到ACM Transactions on Computer Systems上(The Part-Time Parliament)。即便如此paxos算法还是没有得到重视,2001年Lamport 觉得同行无法接受他的幽默感,于是用容易接受的方法重新表述了一遍(Paxos Made Simple)。可见Lamport对Paxos算法情有独钟。近几年Paxos算法的普遍使用也证明它在分布式一致性算法中的重要地位。2006年Google的三篇论文初现“云”的端倪,其中的Chubby Lock服务使用Paxos作为Chubby Cell中的一致性算法,Paxos的人气从此一路狂飙。(Lamport 本人在 他的blog 中描写了他用9年时间发表这个算法的前前后后)

    注:Amazon的AWS中,所有的云服务都基于一个ALF(Async Lock Framework)的框架实现的,这个ALF用的就是Paxos算法。我在Amazon的时候,看内部的分享视频时,设计者在内部的Principle Talk里说他参考了ZooKeeper的方法,但他用了另一种比ZooKeeper更易读的方式实现了这个算法。

    简单说来,Paxos的目的是让整个集群的结点对某个值的变更达成一致。Paxos算法基本上来说是个民主选举的算法——大多数的决定会成个整个集群的统一决定。任何一个点都可以提出要修改某个数据的提案,是否通过这个提案取决于这个集群中是否有超过半数的结点同意(所以Paxos算法需要集群中的结点是单数)。

    这个算法有两个阶段(假设这个有三个结点:A,B,C):

    第一阶段:Prepare阶段

    A把申请修改的请求Prepare Request发给所有的结点A,B,C。注意,Paxos算法会有一个Sequence Number(你可以认为是一个提案号,这个数不断递增,而且是唯一的,也就是说A和B不可能有相同的提案号),这个提案号会和修改请求一同发出,任何结点在“Prepare阶段”时都会拒绝其值小于当前提案号的请求。所以,结点A在向所有结点申请修改请求的时候,需要带一个提案号,越新的提案,这个提案号就越是是最大的。

    如果接收结点收到的提案号n大于其它结点发过来的提案号,这个结点会回应Yes(本结点上最新的被批准提案号),并保证不接收其它<n的提案。这样一来,结点上在Prepare阶段里总是会对最新的提案做承诺。

    优化:在上述 prepare 过程中,如果任何一个结点发现存在一个更高编号的提案,则需要通知 提案人,提醒其中断这次提案。

    第二阶段:Accept阶段

    如果提案者A收到了超过半数的结点返回的Yes,然后他就会向所有的结点发布Accept Request(同样,需要带上提案号n),如果没有超过半数的话,那就返回失败。

    当结点们收到了Accept Request后,如果对于接收的结点来说,n是最大的了,那么,它就会修改这个值,如果发现自己有一个更大的提案号,那么,结点就会拒绝修改。

    我们可以看以,这似乎就是一个“两段提交”的优化。其实,2PC/3PC都是分布式一致性算法的残次版本,Google Chubby的作者Mike Burrows说过这个世界上只有一种一致性算法,那就是Paxos,其它的算法都是残次品。

    我们还可以看到:对于同一个值的在不同结点的修改提案就算是在接收方被乱序收到也是没有问题的。

    关于一些实例,你可以看一下Wikipedia中文中的“Paxos样例”一节,我在这里就不再多说了。对于Paxos算法中的一些异常示例,大家可以自己推导一下。你会发现基本上来说只要保证有半数以上的结点存活,就没有什么问题。

    多说一下,自从Lamport在1998年发表Paxos算法后,对Paxos的各种改进工作就从未停止,其中动作最大的莫过于2005年发表的Fast Paxos。无论何种改进,其重点依然是在消息延迟与性能、吞吐量之间作出各种权衡。为了容易地从概念上区分二者,称前者Classic Paxos,改进后的后者为Fast Paxos。

    总结

    下图来自:Google App Engine的co-founder Ryan Barrett在2009年的google i/o上的演讲《 Transaction Across DataCenter》(视频:  http://www.youtube.com/watch?v=srOgpXECblk

    前面,我们说过,要想让数据有高可用性,就需要冗余数据写多份。写多份的问题会带来一致性的问题,而一致性的问题又会带来性能问题。从上图我们可以看到,我们基本上来说不可以让所有的项都绿起来,这就是著名的CAP理论:一致性,可用性,分区容忍性,你只可能要其中的两个。

    NWR模型

    最后我还想提一下Amazon Dynamo的NWR模型。这个NWR模型把CAP的选择权交给了用户,让用户自己的选择你的CAP中的哪两个

    所谓NWR模型。N代表N个备份,W代表要写入至少W份才认为成功,R表示至少读取R个备份。配置的时候要求W+R > N。 因为W+R > N, 所以 R > N-W 这个是什么意思呢?就是读取的份数一定要比总备份数减去确保写成功的倍数的差值要大。

    也就是说,每次读取,都至少读取到一个最新的版本。从而不会读到一份旧数据。当我们需要高可写的环境的时候,我们可以配置W = 1 如果N=3 那么R = 3。 这个时候只要写任何节点成功就认为成功,但是读的时候必须从所有的节点都读出数据。如果我们要求读的高效率,我们可以配置 W=N R=1。这个时候任何一个节点读成功就认为成功,但是写的时候必须写所有三个节点成功才认为成功。

    NWR模型的一些设置会造成脏数据的问题,因为这很明显不是像Paxos一样是一个强一致的东西,所以,可能每次的读写操作都不在同一个结点上,于是会出现一些结点上的数据并不是最新版本,但却进行了最新的操作。

    所以,Amazon Dynamo引了数据版本的设计。也就是说,如果你读出来数据的版本是v1,当你计算完成后要回填数据后,却发现数据的版本号已经被人更新成了v2,那么服务器就会拒绝你。版本这个事就像“乐观锁”一样。

    但是,对于分布式和NWR模型来说,版本也会有恶梦的时候——就是版本冲的问题,比如:我们设置了N=3 W=1,如果A结点上接受了一个值,版本由v1 -> v2,但还没有来得及同步到结点B上(异步的,应该W=1,写一份就算成功),B结点上还是v1版本,此时,B结点接到写请求,按道理来说,他需要拒绝掉,但是他一方面并不知道别的结点已经被更新到v2,另一方面他也无法拒绝,因为W=1,所以写一分就成功了。于是,出现了严重的版本冲突。

    Amazon的Dynamo把版本冲突这个问题巧妙地回避掉了——版本冲这个事交给用户自己来处理。

    于是,Dynamo引入了Vector Clock(矢量钟?!)这个设计。这个设计让每个结点各自记录自己的版本信息,也就是说,对于同一个数据,需要记录两个事:1)谁更新的我,2)我的版本号是什么。

    下面,我们来看一个操作序列:

    1)一个写请求,第一次被节点A处理了。节点A会增加一个版本信息(A,1)。我们把这个时候的数据记做D1(A,1)。 然后另外一个对同样key的请求还是被A处理了于是有D2(A,2)。这个时候,D2是可以覆盖D1的,不会有冲突产生。

    2)现在我们假设D2传播到了所有节点(B和C),B和C收到的数据不是从客户产生的,而是别人复制给他们的,所以他们不产生新的版本信息,所以现在B和C所持有的数据还是D2(A,2)。于是A,B,C上的数据及其版本号都是一样的。

    3)如果我们有一个新的写请求到了B结点上,于是B结点生成数据D3(A,2; B,1),意思是:数据D全局版本号为3,A升了两新,B升了一次。这不就是所谓的代码版本的log么?

    4)如果D3没有传播到C的时候又一个请求被C处理了,于是,以C结点上的数据是D4(A,2; C,1)。

    5)好,最精彩的事情来了:如果这个时候来了一个读请求,我们要记得,我们的W=1 那么R=N=3,所以R会从所有三个节点上读,此时,他会读到三个版本:

      • A结点:D2(A,2)
      • B结点:D3(A,2;  B,1);
      • C结点:D4(A,2;  C,1)

    6)这个时候可以判断出,D2已经是旧版本(已经包含在D3/D4中),可以舍弃。

    7)但是D3和D4是明显的版本冲突。于是,交给调用方自己去做版本冲突处理。就像源代码版本管理一样。

    很明显,上述的Dynamo的配置用的是CAP里的A和P。

    我非常推大家都去看看这篇论文:《Dynamo:Amazon’s Highly Available Key-Value Store》,如果英文痛苦,你可以看看译文(译者不详)。

    展开全文
  • 分布式事务处理方式总结

    千次阅读 2019-08-01 21:43:30
    在项目开发中,经常会需要处理分布式事务。例如数据库分库分表之后,原来在一个单库上的操作可能会跨越多个数据库。系统服务化拆分之后,原来的在一个系统上的操作可能会跨越多个系统...
  • MySQL数据库事务处理

    万次阅读 多人点赞 2017-03-16 15:43:33
    通常,联机事务处理 (OLTP) 系统执行大量的相对较小的事务。 事务处理是将多个操作或者命令一起执行,所有命令全部成功执行才意味着该事务的成功,任何一个命令失败都意味着该事务的失败,因此,事务处理不是一荣俱荣...
  • Spring事务控制--Spring中的事务处理

    万次阅读 多人点赞 2018-11-07 15:22:08
    事务回顾 什么是事务事务是逻辑上的一组操作,组成这组操作的各个逻辑单元,要么一起成功,要么一起失败。 事务的特性 原子性:强调事务的不可分割 一致性:事务执行的前后数据的完整性要保持一致 隔离性...
  • 数据到了多机后,原来单机中通过事务进行处理逻辑会有很大影响,要么放弃原来的单机事务,修改实现,要么引入分布式事务。 b、一些join操作会变得比较困难,因为数据可能已经在两个数据库中了。 c、靠外键去进行...
  • Oracle 分布式事务 2pc 故障处理

    万次阅读 2021-09-09 23:00:10
    在这种机制下,事务处理过程分为三个阶段: PREPARE:发起分布式事务的节点通知各个关联节点准备提交或回滚。 COMMIT:写入commited SCN,释放锁资源 FORGET:悬疑事务表和关联的数据库视图信息清理 各关联节点此时...
  • oracle事务处理详解

    千次阅读 2017-08-29 15:58:30
    1、事务概念:  概念:在数据库中事务是工作的逻辑单元,一个事务是由一个或多个完成一组的相关行为的SQL语句组成,通过事务机制确保这... 对一组SQL语句操作构成事务,数据库操作系统必须确保这些操作的原子性,一致
  • 前两章节主要讲解了在SpringBoot中关于对数据的操作,本章节将介绍如何进行事务处理。所有的数据访问技术都离不开事务处理,否则将会造成数据不一致。事务是一系列的动作,一旦其中有一个动作出现错误,必须全部回滚...
  • 分布式事务处理方案示例

    千次阅读 2018-04-25 18:35:02
    问题的起源在电商等业务中,系统一般由多个独立的服务组成,如何解决分布式调用时候数据的一致性? 具体业务场景如下,比如一个业务操作,如果同时调用服务 A、B、C,需要满足要么同时成功;要么同时失败。A、B、C ...
  • 事务故障、系统故障和介质故障的恢复1,事务故障的恢复2,系统故障的恢复3,介质故障的恢复:重装数据库,然后重做已完成的事务。 1,事务故障的恢复 (1) 反向扫描日志文件,查找该事务的更新操作。 (2) 对该...
  • MySQL事务处理

    千次阅读 2019-03-13 16:27:00
    1 事务处理注意点 2 MySQL事务处理 3 PHP之PDO处理事务 4 PHP之MySQLi处理事务 1 事务处理注意点 MySQL中Innodb支持事务,而MyISAM不支持事务 事务 的ACID 特性:Atomicity(原子性)、Consistency(稳定性)...
  • Java事务处理总结

    千次阅读 2017-04-28 08:49:48
    一、什么是Java事务 事务必须服从ISO/IEC所制定的ACID原则。ACID是原子性(atomicity)、一致性(consistency)、隔离性(isolation)和持久性(durability)的缩写。事务的原子性表示事务执行过程中的任何失败都将...
  • ORA-02049: 超时: 分布式事务处理等待锁。 【问题思路】: (1)首先我在数据库中刚查过数据(印刷流水号),sql为: select visaserialno, businessno,visacode, visaname, usercode, visastatus, comcode from ...
  • C#事务处理(一)之概念

    千次阅读 2017-03-14 11:07:47
    事务常用于数据库,但利用System.Transactions名称控件中的类,还可以对不稳定的,基于内存的对象执行事务处理,如对象列表。对于支持事务的对象列表,如果添加或删除了一个对象时事务处理失败,这个列表的操作会
  • 微服务如何处理事务

    千次阅读 2020-02-21 15:52:48
    分布式事务的实现主要有以下 5 种方案: XA 方案 TCC 方案 本地消息表 可靠消息最终一致性方案 最大努力通知方案 两阶段提交方案/XA方案 所谓的 XA 方案,即:两阶段提交,有一个事务管理...
  • 用rpc 进行跨系统访问时,事务怎么处理? 谢谢!
  • 今天来说一说Spring中的事务管理机制把,在Spring中可以通过xml配置和注解配置的方式,实现对事务的管理和控制。xml配置,emmmmm,我已经忘得差不多了。主要是注解用的太爽了,哈哈哈哈。本篇文章就只说一下注解配置...
  • 今天说一说事务处理的内容,我们会介绍事务处理的很多概念与应用。 二、事务处理的简介: 1.现实的问题: 一个在线多站航班预订系统(web或app)。 用户提交他们的订单并期望得到: 尽可能快地处理,也意味着用户...
  • 1、事务消费介绍 我们经常支付宝转账余额宝,这是日常生活的一件普通小事,但是我们思考支付宝扣除转账的钱之后,如果系统挂掉怎么办,这时余额宝账户并没有增加相应的金额,数据就会出现不一致状况了。 上述场景...
  • 笔者现在碰到一个项目,项目是类似于一卡通的数据模型,就是所有的金额存放在A系统中,A系统负责金额的处理,B系统负责业务处理,并向A系统发送相应的命令以进行数据处理,并返回相应处理的结果。  A和B系统之间的...
  • Oracle EBS OM 销售订单挑库,搬运单分配以后就被卡在待定事务处理和保留中
  • 文章目录事务性请求处理Leader 事务处理分析预处理阶段事务处理阶段事务执行阶段响应阶段源码分析小结 Leader 服务器在 ZooKeeper 中的作主要是处理事务性的会话请求以及管理 ZooKeeper 集群中的其他角色服务器 ...
  • 【MySQL】数据库事务处理---MySQL

    千次阅读 2018-07-01 23:45:50
    通常,联机事务处理 (OLTP) 系统执行大量的相对较小的事务----百度百科。事务处理是将多个操作或者命令一起执行,所有命令全部成功执行才意味着该事务的成功,任何一个命令失败都意味着该事务的失败。以银行转账为例...
  • Laravel 分布式事务处理

    千次阅读 2020-05-24 16:31:43
    TCC 是现在非常流行分布式处理模式,属于柔性事务。柔性事务,基于分布式领域 BASE 理论,它是在 CAP 理论(一致性、可用性、分区容忍性)的基础之上的延伸,包括:基本可用(Basically Available)、柔性状态(Soft...
  • OLTP - 联机事务处理

    千次阅读 2013-11-20 10:55:21
    原文地址:... ...------------------------------ ... 数据处理大致可以分成两大类:联机事务处理OLTP(on-line transaction processing)、联机分析处理OLAP(On-Line Analytic

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 561,667
精华内容 224,666
关键字:

典型的事务处理系统

友情链接: bmpshow.rar