新浪微博的“关注功能”数据库是如何设计的

你好。方法有二个：

我觉得是这样设计的

一个字段记录他所关注的好友信息

应该是json的

然后去数据库查最新的就是更新就是

uchome就是这么干的

-- 用户表(如果这个表数据相当多，可以用分区表)

create table userinfo

( userid number(38,0), -- 可以用序列递增值也成，自己看着办

  username varchar2(60),

  phone varchar2(20),

  address varchar2(20),

  sex char(1),

  cdate date default sysdate

  -- 其他字段，自己添加

)

 

alter table userinfo add constraints pk_userinfo primary key(userid)

 

-- 用户关注信息表(如果这个表数据相当多，可以用分区表)：

create table userattention

( userid number(38,0),           -- 用户ID

  attention_userid number(38,0), -- 被关注的用户ID

  status number(18,0),           -- 关注状态(或者说关注等级，自己定义：0代表什么，1代表什么)

  cdate date default sysdate,    -- 创建时间

  udate date default sysdate     -- 修改时间

  -- 其他字段，自己添加

)

 

-- 为保持数据完整性：不管是“用户ID”还是“被关注的用户ID”其ID必须在userinfo表中存在！

alter table userattention add constraints pk_userattention primary key(userid,attention_userid)

alter table userattention add constraints fk_userattention_userid foreign key (userid) references userinfo(userid)

alter table userattention add constraints fk_userattention_att_userid foreign key (attention_userid) references userinfo(userid)

 

userattention表中一个userid对应该可能有N条记录(而不像你说的：用一条记录，其不同的attention_userid 用逗号隔开，这样设置是不合理的)

 

-- 好比QQ号，我的QQ可以添加N个QQ好友，但我想：腾迅应该不会将我这N个QQ好友用字串连成一条记录（这也太吝啬啦）

对于第一个问题，设计一个schema->(messageID，likedCount)，记录每条微博的点赞数。messageID是微博的编号，likedCount是该微博的点赞人数。但是这里有两个问题需要解决，第一是并发，第二是数据量。

每条微博都有可能有很多人同时点赞，为了保证点赞人数精确就需要保证likedCount++是原子 *** 作，这个可以由应用程序来实现，也可以用redis的事务来实现(如果redis有事务机制或者自增功能的话)，但是我觉得为了性能考虑，也可以不用实现原子 *** 作，具体原因就不展开了。

每天都上亿可能更多的微博内容产生，这样就会有上亿个新的(messageID，likedCount)生成，这样的数据量是比较大的，单机数据库比较难提供高效的服务，所以需要采取sharding的功能(有时候也叫分表分库)，可能根据messageID把这些schema分散到十个或者更多的shards上(据说，sina微博有600个节点，如何三个节点组成一个shard，就有200个shards)，这样每个shard处理的请求就只有原来的十分之一，从而就能提高服务的性能。

关于点赞人列表的设计，一般来说，可能想到的schema是(messageID，userID)，但是这样的设计有一个小问题，就是有些大发的微博可能会得到几十万的点赞，这样就会产生几十万个条数据，这样数据有点多，读取起来可能也慢。所以可以用这样一个schema(messageID，partID，userIDs)，让一个messageID对于多个userID，同时比对应太多的userID，所以加入一个新的partID，一个part存1000个userID，这样几十万个点赞，只需要存几百条数据。这样做还有一个好处，用户点击查看点赞人时的，一般都不是完全显示所有点赞人，而是一批一批显示，这样可以一次只读一条数据，就可显示一批点赞用户信息。

我虽然没参与过微博底层的开发，如果是我设计这个数据库的话我会用2张表解决这个问题

第一张表 用户信息表， 主要依靠ID主键识别用户

第二张表，关系表， 关键col3列 前两列 分别是 好友源 和 好友目标 ,第三列是 关系状态

然后加了好友 只要不断地 在第二张表加入 新行 比如

用户A，用户C ，好友

用户A，用户B ,黑名单

用户B,用户A, 好友

如果是QQ这类 检索关系时候 0， 1字段一起搜索ID 就是互为好友

微博这种 就是单向的 关注。

大概就是这样的模型

可能的问题是用户过多时候表2可能会非常巨大。检索速度可能会受影响

用资源换效率的方式

还可以每个用户一张表

---