1、Orderer节点和通道配置
orderer节点除了扮演排序的角色外，还维护允许创建通道的组织的列表（联盟），该列表本身保存在“orderer系统通道”的配置中。默认情况下，此列表只能由所处通道排序管理员编辑。
orderer节点还对通道实施基本的访问控制，限制对于通道的读写以及配置权限。有权修改通道配置的人员必须受到相关管理员在创建联盟或通道时设置的策略的约束。修改配置也是以transaction的形式进行的。
2、Orderers和Transaction流程
第一阶段：提议
客户端应用程序将transaction提议发送给对等方的子集，相应的对等方调用智能合约产生建议的ledger更新，然后对结果进行认可。认可的对等方此时并不将更新应用于其账本副本，而是将对于提议的响应返回到客户端应用程序，当客户端应用程序接收到足够多的（满足认可策略）认可的提议响应后，进入第二阶段。
第二阶段：打包
客户端应用程序将收到的由需要的对等节点认可的交易提议响应提交到排序服务节点，排序节点将某一时间内收到的所有transactions按一定的顺序打包成块，并分发到通道上的所有对等节点上，以进行最终验证。
hyperledger fabric会对区块内的transactions进行严格排序，这和其他区块链不同，其他区块链中，同一笔交易可以打包成多个不同的区块，竞争形成一个链，在hyperledger fabric中，排序服务生成的区块是最终的，一旦将transaction写入一个块，就可以确保其在ledger中的位置，hyperledger fabric的终结性意味着没有分类账分叉，验证的交易将永远不会被还原或丢弃。
排序节点不会对transaction的内容作出判断（通道配置transaction除外）。
第三阶段：验证和提交
排序节点将区块分发给与其相连的所有对等点，并非每个对等点都需要连接orderer，对等点可以使用gossip协议将区块分发到其他对等点。
每个对等点独立以确定的方式验证区块，即验证区块中每个transaction是否由需要的组织对等方认可，并未被其他最近提交的transaction导致为无效（似乎就是前面所说的验证读集）。无效的transaction仍保留在orderer创建的不可变区块中，但对等方将其标记为无效，并且不会更新ledger状态。
3、排序服务实现
排序服务实现有：Raft、Kafka、Solo，但是后两者在V2.0版本中都弃用了。
Raft：Crash Fault Tolerant（CFT）排序服务，遵循“leader and follower”模型，leader的决定会被follower复制。
Kafka：类似于基于Raft的排序，但是Kafka集群的额外开销令人生畏。
Solo：测试中用的单排序节点结构。
Raft协议Fabric实现:
Raft协议的Fabric实现使用“leader and follower”模型，leader是在通道中的排序节点之间动态选举的（参与者集），leader节点将消息复制到follower节点，只要系统中绝大多数节点存在，系统就可以接受包括leader节点在内的节点丢失，因此Raft被称为“故障容错”（3个节点可以丢失1个，5个节点可以丢失2个）。
Raft和Kafka区别：Raft更容易安装，更有利于系统的分散，减少了额外的学习，是Fabric开发拜占庭容错排序服务的第一步。
Raft排序服务也有可能丢失transaction，例如leader大约在follower提供确认同时崩溃，因此，应用程序客户端无论如何都应在对等节点上监听提交transaction（验证transaction），但是要格外小心，客户端也要能容忍超时（配置的时间范围内完成对transaction的排序打包）。在超时的情况下，重新提交transaction或收集一组新的认可，取决于应用程序。
Raft协议相关概念：
Log entry（日志记录）：Raft排序服务中的主要工作单元，如果大多数成员同意记录及其顺序，则我们认为日志是一致的。
参与者集：排序节点积极参与给定通道的共识机制，并接受该通道的复制日志，可以是所有可用节点。
有限状态机（FSM）：每个排序节点都有一个FSM，它们共同用于确保各个排序节点中日志的顺序是以相同的顺序编写。
法定人数：描述需要确认transaction以便可以排序transaction的参与者的最小数量，对于每个参与者集，这是大多数节点，任何原因导致的无法达到法定数量的节点，则排序服务集群无法用于通道上的读写，无法提交日志。
leader：在任何给定的时间，通道的参与者集会选举一个节点作为leader，负责提取新的日志记录，并将其复制到follower排序节点，并管理何时将记录视为已提交。这不是排序节点的特殊类型，只是其在某些时候扮演的角色。
follower：从leader那里接受日志并复制它们，以确保保日志保持一致。follower还会从leader那里收到“心跳”信息，如果leader在可配置的时间内停止发送这些信息，则follower将发起leader选举，其中一个将被选举为新的leader。
Raft中选举leader的工作方式：
raft节点始终处于以下三种状态之一：follower、候选者、leader。若在设定的时间段内没有收到日志记录或者心跳，则节点自动升级为候选者，并向其他节点请求投票，如果获得法定人数的选票，则晋升为leader。
快照：
排序节点出现故障时，用于重新获得重启时丢失的日志的机制。用户可以在快照中定义将在日志中保留多少字节的数据，此数据量符合一定数量的块（快照中仅存储完整的块）。
————————————————
版权声明：本文为CSDN博主「Galar Xia」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/Nemoosi/article/details/104537568