去有一个我的主界面，我有一些好友，也是一些人的粉丝，你们怎么做排序？
杨为华：我们就是时间排序，最简单的方法，我们没有找到更好的算法之前。
提问：不是根据一些热点？
杨为华：我们也考虑过那个方向，但是我们认为挑战性非常大，你认为好的方法用户不一定认可，这个挑战很大。你用算法做一些东西，但是用户认为不重要的东西，如果用户没有展示，用户可能也会有其他看法。为什么用复合模式，我们也不知道为什么叫复合模式，我们根据实时运行情况，发现哪里有瓶颈我们会想到更好的方法解决。这个瓶颈，能不能给在线用户加一个什么东西，减少系统压力，不影响原来的价值，主要处于每个性能模块的角度考虑的。
提问：你能不能说一下一个用户登陆以后你们做了一些什么步骤，我估计有些是用推的，有些是用拉，各个平台设计微博不一样，有的速度很快，有的会有延迟，你能介绍你们用户交流流程吗？
杨为华：这个图可以看到，最前面还有别的cache，用刚才方式我们看有没有命中，如果没有通过OTUBOX关注列表进行计算，然后把结果合并起来，在上面有一些配件成了cache，反映给用户，整个流程跟这个图上原理来说区别不大。
欢迎补充：微博的数据库设计 这学期学习数据库，老师让我们最后提交一份大作业，于是乎，想做一个小的微博系统，以下是我设计的数据库表： 用户信息 字段名 字段代码 字段类型 描述 编号 User_Id number 主码 用户名 Name varchar(50) 性别 Sex varchar(2) 男or女 生日 Birthday date 注册日期 Rdate date 邮箱 E-Mail varchar(50) 博客地址 Blog varchar(50) 工作 Job varchar(10) 一句话备注 Remarks varchar(100) 信息
字段名 字段代码 字段类型 描述 信息编号 M_Id number 主码 用户编号 User_Id number 发布日期 Release_Date date 内容 Content varchar(300) 评论 字段名 字段代码 字段类型 描述 评论编号 Comments_Id number 主码 信息编号 M_Id number 评论用户编号 C_User_Id number 被评论用户编号 Bc_User_Id number 评论日期 C_Date date 内容 Content varchar(300) 私信 字段名 字段代码 字段类型 描述 私信编号 Private_M_Id number 主码 用户编号 User_Id number 接收用户编号 Receive_User_Id number 发送日期 Send_Date date 内容 Content varchar(300) 回信 字段名 字段代码 字段类型 描述 回信编号 Reply_M_Id number 主码 私信编号 Private_M_Id number 用户编号 User_Id number 接收用户编号 Receive_User_Id number 发送日期 Send_Date date 内容 Content varchar(300) 关注-被关注 字段名 字段代码 字段类型 描述 编号 Id number 主码 关注者编号 concern_User_Id number 被关注者编号 concerned_User_Id number 目前是这样的思路，逐渐改进中，希望高手指点- -
一个微博数据库设计带来的简单思考
在微博系统中，当前用户、关注者（也就是粉丝）、被关注者（崇拜对象） 这三种角色是少不了的。他们之间看似简单
的关系，但是其中数据库表将如何设计，却让我很难琢磨，在如下解决方案中，你们会选择哪种 ? 为什么要选择这种 ? 是否有更好的解决方案 ?
解决方案一： 表名 用户信息表
字段名 字段代码 字段类型 描述 用户名 User_id Varchar(20) 主键 登陆密码 Password Varchar(20) …… …… ……
表名 关注和被关注者表 字段名 字段代码 字段类型 描述 用户名 User_id Varchar(20) 主键 关注者 Funs Text 被关注者 Wasfuns Text
这是我最初想到的一种设计，这里“关注者”和“被关注者”都是采用拼接一些特殊字符分割存储的，比如 A用户有只有关注者 B、 C、 D、 E，那么存入数据库关注者字段的数据将是 B;C;D;E（暂且认为分割字符为；）。
基于上述方案，我提出一个问题：当这个用户的“关注者”或“被关注者”数量很大的情况下（比如 10 万个关注者）将是
怎样的一串字符呢？而且当我们需要查询“关注者”或者“被关注者”最近的博客信息，将面临和博文信息表的一些时间排序查询，处理难度是要浪费性能的。
解决方案二：
基于上述面临的问题，有人给我提供了一个扩展性的解决方案，同时也很好的解决了一个字段海量数据的问题。将方
案一中的关注和被关注者表分解成两张表，如下：
表名 关注者表
字段名 字段代码 字段类型 描述 编号 Id Number 主键 用户名 User_id Varchar(20) 关注者编号 Funs_id Varchar(20)
表名 被关注者表
字段名 字段代码 字段类型 描述 编号 Id Number 主键 用户名 User_id Varchar(20)
被关注者编号 Wasfuns_id Varchar(20)
我看到这样的设计我很吃惊，试想一下，假如我一个用户对应有 1W个关注者，那么该用户就会在关注者表中存在一万条他的记录，这难道不是严重的数据冗余吗？这甚至不符合数据库的设计规范。但是事实上证明，这种设计对大数据量的扩展是很不错的，既然如此，那假如用户和用户之间的关系不只是限于关注和被关注的关系，是不是又要新增表 ？
解决方案三：
话说“合久必分，分久必合”，对上述的设计再进一步修改，于是将方案二的两张表又合二为一，如下： 表名 关注和被关注者表
字段名 字段代码 字段类型 描述 编号 Id Int 主键
用户名 User_id Varchar(20)
目标对象 Operate_object Varchar(20) 状态 Status Number
当目标对象为关注者，标示为1；
当目标对象为被关注者，标示为2； 当双方互相关注，标示为3； 当目标对象为OO，标示为XX。
OK，这样的设计不仅解决了相当一部分的数据冗余，而且还能表示用户之间的多种关系，方便系统日后的扩展。但是问
题又出来了，很明显这样设计对状态的维护也是存在疑问的，用一张表代替多张表，数据肯定是成倍的增长，是否不符合当前常说的“拆库拆表”的战略方针（好像这样的状态一般用于“标记男女”或者“是否删除了”之类的，貌似用于这种场合比较的少）。
做一个微博项目，如何设计数据库表，指点指点，谢谢了。
用户模块 |- 用户注册
|- 填写用户名，昵称，生日（选择），性别，密码，密码提示问题，密码答案完成注册（要求验证用户名不能重复，并加入验证码） |- 个人资料
|- 可以对昵称，生日，性别以及自我介绍进行修改。 |- 上传头像
|- 选择上传用户头像，只允许格式jpg，jpeg，gif和png，且大小小于2M |- 我的听众
|- 查找所有收听我的用户，并列表显示（6条，显示信息参考找人的列表），对于你没收听的用户，可以选择立刻收听 |- 我收听的人
|- 查找所有我收听的用户，并列表显示，可以选择取消收听此用户。 |- 私信 |- 收件箱
|- 可以查看收到的所有私信，列表显示（5条，按时间倒序），显示发送用户的昵称，照片，发送内容，发送时间
|- 可以选择删除某封信，也可以选择直接回复私信 |- 发件箱
|- 可以查看所有发送过的私信，列表显示（5条，时间倒序），显示接收用户的昵称，照片，发送内容，发送时间
|- 可以选择删除某封信，也可以选择为其再写一封 |- 写信
|- 输入收信人帐号以及发送内容，将私信发送给该用户
广播模块 |- 我的大厅
|- 显示当前登陆用户的照片，昵称，并显示我当前的听众数量以及所有发送过的微博数量
|- 可以在输入框里发送自己的微博信息，允许上传一张图片（也可以不传） |- 可以显示所有收听的人和自己发送的最新微博信息（时间倒序，5条每页），显示时要显示发送人昵称，照片，时间（显示距当前系统时间的差距，例如：XXX分钟前，XXX小时前，XXX天前。 只需要显示最大范围的单位即可，例如：如果是1小时30分前，只需要显示“1小时前”即可。） |- 显示最进的热门话题（显示5个，按消息数量倒序） |- 我收听的话题（显示5个，按消息数量倒序） |- 我收听的用户（显示9个，按听众数倒序） |- 广播大厅
|- 显示所有人发布的微博信息（5条，按时间）
|- 可以选择30秒自动刷新功能（选中的每30秒自动刷新页面） |- 热门话题，我收听的话题（同上） |- 我的广播
|- 显示我发布的最新微博信息（时间倒序，5条） |- 其他同上 |- 提到我的