开发者进阶进阶222 次阅读
链重组处理：为什么确认数对开发者也重要
重组是共识机制的正常产物，被回滚的不只是交易还有事件。讲清确认数、索引回滚与幂等写入三种务实做法。
#链重组#确认数#事件监听#回滚#幂等
一句话结论
链重组不是极端情况，而是共识机制的正常工作方式。任何"读到交易就当真"的逻辑，在重组面前都会出错。
重组是怎么发生的
当两个出块者几乎同时产出区块时，网络会短暂出现分叉。共识规则最终让其中一条链胜出，另一条链上的区块被抛弃，其交易要么回到待处理队列，要么直接消失。于是原本"已确认"的交易可能不再存在，状态回退到分叉点之前——这就是重组。分叉点越靠近链头，发生的概率越高。
为什么对开发者也重要
- 事件会被回滚：你监听转账、铸造或余额变化事件并据以更新数据库时，依据的可能是一个最终被抛弃的区块。
- 日志本身带删除标记：节点会告诉你某条日志被移除了，忽略这个信号就会留下脏数据。
- 交易可能"成功过又消失"：界面上已经显示的"已完成"需要被打回去。
三种务实做法
一是按确认数分级处理。 低价值、可重试的动作（前端展示、通知）可以只等少量确认；涉及资金交付、发币、记账的动作应等更充分的确认，并且确认数可以随交易金额上调。
二是在索引器里实现回滚。 记录"每个区块对数据库做了什么"，检测到重组时按块号倒序撤销。这比"改完再修"可靠得多。
三是把幂等性做进去。 所有写库操作都设计成重复执行不产生副作用，用交易哈希或日志唯一键去重，这样重组后重新处理同一个事件不会重复记账。
给你的教训
- 不要用"最新区块"作为事件的最终判断依据，把确认数做成一个显式的、可配置的参数。
- 处理事件时先检查它是否已被移除，链上推送的日志本身就带这个信号。
- 索引表与业务表都要能按区块号回滚，否则一次重组就需要人工修数据。
- 面向用户的界面要区分"已提交"与"已确认"：不要把还会被回滚的状态展示成完成。