一、问题背景与核心挑战

在社交、游戏、即时通讯等高并发场景中，实时统计用户在线状态（如在线/离线/隐身）是系统设计的关键环节。当用户规模达到亿级时，传统单机或集中式方案面临三大核心挑战：

数据规模爆炸：亿级用户状态数据需高效存储与快速查询
实时性要求：状态变更需在毫秒级同步至统计系统
系统可靠性：需避免单点故障导致的数据不一致

典型应用场景包括：实时显示好友在线列表、推送在线用户专属活动、计算在线用户峰值等。这些场景对系统吞吐量（QPS）、延迟（P99）和一致性（最终一致/强一致）提出严苛要求。

二、分布式架构设计思路

1. 分片存储与水平扩展

采用用户ID哈希分片策略，将用户状态数据分散至多个节点。例如使用一致性哈希算法分配用户到N个分片，每个分片独立处理状态更新与查询。

# 一致性哈希分片示例
class ConsistentHash:
    def __init__(self, nodes, replicas=3):
        self.replicas = replicas
        self.ring = dict()
        self.sorted_keys = []
        for node in nodes:
            for i in range(replicas):
                key = self._hash(f"{node}-{i}")
                self.ring[key] = node
                self.sorted_keys.append(key)
        self.sorted_keys.sort()
    def _hash(self, key):
        return int(hashlib.md5(key.encode()).hexdigest(), 16)
    def get_node(self, user_id):
        key = self._hash(user_id)
        for k in self.sorted_keys:
            if key <= k:
                return self.ring[k]
        return self.ring[self.sorted_keys[0]]

优势：支持动态扩容，新增节点时仅需迁移部分数据

2. 混合存储引擎选择

根据访问模式选择存储方案：

热数据层：使用Redis集群存储在线用户状态（ZSET/HASH结构）

# 用户状态存储示例
HSET user:12345 status online last_active 1633046400
ZADD online_users 1633046400 12345

冷数据层：使用HBase/Cassandra存储历史状态变更记录
缓存层：本地Cache（如Caffeine）缓存高频查询用户状态

选型依据：Redis提供亚毫秒级响应，HBase支持海量数据存储，本地缓存降低后端压力

三、实时更新机制实现

1. 状态变更推送方案

长连接通道：通过WebSocket/TCP长连接接收客户端状态变更

// WebSocket处理示例
func handleConnection(conn *websocket.Conn) {
    for {
        _, message, err := conn.ReadMessage()
        if err != nil {
            updateStatus(conn.UserID, "offline")
            break
        }
        updateStatus(conn.UserID, string(message))
    }
}

异步消息队列：使用Kafka/RocketMQ解耦状态变更与统计处理

// 状态变更消息格式
{
  "user_id": "12345",
  "status": "online",
  "timestamp": 1633046400
}

2. 批量处理与聚合

采用时间窗口聚合策略，每秒汇总各分片状态变更：

分片节点每100ms将本地变更写入消息队列
聚合服务按用户ID去重后更新全局状态
使用BitMap或RoaringBitmap压缩存储在线用户集合

性能优化：批量写入使Redis吞吐量提升3-5倍，Bitmap存储空间减少80%

四、统计查询优化策略

1. 多级缓存体系

L1缓存：Node.js/Go服务本地缓存（5分钟TTL）
L2缓存：Redis集群分片缓存（1分钟TTL）
L3存储：HBase持久化存储

2. 近似统计技术

对非精确场景（如在线用户数预估）采用：

HyperLogLog：统计UV时误差率<1%

PFADD online_users "12345" "67890"
PFCOUNT online_users

Count-Min Sketch：高频用户状态查询加速

3. 预计算与物化视图

定时任务生成统计物化视图：

-- 每日在线时长统计示例
CREATE MATERIALIZED VIEW daily_online_stats AS
SELECT user_id, 
       SUM(CASE WHEN status = 'online' THEN 1 ELSE 0 END) * 5 AS online_minutes
FROM user_status_logs
GROUP BY user_id;

五、容错与一致性保障

1. 数据一致性方案

最终一致性：通过消息队列+重试机制保证

强一致性：对关键操作使用Redis事务或分布式锁

// Redis分布式锁示例
func acquireLock(key string) bool {
    id := uuid.New().String()
    if redis.SetNX(key, id, 30*time.Second) {
        return true
    }
    return false
}

2. 故障恢复机制

数据备份：每日全量备份+实时增量日志
熔断降级：当Redis集群不可用时，自动降级为本地缓存+异步补录
灰度发布：新版本分片逐步上线，监控指标异常时自动回滚

六、性能监控与调优

建立三维监控体系：

基础指标：QPS、延迟、错误率（Prometheus+Grafana）
业务指标：在线用户数、状态变更频率
资源指标：CPU、内存、网络IO

调优实践：

Redis内存优化：使用intset编码存储小范围ID
网络优化：启用TCP_NODELAY减少小包延迟
线程模型调整：根据CPU核心数配置Worker线程数

七、典型架构图示

[客户端] --(长连接)--> [连接服务集群] 
                       --> [消息队列集群]
                       --> [状态处理集群]
                       --> [Redis集群]
                       --> [HBase集群]
[查询接口] <--(缓存)--> [L1/L2缓存]
          <--(聚合)--> [统计服务集群]

八、实施路线图建议

MVP阶段：单机Redis+本地缓存实现核心功能
分片阶段：引入一致性哈希分片，部署3节点集群
优化阶段：接入消息队列，实现批量处理
完善阶段：添加多级缓存、监控告警体系

成本估算：亿级用户系统初期硬件成本约50万元，年维护成本20万元（含云服务器、带宽、监控等）

通过上述方案，可构建支持每秒10万+状态更新、查询延迟<50ms、99.9%可用性的在线状态统计系统。实际实施时需根据业务特点调整分片策略、缓存策略和一致性级别。

亿级用户在线状态统计：分布式系统设计与优化实践