把区块链技术里的缓冲机制说白了就是给存在链上的数据设置了一个中间过渡的层次。这样做的目的是让数据的写入操作和读取操作不再非要去挤占用同一个处理环节。我接触这个领域的技术已经有两年多的时间了。
在刚刚开始的时候, 我心里头想的不就是通过它不就是实现一个队列功能嘛。后来在实际应用里慢慢发现了这玩意儿是真的能够切实解决好多实际工作当中的痛点。今天我就打算把它的前因后果仔仔细细地给大家讲明白透彻一点。
区块链buf是啥原理
其核心思路其实并不复杂, 就是在交易数据写入区块链之前, 先让其落入一个临时的缓冲池当中, 等到攒够了一批数量或者满足了特定的条件之后, 然后再进行打包并上链。这样做的好处在于, 在高并发访问的时段, 可以防止将验证节点压垮无法正常工作, 这种做法本质上就是一种削峰的操作方式。
但是,缓冲池本身内部的共识机制这一块内容, 才是真正比较难的点。因为buf这个层级也得有那种轻量级别的节点共识才行, 不然那些缓冲的数据到底由谁来验证、又由谁来防止被篡改呢, 这是一个必须面临的问题。
在目前看来, 主流的这样的方案是用的那种简化版本的BFT算法, 把节点的数压到一个个位数的这么小范围就能运行跑了, 延迟的这部分是可以控制的, 是可控状态下的。
区块链buf怎么用合适
适合的场景是相当明确的, 也就是说, 是针对那些高频的、小额的写入操作, 以及物联网设备的数据上报场景, 还有链下计算完成之后的结果回传。
对于一个工厂而言, 其传感器每秒产生的几百条数据, 如果全部被塞到区块链上面去的话, 这既是不现实的, 也是完全没有必要的, 通过缓冲区进行攒批之后再上传到链上, 其成本直接就砍掉了一个数量级。
需要避免的陷阱也确实存在。一旦buf层出现故障, 缓冲数据就会全部丢失, 所以必须完成持久化备份工作。攒批策略如果设置得过于激进, 会导致用户体验变差, 但如果设置得过于保守, 就无法达到削峰的效果, 因此需要根据业务节奏进行调整。
在挑选_buf_方案的时候, 一定不要只看吞吐量这一个指标, 因为节点是不是稳定、缓冲数据安不安全工作中的安全, 这两件事才是真正决定成败的关键命脉所在, 因为我见过非常多团队就是因为在这两个地方栽了跟头。
