IPFS_API基于流的传输

我们都知道IPFS是一个大项目，并且大家都认为它是一个划时代的产品，至于为什么是划时代的产品，无需多说。

基于IPFS技术的项目有大名鼎鼎的openbazaar（国外的一个去中心化版淘宝），openbazaar之所以为大家所熟知，主要还是因为它的出现和理念让越来越多的人在讨论“A里巴巴还有存在的必要吗？”

IPFS的诸多优点此处不再赘述，毕竟IPFS作为分布式文件系统本身来看已经是一个可以投入生产系统并能够落地的项目。我们这次讨论的主题是“IPFS的流传输”。

基于IPFS的生态系统在使用IPFS的过程中，都是使用IPFS提供的API，官方的Java IPFS提供的接口默认添加文件没有添加流的功能，如下图所示。

一、详细说明其实验步骤

❶前端上传大文件到后台（私有网络），测试1.21G的文件，需要花费50秒，后端才收到文件。此时前端上传此大文件一直阻塞，上传进度无法展示，后端一直处于等待状态，影响文件的总体上传进度，故在此上传采用分片处理技术。

❷后台处理：后台接收分片文件，此时如果先放入缓存，如果文件很大，需要占用很大内存，显然不合适，存临时文件，效率会下降，这里我们采用多线程使用循环缓存把分片数据转换为加密输入流。

❸加密处理：原理同后台处理，多线程使用循环缓存把加密输出流转换为输入流，IPFS采用流输入上传到IPFS存储系统。

❹获取文件的流处理原理和上传文件类似。调用IPFS API的获取文件流接口，获取的文件流作为解密处理的输入流，多线程使用循环缓存把解密输出流转换为输入流供DAPP调用。

二、实际测试效果。

❶上传31G的文件时间为37分钟，上传完成自动调用IPFS集群API实现集群节点的备份。

❷上传时的服务器性能：java服务器程序的CPU是稳定的，IPFS的内存稳定，CPU会波动（System Monitor）

❸上传时的网络速度（System Monitor）

❹上传时的硬盘速度（iotop）

❺下载31G的文件时间为16分钟

❻下载时的服务器性能：java服务器程序的CPU是稳定的，IPFS的内存稳定，CPU会比较大的波动（System Monitor）

❼下载时的网络速度（System Monitor）

❽下载时的硬盘速度（iotop）

综上所述，用IPFS上传大文件的时候，传统方式并不是非常顺利，采用流传输和分片技术可以解决大文件上传的稳定性问题。因为Heathwallet项目要解决人类基因数据的上链问题，迫使我们深入优化IPFS，让其能够为我们所用。当然在其他领域，如果诸位想干掉D滴和M团，这个梦想也可以有，我们可以一起努力。欲知更多，请扫码加入我们的微信群：

完