《区块链：交易系统开发指南》

书海网短评：
适读人群：多年区块链交易系统产品研发实践经验的概括和总结，区块链交易系统实现大揭秘，助你快速设计搭建自己的区块链交易系统，区块链大咖孟岩及众专家力荐，区块链和通证经济时代技术人员必备多年区块链交易系统产品研发实践经验

编辑推荐

适读人群：多年区块链交易系统产品研发实践经验的概括和总结，区块链交易系统实现大揭秘，助你快速设计搭建自己的区块链交易系统，区块链大咖孟岩及众专家力荐，区块链和通证经济时代技术人员必备

多年区块链交易系统产品研发实践经验的概括和总结，区块链交易系统实现大揭秘，助你快速设计搭建自己的区块链交易系统，区块链大咖孟岩及众专家力荐，区块链和通证经济时代技术人员必备。

多年区块链交易系统产品研发实践经验的概括和总结

助你快速设计搭建一个属于自己的区块链交易系统

主题新颖：交易系统是区块链的重要组成部分，也是重要特色之一

全面系统：从交易系统架构设计到交易系统功能实现，面面俱到

内容实用：让交易系统技术不再为少数人所有，“刀刀见肉”

案例丰富：作者实际搭建过很多套交易系统，融入了很多案例

内容简介

《区块链：交易系统开发指南》使用通俗易懂的语言，从技术的角度详细介绍了区块链交易系统应有的功能架构及工作原理，让人们能够张开双臂轻松地拥抱区块链技术，享受区块链交易系统带来的惊喜与成就感。

《区块链：交易系统开发指南》共分7章，第1~2章主要介绍区块链及数字货币的基本概念，以及各种公有链的API接口；第3~5章主要介绍区块链交易系统的分类架构及功能；6章主要介绍区块链交易系统面临的问题及演进方向；第7章对《区块链：交易系统开发指南》做了总结。

《区块链：交易系统开发指南》是作者多年从事区块链交易系统产品研发实践经验的概括和总结，实用性和技术指导性较强，可供从事区块链产品研发和区块链交易系统研发的人员参考研究，也可供希望了解区块链技术或希望投身于区块链交易系统开发的技术人员学习。《区块链：交易系统开发指南》同样适用于传统行业、互联网金融等一些非区块链行业中从事电子商务、在线购物等其他交易系统产品研发、测试、维护等的技术人员参考学习。

作者简介

武源文

北京宏畅通科技有限公司董事长，中关村大数据产业联盟副秘书长，区块链金融协会副会长，国内大数据领域和产业互联网发展专家，区块链和大数据领域专家，《区块链世界》《区块链与大数据》的主要作者。

在电信行业有超过20年的工作经验、10多年的电信行业软件项目经理经历，主持开发的系统用户数据超过5亿条。作为武汉长江大数据交易所总经理，主持开发的武汉大数据交易系统支持千万级用户的大数据交易。

柏罡

北京井立通科技有限公司研发经理，数字资产交易系统技术负责人，高级系统架构师。

在软件行业有13年工作经历，拥有丰富的金融、保险、电信领域软件产品设计研发经验，拥有每日60TB海量数据分析系统设计经验。

温江凌

大数据智能链创始人兼CEO，北京大地宝科技发展有限公司CEO，系统分析师。

在软件行业有23年工作经历，在电信行业有超过18年的工作经验，主持开发的系统日处理数据超过3亿条。在金融行业量化交易方面有7年工作经验。

精彩书评

区块链正在步入3.0时代，越来越多的传统企业与区块链结合，发行自己的数字资产，交易系统在数字资产的交易中起着重要的作用。通过阅读《区块链：交易系统开发指南》，开发团队可以快速开发出一个属于自己的区块链交易系统，让数字资产在一定范围内自由交易，形成相对稳定的企业联盟。《区块链：交易系统开发指南》内容通俗易懂，通过大量的源码和示例介绍区块链交易系统的开发过程，是一本难得的讲解区块链技术重要环节的好书，值得区块链开发者、爱好者和区块链技术公司人员阅读。《区块链：交易系统开发指南》一定会在区块链的发展历程中留下光辉的一笔。

——程晓明中国社会科学院博士、新三板教父

交易是一种基本的经济活动，在区块链生态中其集中在交易所是不合理和不科学的，交易应该随时都能得到实施。从这个角度来说，交易系统是生态的基础设施。《区块链：交易系统开发指南》从技术角度系统阐述了交易系统，不仅可以为技术人员提供参考，也可以为相应的监管部门提供参考。

——高斌中国区块链普及工程推进联盟秘书长、旗点商学院院长

传统的证券交易市场通常赋有国家荣誉属性，其核心交易系统大多是由精英团队开发的，以保障高吞吐量、高安全性的交易。交易系统的架构与技术往往不被外界所知，除在专业性很强的期刊或专利搜索上可以查询到部分内容以外，系统性介绍相关内容的书籍基本没有。近年来，随着比特币等数字资产的蓬勃兴起，相关的交易需求日益增加，交易系统的建设也呈现出社区化与平民化的趋势。《区块链：交易系统开发指南》所讲解的数字货币的交易系统技术基本上是以开源软件为基础的，加上钱包模块等处理加密货币必要的组件，《区块链：交易系统开发指南》系统性、逻辑性和实用性都非常强，是人人可以写数字货币交易系统时代不可多得的开发指南。从完备性的角度来看，没有理由认为基于《区块链：交易系统开发指南》开发出来的系统，在可用性和安全性上不可以比肩传统证券交易所的核心系统。

——左涛中国香港交易所原董事总经理兼HKEX内地技术公司总经理、大连商品交易所原首席架构师

精彩书摘

3.1.3　设计理念

1.以空间换时间

（1）多级缓存，静态化

客户端页面缓存（HTTPheader中包含Expires/CacheofControl、lastmodified（304，Server不返回body，客户端可以继续用Cache，减少流量）、ETag）。

反向代理缓存。

应用端的缓存（Memcache）。

内存数据库。

Buffer、Cache机制（数据库、中间件等）。

（2）索引

哈希索引适合于综合数组的寻址和链表的插入特性，可以实现数据的快速存取。

B树索引适合于以查询为主导的场景，避免多次I/O，可以提高查询效率。

倒排索引实现单词到文档映射关系的最佳实现方式和最有效的索引结构，被广泛用在搜索领域。

Bitmap是一种非常简捷、快速的数据结构，它能同时使存储空间和速度最优化（而不必以空间换时间），适合于海量数据的计算场景。

2.并行与分布式计算

（1）任务切分，分而治之（MR）

在大规模的数据中，数据存在一定的局部性特征，利用局部性原理将海量数据计算的问题分而治之。

MR模型是无共享的架构，数据集分布至各个节点。在处理时，每个节点就近读取本地存储的数据进行处理（Map），并将处理后的数据进行合并（Combine）、排序（ShuffleandSort）后再分发（至Reduce节点），避免了大量数据的传输，提高了处理效率。

（2）多进程、多线程并行执行（MPP）

并行计算（ParallelComputing）是指同时使用多种计算资源解决计算问题的过程，是提高计算机系统计算速度和处理能力的一种有效手段。它的基本思想是用多个处理器/进程/线程来协同求解同一个问题，即将被求解的问题分解成若干部分，各部分均由一个独立的处理器来并行计算。

MPP和MR的区别在于，它是基于问题分解的，而不是基于数据分解的。

3.多维度可用

（1）负载均衡、容灾、备份

随着平台并发量的增大，需要扩容集群节点，利用负载均衡设备进行请求的分发。通常负载均衡设备在提供负载均衡的同时，也提供了失效检测功能。为了提高可用性，需要有容灾备份，以防止节点宕机失效带来不可用问题。备份分为在线和离线两种，可以根据失效性要求的不同，选择不同的备份策略。

（2）读写分离

读写分离是针对数据库来讲的，随着系统并发量的增大，提高数据访问可用性的一个重要手段就是写数据和读数据分离。当然，在读写分离的同时，需要关注数据的一致性问题；对于一致性问题，在分布式系统CAP定理中应更多地关注可用性。

（3）依赖关系

平台中各个模块之间的关系尽量低耦合，可以通过相关的消息组件进行交互，能异步的则异步，分清楚数据流转的主流程和副流程，主、副是异步的。比如记录日志可以异步操作，以增加整个系统的可用性。

当然，在异步处理中，为了确保数据被接收或处理，往往需要确认机制（Confirm、Ack）。然而，在有些场景中，虽然请求已经得到处理，但是因其他原因（比如网络不稳定）确认消息没有返回，那么在这种情况下就需要进行请求的重发，对请求的处理设计因重发因素需要考虑幂等性。

（4）监控

监控也是提高整个平台可用性的一个重要手段，多平台进行多个维度的监控；模块在运行时是透明的，以达到运行期白盒化。

4.伸缩性

（1）拆分

拆分包括对业务的拆分和对数据库的拆分。

系统的资源是有限的，对于执行时间比较长的业务，如果采用一竿子执行的方式，在大量并发操作下，这种阻塞方式无法有效地及时释放资源给其他进程使用，从而导致系统的吞吐量不高。因此需要对业务进行逻辑分段，采用异步非阻塞方式，提高系统的吞吐量。

随着数据量和并发量的增大，读写分离不能满足系统并发性能的要求，需要对数据进行切分，包括对数据进行分库和分表。这种分库分表的方式，需要增加对数据的路由逻辑支持。

（2）无状态

对于系统的伸缩性而言，模块最好是无状态的，通过增加节点就可以提高整个系统的吞吐量。

5.优化资源的利用

（1）系统容量有限

系统的容量是有限的，其承受的并发量也是有限的，所以在进行架构设计时，一定要考虑流量控制，防止因意外攻击或者瞬时并发量的冲击导致系统崩溃。比如可以考虑对请求进行排队，如果超出预期的范围，则可以进行告警或者丢弃。

（2）原子操作和并发控制

对于对共享资源的访问，为了防止冲突，需要进行并发控制，同时对于有些交易需要通过事务性来保证一致性。所以在进行交易系统设计时，需要考虑原子操作和并发控制。

保证并发控制常用的一些高性能手段有乐观锁、Latch、Mutex、写时复制、CAS等；多版本并发控制（MVCC）通常是保证一致性的重要手段，它在数据库设计中经常被用到。

（3）基于不同的逻辑，采取不同的策略

平台中的业务逻辑存在不同的类型，有计算复杂型的、有消耗I/O型的，并且就同一种类型而言，不同的业务逻辑消耗的资源数量也是不一样的，这就需要针对不同的逻辑采取不同的策略。

针对消耗I/O型的业务逻辑，可以采取基于事件驱动的异步非阻塞方式，单线程方式可以减少线程切换引起的开销，或者在多线程的情况下采取自旋（Spin）的方式，减少对线程的切换（比如OracleLatch设计）；对于计算复杂型的业务逻辑，可以充分利用多线程进行操作。

对于同一种类型的调用方式，对不同的业务进行合适的资源分配，设置不同的计算节点数量或者线程数量，对业务进行分流，优先执行优先级高的业务。

（4）容错隔离

当系统的有些业务模块出现错误时，为了减少在并发情况下对正常请求处理的影响，有时候需要考虑对这些处于异常状态的请求进行单独渠道的处理，甚至暂时自动禁止这些异常的业务模块。

有些请求的失败可能是偶然的、暂时的（比如网络不稳定导致的失败），需要考虑进行请求重试。

（5）资源释放

系统的资源是有限的，使用完后一定要在最后释放资源，面不管请求走的是正常路径还是异常路径，以便于资源的及时回收，供其他请求使用。

（6）超时

在设计通信架构时，往往需要考虑超时控制。

在接口调用过程中，Consumer调用Provider，Provider在响应时有可能会慢，如果Provider10s响应，那么Consumer也会至少10s才响应。如果出现这种情况的频度很高，那么就会整体降低Consumer端服务的性能。

这种响应时间慢的症状就会像一层一层波浪一样，从底层系统一直涌到最上层，造成整个链路的超时。所以，Consumer不可能无限制地等待Provider接口的返回，它会设置一个时间阈值，如果超过了该阈值，就不继续等待了。

对超时时间的选取，一般看Provider正常响应时间是多少，再追加一个Buffer即可。

（7）重试

设置超时时间是为了保护服务，避免因为Provider响应慢，Consumer服务也变得响应很慢，这样Consumer就可以尽量保持原有的性能。

但是也有可能Provider只是偶尔抖动，如果超时后直接放弃，不做后续处理，就会导致当前请求错误，也会带来业务方面的损失。所以对于这种偶尔抖动，可以在超时后进行请求重试，如果重试时正常返回了，那么这次请求就被挽救了，能够正常给前端返回数据，只不过比原来响应慢一点。

重试时的细化策略是：重试时可以考虑换一台机器来进行调用，因为原来的机器可能由于临时负载高而性能下降，重试会加剧其性能问题，而换一台机器更快返回的概率也更大一些。

（8）幂等

如果允许Consumer重试，那么Provider就要能够做到幂等。即同一个请求被Consumer多次调用，对Provider产生的影响（一般指与某些写入相关的操作）是一致的。而且这个幂等应该是服务级别的，而不是某台机器层面的，重试调用任何一台机器都应该做到幂等。

（9）熔断

重试是为了应付偶尔抖动的情况，以求更多地挽回损失。可是如果Provider持续的响应时间超长，该怎么办呢?

如果Provider是核心路径的服务，宕掉基本就没法提供服务了，那我们也没办法。但如果是一个不那么重要的服务，却因为这个服务响应时间长导致Consumer里面的核心服务也被拖慢，那就得不偿失了。

一般超时时间都比平均响应时间长一些，现在所有到达Provider的请求都超时了，那么Consumer请求Provider的平均响应时间就等于超时了，系统变慢，服务的响应能力下降。

而重试则会加重这种问题，使Consumer的可用性变得更差。因此就出现了熔断的逻辑，即如果检查出来频繁超时，就把Consumer调用Provider的请求直接短路掉，不实际调用，而是直接返回一个mock的值。等Provider服务恢复稳定之后，再重新调用。

（10）限流

上面几种策略都是Consumer针对Provider出现的各种情况而设计的。而Provider有时候也要防范来自Consumer的流量突变问题。

比如有这样一个场景：Provider是一个核心服务，给N个Consumer提供服务，突然某个Consumer的流量飙升，占用了Provider大部分机器时间，导致其他可能更重要的Consumer不能被正常服务。

对于这样的场景，Provider端需要根据Consumer的重要程度，以及平时的QPS大小，给每个Consumer设置一个流量上限，在同一时间内只会给一个Consumer提供N个线程支持，超过限制则等待或者直接拒绝。

（11）资源隔离

Provider可以对从Consumer来的流量进行限制，防止Provider被拖垮。同样，Consumer也需要对调用Provider的线程资源进行隔离，这样可以确保调用某个Provider逻辑不会耗光整个Consumer的线程池资源。

（12）服务降级

降级服务既可以通过代码自动判断，也可以根据突发情况人工切换。

前言/序言

序

交易（transaction）是最基本的经济活动，也是区块链中最基本的数据结构。我当初学习比特币技术的时候，对比特币中的transaction数据结构设计狠下过一番工夫进行研究。然而，比特币中的交易是单向的，只包含了资金侧的转账支付（transfer/pay），并不包含商品和服务流一侧的数据。在理想的通证经济系统中，交易的双侧都应该表达为通证的流转，也就是代表价值的通证与代表商品与服务权益的通证在交易中进行原子化的所有权对调（exchange）。

麻烦的是，在中文区块链世界里，我们把transaction翻译成“交易”，把exchange也翻译成“交易”，这就摆了乌龙。实际上，transaction在数据库技术世界中被普遍翻译为“事务”，强调的是其原子性—要么保持原状，要么完全成功，没有中间状态。在transaction中既包括transfer/pay，也包括exchange，还可以有其他更复杂的操作，因此在区块链世界里，将transaction翻译成“交易”是不合适的。交易，要有来有往，有交有易。所以，exchange才是交易。

支付（transfer/pay）是单向的，而交易（exchange）是双向的。通证经济的基础设施，将会努力将各种价值和权益都通证化，因此在通证经济中交易表现为两份通证的对换。你去电商网站购买商品，其实花出去的是数字货币，买到的是一张数字合同，这才是这次交易的本质。至于商家通过快递将商品发送给你，只是对数字合同规定条款的履约行为，是“副作用”。单向的通证流转（transfer/pay），以及双向的通证对换交易（exchange），这是未来通证经济中最基本的两个事务性操作。后者当然要比前者复杂，但由于包含了完整的交易流信息，因此可以更好地进行验证、追溯、分析和优化，其价值要比前者高得多。

理解了这一点，我们就会明白，在未来的大多数通证经济应用场景下，交易（exchange）将成为最普遍的基本操作。在通证经济里，购物是交易，阅读是交易，发表文章是交易，投票是交易，可能说句话都是交易。我们甚至可以把本来是支付的操作升级为交易—用户的支付行为，实际上是用一笔数字资产交换一个数字收据。这样一来，我们也可以认为，未来的世界，交易将是泛在（pervasive）的。

然而，看看我们现在的区块链和通证技术圈子，交易这一操作只集中出现在一个场所中，那就是交易所。而在其他大部分区块链和通证经济应用中，都回避了双向的exchange，而钟情于单向的transfer/pay。在这样的架构下，从区块链上你只能看到交易的一半，看不到另一半。这显然不能被视为通证经济的高级状态。

我在这里大胆猜测，未来在每一个区块链和通证经济应用当中，都需要有交易系统的功能，或者内置，或者外包，或者服务化，总之，交易系统将无所不在，集合竞价的交易模式将无所不在。也就是说，未来当通证经济发展到成熟阶段的时候，交易系统将不独为某一类特别组织所有，而是泛在的基础设施。交易系统技术将成为与Web后端一样被广泛研究的技术，数以百万计的开发者将会在这个领域工作。因此，学习和研究交易系统技术，对于今天的技术人员来说，绝对是最具价值的投资之一。

遗憾的是，交易系统开发绝非易事，不但涉及面广，而且在性能、并发、安全等核心技术上有极大的挑战。更糟糕的是，市面上探讨交易系统开发技术的资料十分稀缺，高质量的内容更加少见。

由井通生态团队编写的这本开发指南，几乎是目前市面上唯一一本从开发技术层面阐述交易系统的图书，可谓本类作品的一个起点。可贵的是，这个起点相当高，这《区块链：交易系统开发指南》不但内容丰富，覆盖了区块链交易系统的各个方面，而且特别“实诚”，可谓“刀刀见肉”，章章都是实料。我本人并非这个领域的专家，但是翻读此书，对于交易系统的认识有了很大的提升。如果读者是一位有经验的开发者，那么这《区块链：交易系统开发指南》应该可以引导他走入区块链交易系统开发的大门。

很愿意向技术圈的朋友推荐这《区块链：交易系统开发指南》，我相信这《区块链：交易系统开发指南》会在中国区块链和通证经济的发展进程中留下自己的印记。

孟岩

前言

在区块链问世的第10个年头，区块链和区块链技术已经越来越多地出现在我们的生活中，越来越深入地改变着我们的价值传递方式。区块链交易系统可以为价值传递提供安全、可靠、便捷的活动场所，因此也逐渐受到人们的青睐。而如果没有系统地研究学习过区块链，则很容易被各种抽象概念和复杂的设计理念搞得云里雾里摸不着头脑。若要想设计搭建一个属于自己的区块链交易系统，更是无从下手。《区块链：交易系统开发指南》使用通俗易懂的语言，介绍了区块链的基本概念、设计思想，并从技术的角度详细介绍了区块链交易系统应有的功能架构及工作原理，目的就是揭开区块链交易系统的神秘面纱，填坑清障，指引前行，让人们能够张开双臂轻松地拥抱区块链技术，享受区块链交易系统带来的惊喜与成就感。

《区块链：交易系统开发指南》共分7章，第1~2章主要介绍区块链及数字货币的基本概念，以及各种公有链的API接口；第3~5章主要介绍区块链交易系统的分类架构及功能；第6章主要介绍区块链交易系统面临的问题及演进方向；第7章对《区块链：交易系统开发指南》做了总结。王春、王万云、王亚伟、魏庆伟、潘子鑫、郝运锴、张庆娜等协助《区块链：交易系统开发指南》作者完成了大量的资料收集和整理工作，计松辰对《区块链：交易系统开发指南》内容进行了统稿。

《区块链：交易系统开发指南》是作者多年从事区块链交易系统产品研发实践经验的概括和总结，实用性和技术指导性较强，可供从事区块链产品研发和区块链交易系统研发的人员参考研究，也可供希望了解区块链技术或希望投身于区块链交易系统开发的技术人员学习。《区块链：交易系统开发指南》同样适用于传统行业、互联网金融等一些非区块链行业中从事电子商务、在线购物等其他交易系统产品研发、测试、维护等的技术人员参考学习。

在《区块链：交易系统开发指南》出版之际，衷心感谢张少华、李孟杰、郭媛媛、王春、王栋、韩金祺、赵树理等与我们分享了运营实践、产品架构设计等多个层面的丰富经验，并为《区块链：交易系统开发指南》的编写提出了非常宝贵的意见和建议；感谢在《区块链：交易系统开发指南》编写过程中给予我们大力支持和帮助的各界人士；感谢电子工业出版社的大力支持。在《区块链：交易系统开发指南》编写过程中参考了大量的文献资料，对这些文献资料的作者表示真诚的谢意。

由于水平有限，书中难免出现纰漏和不妥之处，敬请读者朋友们批评指正。