笔记
0工具
0此页用于记录用户反馈问题后的每一次改进
关于
“写笔记”支持四种格式——Word 文档、Excel 表格、Markdown、纯文本，起稿或二次编辑时都能随时切换，同一篇笔记想用哪种形态来记，都由你说了算。
md、txt、csv、json 这类纯文本则原样载入，不做多余加工。拿一张现成的表倒进来、改几笔、再导出去，等于白用一台免费的格式转换器。
要带走就在右上角点“下载”，可导出 PDF、Word、Markdown、Excel、TXT 等格式；列表卡片“⋯”菜单里，也有同样的下载入口。
在“工具”页点“＋ 上传工具”即可发布：填好名称与链接，再用 Markdown 把使用方法写清楚——能解决什么问题、怎么装、怎么用，比堆介绍实在。
要分发安装包就一并上传压缩包（ZIP、RAR、7Z、TAR.GZ，最大 35MB），别人在详情页一键下载；只放链接不带附件也可以。
工具按大家的收藏热度排序，好用的自然会被顶上来。发布后可在详情页或卡片菜单里编辑、下架。
写笔记时勾上“隐藏”，这篇就只存在于你自己的账号里：不进列表、不进搜索、不上首页精选，也不会出现在任何公开的页面，链接发给别人同样打不开。
适合放密码、草稿、日记这类只给自己看的内容；想公开，去“发布”打开它，把“隐藏”的勾去掉再保存，之后编辑会默认保持原状态，不会悄悄变回公开。
不想公开、只想临时给人看：点“分享”生成一条带密码和有效期的链接，到期自动失效，你也能随时撤销。
你的内容会同时保存在多个副本上，系统定期做备份与完整性校验，再配合异地容灾机制：就算某台机器出问题，数据也不会丢，可以长期放心存放；特别重要的资料，仍建议你另外再留一份备份。
全站跑在容器化、模块化的现代架构上，更新、部署、回滚都很快，扩展性和稳定性都按长期运营的标准来设计（Built for reliability, designed to scale）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
趋势
Redis 崩一次丢了三分钟数据，才搞懂 RDB 和 AOF
上周那台 Redis 崩了一次，起来之后丢了大概三分钟的数据，这才把 RDB 和 AOF 的选型从头看了一遍。记录一下。
背景是自建的单机 Redis，既当缓存又当临时队列，内存分配了 4G，跑在容器里，版本 6.2。某天凌晨容器被 OOM 杀掉——旁边一个 Java 服务把宿主机内存吃满，Redis 被牵连。重启之后，业务反馈有几分钟的订单状态丢了，因为这些中间状态只写 Redis 没同步 MySQL，属于我自己设计上欠的债，正好借这次把持久化补上。
先说为什么丢。默认配置只开了 RDB 快照：
save 900 1
save 300 10
save 60 10000
含义是：至少 1 个 key 变化且距上次快照超过 900 秒，或者 10 个 key 变化超过 300 秒，或者 10000 次写超过 60 秒，才触发一次 bgsave。我们那台写量不大，大部分时间靠第一条 900 秒的规则兜底，等于最坏情况丢 15 分钟的数据。崩溃时距上次快照刚过去 3 分钟，就丢了这 3 分钟。怎么确认丢了多少？看持久化信息里的时间戳：
redis-cli info persistence
重点看 rdb_last_save_time 离崩溃时刻多远，基本就是丢失窗口。
RDB 还有另一个问题：fork。bgsave 要 fork 子进程，内存越大 fork 越慢，因为要复制页表，期间主进程会卡顿。我见过一台 20G 的实例，bgsave 时主进程卡了 1 到 2 秒，期间命令全部排队。所以大实例纯靠 RDB 也不舒服，这是个很多人没注意的隐性成本。
后来把 AOF 打开：
appendonly yes
appendfsync everysec
aof-use-rdb-preamble yes
appendfsync 三档：always 每个写命令都 fsync，最稳但吞吐掉得厉害；everysec 每秒刷一次盘，最多丢 1 秒，是大多数场景的选择；no 完全交给操作系统刷，丢多少看命。我用 everysec，崩一次最多丢 1 秒，比默认 RDB 的 15 分钟强太多。
aof-use-rdb-preamble yes 是 4.0 之后的混合持久化：AOF 做 rewrite 之后，文件前半段是 RDB 二进制快照，后半段是 rewrite 之后的增量命令。好处是重启加载快、文件体积小。不开的话 AOF 是纯命令追加，跑久了 rewrite 之前能攒到好几个 G，重启时一条条重放，加载慢得明显。
现在两台 Redis 都是 AOF everysec 加保留 RDB 的策略，RDB 文件顺手当异地备份。重启恢复时 Redis 会优先读 AOF，因为 AOF 更新。反过来如果是纯缓存、能接受丢十几分钟，就只留 RDB 图省事，还能避免 everysec 那一下的 fsync 开销。
还有一个没验证完的猜测：AOF rewrite 的自动触发条件是 auto-aof-rewrite-percentage 100 加 auto-aof-rewrite-min-size 64mb，写量忽高忽低的实例如果一直不触发 rewrite，AOF 会持续涨。这块参数我还没细调，先记着，等观察一阵再说。
补一个当时做的小实验。为了确认 everysec 到底会丢多少，我压了一批写之后直接 kill -9 模拟断电，重启看丢了哪些 key，结果和文档说的一致：最多丢到最后一次 fsync 之前的写，实测丢了一条。always 档也压了一遍，同样吞吐下每秒写入从两万掉到一万上下，写密集场景掉得有点肉疼，所以最后还是定了 everysec。AOF 文件如果写到一半断电坏了，Redis 会拒绝加载，得用 redis-check-aof 修，它会把文件尾部不完整的命令截掉：
redis-check-aof --fix appendonly.aof
这个工具平时用不上，真到启动不起来再找就晚了，建议先在测试实例上跑一遍熟悉输出。另外 AOF 和 RDB 都开着时，加载优先走 AOF；纯 RDB 的话恢复就是直接 load rdb 文件，很快，一旦 AOF 是纯命令追加、体积又大，恢复就会慢。混合持久化让 AOF 前半段直接按 RDB 加载，我这台 4G 数据量的实例，重启从之前的十几秒降到两三秒，体感很明显。
RDB 这边也顺手补了个整点快照：除了触发式 save，我加了一条 cron 在每天低峰手动 bgsave 一次，再把 rdb 文件 rsync 到异机，当作可回溯的整点备份。AOF 再全也只是最近一段时间的增量，真要回滚到昨天某个时刻，得 RDB 加 AOF 一起用才行。这个组合先跑一个月，看看文件增长和重启耗时再决定要不要调。