一、项目背景与业务价值
在竞争激烈的跨境电商领域，用户体验和精细化运营至关重要。为了实现精准营销、动态定价和运营分析等关键业务场景，我们需要更及时、更准确地理解用户行为。
然而，传统用户标签系统依赖离线计算，数据更新频率为每日一次，实时性不足，无法满足业务快速响应用户行为变化的需求。例如，新用户下单后无法立即享受老用户折扣，个性化推荐也存在滞后性。
为了解决这些痛点，我们启动了实时用户标签系统项目，旨在构建一套高性能、低延迟、可扩展的用户标签基础设施，实现用户行为的实时采集、计算和应用，为业务增长提供有力的数据支撑。
系统上线后，成功支撑日均三千万级用户行为数据处理，标签更新延迟控制在500ms内，为以下关键业务场景提供了有力支持：
- 精准营销：基于用户标签实现千人千面的商品推荐，提升点击率和转化率。
- 动态定价：根据用户标签（如新老用户）实施差异化价格策略，提升用户粘性和复购率。
- 运营分析：通过用户行为标签进行用户行为洞察和转化率优化，指导运营策略调整。
二、架构设计全景图
1. 整体架构
graph TD
AAW[App/Web] -->|HTTP上报| A[区域A数据采集系统]
ABK[后端系统] -->|SDK上报| A
BAW[App/Web] -->|HTT上报| B[区域B数据采集系统]
BBK[后端系统] -->|SDK上报| B
A -->|MQ| C[标签计算系统]
B -->|MQ| C
C --> Da[区域A数据库集群: MongoDB+MySQL+Redis]
C --> Db[区域B数据库集群: MySQL+Redis]
Ea[标签查询] --> Da
Fa[用户系统]-->Ea
Ga[订单系统]-->Ea
Ia[营销系统]-->Ea
Ha[其它...系统]-->Ea
Eb[标签查询] --> Db
Fb[用户系统]-->Eb
Gb[订单系统]-->Eb
Ib[营销系统]-->Eb
Hb[其它...系统]-->Eb
数据流: App/Web/后端系统 → HTTP/SDK上报 → 区域采集系统 → RabbitMQ → 标签计算系统 → MongoDB/MySQL/Redis
分层架构:
- 数据采集层：采用 Nginx+SpringCloud 技术栈，双区域独立部署 (区域A和区域B数据采集系统)，支持 App/Web/API 多端统一接入。具备 高并发 HTTP 接入 能力和 区域路由 功能，确保数据就近接入，降低网络延迟。
- 消息中间件：复用现有 RabbitMQ 集群，降低运维成本。RabbitMQ 承担 数据缓冲和异步解耦 的作用，保障数据采集层和计算层之间的稳定通信。
- 计算存储层：
- 标签计算系统：基于 Spring 构建，采用 轻量级规则引擎 框架，易于扩展和维护。
- 规则管理：MySQL 存储标签规则，实现 规则版本控制和回滚，方便规则迭代和管理。
- 标签存储：采用 MySQL+Redis 组合，MySQL 持久化存储标签规则与计算结果，Redis 提供 实时查询能力，支撑高并发的标签查询请求。
2. 核心组件设计
| 模块 | 技术选型 | 设计要点 |
|---|---|---|
| 数据采集 | Nginx+SpringCloud | 高并发HTTP接入，区域路由 |
| 消息队列 | RabbitMQ集群 | 消息持久化，自动故障转移 |
| 标签计算 | Spring | 轻量级规则引擎，易于扩展 |
| 规则管理 | MySQL | 规则版本控制，支持回滚 |
| 标签存储 | MySQL+Redis | 冷热数据分离存储策略 |
| 用户行为存储 | MongoDB | 用户行为持久化 |
三、核心设计决策
1. 数据采集方案
- 多端统一接入：定义标准 HTTP 上报协议，统一
App/Web/API多端数据接入方式，降低接入成本。 - 区域路由策略：基于 用户标识自动路由 到相应区域采集节点，提升数据上报效率，降低网络延迟。
- 数据校验机制：
- 上报数据格式校验：在采集层进行数据格式校验，过滤无效数据。
- 去重处理：对重复上报数据进行 去重处理，保障数据质量，避免重复计算。
2. 消息中间件选型
| 对比维度 | RabbitMQ优势 | 设计考量点 |
|---|---|---|
| 运维成本 | 复用现有集群 | 无需额外运维投入 |
| 可靠性 | 消息持久化+ACK机制 | 数据零丢失保障 |
| 扩展性 | 集群模式支持水平扩展 | 满足未来增长需求 |
选型分析: 综合考虑 运维成本、可靠性和扩展性 等因素，复用现有 RabbitMQ 集群 是最优选择。RabbitMQ 集群具备良好的 消息持久化、ACK 机制和水平扩展能力，能够满足实时用户标签系统对消息队列的需求。
3. 计算存储架构
| 数据类型 | 存储方案 | 设计考量点 |
|---|---|---|
| 上报日志 | MongoDB分片集群 | 高吞吐写入，灵活 Schema，支持海量用户行为日志存储 |
| 标签规则 | MySQL | 事务支持，版本管理，保障规则数据一致性和可维护性 |
| 标签结果 | MySQL+Redis | 实时查询与持久化存储，兼顾实时查询性能和数据可靠性 |
存储选型:
- MongoDB 分片集群：适用于存储 海量、Schema 灵活 的用户行为日志数据，满足高吞吐写入需求。
- MySQL：适用于存储 结构化 的标签规则和标签结果数据，提供 事务支持和数据一致性 保障。
- Redis：适用于缓存 热点标签数据，利用其 高性能内存数据库 特性，提升标签查询效率。
四、性能优化实践
1. 采集层优化
- 负载均衡：采用 Nginx 轮询 + 权重分配 策略，实现采集层负载均衡，单节点支持 10k QPS 高并发接入。
- 异步处理：数据上报请求 异步化处理，降低请求响应时间，响应时间 <50ms。
- 数据压缩：采用 Gzip 压缩 技术，对上报数据进行压缩，降低 70% 网络传输量，提升传输效率。
2. 容灾方案设计
- 消息重试：RabbitMQ 启用 死信队列，处理标签计算失败消息，保障数据可靠性。
- 数据备份：MySQL 数据库进行 每日全量备份 + 增量备份，防止数据丢失。
- 故障切换：Redis 采用 主从模式 部署，实现 主从自动切换，切换时间 <30s，保障缓存服务高可用。
五、标签体系设计
1. 标签分类模型
graph TD
A[用户标签] --> B(基础标签)
A --> C(行为标签)
B --> D[用户属性]
B --> E[设备信息]
C --> F[购买行为]
C --> G[浏览偏好]
- 基础标签：描述用户的静态属性，例如：用户属性（年龄、地域）、设备信息（设备类型、操作系统）。更新机制为批量每日更新。
- 行为标签：描述用户的动态行为，例如：购买行为（购买商品、订单金额）、浏览偏好（浏览商品类目、浏览时长）。更新机制为事件驱动实时更新。
2. 典型场景实现：新用户转老用户逻辑
以 新用户转老用户 标签更新场景为例，说明实时标签系统的应用流程：
- 监听下单事件：系统 实时监听 订单系统产生的下单事件。
- 校验历史订单数：标签计算系统接收到下单事件后，校验用户近一年内历史订单数是否为 1。
- 触发标签状态变更：若校验通过，则 触发用户标签状态变更，将用户标签从 “新用户” 更新为 “老用户”。
- 推送价格策略：标签计算系统将 新的用户标签推送至商品服务。商品服务 实时更新价格策略，使用户在 <500ms 内 看到商品价格折扣。
六、总结与展望
实时用户标签系统的成功上线，显著提升了用户标签的实时性和应用效率，为业务的精细化运营提供了强有力的数据支撑。项目在高性能、高可靠、可扩展等方面做了深入设计和优化，为后续的迭代升级奠定了坚实基础。
未来，我们将继续在以下方面进行探索和优化：
- 更智能的告警：引入 异常检测 等智能告警策略，提升问题发现和处理效率。
- 更丰富的标签类型：扩展 用户兴趣标签、用户偏好标签 等，构建更全面的用户画像。
- 更灵活的规则引擎：实现更负载的标签计算逻辑，提升系统灵活性。
随着实时用户标签系统的不断完善，将为业务带来更大的价值，持续驱动业务增长。