专栏名称: 程序人生

十年漫漫程序人生，打过各种杂，也做过让我骄傲的软件；管理过数十人的团队，还带领一班兄弟姐妹创过业，目前在硅谷一家创业公司担任 VP。关注程序人生，了解程序猿，学做程序猿，做好程序猿，让我们的程序人生精彩满满。

ABT network 部署记

程序人生 · 公众号 · 程序员 · 2019-03-31 13:12

正文

请到「今天看啥」查看全文


   
    
     update_asset
    
    :
    
     5


   
    
     consume_asset
    
    :
    
     5


   
    
     simulations
    
    :


   
    
     -
    
    
     name: exchange token and assets


   
    
     type
    
    :
    
     exchange


   
    
     settings
    
    :


   
    
     value
    
    :
    
     "1000..20000"


   
    
     -
    
    
     name: transfer token and assets


   
    
     type
    
    :
    
     transfer


   
    
     settings
    
    :


   
    
     value
    
    :
    
     "1000..5000"


   
    
     -
    
    
     interval: 1


   
    
     action
    
    :
    
     consume_asset

通过改变 pool size，我们可以调节并发程度，通过控制 tick，我们控制 traffic 的速率；通过添加更多的 simulation，我们改变 traffic 的多样性。

在 simulator 的作用下，很长一段时间里，我们的开发网络三天两头 crash —— 一会 out of memory，一会 too many open files，一会 gen_server tiemout，一会 tcp send/receive buffer full。这些问题，如果换上个 4G memory / 4 CPU / 100G disk 的主机，只有很小的概率才暴露出来，而我们主动让其发生在开发环境中，使得大部分问题得到了妥善处理。比如说，我们发现我们使用的 consensus engine 不稳定，时不时 crash，crash 之后很容易把 state db 写坏，使得节点彻底崩溃，无法恢复。对此，我们的做法是，一旦 consensus engine crash，我们让 Forge 自动 crash（可惜了 erlang VM 强大的 crash recover 机制），然后由我们开发的 forge starter 将 forge 重启。重启后，我们回溯到上一个区块的数据，重新 apply，如果 consensus engine 可以恢复，那么旧继续往后走；否则便继续 crash 和继续回溯。

在这样严苛的环境下 Forge 逐渐成长，至尊乞丐节点组成的网络，不断死亡，不断重生，就像「明日边缘」里的汤姆克鲁斯，从小白一路成长为小强，迎来了第一百万个 transaction。

好景不长，在大约 1.5M txs 时，网络再次 crash：