区块链(交易系统开发指南)

作者简介

武源文？ 北京宏畅通科技有限公司董事长，中关村大数据产业联盟副秘书长，区块链金融协会副会长，国内大数据领域和产业互联网发展专家，区块链和大数据领域专家，《区块链世界》《区块链与大数据》的主要作者。 在电信行业有超过20年的工作经验、10多年的电信行业软件项目经理经历，主持开发的系统用户数据超过5亿条。作为武汉长江大数据交易所总经理，主持开发的武汉大数据交易系统支持千万级用户的大数据交易。 柏罡？ 北京井立通科技有限公司研发经理，数字资产交易系统技术负责人，高级系统架构师。 在软件行业有13年工作经历，拥有丰富的金融、保险、电信领域软件产品设计研发经验，拥有每日60TB海量数据分析系统设计经验。 温江凌？ 大数据智能链创始人兼CEO，北京大地宝科技发展有限公司CEO，系统分析师。 在软件行业有23年工作经历，在电信行业有超过18年的工作经验，主持开发的系统日处理数据超过3亿条。在金融行业量化交易方面有7年工作经验。

内容简介

3.1.3　设计理念 1. 以空间换时间 （1）多级缓存，静态化 客户端页面缓存（HTTP header中包含Expires/Cache of Control、last modified（304，Server不返回body，客户端可以继续用Cache，减少流量）、ETag）。 反向代理缓存。 应用端的缓存（Memcache）。 内存数据库。 Buffer、Cache机制（数据库、中间件等）。 （2）索引 哈希索引适合于综合数组的寻址和链表的插入特性，可以实现数据的快速存取。 B树索引适合于以查询为主导的场景，避免多次I/O，可以提高查询效率。 倒排索引实现单词到文档映射关系的最佳实现方式和最有效的索引结构，被广泛用在搜索领域。 Bitmap是一种非常简捷、快速的数据结构，它能同时使存储空间和速度最优化（而不必以空间换时间），适合于海量数据的计算场景。 2. 并行与分布式计算 （1）任务切分，分而治之（MR） 在大规模的数据中，数据存在一定的局部性特征，利用局部性原理将海量数据计算的问题分而治之。 MR模型是无共享的架构，数据集分布至各个节点。在处理时，每个节点就近读取本地存储的数据进行处理（Map），并将处理后的数据进行合并（Combine）、排序（Shuffle and Sort）后再分发（至Reduce节点），避免了大量数据的传输，提高了处理效率。 （2）多进程、多线程并行执行（MPP） 并行计算（Parallel Computing）是指同时使用多种计算资源解决计算问题的过程，是提高计算机系统计算速度和处理能力的一种有效手段。它的基本思想是用多个处理器/进程/线程来协同求解同一个问题，即将被求解的问题分解成若干部分，各部分均由一个独立的处理器来并行计算。 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）的方式，减少对线程的切换（比如Oracle Latch设计）；对于计算复杂型的业务逻辑，可以充分利用多线程进行操作。 对于同一种类型的调用方式，对不同的业务进行合适的资源分配，设置不同的计算节点数量或者线程数量，对业务进行分流，优先执行优先级高的业务。 （4）容错隔离 当系统的有些业务模块出现错误时，为了减少在并发情况下对正常请求处理的影响，有时候需要考虑对这些处于异常状态的请求进行单独渠道的处理，甚至暂时自动禁止这些异常的业务模块。 有些请求的失败可能是偶然的、暂时的（比如网络不稳定导致的失败），需要考虑进行请求重试。 （5）资源释放 系统的资源是有限的，使用完后一定要在最后释放资源，面不管请求走的是正常路径还是异常路径，以便于资源的及时回收，供其他请求使用。 （6）超时 在设计通信架构时，往往需要考虑超时控制。 在接口调用过程中，Consumer调用Provider，Provider在响应时有可能会慢，如果Provider 10s响应，那么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）服务降级 降级服务既可以通过代码自动判断，也可以根据突发情况人工切换。 多年区块链交易系统产品研发实践经验的概括和总结 助你快速设计搭建一个属于自己的区块链交易系统 主题新颖：交易系统是区块链的重要组成部分，也是重要特色之一 全面系统：从交易系统架构设计到交易系统功能实现，面面俱到 内容实用：让交易系统技术不再为少数人所有，“刀刀见肉” 案例丰富：作者实际搭建过很多套交易系统，融入了很多案例