按业务分解任务

• 查看朋友的分享

• 看朋友圈嵌入的广告

• 发朋友圈

• 点赞 && 评论

查看朋友的分享

在 DB 查询各位好友创建的朋友圈条目

• 每个人的账号在创建的时候跟其他账号是没有关联的，加好友后才产生关联。

每天有 7.8 亿人看，1.2 亿人发朋友圈。所以是读多写少。单机存储选择 MySQL 这种用 B+ Tree 的 DB。

表：除用户表外，还有用户表, 朋友圈用户表，朋友圈用户关系表

• 用户表：笼统的用户信息，与朋友圈用户表关联。

• 朋友圈用户表：存储每个用户的朋友圈设置，如是否发布朋友圈，多少天内的朋友圈可被看见，被发布的朋友圈消息。

• 朋友圈用户关系表：哪些好友的朋友圈可以被哪些人看见，与朋友圈用户表关联。

打开朋友圈时，请求先被负载均衡到某个任务分配器上，分配机器去朋友圈用户表，朋友圈用户关系表查哪些朋友圈可读。

• 搜集可以被查看好友的 ID。根据用户 ID 的分段，去请求不同服务器获取数据。

• 以上操作属于任务分配，有任务分配器。考虑到微信用户多，任务分配器有集群。

• 考虑刚删除，或添加的好友；或者刚决定看或不看其朋友圈的人；这些变动会实时的反映在朋友圈？

每天打开有 7.8 亿人打开微信朋友圈（SL），所以用户肯定要被分库分表。

• 不是所有的好友都会在一个库一张表里。

• 查询返回的数据需要组装。

发朋友圈

发朋友圈，写入朋友圈用户表

• 可以异步复制，或者半同步复制。

• 看别人的朋友圈有延迟是可以接受的。

• 每条朋友圈可能包含的内容：图片，文字，转发（所有在线内容），GPS 定位，提醒谁看，谁可以看。

• 图片需要被单独存储，存储的路径保存在朋友圈用户表。

• 朋友圈用户表直接保存文字，转发（所有在线内容），GPS 定位，谁可以看。

• 提醒谁看：在朋友圈发布时，发出请求提示列表中的用户。可以根据提示好友的数量决定是否执行任务分配。

点赞和评论只会被共同好友看见。

• 这些信息要单独存一个表，也需要查询消息可见人。若人多，可以分配任务。

广告

单独有广告用户表存放用户可能感兴趣的话题，每个话题都有自己的表存放相关内容。

广告用户表针对每个话题记录用户拒绝或点击和点击并促成交易的次数。

• 若用户拒绝某个话题超过五次，把这个话题从广告用户表中标记移除。

• 若点击和点击并促成交易，持续推送相关话题的广告。

• 广告有持续推送或轮巡推送。

• 每个用户看的的广告数量不会太多，负载均衡发送广告就好。

• 但是对所有用户发广告跟朋友圈消息不同，所以这两件事会被任务分解。