bitcoin区块数据的获取及mysql的优化加速

距离找到获取比特币余额的方法已经过去四个多月了，中间停顿了一段时间，没有深入研究，最近又重新拾起这个需求来，遇到了一些大大小小的问题，记录下来，作为自己一个成长的见证

 

开始时的代码结构是这样

每个getblock返回的tx可能是几个到几千个，每个tx可以根据gettransaction生成详细的交易记录older，根据交易信息获取当前接收方的utxo及address地址，这样从头连到尾便会形成比特币这个特殊的余额。

当然，在成功之前遇到了各种问题，然而都合理解决掉了

 

首先是围绕性能问题，ps：主要是性能问题，其他问题都不大，本文就不罗嗦了。

性能瓶颈1

由于每次找到一个交易详情后，需要向前一步找到send，也就是每一个txid对应的是至少两次操作。

相对的时间至少会增加两倍，实际肯定会超出两倍。

解决方法

遍历一次txid，通过两种不同的数据表存放send及rece，用相对较小的空间换取时间，性能提高两倍有余。

算法复杂度由O（n*N）缩小为O（n）。

实际上这个方法也改变了数据存放的结构，间接影响了mysql的性能。

 

性能瓶颈2

bitcoin的API命令gettransaction命令会去index文件夹下遍历levelDB数据库

锁定到这一行代码后，研究了一番levelDB，发现levelDB的写性能十分强劲，而随机读就有点相形见绌了。

要知道bitcoin截至到目前为止将近4亿个txid，而我每次通过gettransaction访问txid的交易记录便是一次随机读。

根据实际测试，平均读取速度是每次70ms左右，要知道，光是读取txid就要1000个小时，这肯定是不可以的.

解决方法

解决方法是通过getblock获取整个tx下的txid交易详情，执行一次大约需要400ms，但是getblock对应的数据量只有区区56万多个块，获取同样数量的txid只需要72个小时，性能提升有多高不需要细说了吧。

 

性能瓶颈3

mysql插入语句insert，开始时使用go库中sql的事务，后来检查sql语句在执行事务时是每个value执行一次insert语句。

要知道，mysql资源占比中，语句的重复插入占比非常高。

解决方法

将value值用字符串拼接方法拼接，一个数据表只执行一次insert语句便将所有对应的value插入

在这个方法下，性能提高5-10倍，由于预计将有20多亿条数据存放，所以mysql分表数量为512个。

多个表的情况下确实会降低mysql的insert性能，不过这些相对数据量来说是不可避免的。

 

性能瓶颈4

mysql中的主键索引随着数据量的增加也会直接影响性能，经过测试，当每个表中的数据量达到几万时，便会大大降低insert速度

解决方法

索引在insert时不设置，当数据插入完成后设置

性能相对来说，提高几倍-几十倍，这个没有实现完整的表数据无法获取到精确数值

 

性能瓶颈5

由于以上所有的硬盘操作都是采用win10下的机械硬盘，所以考虑到服务器的c盘是固态硬盘，将mysql的数据移到c盘的固态中

解决方法

经过测试，由原来的机械硬盘100%占用率到固态硬盘的5%占用率，看到后大喜。

直接开10个并发，因为一开始写代码时就考虑到了以后要并发，所以并发只是一个参数的问题。

开启并发后，cpu占用率到70%，固态占用50%。

性能相比最开始的提高整整几千几万倍。

 

经过计算抓取完整区块信息时间不超过2天48小时，整个过程包括getjson，解析，分类，存库，最后大功告成。

这个过程非常的舒服，很有成就感，本次分享到此结束。