第1章：技术选型避坑：开源 vs 商业方案
做在线监测系统，第一步就卡在技术选型上。我见过太多团队，上来就拍脑袋选一套技术栈，结果半年后推倒重来。说白了，选型这件事，选对了省心三年，选错了天天加班。
今天咱们就聊聊三个核心组件的选型：时序数据库、消息队列，以及开源与商业方案之间的博弈。
1.1 开源 vs 商业方案：别被“免费”冲昏头
很多初创团队一听到“开源”就两眼放光。免费嘛，谁不喜欢？但我得泼盆冷水——开源不等于零成本。
核心观点：开源省的是许可证费用，但运维成本、学习成本、定制成本，一样不少。
我在项目中遇到过一家公司，选了某个开源时序库，觉得省了几十万。结果呢？运维团队花了三个月才把集群稳定下来，中间还丢过两次数据。嗯，这里要注意——开源方案通常需要你养一个懂底层原理的工程师。
商业方案呢？贵，但省心。比如 TimescaleDB 的企业版，出了问题一个电话就有人帮你排查。怎么选？我建议你按这个思路来：
- 团队规模小于10人：优先商业方案，别拿时间换钱
- 有专职运维：可以考虑开源，但要做好踩坑准备
- 数据量级在TB以下：开源完全够用
- 数据量级在PB以上：商业方案更稳妥
我的经验：如果预算允许，核心链路用商业方案，边缘业务用开源。这样既控制了成本，又保证了核心稳定性。
1.2 时序数据库选型：InfluxDB vs Prometheus vs TimescaleDB
时序数据库是监测系统的核心。选错了，查询慢、存储贵、扩展难。我见过最惨的案例——有人用 MySQL 存时序数据，三个月后一张表几十亿行，查询一次等半小时。
咱们直接看对比：
| 特性 | InfluxDB | Prometheus | TimescaleDB |
|---|---|---|---|
| 存储引擎 | 自研TSM | 自研TSDB | 基于PostgreSQL |
| 查询语言 | Flux / InfluxQL | PromQL | 标准SQL |
| 集群能力 | 企业版支持 | Thanos/Cortex扩展 | 原生支持 |
| 数据保留策略 | 自动过期 | 按时间窗口 | 自动分区+压缩 |
| 适用场景 | IoT、APM | 监控告警 | 金融、工业 |
说说我的个人习惯：
- 做监控告警：Prometheus 是首选。PromQL 写起来太顺手了，而且生态好，Grafana 直接对接。
- 做IoT数据采集：InfluxDB 更合适。它的写入性能极高，我测过单机每秒能写几十万点。
- 做金融级分析：TimescaleDB 是唯一选择。标准SQL意味着分析师可以直接上手，不用学新语言。
避坑指南：我曾经在某个项目中选了 InfluxDB 做长期存储，结果发现它的数据压缩率不如 TimescaleDB。半年后存储成本翻了三倍。后来迁移到 TimescaleDB，压缩率提升了60%。所以——先算存储成本，再选数据库。
1.3 消息队列选型：Kafka vs RabbitMQ
消息队列是系统的“血管”。选错了，要么吞吐上不去，要么消息丢失。我见过有人用 RabbitMQ 处理每秒百万级消息，结果队列堆积到内存溢出——嗯，这属于典型的选型失误。
直接上对比：
| 特性 | Kafka | RabbitMQ |
|---|---|---|
| 设计理念 | 分布式日志 | 消息代理 |
| 吞吐量 | 百万级/秒 | 万级/秒 |
| 消息可靠性 | 持久化+副本 | ACK+持久化 |
| 路由能力 | 弱（基于Topic） | 强（多种Exchange） |
| 运维复杂度 | 高 | 中 |
怎么选？我建议这样：
- 数据量大于10万/秒：必须上 Kafka。RabbitMQ 扛不住这个量级。
- 需要复杂路由：比如根据消息内容分发到不同队列，RabbitMQ 更灵活。
- 需要消息回溯：Kafka 天然支持，因为它是基于日志的。
- 团队运维能力弱：RabbitMQ 更友好，Kafka 的调优参数太多了。
我的经验：在线监测系统里，我通常用 Kafka 做数据采集层，RabbitMQ 做业务处理层。Kafka 负责扛住海量设备上报，RabbitMQ 负责把数据分发给不同的处理模块。各司其职，互不干扰。
1.4 知识体系总览
下面这张图，是我自己总结的选型决策流程。你想想看，每次选型都走一遍这个流程，基本不会出大错。
这张图的核心逻辑很简单：先看团队能力，再看业务场景。别一上来就纠结技术细节，先把大方向定下来。
总结一句话：技术选型没有银弹。适合别人的，不一定适合你。多花一周做调研，少花半年填坑。
公众号:蓝海资料掘金营，微信deep3321