笔记
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）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
趋势
热点 key 过期把 DB 打爆，代码里怎么防击穿
记录一下那次缓存击穿，以及后来在代码里到底是怎么防的。
场景是商品详情页，数据在 MySQL，Redis 里缓存了详情 JSON，key 过期时间统一 30 分钟。某天一个爆款商品上了首页，它的缓存 key 正好到点过期，一瞬间几百个请求同时发现 miss，全部去查 DB——连接池被打满，接口耗时从 50ms 飙到 8 秒，最后把主库也拖出告警。
先把三个词分清楚，网上混着讲的多，实际修法完全不一样：
缓存穿透：查的 key 在 DB 里压根不存在，缓存永远 miss，每次都打到 DB。
缓存击穿：单个热点 key 过期的瞬间，大量并发同时回源。
缓存雪崩：大量 key 同一时间过期，DB 被一波流量压垮。
那次是典型的击穿。当时上的土办法是互斥锁：缓存 miss 之后不让所有人都去查 DB，先抢一把锁，抢到的那个线程去查库回填缓存，其余线程短暂等待后重新读缓存。用 Redis 的 set nx 实现：
String lockKey = "lock:detail:" + id;
Boolean got = redis.setIfAbsent(lockKey, "1", Duration.ofSeconds(3));
if (got) {
try {
String data = queryDb(id);
redis.set("detail:" + id, data, Duration.ofMinutes(30));
} finally {
redis.delete(lockKey);
}
return data;
}
Thread.sleep(50);
return redis.get("detail:" + id);
setIfAbsent 必须带过期时间，否则查库的线程中途挂了，锁永远不释放，后面的请求全卡死，比不打锁还惨。这个写法在单机、主从场景够用；Redis Cluster 下 setnx 锁在主从切换时可能丢锁，严格的话要上 Redisson 那种带看门狗的分布式锁，我当时量级没到，没上。
穿透是另一个活动踩的。有人拿不存在的商品 id 循环刷，全是 miss 全打 DB，把只读库都打高了。两个修法：一是空值也缓存，查库结果是 null 就 set 一个占位值，TTL 给短点，比如 60 秒，能挡住同一批不存在 id 的反复轰炸；二是布隆过滤器，启动时把所有合法 id 加载进一个 bitset，查询前先判断，不存在直接返回，连 Redis 都不查。我当时合法 id 才几十万，没上布隆（有误判率，还得维护增量加入），用了空值缓存加对明显非法入参提前拦截就够。以后量大了再考虑布隆。
雪崩的处理在过期时间上做文章。原来所有 key 固定 30 分钟过期，如果一批 key 是同时写入的，就会在同一分钟集体过期，回源流量瞬间叠加。改成过期时间加随机抖动，把过期点打散：
int ttl = 1800 + ThreadLocalRandom.current().nextInt(300);
热点 key 还有一种更省事的做法：逻辑过期。value 里塞一个过期时间戳，读的时候发现逻辑上过期了就先返回旧值，同时异步去刷新缓存。坏处是极端情况下会返回一两秒的旧数据，实时性要求高的场景别用。我们详情页最后是逻辑过期加互斥锁兜底一起用，之后没再被打穿过。代码是 Java 加 Spring Data Redis，别的语言思路一样，核心就三条：锁住回源、空值占位、过期时间打散。
复盘后又在详情页前面加了一层进程内缓存兜底：热点 key 的数据再在应用本地用 Caffeine 缓存十几秒，过期时间比 Redis 的短。这样即使 Redis 里那个 key 真过期了、在等互斥锁回源，同一台机器上的请求也能先命中本地缓存，不会全部卡在 sleep 重试上。代价是每台机器多一份拷贝，数据更新时要主动失效本地缓存，适合读多写少的详情页，写频繁的接口别这么干。
逻辑过期的实现也记一下：存的时候不是直接存 JSON，而是存一个带 expireAt 的包装对象，读的时候先判断 expireAt 过没过，没过直接返回；过了就先返回旧值，同时丢一个异步任务去刷新 Redis：
DetailVO vo = JSON.parseObject(raw, DetailVO.class);
if (vo.getExpireAt() > now) { return vo.getData(); }
asyncRefresh(id); // 异步回源并写新值
return vo.getData(); // 先给旧值
异步刷新那一步要做节流，同一个 key 在一分钟内只允许一个线程真正查库，不然热点一过期又是一堆线程同时回源，跟没防一样。判空、超时、并发这几个边角处理干净之后，这套组合目前日常活动峰值都稳，双十一那种量级扛没扛住我还没机会验证。