前言

百万并发的业务需求显然是需要分布式系统才能完成的任务，用单个数据库完成会存在单点和扩展性问题

如果用分库分表方案，复杂度也很高，单个节点损坏同样影响整个系统，参考如下文章：

分层情况（总体）

任务生成
- 实时交易：实时交易由应用层生成通过负载均衡，经过交易校验后到排序出块层
- 批量交易：代扣代收规则已经确定后，由专门的批量模块生成相关预备数据给执行者了，到合适时间，排序出块层单独通道加入了拆分后的部分批量执行指令（批量指令预先拆分过，不是边处理边拆分，减少网络流量）
任务排重、打包、发布（采用块链式结构，保证交易顺序性，减少传输验证hash的成本）
任务并发执行
- 任务分解（实时交易分解成一加一减，批量任务已经预先分解成n个，触发即可）
- 任务分散执行（按from to地址分解，相关地址分在一个执行包，每个线程只管自己部分的任务执行，并将执行结果反馈给master线程汇总判断，并有CAS判断机制，如果有潜在冲突也能重新执行）
- 执行结果判断OK后，生成本块的mpt树根，格式（区块号码和树根hash），并将本次kv对的set动作放入写入队列中，最后写入mpt树根；后续根据区块对应的mpt树根，就可以调用磁盘上leveldb中保存的数据，重构当前mpt树根对应的账户余额

在这里插入图片描述

在这里插入图片描述

slaver执行单点问题，只影响一部分，但是这部分就不能执行了，我们这边方案类似于传统数据库的分库分表，对数据库的健壮性还是有要求的，初期为求快，对出问题后自动恢复的考虑少点
能执行的业务比较单一