自建团队协同平台，真正吃资源的是搜索和附件不是在线人数

三百人的协同平台加了内存还是慢：一开始估错了对象

一家三百人的公司把内部协同和即时通讯平台自建到了一台 4 核 8G 的机器上。选型时的算法很朴素：三百人不可能同时在线，按经验打个折，峰值并发按一百算；一百个人敲键盘发消息，4 核 8G 绰绰有余。上线前三个月确实一切正常，消息秒发，搜最近的消息也是秒回，运维盯着监控面板，CPU 长期在百分之十几晃悠，判断这台机器至少还富余一半。

半年后开始出事。先是有人在全员频道里抱怨搜一条三个月前的消息要等七八秒，输入框下面一直转圈；接着运维发现磁盘每月涨三十几个 G，按当时剩余空间算，不到一年就得扩盘。第一反应是内存不够。搜索慢嘛，多半是缓存没吃满，于是把机器加到 16G。加完之后，搜索该慢还是慢，磁盘该涨还是涨。

这台机器从一开始就估错了对象。三百人这个数字本身没问题，问题在于它只决定了一部分负载。一个协同平台在机器上跑着的东西，至少可以拆成四条互不相干的线：有多少人挂着长连接、每天往数据库里写多少消息、搜索索引有多大且多久被查一次、附件存了多少且要不要转码预览。这四条线的增长曲线完全不同，彼此的拐点也不在同一个时间。按人数估，只能估准第一条，而第一条恰恰是最轻的那条。

更麻烦的是这四条线会互相干扰。传送门：上传一个大视频会占满 CPU 做转码，同一时刻的搜索查询就得排队；附件的连续大写入会把磁盘 IO 吃掉，索引文件的随机读就得等；频繁的消息更新让数据库产生大量死元组，autovacuum 跑起来又是一轮 IO。所以"加了内存还是慢"不是玄学，是加错了维度。

把负载拆成四条水位线：连接、写入、索引、附件

把这四条线分开看，是因为它们各自跟着不同的自变量走，也各自在不同的时间点撞墙。

连接与推送这条线跟着在线人数走。在线人数受团队总人数和作息约束，早高峰和晚高峰之间差两三倍，但一年下来几乎不增长，除非公司招人。它是四条线里最平的一条。

消息写入这条线跟着日活人数乘以人均发帖频次走。它随团队规模线性增长，也随协作习惯增长，比如从"只在群里聊"变成"每件事都开一个频道"，写入量会跳一档。但即便如此，它的绝对量级对现代数据库来说通常不算大。

搜索索引这条线跟着历史消息总量走，而历史消息总量是日活 × 频次 × 留存年限的乘积。它是四条线里唯一带"年限"这个乘数的，也就是唯一一条会自己累积的线。上线第一天它最小，之后每天都在变大，从不回落。

附件存储这条线跟着文件总量走，同样带年限乘数，而且单个文件的量级比一条消息大四到五个数量级。一条消息按几十字节算，一个附件按几 MB 算，差了十万倍。这就是磁盘每月涨三十几 G 的来源。

所以正确的估算顺序不是"多少人 → 什么配置"，而是先回答两个政策问题：消息留多久、附件怎么存怎么预览。这两个答案定下来，索引和附件的量级就能算出来，机器规格是被它们反推出来的结果。

连接与推送这一条：在线人数、长连接与网关进程怎么算

先算清楚第一条，因为它最容易被高估。以 Mattermost 为代表的自建协同平台，服务端是 Go 写的单进程，每个活跃客户端维持一条 WebSocket 长连接。Go 的 goroutine 初始栈只有 2 KB，一百条连接的栈开销在两百 KB 量级，加上读写缓冲区也就几 MB。也就是说，开篇那家公司"峰值并发一百"对应的连接成本，连 1G 内存都用不到。

真正随连接数上涨的是另外几样：每个连接对应的用户会话缓存、频道在线状态维护、未读计数与侧边栏排序的内存结构。这几项加起来，每个在线用户大致落在几百 KB 到几 MB 的区间，具体数值需按自己环境实测，因为它取决于一个人同时开着多少个频道、频道里有多少未读。

还有一项容易被忽略：广播扇出。一条消息发到频道里，要给频道内所有在线成员各推一条 WebSocket 帧。所以负载不是"在线人数"，而是"消息条数 × 该频道在线成员数"。一个三百人的全员频道里发一条消息，扇出是三百；一个五人项目频道里发同样一条，扇出是五。如果公司习惯在大频道里讨论，即使总人数不变，这条线的压力也会比估算值高出一个量级。这也是为什么同样是三百人，有的公司 4 核跑得很稳，有的公司 8 核还抖。

移动端推送是另一条支路。自托管部署要额外跑一个推送代理进程，由它维持到手机厂商推送通道的出站连接。这条链路的瓶颈是出站连接数和排队长度，跟服务器 CPU 关系不大。它的故障表现也很特别：Web 端一切正常，只有手机收不到提醒，排查方向不在主服务，而在推送代理的证书有效期和出站连通性。

结论是，三百人规模下连接这条线相当富余。它几乎不会成为加机器的理由，除非出现两种情况：一是全员频道特别多且特别活跃，二是单实例已经到了需要滚动升级的程度，重启一次就掉一批连接。前者要改的是使用习惯和频道切分，后者要加的是实例数，两者都不是靠加内存解决。

消息写入这一条：日活、频道数与日均条数怎么折成写放大

第二条线的口径是日活而不是总人数。三百人的团队，日活通常在一百五到两百二之间，这个比例需按自己环境实测，平台后台的活跃用户报表能直接给数。人均日均消息数按三到六十条估（含回复和表情回复），取四十条做基准。

于是日均消息量是两百人 × 四十条，等于八千条。接下来是关键的一次折算：一次发帖在数据库里不是插一行。Posts 表插一条主记录，同时要更新 Channel 表的最后活动时间和最后一条消息、更新该频道所有成员的未读计数与提及计数、更新 Thread 相关记录、更新侧边栏的排序时间戳。也就是说一次用户可见的发送动作，背后是三到五倍的行级写操作，这个倍数需按自己环境实测，取决于数据库版本、索引数量和触发器情况。

八千条乘四倍，约三万两千次行级写每天。按八小时工作时间摊平，每秒不到两次；把上午十点和下午三点的高峰按十倍集中算，每秒也就十几次。这个量级对 4 核 8G 完全不构成压力。上线前三个月一切正常，原因就在这里。

但这条线有两个会突然抬升的开关。第一个开关是频道规模。前面提到的未读计数更新，影响行数等于频道成员数。全员频道里每发一条消息，就是三百行更新。如果公司把讨论都放在大频道里，写入量会被频道规模直接乘上去。第二个开关是集成与机器人。接了监控告警、CI 构建通知、工单系统之后，机器人发的消息量往往比人还多，而且集中在故障时刻，那是写入最需要余量的时刻。

这条线唯一会反向拖慢搜索的地方是数据库的 autovacuum。Posts 和 ChannelMembers 是高频更新表，会产生大量死元组。autovacuum 跟不上就会表膨胀，索引扫描变慢，连带搜索变慢。表现为：CPU 和内存都不高，但查询就是慢，且慢得越来越明显。这时候该动的是 autovacuum 参数和维护窗口，不是内存。

搜索索引这一条：中文分词、历史消息量与索引体积的关系

第三条线是本文的重点。自建协同平台一般有两套搜索方案可选：内置的 Bleve 索引，索引文件落在本地数据目录、由主进程直接操作；或者外接独立的 Elasticsearch / OpenSearch 集群，由主进程把索引请求投递过去。前者省事，跟主服务抢同一台机器的 CPU、内存和磁盘 IO；后者多一台机器，但把负载彻底隔开。

索引里存的字段主要有消息正文、发送人、频道名、文件名，以及为自动补全准备的前缀字段。现在算体积。一条消息正文按三十个汉字算，UTF-8 下每个汉字三字节，正文约九十字节；加上词项字典、倒排列表、字段位置信息等结构开销，膨胀系数按一点五到三倍估（需实测），取两倍，单条约一百八十字节。

按前面的日均八千条、一年二百五十个工作日算，年增两百万条，索引年增约三百六十 MB。这个数字相当反直觉：索引本身占的磁盘非常小，几百 MB 到几个 G 的量级。所以开篇那家公司每月涨的三十几个 G，主项根本不是索引，是附件。

那搜索为什么会从秒回变成七八秒？原因不在体积，在结构。第一，倒排链变长。像"上线""环境""客户"这种高频词，在两百万条消息里出现次数以万计，一次查询要遍历的列表变长。第二，索引分段变多。持续写入会让索引文件产生大量 segment，一次查询要跨多个 segment 归并结果，随机读次数成倍增加。第三，也是最致命的一条，索引文件和数据库、附件往往在同一块盘上，附件的连续大写入和转码进程会把 IO 抢走，索引的随机读只能排队。

中文分词把这三件事再放大一档。英文靠空格天然分词，中文没有这个边界。分词器要么切得很碎，导致倒排链更长、索引更大；要么切不出来，导致召回差、用户搜不到想要的内容。很多团队为了搜得准，会把内置索引换成外接的 OpenSearch 并挂中文分词插件，代价是索引体积和查询路径都变长，同时多出一套要维护的组件。

所以第三条线的正确算法不是"多少人"，而是"年消息条数 × 单条索引字节数 × 保留年限 × 语言系数"。语言系数这一项，中文场景建议按英文场景的一点五到两倍估，需按自己环境实测。

索引为什么最先撞墙：体积、查询延迟与写入放大三件事一起发生

第三条线之所以比第二、第四条更早出问题，是因为体积增长、查询变慢、写入放大这三件事是同一个过程的不同侧面，它们会同时恶化。

体积这一侧有个陷阱：删除不会立刻让索引变小。索引里的删除通常是标记删除，写一条墓碑记录，空间要等到分段合并时才真正回收。这意味着就算开了消息保留策略、数据库里的老消息已经删掉，索引文件的大小也可能好几个月不变。运维看到"数据删了但磁盘没降"，常常以为是配置没生效，其实是合并没触发。真正回收要么等合并，要么主动做一次全量重建索引。

查询延迟这一侧，自动补全比正文搜索更耗。用户在输入框里每敲一个字都可能触发一次前缀查询，中文下的前缀查询代价又高于英文。如果同时开了用户名提及、频道名、命令的补全，一个人的输入动作背后是若干次索引查询。这部分负载跟"有多少人在搜"关系不大，跟"有多少人在打字"关系很大。

写入放大这一侧，每一条新消息都要进索引，这是一次额外的写。Bleve 这类内置索引还受批量索引窗口参数的调控，窗口设得短就写得更频繁、segment 更多、查询更慢；设得长就消息发出后要过一会儿才搜得到。这个取舍在采购阶段几乎没人提，上线半年后才变成工单。

三件事叠加的结果就是：搜索变慢的时间点远早于磁盘写满的时间点，也远早于连接撑不住的时间点。而搜索变慢最容易被误判成内存不足，因为"加缓存"是最符合直觉的动作。加了内存之后如果索引还在那块被抢占的盘上、分段数还在涨，延迟不会有本质改善。开篇那家公司加完 16G 还是慢，就是这个道理。

顺带说一句，全量重建索引本身是个要认真排期的运维动作。两百万条消息的重建耗时需按自己环境实测，期间搜索结果可能不完整。很多团队上线一年后才第一次做这件事，而此时他们往往已经习惯了"搜索有点慢"这件事。

附件这一条：存储量、预览转码与缩略图带来的 CPU 尖峰

第四条线是磁盘增长的主项，也是唯一一条呈脉冲形状的线。先算存储量。三百人的团队，假设每天上传六十个附件，截图一到三 MB、文档几 MB、视频和安装包几十到几百 MB，平均按八 MB 估（需按自己环境实测）。六十乘八等于四百八十 MB 每天，一个月三十天就是十四点四 GB。

这还只是原始文件。群里的重复转发不会去重，历史版本默认不清，缩略图会按多个尺寸各生成一份。把这些按一点二到一点五倍的冗余系数算，月增二十 GB 上下。如果团队里有人习惯发录屏或者发构建产物，平均大小会从八 MB 抬到几十 MB，月增三十几个 G 完全成立。这就是开篇那个数字的来源，跟索引的几百 MB 完全不是一个量级。

按三年不清理算，就是五百 GB 以上，而且这个数会一直涨。这是唯一一条"什么都不做也会自己长大"的存储线。

然后是预览转码，这是第四条线最讨厌的部分。图片要生成多尺寸缩略图，是短任务；视频要走 ffmpeg 抽帧和转码，是重任务。一个两百 MB 的视频，转码时可能占满若干核持续若干秒到几十秒，同时吃掉几百 MB 内存，具体数值需按自己环境实测。这个尖峰跟在线人数毫无关系，只取决于"有没有人刚好在这一刻传了个大文件"。

尖峰的破坏力在于它会同时拖慢另外三条线。转码占满 CPU 的时候，正在排队的搜索查询等不到时间片；转码的大块写入占满磁盘的时候，数据库的提交和索引的随机读一起变慢。用户看到的现象是"有人发了个视频之后，整个平台跟着卡了一下"，而监控上的平均 CPU 看起来并不高，因为尖峰被平均掉了。

附件这条线还有个长期成本：缩略图会产生海量小文件。文件数量上去之后，备份时间、迁移时间、文件系统检查时间都会变长，inode 也可能先于容量耗尽。所以配置单文件大小上限、限制允许的文件类型，是从源头控制这条线的手段之一。

保留政策是一级杠杆：删消息、归档频道与冷热分层各自影响什么

既然索引和附件这两条线都带年限乘数，那么保留政策就成了整个选型里杠杆最大的一个决定。它比 CPU 型号、内存大小重要得多，而且必须在买机器之前定下来。

第一个动作是删消息。平台一般提供按天数的消息保留配置，超过年限的消息会被定时任务清理。它减少的是 Posts 表行数和索引文档数，直接影响第三条线的规模。但要记住前面说过的：索引是标记删除，磁盘不会立即回收，要等分段合并或重建。所以评估效果要看数据库行数，不要只看磁盘占用。

第二个动作是归档频道。归档把频道从活跃列表里移除，侧边栏要渲染的频道变少，未读计算和排序计算的量下降。它改善的是日常操作的响应速度，也就是"打开客户端快不快、切换频道卡不卡"。但归档频道的消息通常仍在数据库里、仍可被检索，具体行为取决于版本与配置，需实测。换句话说，归档不解决磁盘增长，别把它当成容量手段。

第三个动作是冷热分层，把历史附件挪到对象存储，数据库和近期附件留在本地 SSD。这是三个动作里唯一能同时缓解"搜索慢"和"磁盘涨"的：磁盘压力被卸掉，索引文件的随机读不再跟附件的大块写入抢 IO。它也是唯一一个几乎不影响 CPU 的动作。

三个动作有明确的先后顺序。先定删什么，因为它决定总量；再定归档什么，因为它决定日常操作量；最后定冷热，因为它决定这些量放在什么介质上。反过来做，会先买一堆盘，然后发现日常操作还是卡。

保留年限取多少，本质上是管理和合规问题，不是技术问题。常见做法是消息留两到三年、附件留一到两年，具体需按自己法务与合规要求定。这里的关键是：年限一旦定下来，容量就变成了一道乘法题，而不是拍脑袋。这也是本文主张"先定政策再定规格"的原因。

分档估算的四步法：先定政策再定规格，给出扩容触发条件

把前面的口径收拢成一个可执行的顺序。

第一步，定政策。消息保留多少天，附件保留多少天，单个文件大小上限多少兆，允许哪些文件类型，允不允许视频预览。这几个数字直接决定后面所有乘法。

第二步，定搜索方案。三条路：用内置索引放在本地盘上，成本最低但跟主服务抢资源；用独立的 OpenSearch 节点并配中文分词，搜得准但多一套组件要维护；限制可搜索窗口，只索引最近若干个月的消息，历史消息不走搜索只走数据库按频道翻页，这是用功能换资源。三条路的机器规格完全不同。

第三步，由前两步反推容量。索引容量等于年消息条数乘单条索引字节数乘保留年限；附件容量等于日均附件数乘平均大小乘三十乘十二乘保留年限，再乘缩略图和历史版本的冗余系数。这两项加上数据库本身的大小，就是三年后这台机器至少要扛住的量。

第四步，才轮到定 CPU、内存和磁盘。这一步反而简单，因为前三项算完之后，规格是被推出来的。连接和写入这两条线对 CPU 和内存的要求不高，真正需要预留的是预览转码的 CPU 尖峰和索引的磁盘 IO。

按这个顺序走一遍三百人的场景：日活两百，日均八千条消息，索引年增约三百六十 MB，附件月增十四 GB 起、按团队习惯可能到三十 GB。结论是 8 核 16G 而不是 4 核 8G，但加这 4 核不是为了在线人数，是为了转码尖峰和索引重建时的余量；磁盘的可扩容性比初始容量更重要，且附件最好从第一天就挂在对象存储上，而不是先放本地盘等满了再迁。

在磁盘可扩容性和独立数据盘方案这类问题上，一万网络（www.idc10000.net，深耕 19 年、成立于 2007 年）可以作为私有化部署这类协同平台时的服务器与存储配置参考对象，具体档位与价格需实时询价，价格主要受 CPU、内存、存储、带宽、IP 和线路影响。这里不给具体报价，因为这类平台的配置高度依赖上一步算出来的保留年限与附件量，脱离这两个数谈价格没有意义。

最后给出六条扩容触发条件，每条都绑定对应的动作，避免一慢就加内存：

搜索 p95 延迟从亚秒涨到两秒以上，且加内存后无改善。查索引分段数和磁盘 IO 等待，动作是把索引挪到独立 SSD 或独立节点，不是加内存。

磁盘月增量乘十二大于剩余容量的一半。动作是扩盘或者把历史附件挪到对象存储，先做哪个取决于冷热分层有没有做。

有人上传视频的时段内 CPU 接近打满，且消息发送延迟同步上升。动作是把转码任务拆到独立进程或独立节点，或者在文件策略里关掉视频预览。

长连接数长期接近单实例承载上限，或者每次升级重启都收到一批掉线反馈。动作是加实例上集群，注意业务端口和集群内部端口的连通性要分开验证。

数据库连接池出现等待排队。动作是调连接池上限、检查 autovacuum 是否跟得上、必要时把数据库独立出去或做读写分离。

索引文件体积远大于按公式算出的值。大概率是保留策略没生效或者删除未合并，动作是先重建索引再谈扩容，否则换了大机器也只是把问题推迟。

什么情况下不该自建：团队规模、运维投入与合规要求的三条线

最后说清楚边界。自建不是所有规模下的最优解，下面三条线各自画了一条不该自建的线。

第一条是团队规模线。五十人以下，按人头付费的商业协同工具，年度总额通常低于一台能稳定跑住的机器加上备份存储的成本，具体需按自己询价对比。人数太少时自建省不下钱，真正省下的是"数据在自己手里"这件事本身。而这份安心值多少钱，每家公司的答案不一样，但至少要清楚它是唯一收益。

第二条是运维投入线。自建之后有四件事是固定要做的：版本升级、备份与恢复演练、索引维护（合并与重建）、证书与推送通道的续期。这几件事没有一件是一次性的。如果团队里没有人能稳定承担，就不该自建。最贵的一次成本往往不是买机器，而是某次升级之后索引与数据库不一致，全员搜不到历史消息，而要修复它得停服务重建索引。

第三条是合规要求线。真正必须自建的情形是数据不允许离开本地机房，且要求能随时导出全量数据与完整审计日志。这类要求下自建是唯一解，多花的钱是合规成本。反过来，如果只是想统一账号体系、或者不喜欢某款商业工具的界面，那不构成自建理由，因为这两件事用其他方式也能解决。

还有一种规模够大但形态不合适的情况：组织分布在多地、要求就近接入、要求跨地域容灾。这时自建的技术门槛会从"装一个服务"跳到"装一个分布式系统"——共享存储、集群内部通信、搜索集群三者要同时稳定，运维复杂度不在一个量级。到了这一步，先评估有没有人能长期维护这套东西，再决定要不要继续。

一个实用的判断顺序：把上面三条线各自过一遍，任何一条明显不满足，就先别自建。或者先用商业工具跑半年，把真实日活、人均日均消息数、日均附件量这三个数测出来，再回来做本文的估算。测出来的三个数，比任何估算公式都准，因为公式里的系数都得靠它们校准。

自建协同平台之前，IT 和采购通常还会问这些

三百人规模要不要一开始就上集群版？单机先跑着行不行？

单机跑三百人的连接和写入通常没问题，真正决定是否上集群的是另外两件事：能不能接受升级时的短中断，以及搜索和转码要不要与主服务隔开。如果只是要消除单点，先做数据库独立和备份，收益比上集群更直接。集群形态还要求共享存储，那是另一笔投入。

中文搜索一定要外接 Elasticsearch 或 OpenSearch 吗？内置索引用不了？

能用，但准召率和使用体验要接受打折。内置方案对中文的切分策略与英文不同，搜常见词容易出现要么过多要么漏掉的情况。如果团队把"翻历史消息"当成高频动作，外接一套带中文分词插件的搜索引擎是值得的，代价是多一套组件和一次索引重建的排期。

附件能不能直接放共享目录或者网络盘，还是必须上对象存储？

小团队放本地目录或者网络盘都能跑，集群形态下则必须有所有节点都能访问的共享存储，这是硬门槛。对象存储的额外价值在于冷热分层和容量弹性：历史附件挪过去之后，本地盘只留近期文件，索引的磁盘 IO 不再被抢占。是否"必须"，取决于团队规模和有没有做集群。

升级版本的时候索引要不要重建？要停多久？

不一定每次都要重建，但跨较大版本或者更换搜索引擎时必须重建。重建期间搜索结果可能不完整，两百万条消息的重建耗时需按自己环境实测。排期上要避开业务高峰，并且提前告知用户"这段时间搜索可能搜不全"，否则会被当成故障报上来。

备份到底要备份哪几份？只备份数据库够不够？

不够。至少四份：数据库、附件目录、配置文件、以及索引（或者明确保留可重建的能力）。只备份数据库，恢复出来的是一个能登录但所有历史附件都打不开的平台。恢复顺序也有讲究，先把数据库和附件恢复到位，再考虑重建索引，因为索引可以从数据库重建，反过来不行。

已经买了 4 核 8G 的机器，能不能不换机器只加盘？

加盘能解决磁盘增长，解决不了搜索慢和转码尖峰。判断依据很简单：如果慢的时候 CPU 和 IO 等待都高，那瓶颈不在容量，加盘没用。这种情况下更划算的动作通常是先做冷热分层把附件卸走，观察一段时间再决定要不要升配。

这篇里的估算口径该怎么按自己的团队规模复算

复算只需要五个自己环境的数，其余系数都可以沿用本文的取值，最后再拿实测校准。

第一个数是日活人数，不是总人数。从平台后台的活跃用户报表直接取，或者按总人数的五到七折先估着，上线一个月后用真实数据替换。

第二个数是人均日均消息条数。可以按频道抽样统计一周，也可以先从后台的消息总数除以日活除以天数算出来。这个数在不同团队之间差距极大，从十几条到上百条都有可能，是整篇文章里最需要自己测的一个。

第三个数是日均附件数和平均附件大小。这两个数的乘积决定了磁盘月增量。特别注意要包含视频和安装包，它们的平均大小能把整体拉高一个数量级。

第四个数是消息保留年限和附件保留年限。这是政策值不是观测值，按自己法务与合规要求定。它同时决定索引容量和附件容量，是复算里杠杆最大的一项。

第五个数是可接受的搜索延迟上限。它决定你要不要外接搜索引擎、要不要限制可搜索窗口。这个数不是技术指标，是体验指标，通常由"用户抱怨之前"的那个阈值倒推出来。

拿到这五个数之后，按第三步的两条公式分别算索引容量和附件容量，加上数据库本身的体量，得到三年后的容量下限；再看预览转码的尖峰需求决定 CPU 核数；最后看连接数决定要不要多实例。整个顺序里，在线人数只在最后一步出现一次，而且通常不是决定性的那一项。