原始笔记是一段背景描述加一行公式，这里整理成”背景 / 估算 / 验证”三段式，方便后续在同类问题上复用同一个套路。
当前保留内容
1. 背景
B 公司是 A 公司的子公司，由于业务发展需要，A、B 公司要独立运行，信息系统也要做拆分。
经过初步统计：
- A 公司 MySQL 存储大小：1600 G × 16
- A 公司 Redis 大小：360 G
- A 公司员工数：约 3.4 万人（估计值）
- B 公司员工数：约 0.6 万人
- A + B 公司总群数：87 万个
要解决的问题：粗略估计 B 公司拆分后所需的存储大小，以及 B 公司内部大概有多少个群？
2. 估算
群数这一项用了一条经验公式（幂律形式的粗估）：
(870000 * 3 / 20)^(0.85) = 22298
直觉上的解释：群数并不是线性按员工比例分配的，B 公司虽然只有 A 公司大约 1/6 的员工，但群数上不会按 1/6 缩小那么多，所以这里用一个 0.85 的指数来体现”亚线性增长”。
3. 验证
事后查询 Redis 实际数据：
- B 公司真实存在的群数：24632
- 估算结果：22298
两者非常接近，nice~ 说明这种”按比例 + 幂指数修正”的粗估，在做拆分 / 容量评估的早期阶段是足够用的。
后续可补的方向
这篇后续如果继续整理，建议至少补下面几类内容：
- 把存储（MySQL / Redis）按同样套路也算一遍，形成完整的”拆分容量评估”模板
- 对 0.85 这个指数的来源做些解释（参考的经验公式、数据观察依据）
- 类似估算在其它场景（DAU、QPS、流量）下的可迁移版本
- 估算偏差较大时的常见原因与修正方法
当前这篇先当作一个”用简单规则估算复杂系统”的案例占位条目。
FEATURED TAGS
Git
Cheat Sheet
Markdown
Tools
C++
Linker
Thread
Linux
TCP
Network
GDB
Debug
leetcode
链表
WSL
Ubuntu
Windows
Linux Kernel
GCC
Android
adb
Troubleshooting
Profiling
Sanitizer
glibc
MySQL
Database
Python
curl
Build
ELF
clang-format
CMake
Graphviz
Performance
vcpkg
Protobuf
排查
速查
内存
STL
调试
性能分析
性能
读书笔记
方法论
架构
网络
Timer
mbedTLS
TLS
安全
负载均衡
脚本
工具
LRU
二叉树
BST
中序遍历
回溯
二分查找
优先队列
排序
旋转数组
jenkins
部署
