精华内容
下载资源
问答
  • 直观的角度来看,完整的区块链系统内部一定会包含一个「存储模块」,整体而言,区块链系统确实可以起到持久化数据的作用。 但是如果从这个角度出发,直接将区块链系统看作是一个数据库,这样的观点也是有待商榷的。...

    【背景】
    随着区块链技术的发展和应用场景的逐步丰富,越来越多的人开始接触区块链。但在过程中,很多人提过这样的问题:“底层用区块链系统和用数据库有什么区别呢?”、“区块链系统是不是就是一个OLTP数据库系统?”…

    直观的角度来看,完整的区块链系统内部一定会包含一个「存储模块」,整体而言,区块链系统确实可以起到持久化数据的作用。

    但是如果从这个角度出发,直接将区块链系统看作是一个数据库,这样的观点也是有待商榷的。在作出最终比较之前,我们先来分析一下传统数据库系统的运行机制以及区块链系统内部存储模块的功能职责。

    【传统OLTP数据库VS区块链存储】
    ▲ 传统OLTP数据库存什么?
    现阶段的数据库系统、存储引擎的设计一般是面向某一通用场景的,比如sql型数据库、NoSQL型数据库(kv数据库、文档数据库等),而不是面向具体业务场景的,那一般的OLTP数据库内部的数据分为四大类:

    数据库内部的管理性质的元数据。这部分数据基本上对用户是透明的,负责数据库内部的管理与控制逻辑;

    用户自定义数据。这部分数据是用户通过API向数据库写入的数,数据库系统一般不关心这部分数据的具体内容,而是侧重于如何正确、完整的将这些数据保存到持久化设备;

    索引数据。索引数据一般是数据库设计中不可或缺的一个组成部分。为了保证数据库“读数据”功能的响应时间在用户可接受范围内,几乎所有数据库系统都需要或多或少的引入索引;

    日志数据。日志数据是一种数据库内部数据,其内容一般是记录数据变更行为,一般用于数据库宕机重启后的数据恢复。在不同的数据库中,日志数据的内容差距也非常大,比如:有的数据库使用日志来记录存储层的数据变更(磁盘上位置X开始,连续N个字节从Value1变成了Value2),有的数据库使用日志来记录用户的写入命令请求(比如插入操作,内容为key=1,value=“ABC”)等等。
    在这里插入图片描述
    ▲ 区块链存储模块有何不同?
    当我们站在区块链系统内部“数据存储”功能的角度看待“区块链系统”时,我们会发现,区块链系统具有确定性的系统架构、确定性的内部业务逻辑,以及一些通用的数据组织格式(比如:区块是一种append-only形式的数据、只有虚拟机执行指令的过程中会修改状态数据等)。区块链系统中的数据存储只需要满足这一套运转逻辑过程中的持久化需求即可,也就是说,区块链系统为其存储模块划定了比通用数据库更小的模块功能边界。

    ▲区块链存储存什么?——世界状态
    从使用者角度来看,一个最常规的区块链服务是由一个区块链网络提供的。区块链网络由多个节点构成,用户可以向区块链服务发送交易,区块链网络中的所有参与共识的节点会针对交易的内容、执行过程、执行结果达成一致的决议,并将执行结果返回给发起交易的用户。
    上述过程是一个最常规的区块链服务使用流程。但是,如果从区块链网络中的节点的角度出发,节点感知的过程或者变化有哪些呢?

    我们略去网络交互、共识、执行等等的细节说明,直接讨论我们关注的重点——“世界状态”:

    如果我们将区块链可以看为一个分布式的状态机:所有节点从同一个创世状态开始,依次执行相同顺序的交易,驱动各个节点的状态按照相同操作序列不断变化,实现所有节点在同一交易序列执行完成后,状态完全一致。而这个状态,就称为“世界状态”。
    在这里插入图片描述
    在区块链网路中,所有诚实节点本地维护的“世界状态”是一致的,这个“世界状态”就是区块链存储模块要重点关注的内容。

    解释了 “世界状态” 的定义,我们还是要关注 “世界状态” 到底包括什么内容:首先,一个区块链系统中的数据状态的更迭,一定是由 “用户交易” 驱动的,那么我们只需要保证 ‘世界状态’ 能够涵盖交易的“请求内容、执行过程和执行结果” 三部分内容,就可以满足上述 “分布式状态机” 中的一致性要求。

    接下来,我们将从三个角度分别分析“世界状态”中要存储的具体内容。

    区块链系统通用的存储内容——块链结构
    区块链系统中,区块通过保存前序区块的标识(一般都是用区块哈希)来形成逻辑上的一条链。这样做的目的和意义本文不再赘述,这里重点关注的是这个“区块”的数据组织和存储形式。
    区块里面会存储哪些内容呢?一般的区块链系统中,区块会被分为区块头和区块体两个部分。
    “区块体” 部分相对简单,这个部分负责将交易内容按照一个确定的顺序存储下来;存储交易内容是很好理解的,但“一个确定的顺序”是指什么呢?回顾上文,“世界状态”是由交易驱动的,不同的交易执行顺序可能会导致数据变更操作的顺序不同,进而很可能导致世界状态的不同。因此“区块体”的内容,即体现了完整的交易内容,还同时体现了确定的交易顺序。

    “区块头”部分会包含很多的元素,区块头中一般会包含一个最重要的区块哈希字段,这个区块哈希一般会用于表示当前系统的世界状态。这就要求区块哈希的计算来源至少包含:前一区块的区块哈希(代表了前序的世界状体)、当前区块对世界状态造成的变更影响(当前区块包含的所有交易的内容、执行结果和执行过程中对账本数据的修改)。但是,区块哈希的具体计算方式可以由执行层来决定,不同系统间计算方式不尽相同[1][2]。
    在这里插入图片描述
    注:目前也存在一些新型的区块链系统采用了DAG模型[3]组织交易,甚至形成区块结构,这种情况本文暂时不做分析。

    账本数据——UTXO模型账本VS账户模型账本
    区块数据内部包含了交易内容,但是交易的内容一般只定义了对区块链上数据的修改请求,“执行过程” 和 “执行结果” 这两部分数据可能并不包含于交易内容中。本节将首先讨论交易 “执行过程” 对 “世界状态” 的影响。为此,我们引入了 “账本数据” 的概念。
    目前比较通用的账本数据组织形式包括:UTXO模型和账户模型。
    UTXO模型相对比较简单,系统中仅支持一种运行模式:“UTXO” 在不同的账户间流通。在这种运作模式下,一笔交易代表了一次流通行为,具体的流通过程为:输入的UTXO被销毁,输出的UTXO被创建,输入总额需要大于或等于输出总额[4]。
    在UTXO模型下的账本数据定义较为直观:当前链上全量的未消费的UTXO(包括UTXO上的绑定的脚本)。因为在这种模式下,如果交易执行成功,则输出有效,如果交易执行失败,则输出无效。而执行过程中的锁定、解锁等脚本的验证过程不会产生额外的账本数据修改。因此交易执行过程不涉及账本数据的更改。
    在这里插入图片描述
    但是账户模型的账本组织方式会略微复杂一些。一般账户模型的账本都是可以支持 “智能合约” 的,账户模型下的区块链系统会建立一个 “账户空间” 。

    “账户空间” 是由很多个账户组成的,其中的账户可能分为多种类型。以以太坊为例,系统中以一个通用的数据结构定义了普通账户、合约账户两种类型。普通账户的行为包括:发起交易、互相转账、创建账户等等;而合约账户则对应了一份部署在链上的智能合约,相应的,合约账户会管理所有在这份智能合约中定义的、需要存储到区块链账本中的key-value数据对,我们称之为 “状态数据” 。

    在交易执行的过程中,可能涉及到 “账户数据” 和 “状态数据” 的变更,这些改变可能既不会体现在合约内容本身中,也不会体现在交易执行结果中。因此,为了保证 “世界状态” 的完整性,经过交易执行修改后的整个 “账户空间” 的数据状态,需要被纳入“世界状态”的范畴。

    那么作为世界状态的一部分,系统会规定一种特定的方式(以太坊的MPT树、Fabric的bucketTree等等)计算出一个能反应账户空间整体状态的、易于比较的结果值,这个结果值会参与到上一节提到的“区块哈希”的计算中。(某些计算过程中的数据可能也会被持久化,比如MPT会将计算树根过程中的路径上的节点数据也存储在账本数据中)
    在这里插入图片描述
    交易执行结果/回执数据
    “UTXO模型” 的系统交易执行结果比较直接,所有的合法交易的执行结果就是成功标识+ “交易输出” 内容;所有非法交易的执行结果就是失败标识,而交易的输入部分保持原状。

    但是 “账户模型” 的区块链系统中,一般会包含转账交易和智能合约调用交易。交易的执行结果一般要经过虚拟机执行得到,考虑合约调用的场景,交易的执行结果很可能并不体现在交易内容和账户空间变更结果中;因此,交易的回执数据需要独立存储,为了统一账户创建、账户间转账、智能合约调用等多种交易的执行结果,系统一般会设计统一的回执数据组织格式。

    至此,交易数据+账户空间+交易执行结果三者一同构成了账户模型下的系统的最基本的世界状态。相应的,这类系统中的存储模块,需要提供这三类数据的存储功能。在具体设计和实现存储模块时,可以结合区块链系统的运作模式,综合考虑吞吐量和延迟等指标,根据不同数据的业务特点设计和使用不同的底层存储引擎。

    索引数据
    一个完整的区块链系统除了提供上述写入功能外,还需要提供历史数据的查询功能。如果系统中只存储了上述世界状态数据,那么用户对历史数据的查询只能通过遍历所有区块实现,这样的代价和延迟很显然是无法接受的。

    因此,一般的区块链系统都会考虑设置一种基本的索引——交易索引。借由这种索引,系统能够快速的确认交易所在的区块,甚至可以更细粒度的直接定位到交易存储于这个区块内的哪个位置。索引的内容一般就是“交易哈希(交易标识)”到“交易所在位置”的映射。

    这样的索引设计会给系统持久化区块的过程带来一定的 “写放大” ,单无论从数据量还是从必要性角度出发,一般的区块链系统都会选择接受这种代价。

    【区块链存储相关的 “一致性”】
    至此,一个简单通用的区块链系统必要的存储内容已经介绍完毕。但是这还不是区块链系统的存储模块需要考虑的全部内容。在区块链网络中,所有诚实节点在相同的区块执行完毕后,需要拥有完全一致的世界状态。这个世界状态可以由区块确认后的 “区块哈希”表示。

    但是,区块链系统一般会运行在一个拜占庭网络环境中;那么,区块链系统随时存在着数据落后的情况,整个网络也存在着随时新增和删除节点的情况。无论是落后的诚实节点,还是新增进入网络的诚实节点,都需要尽快追赶上网络中的其他诚实节点。

    那么落后的节点如何 “追赶” 其他的诚实节点呢?这里我们再重新审视一下 “交易” 这个角色。前文提到:“区块链系统的整体数据状态是依赖交易的执行而不断向后演进的”,那么交易就可以看作是区块链系统世界状态变更的 “日志” 。

    基于这样的理解角度,落后节点 “追赶” 其他诚实节点可以通过同步诚实节点的区块来实现,因为区块中的区块体包括了全量的交易内容,那么落后节点可以通过重放其缺少交易,最终达到与其他节点一致的世界状态。这个恢复的过程,落后节点不需要参与共识,而是借由一系列校验协议来确保数据的完整性和正确性。

    进一步分析上述交易重放流程,如果是UTXO模型的系统,交易的内容和执行过程比较简单;但是对于账户模型的系统,则交易可能是合约执行请求,那么执行这笔交易的过程就不可避免的会涉及执行环境的创建,使用虚拟机执行完整的合约指令等等步骤。那么,对于节点间网络环境较好的场景,是不是有进一步提高落后节点“追赶”速度的策略呢?

    由此,在特定的场景下,比如 “联盟链+账户模型” 的系统中,数据同步的过程可以引入另一种策略:如果在交易执行的过程中,系统将所有的账本数据(也就是账户空间)修改相关的操作都记录下来,形成一份账本操作日志数据(可以类比MySQL中Binlog的row模式思路);那么在做数据同步时,落后节点可以直接拉取区块数据、账本操作日志数据和交易回执数据,完成后并将拉取账本操作日志数据按序应用到本地账本数据上,完成应用日志的过程后,落后节点便完成了与其他诚实节点一致的“世界状态”的构建。
    在这里插入图片描述

    基于上述思路,存储模块可以引入另一种与世界状态有关的数据——操作日志数据,这些数据与交易的执行过程强相关。在某些网络带宽充裕、智能合约计算逻辑复杂但账本数据修改不频繁的场景下,上述思路是一种有效加速节点间数据同步的解决方案。

    【小结与思考】
    至此,本文第一个引入的 “区块链存储模块是不是数据库” 的问题,可以做一个简单的总结:笔者认为,数据库和区块链存储是可以区分开来看待的概念,区块链存储模块无论从功能边界、服务对象还是自身的拓展优化思路上,都是和 “区块链系统” 这个场景强相关的。本系列后续的文章会针对区块链系统的内部逻辑和场景,分别讨论各种数据的存储模式和存储设计思路。但是OLTP数据库系统,其考虑的场景则是一个更宽广、更通用的层面。

    最后,可能部分读者会思考这样一个问题:本文一直在强调 “区块链存储系统的专用性和为区块链场景定制” 的思路,那在现实业务场景使用区块链底层平台时,平时常听到的 “通用型平台” 这个概念又该如何理解呢?

    其实,“为区块链系统的内部运作机理提供定制化的存储模块功能” ,与 “区块链系统整体对外提供通用的业务支持” ,是两个层面的问题,两者并不矛盾。本文讨论的存储模块的定制化,专用性,是针对区块链系统的内部运行逻辑定制化的设计存储功能,但是区块链系统中账本组织模型的设计和智能合约功能的存在,则允许用户为多种业务场景自定义合约逻辑、自定义账本 “状态数据” 。

    作者简介
    郭威
    趣链科技基础平台部 区块链存储研究小组
    参考文献
    [1] https://github.com/ethereum/go-ethereum
    [2] https://github.com/hyperledger/hyperledger
    [3] https://developer.confluxnetwork.org/
    [4] 《精通比特币 第二版》

    展开全文
  • 分布式存储最早是由谷歌提出的,其目的是通过廉价的服务器来提供使用大规模,高并发场景下的Web访问问题。它采用可扩展的系统结构,利用多台存储服务器分担存储负荷,利用位置服务器定位存储信息,它不但提高了...

    分布式存储最早是由谷歌提出的,其目的是通过廉价的服务器来提供使用与大规模,高并发场景下的Web访问问题。它采用可扩展的系统结构,利用多台存储服务器分担存储负荷,利用位置服务器定位存储信息,它不但提高了系统的可靠性、可用性和存取效率,还易于扩展。【.本文​由qkljys123整理发布.】

    分布式存储系统特点

    1、大容量:系统节点可采用通用的X86架构存储服务器作为构建单元,可根据用户需要横向无限扩展存储节点,并且形成一个统一的共享存储池。

    2、高性能:相比传统存储而言,分布式存储系统能提供高出数倍的聚合IOPS和吞吐量,另外可以随着存储节点的扩容而线性增长,专用的元数据模块可以提供非常快速精准的数据检索和定位,满足前端业务快速响应的需求。

    3、更可靠:整个系统无任何的单点故障,数据安全和业务连续性能够得到保障。每个节点可看成是一块硬盘,节点设备之间有专门的数据保护策略,可实现系统的设备级冗余,并且可在线更换损坏的硬盘或者节点设备。

    4、易扩展:系统可以支持在线无缝动态横向扩展。在采用冗余策略的情况下,任何一个存储节点的上线和下线对前端业务没有任何影响,完全是透明的。并且系统在扩充新的存储节点后,可以选择自动负载均衡,所有数据压力会均匀分配在各存储节点上。

    5、易整合:兼容任何品牌的X86架构通用存储服务器,在标准的IP/IB网络环境下即可轻松实施,无须改变原有网络架构。

    6、易管理:通过一个简单的Web界面就可以对整个系统进行配置管理,运维简便,极低的管理成本,一个管理员就可以轻松管理PB级别的存储系统。【.本文​由qkljys123整理发布.】

     

    展开全文
  • 区块链分布式数据库的区别

    千次阅读 2021-11-10 16:24:01
    ... 说一下自己的理解,如果理解有误欢迎评论区讨论 : ) 首先区分一下分布式 (distributed) 和去中心化 (decentralized) 这两个词。 分布式:多节点共同组成一个系统,这些节点属于同一个信任域 ...区块链是一.

    欢迎关注一下我的 知乎账号,以后主要在知乎分享内容。感谢~
    https://www.zhihu.com/people/ypjiang96/posts

    说一下自己的理解,如果理解有误欢迎评论区讨论 : )

    首先区分一下分布式 (distributed) 和去中心化 (decentralized) 这两个词。

    • 分布式:多节点共同组成一个系统,这些节点属于同一个信任域
    • 去中心化:也是多个节点组成一个系统,但是这些节点可能属于不同的信任域

    同一个信任域内的节点互相信任,不同信任域的节点之前不存在信任。
    区块链是一个去中心化系统,有多个信任域,不同信任域可能有多个节点。

    传统的分布式系统绝大部分应该都是属于单信任域系统。

    注意,即使在同一个信任域内的系统,也可能需要拜占庭容错,因为节点可能遭受外部攻击。

    不过传统的单信任域的系统出于性能考虑绝大部分都没有考虑拜占庭容错,使用了 Paxos 或者 Raft 共识算法。

    而区块链则天然就要求拜占庭容错,因为根据定义区块链属于多信任域系统。

    那么,区块链就是支持拜占庭容错的分布式系统吗?

    其实二者还有更加微妙的区别。

    在细说之前,我们再来区分一个词:transaction。数据库里一般翻译成事务,区块链里一般称为交易。

    但是,区块链里的 transaction 和数据库里的 transaction 其实是有很大区别的。

    如果非要对应的话,区块链中的 transaction 其实对应数据库里的存储过程 (stored procedure) ,二者都是在 server 端完成存储和计算。

    而数据库里的 transaction 只是使用了数据库 server 端提供的 read/write/commit/abort 等接口,真正的计算是在单个 client 端完成的,注意这里的 client 是指应用程序所在的 server。

    一个数据库系统也可能支持多个不同的应用。

    那么,数据库的正确性就取决于这些应用是否是正确的,如果任何一个应用被攻击,就可能导致数据库的数据出现错误。

    比如,某个应用的 transaction 逻辑被攻击之后篡改了,那么攻击者可能发起恶意的 transaction,也能 commit 到数据库。

    如果使用存储过程,那么攻击者需要攻击数据库节点的存储过程逻辑才能攻击成功。而且数据库节点使用了共识算法来容错,系统可以容忍部分节点被攻击。

    感觉数据库的存储过程和另一个概念非常类似,这里也一起讲一下:复制状态机 (state machine replication, SMR)。 二者的本质都是把 client 端的逻辑移到了 server 端,直接给 client 提供更加丰富的 API 来实现上层应用。而且为了不同节点的一致性,存储过程和 SMR 都要求逻辑是确定性的 (deterministic) 。

    那么区块链就是支持拜占庭容错的 SMR 吗?
    Fabric 论文片段

    Hyperledger Fabric 的论文里其实已经说了三点区别:

    1. BFT SMR 只支持一个应用,区块链支持多个应用并行
    2. 区块链的应用 (智能合约) 可以被任何人(可能有权限控制)动态部署
    3. 应用代码是不受信的,甚至可能是恶意代码

    感觉 BFT SMR 要想支持动态部署多应用也不难,所以关键还是在于第三点:既然应用可能是恶意代码,那么就需要对应的措施来防止恶意代码可能的危害,也就是需要解决停机问题,Ethereum 里用了 Gas 费用来解决停机问题。

    此外,关于 determinism,传统的存储过程和 SMR 都是直接假设了 determinism,一旦存在 nondeterminism 就会导致非常严重的问题,而 Ethereum 则是设计了 EVM 和 Solidity 来从语言层面消除 nondeterminism 。

    综上,个人认为,区块链相比传统分布式系统最核心的区别在于可能存在恶意代码,需要解决停机问题和 nondeterminism 问题,而传统分布式系统都是假设不存在这两个问题。

    展开全文
  • 这些异常可能有 机器宕机、网络异常、消息丢失、消息乱序、数据错误、不可靠的TCP、存储数据丢失、其他异常等等… 对分布式系统有过研究的读者, 听说过 “CAP定律”、“Base理论” 等,这里不对这些概念做过多的...

    前言

    区块链系统是典型的去中心化分布式系统,而分布式系统架构中非常核心的一部分便是分布式事务的实现。在企业级区块链系统中,往往有需要多个数据库来满足系统架构的需要,例如区块信息易保存在k-v数据库中,而区块链系统的业务数据需要保存在传统的关系型数据库中,这种跨数据库、跨服务器的数据操作架构设计对事务的管理要求极高,下面我们讨论一下常见的分布式事务解决方案。

    一、数据库事务

    1、事物的特性

    事务是由一组SQL语句组成的逻辑处理单元,事务具有以下4个属性,通常简称为事务的ACID属性:

    原子性(Atomicity):事务是一个原子操作单元,其对数据的修改,要么全都执行,要么全都不执行。

    一致性(Consistent):在事务开始和完成时,数据都必须保持一致状态。这意味着所有相关的数据规则都必须应用于事务的修改,以保持数据的完整性;事务结束时,所有的内部数据结构(如B树索引或双向链表)也都必须是正确的。

    隔离性(Isoation):数据库系统提供一定的隔离机制,保证事务在不受外部并发操作影响的“独立”环境执行。这意味着事务处理过程中的中间状态对外部是不可见的,反之亦然。

    持久性(Durabe):事务完成之后,它对于数据的修改是永久性的,即使出现系统故障也能够保持。

    2、事务类型:

    JDBC事务:

    即为上面说的数据库事务中的本地事务,通过connection对象控制管理。

    JTA事务:

    JTA指Java事务API(JavaTransaction API),是Java EE数据库事务规范, JTA只提供了事务管理接口,由应用程序服务器厂商(如WebSphere Application Server)提供实现,JTA事务比JDBC更强大,支持分布式事务。

    3、事务种类:

    本地事务:

    普通事务,独立一个数据库,能保证在该数据库上操作的ACID。

    分布式事务:

    涉及两个或多个数据库源的事务,即跨越多台同类或异类数据库的事务(由每台数据库的本地事务组成的),分布式事务旨在保证这些本地事务的所有操作的ACID,使事务可以跨越多台数据库。

    二、如何保证数据的强一致性

    1、本地事务(mysql 之 InnoDB):

    InnoDB支持事务,同Oracle类似,事务提交需要写redo、undo。采用日志先行的策略,将数据的变更在内存中完成,并且将事务记录成redo,顺序的写入redo日志中,即表示该事务已经完成,就可以返回给客户已提交的信息。但是实际上被更改的数据还在内存中,并没有刷新到磁盘,即还没有落地,当达到一定的条件,会触发checkpoint,将内存中的数据(page)合并写入到磁盘,这样就减少了离散写、IOPS,提高性能。

    在这个过程中,如果服务器宕机了,内存中的数据丢失,当重启后,会通过redo日志进行recovery重做。确保不会丢失数据。因此只要redo能够实时的写入到磁盘,InnoDB就不会丢数据。

    2、分布式事务:

    多个数据库中的某个数据库在提交事务的时候突然断电,那么它是怎么样恢复的呢? 这也是分布式系统复杂的地方,因为分布式的网络环境很复杂,这种“断电”故障要比单机多很多,所以我们在做分布式系统的时候,最先考虑的就是这种情况。这些异常可能有 机器宕机、网络异常、消息丢失、消息乱序、数据错误、不可靠的TCP、存储数据丢失、其他异常等等…

    对分布式系统有过研究的读者, 听说过 “CAP定律”、“Base理论” 等,这里不对这些概念做过多的解释,有兴趣的读者可以查看相关参考资料 。

    在分布式系统中,同时满足 “CAP定律” 中的 “一致性”、“可用性” 和 “分区容错性” 三者是不可能的, 根据不同的业务场景使用不同的方法实现最终一致性,可以根据业务的特性做部分取舍,在业务过程中可以容忍一定时间内的数据不一致。

    三、实现分布式事务常见方案对比

    1、基于XA协议的两阶段提交(2PC)

    XA 是由 X/Open 组织提出的分布式事务的规范

    XA 规范主要 定义了 ( 全局 ) 事务管理器 ( Transaction Manager ) 和 ( 局部 ) 资源管理器 ( Resource Manager ) 之间的接口。 XA 接口是双向的系统接口,在事务管理器(Transaction Manager)以及一个或多个资源管理器(Resource Manager)之间形成通信桥梁。 XA 之所以需要引入事务管理器是因为,在分布式系统中,从理论上讲(参考Fischer等的论文),两台机器理论上无 法达到一致的状态,需要引入一个单点进行协调。 事务管理器控制着全局事务,管理事务生命周期,并协调资源。资源管理器负责控制和管理实际资源(如数据库或 JMS队列)。下图说明了事务管理器、资源管理器,与应用程序之间的关系:
    在这里插入图片描述

    在 JavaEE 平台下,WebLogic、Webshare 等主流商用的应用服务器提供了 JTA 的实现和支持。而在 Tomcat 下是没有实现的(Tomcat 不能算是 JavaEE 应用服务器,比较轻量),这就需要借助第三方的框架 Jotm、Automikos 等来实现,两者均支持 Spring 事务整合。

    在分布式事务的控制中采用了两阶段提交协议(Two- Phase Commit Protocol)。即事务的提交分为两个阶段:

    • 预提交阶段(Pre-Commit Phase)

    • 决策后阶段(Post-Decision Phase)

    为了支持两阶段提交,一个分布式更新事务中涉及到的服务器必须能够相互通信。一般来说一个服务器会被指定为"控制"或"提交"服务器并监控来自其它服务器的信息。

    在一个分布式事务中,必须有一个场地的Server作为协调者(coordinator),它能向 其它场地的Server发出请求,并对它们的回答作出响应,由它来控制一个分布式事务的提交或撤消。该分布式事务中涉及到的其它场地的Server称为参 与者(Participant)。
    在这里插入图片描述

    2、补偿事务(TCC)

    TCC 其实就是采用的补偿机制,其核心思想是:针对每个操作,都要注册一个与其对应的确认和补偿(撤销)操作。它分为三个阶段:

    • Try 阶段主要是对业务系统做检测及资源预留
    • Confirm 阶段主要是对业务系统做确认提交,Try 阶段执行成功并开始执行 Confirm 阶段时,默认Confirm 阶段是不会出错的。即:只要 Try 成功,Confirm 一定成功。
    • Cancel 阶段主要是在业务执行错误,需要回滚的状态下执行的业务取消,预留资源释放。

    举个例子,假入 Bob 要向 Smith 转账,思路大概是:我们有一个本地方法,里面依次调用

    1、首先在 Try 阶段,要先调用远程接口把 Smith 和 Bob 的钱给冻结起来。

    2、在 Confirm 阶段,执行远程调用的转账的操作,转账成功进行解冻。

    3、如果第2步执行成功,那么转账成功,如果第二步执行失败,则调用远程冻结接口对应的解冻方法 (Cancel)。

    优点: 跟 2PC 比起来,实现以及流程相对简单了一些,但数据的一致性比 2PC 也要差一些。

    账成功,如果第二步执行失败,则调用远程冻结接口对应的解冻方法 (Cancel)。

    优点: 跟 2PC 比起来,实现以及流程相对简单了一些,但数据的一致性比 2PC 也要差一些。

    缺点: 缺点还是比较明显的,在2,3步中都有可能失败。TCC 属于应用层的一种补偿方式,所以需要程序员在实现的时候多写很多补偿的代码,在一些场景中,一些业务流程可能用 TCC 不太好定义及处理。

    展开全文
  • 是绝对可以将所需的任何数据存储区块链中的。实际的情况是,由于效率问题,大家都不想存储很大的数据块。 因为,它的另一个功能是,一旦将某些内容写入区块链,它就永远存在。 能删除记录吗?你不能。最好的办法...
  • 《Web3.0中国峰会暨IPFS区块链分布式存储行业大会》于7月15日在中国成都,盛大开启!共享分布式存储新机遇,行业盛会,巅峰相聚,助力国家“东数西算”!现场人头攒动,人山人海,人声鼎沸,热闹非凡!一片繁荣的...
  • 区块链分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。近年来,区块链成为全球互联网领域,特别是金融互联网界快速升温、越来越热的概念。在中国,区块链更是引发越来越多的人、...
  • 这是白话区块链的第1411期原创作者 | 三黎出品|白话区块链(ID:hellobtc)去年10月15日,Filecoin主网于区块链高度148888启动。OKEx、火币、币安陆续宣布支...
  • 分布式存储区块链结合能碰撞出怎样的火花? 日前,工业和信息化部、中央网络安全和信息化委员会办公室发布《关于加快推动区块链技术应用和产业发展的指导意见》。意见提出:到2025年,区块链产业综合实力达到世界...
  • 通知指出,要超前布局区块链,围绕区块链高性能、安全性、隐私保护、可扩展性等方向,加快共识机制、分布式存储、跨链协议、智能合约等技术突破,实现大规模区块链算法性能关键技术突破,以及通过汇聚激活超大规模的...
  • 6月7日,《工业和信息化部 中央网络安全和信息化委员会办公室关于加快推动区块链技术应用和产业发展的指导意见》(以下简称《指导意见》)正式对外发布。 《指导意见》首先明确了区块链的定义以及明确我国区块链...
  • 随着区块链项目的不断发展普及,越来越多的人了解到区块链,尽管很多人对区块链还是比较模糊的一个状态,但是区块链对于未来发展的重要性已经被公众广泛的认知。 目前很多区块链应用技术落地基本上都处于一个孵化期...
  • 分布式数据库和区块链技术及应用

    千次阅读 2021-05-31 22:15:01
    分布式数据库和区块链技术及应用 摘要:早在20世纪70年代,分布式数据库的兴起极大促进了数据库容量的扩大,处理能力的提高和可靠性的增强。近年来在分布式数据库基础上发展而来的区块链技术和比特币的应用又成为...
  • 区块链分布式存储ipfs值得投资么,如何鉴别Filecoin挖矿平台是否靠谱? 据水滴科技集群商说道,在未来,IPFS将会带来颠覆式变革,引领互联网走向Web3.0时代。 最初,我们将数据存储于电脑中,但当电脑发生故障时,...
  • 区块链具备分布式一致性、数据难以篡改、全程可追溯等特性,有助于推动互联网从传递信息向传递价值转变。2020年,区块链技术首次被国家层面明确为新型基础设施,服务于我国数字经济战略。2021年...
  • 焦仕可|2020分布式存储产业链研究报告 我们正在变成一半生物人,一半数字人,欢迎进入数字世界新时代。 作者:焦仕可 出品:聚英国际 战略合作:链世纪财经 目录 观点摘要 行业背景 一、分布式存储...
  • 物联网(IoT)正在快速增长已不是什么秘密。... 作者:MKZ888Z 由于区块链将数据作为交易存储在链中的多个链路上,因此存储必须在每一步都进行优化。 【本文由比链科技官方整理并发布,欢迎随时咨询!】
  • 在6月18号四川全面关闭矿场之后,由四川政府主办的“Web3.0中国峰会中国大数据应用大会暨 IPFS区块链分布式存储行业大会”将于7月15日在成都世纪城新国际会展中心举行。之前已经宣布关闭四川比特币矿场,后面还将...
  • 5月13日,协议实验室官方博客发文宣布区块链实验室Wolfram与分布式存储协议和星际文件系统展开合作。Wolfram正在使用分布式存储协议和星际文件系统为其现有的区块链功能添加新的去中心化功能并扩展存储。 为分布式...
  • Web2.0加速向Web3.0过渡,全球数据存储量呈现“爆炸式”增长。而随着数字化程度不断加深,传统中心化存储的弊端也开始逐一显现,诸如...Web2.0时代的本质是互动,人人都可以分享,实现人人之间互联互通;那么Web3.0时
  • ipfs分布式存储服务器介绍

    千次阅读 2021-07-21 16:16:57
    什么是IPFS?...IPFS-分布式存储-fil-挖矿-排名-ipfs 传统互联网 HTTP 协议是搜索域名地址,但是 IPFS 是搜索内容地址。用 IPFS 这种颠覆 HTTP 协议的方法,理论上可以让网络更快更安全。 IPFS 的理..
  • 分布式存储最早是由谷歌提出的,其目的是通过廉价的服务器来提供使用大规模、高并发场景下的Web 访问问题。它采用可扩展的系统结构,利用多台存储服务器分担存储负荷,利用位置服务器定位存储信息,它不但提高了...
  • 1. 传统云存储模式 ...碎片化分布式存储可以把数据分布到多个网络节点,各网络节点基于区块链 智能合约来提供数据存储服务,在合约有效期内需要定期证明它们能继续提供存储服务的能力。 2.2 访问数据
  • 中科院云计算中心成立“(IPFS)分布式存储联合实验室”将致力于利用分布式存储技术研发成果,推动转化应用落地,制定我国在分布式存储领域的各项标准,促进我国区块链技术实体经济的深度融合发展。 这是继国家...
  • IPFS分布式存储未来趋势面对互联网对大容量数据存储的需求,IPFS分布式存储正在逐渐取代HTTP,成为满足存储需求的新首选。 IPFS是一种内容分发式的文件存储网络协议,主要采用的是分布存储点对点Filecoin的技术。...
  • 在使用传统的集中式网络数据时,网络间的数据采集依赖于少数集中式服务器来响应多个子客户端的数据访问请求,这种数据采集机制由于对应的多...分布式存储作为一种数据存储技术,通过网络使用企业中的每台机器上的磁...
  • 关键技术运用:许可区块链+软件定义的vanet+基于优先级体验重放的深度q学习 传统的问题及文章解决方法 问题1:缺乏基础设施和动态性 ...协议域控制层和区块链系统交互。目标是使用共识协议安全地收集和同步从不同的
  • 《Web3.0中国峰会暨IPFS区块链分布式存储行业大会》成都站将在7月15-17日成都世纪城新国际会展中心举办,共享分布式存储新机遇!行业盛会,巅峰相聚,助力国家“东数西算”建设。 活动组织单位: 四川省经济和...
  • 随着数字艺术品所有权相对应的非标准化代币的普及,区块链技术逐渐进入最意外的领域,而分布式金融正在加速其扩展。 这些独特的,有时是非常有价值的代币在今天尤其重要,因为由于全球大流行有关的限制而关闭了...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 25,216
精华内容 10,086
关键字:

区块链与分布式存储