或许有细心的朋友会注意到，昨天很多帖子的得票都要比前些天少一些。
是因为币价下跌导致大家无心投票嘛，答案是否定的。
get_ops_in_block 出毛病了
那么真实的情况是什么呢？那要先从我的点赞机器人(Curation Bot)说起。昨天一早起来关注了一下我的机器人，然后发现程序在跑着，但是既然一个POST也没抓到，看了一下日志，从7月11号凌晨起就没有数据进来，这不科学啊，不是每三秒一个block嘛，看STEEMIT上帖子和回复这么呢，我咋就一个没抓到呢？
不信邪，写了个简化的程序，还是没数据进来。
于是乎在测试环境下开始漫长的调试之旅，最后发现其它功能都正常，唯独：get_ops_in_block 这个API有毛病
看一下steem代码中的定义和描述
这个API的功能就是把指定块(block)中的操作(operations)顺序取出。
而它出了啥毛病呢，举例说，一个块中会有一系列操作（发帖、回复、点赞、转账等等)，可能多达几十上百个。没出问题的时候，这些操作都会被顺序取出，而11号凌晨出毛病之后，只返回零星的几个操作。就是说大部分操作被它搞丢了 😡
get_ops_in_block 如何影响机器人
点赞机器人的工作原理：
1) 挨个块遍历
2) 把块中操作取出
3) 如果有comment操作(发帖或回复)，则交由程序其它部分判断是否点赞
因为get_ops_in_block 把大部分操作搞丢了，所以在第二步我们几乎没有取回任何操作，就甭提第三步的判断了。
然后，机器人就瞎了。STEEM网上有很多机器人应该是基于get_ops_in_block这个 API的，于是，就都瞎了。这也是点赞数变少的原因。
如何解决和避免
方法一： 换节点
发现这个问题以后，我测试了官网的几个节点，不出意料的全坏掉了。
然后又找了一堆第三方提供的节点，嗯，有两个还好用
- gtg.steem.house:8090
- seed.bitcoiner.me
但是不知道是不是我心里因素，总觉得这两个节点响应速度没官网的快呢，5555
方法二： 读回整个块
虽然get_ops_in_block 不好用了，但是测试了一下get_block还好用
所以另外一种方法就是弃用get_ops_in_block，用get_block读回整个块再处理
似乎数据量比前一种方法大了些(多出witness信息、签名信息等等)，但是似乎也不是忍受不了
方法三： 静等修复
懒人的终极大法，除非是steemit官方刻意让这个API不好用，否则有问题他们都会去修复的，耐心等待即可。
方法四： 自己跑节点
呃，想想就头疼，能不自己跑，还是先偷懒吧
其它影响
我有测试除了上述API外，其它常用的功能都依然正确，所以如果不是从块中读数据或者同步数据，那么基本上不受啥影响。但是需要从块中读数据的可就不好说啦。
steemdata
文章数据
7月11日全天读入的文章数据：8601
而7月10日这个值为：16810点赞数据
7月11日全天 点赞数：97753
而7月10日这个值为：271373
更恐怖的是在2017-07-11 0时至2017-07-11 17:00:00 (UTC) 点赞数据为空哦
以上数据一方面说明 get_ops_in_block API 造成的影响巨大，也说明了Steemdata 还有待完善。
SteemData Notify
我们之前对SteemData Notify 做过一些学习，清楚的知道，SteemData Notify 读取区块链上的操作所用的机制就是get_ops_in_block API，那么这段时间用户设置能否得到确认，或者用户操作能否得到通知，就可想而知了。
其它一些各种机器人
凡是需要读取区块数据，并且使用官网节点，并且使用的 get_ops_in_block API，那么都应该受此影响，但是那么卖票的机器人啥的不是用的这样的方式吧….
问题已经修复 & 思索
早晨重新测试，发现官网节点的这个问题已经恢复正常。
这算是个非常好的消息吧，我的懒人大法也再次立功了。
小小API，看起来作用微乎其微，但是一旦出故障，我们才发现它居然这么重要。
另外，从这个API导致点赞机器人失效、以及steemdata数据库内容缺失、以及可能引发的卖票机器人收钱不卖票，让我不禁思索是否该过度依赖API，但是不依赖API还能依赖啥呢？😀 或者该保持充分怀疑的态度，一旦API出错有各种补救措施，是不是有些杞人忧天的感觉呢？尽管天塌了一次，还会再次塌嘛？想的有点多了，哈哈
感谢阅读 / Thank you for reading.
欢迎upvote、resteem以及 following me @oflyhigh 😎
This page is synchronized from the post: 机器人们肿么了？