在做链上查询这一类工作的时候, 有一个非常具体的问题一直在后面追着我不放, 而且我已经被它这样追了好几年的光景了。
当整体的数据规模一下子变得很大的时候, 去查某一个特定地址的交易记录, 或者说是想要去定位到底某笔交易的哈希值是多少, 这时候响应的速度就会发生非常夸张的变化, 直接就是从毫秒级的状态飙升到了秒级甚至更久的时间。
对于区块链快速查找而言, 最核心的矛盾点并不是说能不能够进行查询这种基本的问题, 而是关于延迟的事情, 关键是要把这个延迟在可以被接受的范围内尽可能压下去。
区块链快速查找怎么做
在当前的项目实践之中, 索引层的构建技术路径是绝对不会被忽略掉的。我们针对这个问题所选择的具体技术方案表现为离线批量索引加增量同步的形式。这个方案的主要执行步骤是先安排全量的历史数据先行全部导入到倒排索引里面去。
等到新的块被生产出来之后, 系统就只需要专门去处理那些新产生的属于增量部分的数据块了。在面临查询请求的时候, 系统会直接读取存放在本地的索引库来进行数据检索。这种方法从根本上避免了需要逐次扫描整个区块链上原始数据的耗时操作。
MerklePatriciaTree是专门负责存证与校验的, 那些真正承担查找任务的活儿, 其实是由旁边那套独立的索引服务来干的嘛, 二者的职责划分那是非常清楚的, 可别把它们强扭在一起搞耦合, 否则一旦改了索引结构的设置, 就会导致整个链条都得重新跑一遍。
区块链快速查找有哪些坑
一致性这个问题是最让人烦恼的。因为索引服务和最新链头之间, 总会存在几百毫秒到几秒的时间差。所以, 当用户刚刚发出交易就立刻去查询的时候, 绝大多数情况下是查不到相关信息的。为此, 我们的前端特意加上了"待确认"状态提示。这样做是为了防止用户误以为数据丢失了, 从而不断地去刷新页面。
在分片扩展这块领域里, 也是存在着各种各样的坑的。因为地址哈希分布这件事, 天生就容易出现不均匀的情况, 而那些热点地址的存在, 会使得单个分片的压力都集中到一起, 这种情况下, 非得去做二次散列不可, 只有这样才能够把数据打散。
还有那个增量同步链路, 一旦出现了中断的现象, 那么索引就会和链头出现脱节的状态，必须得要加上一个定期对账校验机制, 只有这样, 才能作为一个兜底的手段。
虽然不存在那种能够解决所有问题、一劳永逸的神奇方案, 但是只要索引设计得够合理, 增量数据连接的链路能够顺畅运行, 再加上对于一致性边界的处理也非常到位且干净利落, 那么最终使得链上查询体验降低到用户可以接受的范围内是完全可能的。
