区块链:交易系统开发指南

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）服务降级 降级服务既可以通过代码自动判断，也可以根据突发情况人工切换。