RS的实现

写在前面

RS codes作为一门实践丰富的老技术，希望大家不要在其上面花太多时间。最重要的我们用什么方式去实现它。本文将做这一问题的讨论，并给出代码。

EC lib

最自然的，底下用什么库老跑计算是一个重要的问题。开源的库很多，大家尽管放心大胆的用。如果发现有问题可以联系我，因为我也发现了一些问题。但对于大多数人来说这就是个玩具，有些小问题可以直接忽略，但是上生产环境的，这些小问题也不算大事。至于主流公司用什么库公开的信息不多，我这里说两个，TFS用的是Jerasure，这是个好库，只不过1.0版本“引擎”有点慢，其2.0运用了SIMD来做加速，效率高了很多。360用的是intel的ISA-L,这是最好的库。可以设置自动选择使用SSE AVX AVX2来进行加速，其中AVX2是最快的，至于为什么文章很多，不是本文重点，我也就不多提了。

虽然说编码速度还真不是性能瓶颈，但有快的就用快的呗，没什么好犹豫的。而且还有intel作为信誉背书，多好。

我这里选择ISA-L作为底下的库，原因很简单，直接上最好的反正不要钱。另外intel本身这个库的内容要丰富的多，它本质是个存储技术的库，只是直接公开可下载的只有EC部分，其他可以去提申请。反正我没申请下来。: D

Drive

这玩意还需要Drive？我觉得还是需要，毕竟封装他还是比较困难的。市面上有pyeclib这个python库，还有leo_erasure这个erlang库，另外还有backblaze的Java库。不过他们都已经武装到牙齿直接提供很方便的API了。backblaze的我没具体了解，另外两个都有关于ISA-L的封装。

API

我最后选择leo_erasure作为主要介绍的库，原因是因为我在使用pyeclib实现一个比较重要的特性测试的时候发现了一个问题。这里卖个关子，大家可以自己去试验。

leo_erasure原本是基于jerasure的，后来加上了ISA-L。 jerasure是我不需要的，因此我删掉了关于它的部分。另外其API函数可以加入新的元素。

RS业务怎么跑的？

RS在大型分布式系统中最大的运用就是存储冷数据，做好冷数据的筛选很重要，毕竟RS有性能问题。另外一个特征就是，大多数公司都针对小文件进行了合并，多个文件合并为一个固定大小的chunk，有些公司是所有chunk一样大，比如facebook的256MB。也有些提供云服务的公司，因为客户业务多种多样，有好几个chunk模式。

那么，对于RS这种systematic codes来说，最好的实现是直接以chunk为单位作为symbol（block）代替原先的文件打散的方式。这样在一定程度上提升了可用性，当然可靠性和修复成本还是不会变的。

这样的实际需要就意味着传统的encode，decode，repair接口对于使用者来说没有太多意义，我们要引入一个新的func来实现把大小一致的chunks扔进去之后，就计算完冗余。

另外，当一个chunk挂掉时，用户要读取其中一个文件。这个时候通过查询索引得到offset和size，然后读取其他chunk的相应位置，传输到指定的master那里做修复。这意味这要提供可以实现恢复指定编号块的能力。

leo_erasure

leo_erasure代码写的很简洁漂亮，这一部分我觉得也是erlang的功劳，哈哈。虽然没有什么文档和注释，但是仔细看代码也发现了调用情况和参数意义。那么做一下简单封装和修改，上面两个功能就很好实现了。

我随便写了一下，代码可以参考：

https://github.com/templexxx/erl_rs

故事差不多结束了

这次文章写的比较简短，或许可读性更好一些。有什么不清楚的，可以留言