笔记
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）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
趋势
MsgTrans 2.0 Beta 1：把“高性能传输”升级为“可证明高性能可靠”
MsgTrans 2.0 Beta 1 发布有一阵子了，我一直在折腾这个版本，今天终于有空把里面的核心改动捋一遍。说实话，这次升级的跨度比我预想的大得多，不只是修修补补，而是把整个传输层的设计哲学都换了一套。
先交代下背景。MsgTrans 这个项目最早是我为了解决内部服务之间海量小消息的可靠投递问题搞的，第一版主打的是“快”，用共享内存加无锁队列把单机吞吐压到了百万级 TPS。但用着用着就发现，光快没用——一旦进程崩溃或者机器重启，队列里还没消费完的消息就全没了，业务方找过来的时候只能干瞪眼。所以从 1.5 开始我就在琢磨怎么在保持性能的前提下把可靠性补上，但一直没找到特别优雅的方案，直到这次 2.0 的结构重构。
这次 Beta 1 最核心的变化，是引入了写前日志（Write-Ahead Log，WAL）机制，并且把原先的“内存队列 + 后台刷盘”模型彻底推翻，改成了“日志即队列”。什么意思呢？就是所有消息在进入内存队列之前，必须先追加到磁盘上的日志文件里，确认落盘成功后才算“入队成功”。消费者那边也一样，读到一条消息、处理完、再记录一个消费位点，这个位点也是先写日志再更新内存缓存。
这样一来，整个传输链路就变成了一个可回放的事件流，而不是一个易失的内存结构。你可能会问，这不就是 Kafka 那套吗？对，原理上确实是借鉴了分布式日志的思想，但实现上差别很大。Kafka 是面向跨网络的多副本复制，而 MsgTrans 是单机进程内的传输组件，所以我把 WAL 做成了内存映射文件（mmap）加批量组提交（group commit）的方式，避免每次写日志都触发一次系统调用。
具体来说，WAL 文件被划分成固定大小的段（segment），默认每个段 64MB。写入的时候，消息先被拷贝到一块预分配的内存缓冲区里，当缓冲区攒到一定阈值（默认 4KB）或者超过 5 毫秒没攒满，就一次性 msync 到磁盘。这个设计是为了把随机小 IO 变成顺序大 IO，实测在普通 NVMe SSD 上，顺序写吞吐能到 2.3GB/s，而随机写 4KB 块只有不到 300MB/s，差距接近一个数量级。所以攒批是真的有用，不是玄学。
那可靠性怎么保证呢？这里我引入了一个叫 “持久化屏障”（durability barrier） 的概念。每一条消息在日志里都有一个全局递增的序列号，生产者调用 send() 的时候，可以传一个持久化级别参数，有三个档位：
LEVEL_NONE：消息只进内存队列，不写日志，性能最高但会丢消息LEVEL_ASYNC：消息先写内存缓冲，后台线程异步刷盘，性能接近 NONE，但进程崩溃时可能丢最后几百毫秒的数据LEVEL_SYNC：消息必须等日志落盘（msync 返回）才算发送成功，单条延迟大约在 812 微秒，但吞吐会降到每秒 3040 万条左右
默认是 LEVEL_ASYNC，因为大多数场景下丢几百毫秒的数据是可以接受的，但如果你在做金融交易或者订单系统，那就得老老实实选 SYNC。我自己的压测环境里，三档的对比数据是这样的（Intel i9-13900K，64GB DDR5，三星 990 Pro）：
| 持久化级别 | 吞吐（条/秒） | 平均延迟（微秒） | P99 延迟（微秒） |
|---|---|---|---|
| NONE | 1,250,000 | 1.2 | 3.8 |
| ASYNC | 1,180,000 | 1.9 | 5.1 |
| SYNC | 340,000 | 9.6 | 18.4 |
可以看到 ASYNC 和 NONE 差距很小，但可靠性却提升了一个层级。这是我这次最满意的部分。
接下来是消费端的变化。以前消费者是从内存队列里直接 pop，现在改成了从 WAL 里按序列号顺序读取。每个消费者组（consumer group）维护一个独立的消费位点（offset），这个位点本身也存在一个特殊的元数据日志里，每消费一条就更新一次。如果消费进程崩溃，重启后只需要读取元数据日志里最新的位点，然后从 WAL 对应位置继续往后读就行，不会重复也不会丢。
这里有个坑我踩了很久：位点更新如果太频繁，元数据日志会变成热点，性能急剧下降。后来我参考了 RocksDB 的 WAL 管理方式，把位点更新做成了异步批量提交——消费者本地维护一个内存位点，每消费 1024 条或者间隔 100 毫秒，才把最新位点追加到元数据日志。这样即使崩溃，最多也就是重复消费最后 1024 条消息，配合业务方的幂等处理（比如用消息里的业务 ID 去重），完全没问题。
另外，2.0 还加了一个我觉得特别实用的功能：消息回溯（rewind）。以前消息消费完就没了，想重新处理一段历史数据只能靠备份恢复。现在因为 WAL 是按序列号存的，而且段文件默认保留 72 小时（可配置），所以消费者可以随时调用 rewindTo(offset) 跳回任意位置重新消费。这对排查线上问题或者做数据订正简直太方便了。我自己就遇到过生产环境里因为一个 bug 导致部分消息处理错了，以前得写脚本去数据库里捞数据重新跑，现在直接回退 10 分钟前的位点，重放一遍就完事了。
再聊聊内存管理。之前版本用的是无锁环形队列（基于 MPSC 模型），每个消息节点是预分配的对象池，但对象池有个问题——消息大小不均匀时，内存碎片化严重。2.0 里我改成了分块内存池，把内存切成 16B、64B、256B、1KB、4KB 五档，小消息用小块，大消息用大块，分配时按需取，释放时按块归还。这样做的好处是碎片率从原来的 12% 降到了 2% 以下，而且分配一条 64B 消息的开销从 45ns 降到了 12ns。不过代价是代码复杂度上去了，内存池的回收逻辑得处理跨档位的块合并，这部分我写了大概 300 行注释才讲清楚。
还有一个容易被忽略但很重要的点：CPU 缓存友好性。WAL 是按顺序写的，所以读的时候也是顺序读，这样 CPU 的预取器能完美工作。但内存队列是随机的，消费者线程和生产者线程如果跑在不同的核上，会有严重的 cache line 伪共享（false sharing）问题。我在 2.0 里给每个线程的队列头尾指针都做了 64 字节对齐，并且把生产者和消费者的状态变量放到不同的 cache line 上，这样多线程压测时吞吐提升了 23%。这个优化其实很老套，但很多人会忽略。
最后说说监控和可观测性。之前版本只有一个简单的计数器接口，这次我内置了一个轻量级的指标收集器，可以导出以下数据：
- 每秒入队/出队消息数（TPS）
- 当前 WAL 文件大小和剩余可用空间
- 消费者位点落后量（lag）
- 刷盘延迟分布（p50/p95/p99）
- 内存池各档位使用率
这些指标可以通过 HTTP 接口以 JSON 格式拉取，也可以直接推到 Prometheus。我在内部已经接上了 Grafana 看板，实时监控生产环境的传输状态。有一次半夜报警说 lag 涨到 5 万条，我一看指标发现是某个消费者线程因为 GC 停顿卡了 2 秒，导致消费速度跟不上，后来调了 JVM 参数就解决了。没有这些指标的话，这种问题排查起来得靠猜。
总结一下，MsgTrans 2.0 Beta 1 的核心变化就是三个词：WAL、位点、可观测。它把传输从“尽力而为”变成了“可证明的可靠”，而且代价是可控的——ASYNC 级别下性能只损失 5% 左右。当然，这个版本还在 beta，有些边界情况我还没有完全测透，比如 WAL 段文件轮转时的磁盘空间不足处理，以及多进程同时打开同一个 WAL 时的锁竞争。如果你感兴趣，可以直接去 GitHub 拉代码跑跑看，有问题随时提 issue。
哦对了，Beta 1 的配置项比之前多了不少，我建议你重点看这几个：wal.segment.size（默认 64MB）、wal.sync.mode（默认 async）、wal.retention.hours（默认 72）、consumer.offset.batch（默认 1024）。调参的时候记得先用 --dry-run 模式跑一遍，它会打印出当前配置下的预估内存占用和磁盘写入速率，避免上线后才发现资源不够。