微博架构笔记

一、软件选择

1. Redis

   • 特点：

     • 存储形式多样（fri、attention等可存在list数据结构中）

     • 访问速度较快，QPS十万左右

     • 单线程模型（只需一个核心线程）

   • 部署方案：

     • 32核服务器可部署20个Redis实例

     • 理论可达百万级QPS

2. Memcached

   • 特点：

     • 访问速度极快，QPS百万级别

     • 多线程模型（需多CPU支持）

     • 仅支持KV结构

3. MySQL

   • 特点：

     • 持久化存储

     • QPS 3000-6000左右

二、动态内容管理

1. 多级时间线策略

   • totallist：存储最新1000条内容

   • todaylist：存储当天最新200条

   • hourlist：存储最新1小时内容

   • 实现方式：Redis列表/有序集合

2. 缓存命中逻辑

   • 正常情况：请求命中Memcached或Redis

   • Redis宕机时：

     

三、核心业务流程

1. 关注列表查看

   • 步骤：

     1. 按关注时间排序获取关注ID列表（Redis list）

     2. 根据ID从User Cache获取详细信息

   • 缓存策略：

     • 优先访问Redis

     • 次选Memcached

2. 首页Feed生成

   python

   # 伪代码流程
   def generate_feed(uid):
       # 1. 获取关注列表
       fri_list = redis.get(f'following:{uid}')
       
       # 2. 聚合内容ID
       vectors = []
       for follow_id in fri_list:
           vector = redis.lrange(f'user_posts:{follow_id}', 0, 10)
           vectors.append(vector)
       
       # 3. 排序筛选
       merged_ids = merge_sort(vectors)[:100]
       
       # 4. 获取内容
       feed_data = []
       for id in merged_ids:
           content = memcached.get(f'content:{id}') or mysql.query(id)
           feed_data.append(content)
       
       return feed_data

四、高可用架构

1. 多IDC部署

   • IDC选择策略：

     • 根据用户地域/手机号路由

     • 示例：广州用户→广州IDC，北京用户→北京IDC

   • 跨IDC同步：IDC之间消息队列

   • 容灾方案：

     • 广州IDC故障→流量切至北京IDC

     • 数据通过MQ保持最终一致

五、数据存储优化

1. 计数器服务

   • 使用Redis存储

   • 特点：

     • 紧凑存储（几十字节/用户）

     • 存储粉丝数/关注数等轻量数据

2. 冷热数据分离

   存储层级	数据范围	访问频率	存储方案
   热数据	天/小时级	极高	Redis内存存储
   温数据	周/月级	高	Memcached
   冷数据	季度/年级	低	MySQL分库

   • 分库策略：年库→月库→周库→天库

3. 缓存分层（CacheService/DataMesh）

   • 层级结构：

     • L1层：最热数据（Redis）

     • Master库：较热数据（容量TB级）

     • Slave库：Master的备份

     • DB层：持久化存储

   • 访问流程：

     

六、核心设计原则

1. 缓存优先：

   • 98%请求由Redis/Memcached响应

   • MySQL仅作为持久化层和灾备源

2. 资源最大化利用：

   • 通过冷热分离实现：

     • 高频访问数据→高性能存储

     • 低频历史数据→低成本存储

3. 无缝故障转移：

   • 组件级：Redis宕机→Memcached接管

   • IDC级：区域故障→流量跨区调度