磁盘空间都去哪了儿，df -h 与 df -i
邮箱一直提醒查收新邮件，打开阅读全是服务器缓存刷新异常通知，千篇一律皆为 redis 快照保存至磁盘失败。
MISCONF Redis is configured to save RDB snapshots, but is currently not able to
persist on disk. Commands that may modify the data set are disabled. Please check
Redis logs for details about the error.
命令行 ssh 登录服务器后台，.bash_profile 级别的命令就执行报错:
rbenv-init: line 134: cannot create temp file for here-document
查看磁盘使用情况，显示仍有空间虽不大但像 redis/rbenv 占用几十兆的空间不至于报错。
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/xvda1 40G 35G 5G 87.5% /
网上查询资料学到了新技能，没有今天的问题场景相信未来我也不会对该命令感兴趣。刚认为系统还有 5G 的可用磁盘空间，再使用该命令查询直接显示磁盘被爆。
$ df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/xvda1 2621440 2621440 0 100% /
man df 查看参数列表，直奔主题，描述文字里生词不多就是没理解顺畅。
-h "Human-readable" output. Use unit suffixes: Byte, Kilobyte, Megabyte, Giga-
byte, Terabyte and Petabyte in order to reduce the number of digits to three
or less using base 2 for sizes. (二进制，2^10)
-H "Human-readable" output. Use unit suffixes: Byte, Kilobyte, Megabyte, Giga-
byte, Terabyte and Petabyte in order to reduce the number of digits to three
or less using base 10 for sizes.(十进制，10^3)
-i Include statistics on the number of free inodes. This option is now the
default to conform to Version 3 of the Single UNIX Specification (``SUSv3'')
Use -P to suppress this output.
inode 是什么？unix/linux 文件系统中文件储存在硬盘上，硬盘的最小存储单位叫做 "扇区"；多个扇区组成的 "块"，是文件存取的最小单位；文件数据都储存在 "块" 中，还需地方储存文件的元信息，比如文件的创建者、创建日期、大小等，这种储存文件元信息的区域就叫做 inode，译为 "索引节点"。
当前问题是 inode 已经耗完，但硬盘还未存满，此时就无法在硬盘上继续创建新文件。
# 使用一句话说出自己的特点
df -h # 大文件占用大量的磁盘空间
df -i # 大量的文件占用大量的 inode 号
该服务器为测试环境，内存、磁盘空间配置太低，但跑的数据与正式环境相同，缓存数据爆盘理所当然，清理部分数据保证功能测试顺畅即可，没想到删除缓存文件花费我近半日时光！
海量文件删到日落西山, rm -fr 与 rsync
缓存的是门店商品近半月销售数据，商品条形码与门店ID 多对多关系，缓存文件名称格式为: 条形码_门店ID.json，缓存文件数量三百多万（数据库查询），占磁盘空间 11G 。
这么多缓存文件在同一文件夹下拥挤着，心想快刀斩乱麻清空所有缓存文件再清理数据库数据后重新生成，没想到 rm -fr 命令回车后就石投大海没有一点扬起水花的迹象，top 查看到 cpu 狂飙。网上查询，再次确认自己所待的井太深，看到的云彩太淡。
在海量文件面前 rm ls du 都显得苍白无力，这些命令本质都需要遍历，文件列表长度直接溢出。
黑猫白猫善逮老鼠的是好猫，来学习下备份命令 rsync:
$ rsync src dest
当 src 和 dest 文件性质不一致时报错
当 src 和 dest 性质都为文件【f】时，清空文件内容而非删除文件
当 src 和 dest 性质都为目录【d】时，删除该目录下的所有文件，使其变为空目录
将空文件夹备份至待删除的文件夹，最终待删除的文件夹被覆盖成空文件夹，变相的执行了删除操作。
$ mkdir empty/
$ rsync --delete-before -d empty/ /project/cache/
$ rm -fr empty/
不得不说，网友屡试不爽的经验并非让我欣喜，速度依然很慢，最后放弃捷径任由它慢慢执行。
如何避免无能为力的场景，约横构纵
安静的命令终端背后是服务器内存/cpu 的高速运转，闭目养神的同时思考如何避免这种被动场景。
文件数量大是相对缓存文件夹的，怎么样才能分解文件数量压力？拆成多个文件夹，如果单个文件夹下文件数量依然过大，则继续拆，穷尽下去。
门店ID 正是拆解文件数量的切入点，缓存生成逻辑仅修改生成路径可忽略变动影响，更容易查询、计算、删除。约束了文件列表的宽度，增加了文件夹的深度。
大数据小细节
很遗憾的是在网联网、技术书籍中张嘴闭口谈大数据的时代里我仅过手了百万级的数据。即使这样，依然有很多细节需要注意，注意的事项就是不要记录的太细，要暴力，理解了数据的意义。
分享几点处理商品条形码数据缓存问题时的感触:
- 缓存是为了提高访问效率，若每次都不加判断的全部重新生成就太低效，若每条都 redis 记录时间戳则太费内存，利弊取舍后，按主键排序单次取 10000 笔依次平移，记录单次数据的最大时间戳。几百万行缓存只占 redis 几百条记录而已。
- API 访问时，旧逻辑会通过 Model 层判断数据实例是否存在，数据量大时响应效率直线下降。暴力解决，API 访问参数拼出缓存文件路径，存在则直接读取，否则响应默认值，数据过旧时怎么办？缓存数据里写有更新时间，客户端展示时会显示，以此判断服务器是否及时更新。
深感时间管理不当，读书太少，心智太幼稚，总是在磕绊之后才知道哪里有坑。有更佳实践方案的童鞋欢迎留言评论。
