3. 技术选型总览：主流技术栈对比
高并发评分通道的技术选型直接决定了系统的吞吐上限、开发效率与运维成本。本章从后端语言、数据库、消息队列三个维度进行横向对比，帮助你在不同业务场景下做出最优决策。
选型原则：评分通道的核心链路是“接收请求 → 异步削峰 → 实时评分 → 结果持久化”。技术栈必须围绕低延迟、高吞吐、数据一致性三个目标展开。
3.1 后端语言选型：Java / Go / Node.js
三种语言在并发模型、生态成熟度、团队成本上各有优劣。下表从评分通道最关心的维度进行对比：
| 对比维度 | Java (Spring Boot) | Go (Gin / Fiber) | Node.js (Express / Fastify) |
|---|---|---|---|
| 并发模型 | 线程池 + JVM 调优 | Goroutine + CSP | 事件循环 + 异步 I/O |
| 单机吞吐 (QPS) | 5万 ~ 15万 (调优后) | 10万 ~ 30万 (原生) | 3万 ~ 8万 (单进程) |
| 内存占用 | 较高 (基础 200MB+) | 低 (基础 10MB) | 中等 (基础 30MB) |
| 生态成熟度 | ★★★★★ 最丰富 | ★★★★ 快速完善 | ★★★★ 前端生态强 |
| 编译/部署 | JAR 包 + JRE 依赖 | 静态二进制 | 解释执行 / 打包 |
| 学习曲线 | 中高 (框架复杂) | 低 (语法简洁) | 低 (JS 基础) |
| 适合场景 | 大型企业、复杂事务 | 高并发微服务、中间件 | I/O 密集型、BFF 层 |
实战建议：评分通道的核心服务推荐 Go，利用 Goroutine 处理海量评分请求；周边管理后台、报表系统可使用 Java 或 Node.js 快速交付。
3.2 数据库选型：MySQL / Redis / 时序数据库
评分通道的数据具有写多读少、实时性高、历史轨迹可追溯的特点。单一数据库无法满足所有需求，必须采用混合存储架构。
| 数据库 | 核心定位 | 评分通道用途 | 性能指标 | 数据量级 |
|---|---|---|---|---|
| MySQL | 关系型、ACID 事务 | 用户信息、评分规则、最终结果持久化 | 单表 5000 QPS (读写混合) | TB 级 |
| Redis | 内存 KV、缓存/队列 | 实时评分缓存、计数器、限流令牌桶 | 单实例 10万+ QPS | GB 级 (内存) |
| 时序数据库 (TDengine / InfluxDB) | 时间序列、高压缩 | 评分日志、性能监控、趋势分析 | 百万点/秒 写入 | PB 级 (压缩后) |
避坑提醒：不要将评分明细全部存入 MySQL，否则单表很快达到千万级，导致写入瓶颈。建议 MySQL 只存最终评分结果，明细日志写入时序数据库。
3.3 消息队列选型：Kafka vs RabbitMQ
消息队列是评分通道削峰填谷的核心组件。当瞬时评分请求量超过后端处理能力时，MQ 将请求暂存，由消费者按节奏处理。
| 对比维度 | Kafka | RabbitMQ |
|---|---|---|
| 设计理念 | 分布式日志流 | AMQP 消息代理 |
| 吞吐量 | 百万级 msg/s (集群) | 万级 ~ 十万级 msg/s |
| 延迟 | 毫秒级 (批量优化后) | 微秒级 (单条) |
| 消息持久化 | 磁盘顺序写，高可靠 | 内存/磁盘，支持确认 |
| 消费模式 | 拉模式 (Pull) | 推模式 (Push) + 拉模式 |
| 消息顺序 | 分区内严格有序 | 单队列有序 |
| 运维复杂度 | 中高 (依赖 ZooKeeper/KRaft) | 低 (Erlang 自带) |
| 评分通道场景 | 海量评分事件流、日志采集 | 任务分发、延迟队列、死信处理 |
推荐方案：评分通道主链路使用 Kafka 承接高吞吐评分事件；周边通知、重试、延迟任务使用 RabbitMQ 的灵活路由特性。
3.4 本章技术选型总结
- 后端语言：核心评分服务选 Go，管理后台选 Java 或 Node.js。
- 数据库：MySQL 存最终结果，Redis 做实时缓存，时序数据库存评分日志。
- 消息队列：Kafka 处理主链路高吞吐事件，RabbitMQ 处理辅助任务。