作者| 祝威廉 责编 | 张文
来源 | mlsql.tech官方博客，已获转载授权
这篇文章主要内容来自 A distributed Posix file system built on top of Redis and S3 (github.com/juicedata)。
我看完后觉得讨论中不少问答很精彩，很棒，所以摘出来，加上我自己的理解，然后从
诞生背景
安全性
POSIX兼容性
可用性/稳定性
云原生支持
成本和性能
等七个方面进行探讨，以帮助方便大家更好的去理解 JuiceFS，以及他解决的技术问题。
JuiceFS的意义
在存储和计算分离的大趋势下，一个比较明显的例子是：越来越多的云端对象存储涌现，同时也有大量私有的 HDFS 集群会一直存在下去。新的模式往往会带来新的挑战，而这些挑战往往可能需要引入一个中间层来解决，JuiceFS 其实就是在这种背景下诞生的。
我个人认为，JuiceFS 更多的是面向于大数据领域的应用，尽管因为它通过 FUSE 提供了本机挂载，并且具有非常好的 POSIX 接口兼容性，也能被用于别的用途。
使用 JuiceFS 可以获得让你获得如下收益：
应用层不用自己去适配各种对象存储亦或是 HDFS，只需要面向 JuiceFS 即可；
JuiceFS 可以有效的提高对象存储的读取性能；
提升对象存储元数据操作的性能（0.x 毫秒级别），无论读写；
解决对象存储原子性问题，以及只是实现最终一致性问题而带来的问题（尽管 AWS 已经宣称解决了）；
解决了众多已有库可以不加修改的使用对象存储。典型的比如 AI 应用中的众多 Python 库，类似模型保存等等；
降低对象存储成本，减少多种对象存储付费 API 的使用，减少 GET 请求数带来的费用。
在文章的性能部分，我们可以看到即使没有命中缓存，也可以接近 HDD 的响应延迟。同时，这也为计算引擎的提速提供了更好的切面，未来可能包括自动 Prefetch(cache)所有 parquet footer 等。
而元数据如果还能加上 client 端缓存，则可获得更大的提升。
尽管 JuiceFS 拥有很多的优点，而且很努力地去逼近本地存储的性能，但网络延迟，IOPS 以及对象存储自身的限制，在写方面，依然和本地存储有接近百倍的性能差距，这对于很多 OLTP 数据库是有比较大的影响的。但对读的优化，使得其对于 OLAP 等以读多的引擎则帮助巨大。
安全性
JuiceFS 使用 Redis 做文件元信息存储，实际数据则是存储在背后的对象存储里，而对象存储的安全是由云厂商或者内部自己保证的。
尽管如此，文件元信息依然也需要得到足够的安全保证。因为 JuiceFS 目前支持 Redis，那么我们可以利用 Redis 自身安全特性来保证安全。
使用 rediss://host:port/ 去开启 TLS 加密
关闭所有 non-TLS 端口，启动时添加参数：-port 0 -tls-port 6379
未来如果适配更多元数据存储引擎，那么可以使用对应的引擎的安全特性。
POSIX兼容性
在软件开发领域，我们可能难以 100%完全兼容，总有你没有测试到的场景没有得到兼容。
那么 JuiceFS 对 POSIX 的兼容性到底如何呢？JuiceFS 选择使用第三方的测试集来测试兼容性，比如 JuiceFS 通过了 pjdfstest 最新的 8813 个测试。
值得一提的，JuiceFS 还支持常见的操作如 mmap 等。具体列表如下：
关闭再打开数据一致性。一旦一个文件写入完成并关闭，之后的打开和读操作就可以访问之前写入的数据。如果是在同一个挂载点，所有写入的数据都可以立即读。
重命名以及所有其他元数据操作都是原子的，由 Redis 的事务机制保证。
当文件被删除后，同一个挂载点上如果已经打开了，文件还可以继续访问。
支持 mmap
支持 fallocate 以及空洞
支持扩展属性
支持 BSD 锁（flock）
支持 POSIX 记录锁（fcntl）
可用性和稳定性
因为使用了 Redis 事务，所以目前来说 Reids 只能单实例。
那我们该如何面对比如断电，系统异常导致的可能的数据 loss 或者损害？如何实现高可用呢？
下面一些点值得参考：
Redis 可以使用 RDB/AOF 持久化数据
如果你使用了托管的 Redis 服务，那么服务商会保证稳定性
Redis 最新特性 redis raft 也值得期待
未来可能会使用其他元数据存储引擎，他们可能会带来更好的可用性和稳定性
另外，通用的 NFS，网络稳定可能严重影响系统的稳定性，比如网络的不稳定可能导致一些操作执行缓慢亦或是被 hang 住。但是我们可能无法中断或者结束这个操作。
JuiceFS 针对这个难问题，尽可能保证大部分操作都是可以中断的，然而依然有例外，譬如 close 方法是无法中断的。尽管如此，我们可以终止 FUSE 的连接亦或是杀死 JuiceFS 的进程，这样就会取消相关的操作。
总体而言，因为构建与 FUSE，所以我们可以更好的控制他。
云原生支持
JuiceFS 使用 Go 开发，轻量易于使用。Kubernetes CSI driver 也正在路上，你可以用更加 K8s 的方法通过 JuiceFS 挂载对象存储.
成本和性能
6.1 成本
使用 JuiceFS 的成本由四部分组成：
引入后对已有应用的侵入性有多大，这意味着改造适配成本。
Redis 存储成本，无论使用托管还是自建
数据存储会不会有额外的数据膨胀亦或是压缩，有没有自动清理功能，从而增加或是节省了对象存储的成本
有没有使用对象存储的付费 API 譬如 s3 的 list 目录等
针对第一个问题，对于原先就使用 HDFS 亦或是单机本地文件系统的，对应用基本没有迁移成本。
对于类似 ES/ClickHouse 之类集群类应用，他们自己管理 shard 以及裸磁盘，则有一定的修改成本。譬如 ES 通常每个实例配置的数据目录都是一致的，如果使用对象存储后可能会导致覆盖写，另外还有就是故障恢复，冗余度等问题值得关注。
第二个问题，Redis 存储成本也很容易衡量，通常 3GB 内存可以存储稳定数量 1000 万 Inode 节点。
第三个问题，JuiceFS 只是把对象存储当成一个 chunk 存储器，按 4M 大小的 Block 写入。读取文件的时候，会根据元信息去取多个 chunk，从而完成文件的还原。这点非常类似 HDFS 的 block 管理。另外对于 chunk 的存储会使用压缩，所有应该可以获得不错的空间节省效果。
第四个问题，完全可以避免使用对象存储的付费 API，因为文件元信息已经都自己管理了。
6.2 性能
JuiceFS 对读有较大的优化，对写则和原生的对对象存储写差距不会太大。
尽管我们可能可以牺牲一些一致性譬如异步写，批量写去提升写性能。相比原生的本地文件系统(SSD 磁盘)，写操作依然有近乎百倍的差距，这主要是因为 fsync 会比原生的 SSD 慢很多(20ms vs 100us)。而对于读，平均可以接近 HDD 磁盘的效率，如果命中 cache（我们假设你使用 SSD 盘做缓存）,那么基本可以接近本地存储的速度（SSD）。
还有一些数据值得参考，在同一个 Rack，文件元信息操作（和 Redis，比如罗列一个目录等），latency 可以控制 0.2ms - 0.5ms。未来如果使用 client cache，可以进一步降低。
读取性能，在没有命中 cache 的情况下，获取 AWS 的第一个 byte，延迟大概是 20-30ms，这几乎等价于 HDD 磁盘的性能。而对象存储可以获取更好的吞吐，当然，你依然可以对此数据表示疑惑，譬如有人生成 HDD 的平均延迟是 2-3ms，而 AWS 20-30 其实是中位数，会出现更好的延迟的可能性。
实际上，通过缓存以及预读，我们是完全鞥能够获得接近本地的磁盘性能的。
总结
云厂商是目前是推进存储和分离的主要动力，大数据领域领域则是最积极的响应者，尽管现在也有非常多的人在努力在 OLTP 领域尝试存储和分离，比如 AWS 的 Aurora 等。JuiceFS 就是存储和计算分离而催生出来的技术，如果你还在为使用对象存储而面临性能低下，跨云存储兼容等问题而苦恼时，不妨回过头来看看这个项目。
程序员如何避免陷入“内卷”、选择什么技术最有前景，中国开发者现状与技术趋势究竟是什么样？快来参与「2020 中国开发者大调查」，更有丰富奖品送不停！
