引言 Hyperledger Fabric是当前比较流行的一种联盟链系统,它隶属于Linux基金会在2015年创建的超级账本项目且是这个项目最重要的一个子项目.目前,与Hyperledger的另外几个子项目Hyperledger Iroha,Hyperledger Indy和Hyperledger Sawtooth一样,Hyperledger Fabric正处于生命周期中的活跃(active)阶段,它的架构设计正在不断地完善并持续为开发者和用户提供更强大,更便捷的区块链服务. 与主流的区块链系统

Gossip算法正如它的名字,小道消息只需要有人传播一次,那么过一段时间,所有人都会知道,就像新冠病毒一样,所以Gossip算法也有其它的别名"传染病扩散算法"."谣言传播算法"等等.在Fabric中Gossip算法用于区块的传播,即共识后将得到的区块广播给组织内和其它组织.本节会介绍Gossip算法的设计原理.数据结构和部分核心源码的实现,例如Push算法.Pull算法等. 1. 设计原理 Gossip协议可以抽象成广播,即发送节点向其它节点传播同样的消息.在节点

死磕hyperledger fabric源码|Order节点概述 文章及代码:https://github.com/blockchainGuide/ 分支:v1.1.0 前言及源码目录 Orderer排序节点这块内容主要包括了节点启动流程.Broadcast广播交易服务.Orderer共识排序服务以及Deliver区块分发服务.其相关源码目录文件如下: /orderer |-common ​ |-blockcutter:交易切割打包模块 ​ |-bootstrap:引导启动模块,生成创世块 ​

Hyperledger Fabric开源于2015年12月,截至2018年2月初有185个公司/组织成员加入.最初由IBM和DAH的工程师贡献,现在约有70名的代码贡献者,4000+代码提交,代码行数12万行左右.应用开发者使用SDK与Fabric平台交互,目前提供Node, Java和Python SDK,在Github上都可以搜索到.代码贡献方式介绍:https://hyperledger-fabric.readthedocs.io/en/release/CONTRIBUTING.html

2:Fabric源码及镜像文件处理 2.1下载Fabric源码 下载Fabric源码是因为要用到源码中提到的列子和工具,工具编译需要用到go语言环境,因此需要把源码目录放到$GOPATH下.通过1.3中go的安装配置,$GOPATH设置为/opt/gopath. 我们可以使用Git命令下载源码,也可以使用go get命令,偷懒一点,我们直接用go get命令获取最新的Fabric源码: go get github.com/hyperledger/fabric [注:使用离线环境或者内网环境的朋友

Fabric 1.4源码分析 kafka共识机制 本文档主要介绍kafka共识机制流程.在查看文档之前可以先阅览raft共识流程以及orderer服务启动流程. 1. kafka 简介 Kafka是最初由Linkedin公司开发,是一个分布式.分区的.多副本的.多订阅者,基于zookeeper协调的分布式日志系统,一种高吞吐量的分布式发布订阅消息系统.kafka详细介绍可以参考这一篇博客.kafka介绍 2. kafka共识 kafka共识当中,每个orderer节点即是生产者Producer也

Fabric 1.4 源码分析 区块同步 本文主要从源码层面介绍fabric peer同步区块过程,peer同步区块主要有2个过程: 1)peer组织的leader与orderer同步区块 2)peer组织间peer同步区块. 1. peer leader和orderer同步区块 首先,orderer对外主要是broadcast和deliver两个服务orderer服务介绍.并且我们知道peer和orderer同步区块肯定是deliver服务实现的,但是到底是peer从orderer拉还是ord

Fabric 1.4 源码分析peer节点启动 peer模块采用cobra库来实现cli命令. Cobra提供简单的接口来创建强大的现代化CLI接口,比如git与go工具.Cobra同时也是一个程序, 用于创建CLI程序 peer支持的命令如下所示: Usage: peer [command] Available Commands: chaincode Operate a chaincode: install|instantiate|invoke|package|query|signpackag

Fabric 1.4 源码分析 committer记账节点 本文档主要介绍committer记账节点如何初始化的以及committer记账节点的功能及其实现. 1. 简介 记账节点负责验证交易和提交账本,包括公有数据(即区块数据,包括公共数据和私密数据hash值)与私密数据.在提交账本前需要验证交易数据的有效性,包括交易消息的格式.签名有效性以及调用VSCC验证消息的合法性及指定背书策略的有效性,接着通过MVCC检查读写集冲突并标记交易的有效性,最后提交区块数据到区块文件系统,建立索引信息并保存

Fabric 1.4 源码分析 MVCC验证 读本节文档之前建议先查看[Fabric 1.4 源码分析 committer记账节点]章节. 1. MVCC简介 Multi-Version Concurrency Control 多版本并发控制,MVCC 是一种并发控制的方法,一般在数据库管理系统中,实现对数据库的并发访问.在数据库系统中,锁机制可以控制并发操作,但是其系统开销较大,而MVCC可以在大多数情况下代替行级锁,使用MVCC,能降低其系统开销.MVCC是通过保存数据在某个时间点的快照来实

Fabric 1.4 源码分析 Endorser背书节点 本文档主要介绍fabric背书节点的主要功能及其实现. 1. 简介 Endorser节点是peer节点所扮演的一种角色,在peer启动时会创建Endorser背书服务器,并注册到本地gRPC服务器(7051端口)上对外提供服务,对请求的签名提案消息执行启动链码容器.模拟执行链码.背书签名等流程.所有客户端提交到账本的调用交易都需要背书节点背书,当客户端收集到足够的背书信息之后,再将签名提案消息.模拟执行的结果以及背书信息打包成交易信息发给

Fabric 1.4 源码分析 背书节点和链码容器交互 本文档主要介绍背书节点和链码容器交互流程,在Endorser背书节点章节中,无论是deploy.upgrade或者调用链码,最后都会调用ChaincodeSupport.LaunchInit()/Launch()以及ChaincodeSupport.execute()方法.其中Launch()方法启动链码容器,execute()方法调用链码. 1. 准备 ChaincodeSupport.Launch()首先进行判断,根据peer侧该版本链

源码分析 代码结构 cloud-init的代码结构如下: cloud-init ├── bash_completion # bash自动补全文件 │   └── cloud-init ├── ChangeLog # 更新日志 ├── cloudinit │   ├── cloud.py # Cloud类 │   ├── cmd # 命令行操作目录 │   │   ├── clean.py # cloud-init clean │   │   ├── cloud_id.py # cloud-id

ABP是一套非常优秀的web应用程序架构,适合用来搭建集中式架构的web应用程序. 整个Abp的Infrastructure是以Abp这个package为核心模块(core)+15个模块(module).其中13个依赖于Abp这个核心包.另外两个包(FluentMigration,Web.Resources)相对独立 Abp.AutoMapper: 实现对象之间的自动映射. Abp.EntityFramework:通过EntityFramework实现数据访问层. Abp.FluentMigra

1. 引言     在红黑树--算法导论(15)中学习了红黑树的原理.本来打算自己来试着实现一下,然而在看了JDK(1.8.0)TreeMap的源码后恍然发现原来它就是利用红黑树实现的(很惭愧学了Java这么久,也写过一些小项目,也使用过TreeMap无数次,但到现在才明白它的实现原理).因此本着"不要重复造轮子"的思想,就用这篇博客来记录分析TreeMap源码的过程,也顺便瞅一瞅HashMap. 2. 继承结构 (1) 继承结构 下面是HashMap与TreeMap的继承结构: pu

nginx作为一个高性能的HTTP服务器,网络的处理是其核心,了解网络的初始化有助于加深对nginx网络处理的了解,本文主要通过nginx的源代码来分析其网络初始化. 从配置文件中读取初始化信息 与网络有关的配置命令主要有两个:listen和sever_name.首先先了解这两个命令的用法. listen listen命令设置nginx监听地址,nginx从这里接受请求.对于IP协议,这个地址就是address和port:对于UNIX域套接字协议,这个地址就是path. 一条listen指令只能

leader的实现类为LeaderZooKeeperServer,它间接继承自标准ZookeeperServer.它规定了请求到达leader时需要经历的路径: PrepRequestProcessor -> ProposalRequestProcessor ->CommitProcessor -> Leader.ToBeAppliedRequestProcessor ->FinalRequestProcessor 具体情况可以参看代码: @Override protected v

上文: zookeeper源码分析之一服务端启动过程 中,我们介绍了zookeeper服务器的启动过程,其中单机是ZookeeperServer启动,集群使用QuorumPeer启动,那么这次我们分析各自一下消息处理过程: 前文可以看到在 1.在单机情况下NettyServerCnxnFactory中启动ZookeeperServer来处理消息: public synchronized void startup() { if (sessionTracker == null) { createSe

znode 可以被监控,包括这个目录节点中存储的数据的修改,子节点目录的变化等,一旦变化可以通知设置监控的客户端,这个功能是zookeeper对于应用最重要的特性,通过这个特性可以实现的功能包括配置的集中管理,集群管理,分布式锁等等. 知识准备: zookeeper定义的状态有: Unknown (-1),Disconnected (0),NoSyncConnected (1),SyncConnected (3),AuthFailed (4),ConnectedReadOnly (5),Sasl

转载请在页首注明作者与出处 http://www.cnblogs.com/zhuxiaojie/p/6238826.html 一:本文使用范围 此文不仅仅局限于spring boot,普通的spring工程,甚至是servlet工程,都是一样的,只不过配置一些监听器的方法不同而已. 本文经过作者实践,确认完美运行. 二:Spring boot使用websocket 2.1:依赖包 websocket本身是servlet容器所提供的服务,所以需要在web容器中运行,像我们所使用的tomcat,当然