共识这一步一慢下来，整条链上的业务都得跟着等
提交一笔记录，不是写完就完，还得等各家把账对齐才算落定。这一步慢了，上游的页面就一直转，下游按「已存证」才敢走的动作全排在后面，慢的是一处，等的是一整条。一、出块间隔
间隔定多长，按业务能等多久倒着推。对账类的活隔一夜也无妨，现场要当场拿凭证的，等十几秒都嫌长，这两类不该挤在同一条节奏里。报改动时把相关几类活各自能容的等待写在一栏，看的人按那一栏判断该排在哪个时段做，比只写一句要调参数清楚，也不必来回追问到底急不急。
间隔别频繁调，每调一次各家都要跟着校一遍参数。调完没通知到的那家还按老节奏发，轻则排队，重则被当成异常挡在外面。发版窗口避开对账那几个时点，共识一慢，上游页面一直转，下游按已落定才敢走的动作全排在后面，挑个闲时段调参数省心得多。
二、批量再提交
零散的小笔先在自家汇成一批，链上留这批的根，比一笔笔递省不少等待。明细仍在自家库，验的时候顺着根能找到具体那一条，效果一样。各家的等待时间分列成几行报上来，别合成一个数交差，分行看才瞧得出是谁在拖，合成的那条线平平整整，往往正好把该看的那处盖住。
批的大小按峰值定，别攒到很大才发。攒得越大，中间出点岔子要重来的就越多，等的时间没省下，反倒把一批都拖住了。成本上把待落定队列占的资源和批量提交省下的等待一起算，批攒得越大，中间出岔子要重来的越多，账不是单向省的。
三、失败重试
没落定的那笔要能认出来、能再递一次，别当成新的一笔又提交一遍。认不出来，链上就出现两条一样的内容，验真时对得上，统计时却多算了一份。接不进去时上游该怎么做，写进对接页并知会到每个接入方，写的是同一套做法，恢复之后送来的东西形状才齐，不用再逐家问当时各自怎么处理。
重试隔开一小段再来，别一失败就连着敲。多数慢是暂时的，连着敲只会把队列越堆越长，本来等一下就好的事，变成两边一起堵。值班交接把眼下开没开旁路、开了多久交清楚，旁路开着没人管，慢慢会变成默认路径，链上那部分反倒成了事后补录。
四、积压有边界
待落定的队列给个明确的边界，到了就先停下接收，把话说给上游听。边界不设，前面一直涌进来，越积越深，等恢复时要清的是几个小时的量。新接入的一方先在演练环境把单据从头到尾走通，走完由熟手在清单上打勾，勾齐了再开正式权限，这一步卡得住，后面要圆的场就少得多。
到边界时上游该怎么做也写清楚：是排队等，还是先记在自家、回头补。没写，各家自己拿主意，恢复以后数据形状就五花八门了。复盘时把延迟悄悄涨起来的那几段挑出来看，笔数还正常的时候它先动，这时候动手还从容，等成功笔数掉了再查就晚了。
五、监控看延迟
盯着「提交到落定」这段时间，比只盯成功笔数有用。笔数还正常，延迟悄悄涨起来，往往就是快要堵住的先兆，这时候动手还从容。成本上把写错之后补说明、通知各家、在报表里长期挂个例外的工夫折进去，比提交前多一个人看半分钟贵出许多倍。
延迟按各家分开看，能看出是全网都慢还是某一家掉队。混成一条平均值，一家的慢被其余几家一平均，曲线平得看不出毛病。新人演练让他造一次受控的积压，看边界到了之后上游怎么被挡、恢复后按什么顺序补，走过一轮比读几页参数记得牢。
六、降级走旁路
共识一时半会儿缓不过来，业务不能整条停摆。先在本地记下待补的一笔，给上游一个「已收、待落定」的凭据，等恢复再按顺序补进去。
旁路开多久、谁来关，写进值班事项。开着没人管，慢慢就变成默认路径，链上那部分反而成了事后补录，当初要的那份依据就淡了。参数每动一次，把通知到哪几家、各自回没回话记成一张回执表，表上留空的先补一轮再算改完，补过之后谁按哪版跑就都有据可查。
共识慢不是稀奇事，稀奇的是慢的时候整条业务都只能干等。间隔、批量、重试、边界、延迟、旁路，六处备好，等也等得有数；只按顺畅的时候设计，一堵就全乱。 说得很有道理，很多观点都说到点子上了，希望以后能多看到这类帖子。 认真看完了整篇内容，感觉受益匪浅，期待楼主后续更多优质的分享。 希望楼主常来发帖，持续输出优质内容，我们都会一直支持你。 看完感觉打开了新思路，以后遇到类似情况知道该怎么处理了。
页:
[1]