用户信息表（t_user_info）
字段名称 | 字节数 | 类型 | 描述 |
User_id | 4 | uint32 | 用户编号（主键） |
User_name | 20 | Char[20] | 名称 |
Msg_count | 4 | uint32 | 发布消息数量,可以作为t_msg_info水平切分新表的auto_increment |
Fans_count | 4 | uint32 | 粉丝数量 |
Follow_count | 4 | Uint32 | 关注对象数量 |
备注：以User_id取模分表
用户之间关系表（t_user_relation）,必须有关注与被关注的关系
字段名称 | 字节数 | 类型 | 描述 |
User_id | 4 | uint32 | 用户编号（联合主键） |
Follow_id | 4 | uint32 | 被关注者编号（联合主键） |
Type | 1 | Uint8 | 关系类型（0，粉丝；1，关注） |
备注：关系是单向的，以User_id取模分表
{要建立两张表表示用户之间的关系
1. follower表（user, follower）
2. following表(user, following)
由于用户量巨大，所以要对这两个表进行切分库，就是按照user的id进行hash取模，如果要查询什么人follow A ,就只要取模找到A所在的数据库查找follower表，查询A都是follow哪些人，对A取模，然后找到所在的数据库，查找following表
}
用户消息索引表（t_uer_msg_index）
字段名称 | 字节数 | 类型 | 描述 |
User_id | 4 | uint32 | 用户编号（联合主键） |
Author_id | 4 | uint32 | 消息发布者编号（可能是被关注者，也可能是自己）（联合主键） |
Msg_id | 4 | uint32 | 消息编号(由消息发布者的msg_count自增)（联合主键） |
Time_t | 4 | Uint32 | 发布时间（必须是消息元数据产生时间） |
备注：此表就是当我们点击“我的首页”时拉取的消息列表，只是索引，Time_t对这些消息进行排序
消息与消息关系表（t_msg_msg_relation）
字段名称 | 字节数 | 类型 | 描述 |
Reference_id | 4 | uint32 | 引用消息用户编号（联合主键） |
Reference _msg_id | 4 | uint32 | 引用消息编号（联合主键） |
Referenced_id | 4 | uint32 | 消息发布者编号 |
Referenced _msg_id | 4 | uint32 | 被引用消息编号 |
Type | 1 | Uint8 | 操作类型(1,评论；2，转发) |
Time_t | 4 | Uint32 | 发布时间 |
Page_index | 4 | Uint32 | 转发或者评论页码 |
备注：以Reference_id取模分表。
腾讯微博比新浪微博好的一点是一个消息的所有评论和转发都是被固定页码，这样在点击看评论的时候搜索效率更高，因为多了一个where Page_index的定位条件，当然带来的问题就是可能看到有些页的评论排版并不是满页，这就是因为标识为这个Page_index的评论有删除操作。
消息元数据表（t_msg_info）
字段名称 | 字节数 | 类型 | 描述 |
User_id | 4 | uint32 | 发消息用户编号（联合主键） |
Msg_id | 4 | uint32 | 消息编号（联合主键） |
Content | 140 | Char[140] | 消息内容 |
Type | 1 | Uint8 | 消息类型（0，原创；1，评论；2，转发） |
Commented_count | 4 | Uint32 | 评论过数量（只增不减，删除评论不影响此值，可以作为评论多页显示的页码） |
Comment_count | 4 | Uint32 | 保留的评论数量 |
Transferred_count | 4 | Uint32 | 转发过数量（只增不减，删除转发不影响此值，可以作为转发多页显示的页码） |
Transfer_count | 4 | Uint32 | 保留的转发数量 |
Time_t | 4 | Uint32 | 发布时间 |
备注：消息元数据中，content像可能存在图片，这部分可以在分布式文件系统中存储。在2011年数据库大会上听杨海潮的演讲，对于nosql 也有涉及，本人能力有限，对这部分的职责还不清楚，希望高人指点。
非常推崇杨海潮ppt中的归档做法，因为微博是有时间轴线的，对于一定时间之前的记录可以分层次归档，这样在前端的最新的数据表的压力就会减轻很多。
业务逻辑：
1.A关注B
1）在t_user_relation_A中添加
A | B | 1 |
2）在t_user_relation_B中添加
B | A | 0 |
2.原创发消息
1）在t_msg_info_A中添加这条元消息，type为0
2）更新t_user_info_A中Msg_count
3）在t_uer_msg_index_A中插入A发的这条消息的索引（A的编号和消息编号）
4）在t_user_relation_A中找到所有关注A的人，比如B,C,D,E,F等等，并发在这些用户的t_uer_msg_index中插入A的这条信息索引，比如名人微博可以并发多个进程来实现对粉丝的消息同步
3.A转发B的消息msg_b
1）在t_msg_info_A中添加这条元消息msg_a，type为2
2）更新t_user_info_A中Msg_count
3）在t_uer_msg_index_A中插入A发的这条消息的索引（A的编号和消息编号）
4）在t_msg_info_B中更新msg_b的Transferred_count和Transfer_count
5）在t_msg_msg_relation中添加User_a,msg_a与User_b，msg_b的转发关系，page_index为Transferred_count%page_count
4.A评论B的消息msg_b
1）在t_msg_info_A中添加这条元消息msg_a，type为1
2）更新t_user_info_A中Msg_count
3）在t_uer_msg_index_A中插入A发的这条消息的索引（A的编号和消息编号）
4）在t_msg_info_B中更新msg_b的Commented_count和Comment_count
5）在t_msg_msg_relation中添加User_a,msg_a与User_b，msg_b的评论关系，page_index为Commented_count%page_count
5.A删除消息msg_a
1）删除t_msg_info中的元数据msg_a
2）删除t_uer_msg_index_A中的User_a，msg_a行记录
3）备注：如果A的msg_a被别人评论或者引用，那么在对方查看评论或者转发的时候会提示“原消息已被作者删除”
6.A删除转发消息msg_a
1）删除t_msg_info_A中的元数据msg_a
2）删除t_uer_msg_index_A中的User_a，msg_a行记录
3）在t_msg_msg_relation_A表中找到msg_a的源消息，即B的msg_b
4）删除t_msg_msg_relation_A中user_a，msg_a和user_b，msg_b的转发关系
5）更新t_msg_info_B中msg_b记录的Transfer_count，减1
7.A删除评论消息msg_a
1）删除t_msg_info_A中的元数据msg_a
2）删除t_uer_msg_index_A中的User_a，msg_a行记录
3）在t_msg_msg_relation_A表中找到msg_a的源消息，即B的msg_b
4）删除t_msg_msg_relation_A中user_a，msg_a和user_b，msg_b的评论关系
5）更新t_msg_info_B中msg_b记录的Commecnt_count，减1
8.A拉取全部消息
1）从t_uer_msg_index_A中拉取Author_id，Msg_id，Time_t索引，并以Time_t排序
2）通过页码和每页count控制返回结果数量，这样避免了server io 压力冲击
5月25日更新：
1）条件允许的话，所有的index表可以放到内存中，全部cache，而元数据直接ssd，这样读速度会提高很多，当然也要做好热备
2）t_user_relation表最好做合并存储
5月27日更新：
1）在第二步原创发消息要通知给粉丝，这时如果是明星，那么推送的数量可能数百万，新浪采取的做法是对这数百万粉丝进行区别对待，按照活跃度划分为几个层级，每个层级有一个推送时效限定，这样可以做到最想看到这个信息的人能够最及时的看到明星动态
2）用硬件来提升速度，将所有index表放在memory上，元数据放在ssd上，数据可以现在这两层上做处理，并定时持久化到mysql中
3）提供批量处理接口，比如拉取最新更新索引
4）在一定限度上容忍不一样，但要实现最终一致性
6月1日更新：
6月30日更新：
在新浪微博中，评论和转发都与原创消息是一样的独立记录，只不过多了一条消息关系记录，在展现的时候除了要展现自己添加的转发内容或评论内容之外，还需要将最原始的那条目标消息取出来。
12月8日更新：
消息与消息关系表（t_msg_msg_relation）的备注中，应该是以Referenced_id取模分裂
pull的实现
设计要点：
1）DB只作为持久化容器，一切操作在逻辑层完成
2）异步，前端的请求只要在中间server上完成就好，后续的持久化由LazyWriter完成（定时）
3）可以分布式实现，中间逻辑的read和write可是分号段，以适应批量操作，map/reduce
4）尽量做到全量cache，尤其是index
流程说明：
1）在A产生Feed的时候，更新index中A节点的最后更新时间，并标记Feed_id（对于微博来说没有必要做摘要）；然后将content等详细记录写入元数据存储空间
2）B（A的粉丝）登录拉取最新Feed时，由于数量限制（首页有显示空间限制，一般都要做成page_index+page_count）只能拉取所有关注对象中最新的N条Feed，这时先通过批量查询对B的所有关注对象最新Feed做一个排序，因为完全在内存中实现，而且可以map/reduce，所以时间消耗很少，在生成了最新的Feed列表后，直接批量向元数据存储空间拉取完成信息
pull模式的实时性比push模式要好，但是也会遇到关注对象太多时拉取慢的情况，无论pull还是push，最后都可以通过cache index实现快速索引的生成，通过map/reduce实现批量请求的分割与快速处理。
作为互联网应用来说，保证最终一致性才是最重要的，另外一点，对逻辑数据分层次处理，做优先级划分
另，关于用户关系表，上面的做法，在逻辑上有写复杂，也可以这样做
基于上述面临的问题，有人给我提供了一个扩展性的解决方案，同时也很好的解决了一个字段海量数据的问题。将方案一中的关注和被关注者表分解成两张表，如下：
表名 | 关注者表 | ||
字段名 | 字段代码 | 字段类型 | 描述 |
编号 | Id | Number | 主键 |
用户名 | User_id | Varchar(20) | |
关注者编号 | Funs_id | Varchar(20) | |
表名 | 被关注者表 | ||
字段名 | 字段代码 | 字段类型 | 描述 |
编号 | Id | Number | 主键 |
用户名 | User_id | Varchar(20) | |
被关注者编号 | Wasfuns_id | Varchar(20) | |
我看到这样的设计我很吃惊，试想一下，假如我一个用户对应有1W个关注者，那么该用户就会在关注者表中存在一万条他的记录，这难道不是严重的数据冗余吗？这甚至不符合数据库的设计规范。
推和拉的方式
推：
对于u_feed以关注者的id进行水平拆分
用户1发表一条微博
找到用户1的所有关注者
将这条微博根据关注这的id(hash)写入对应的u_feed表
拉：
对于u_feed以发布者的id进行水平拆分
用户1发表一条微博
根据发布者的id写入对应的u_feed中
对于关注者而言，需要一个轮询，比如30s, 就进行如下的操作
或者其关注的所有id, 获取每一个id到u_feed中找发表的最新微博
可以看出，推模式的写的数量量非常大，但是读的性能很好
而拉模式的写的负担比较小，但是要处理好并发读的问题
拉模式的改进主要是在feeds的存储上，使用按照时间进行分区存储。分为最近时间段（比如最近一个小时），近期的，比较长时期等等。我们再来看下查询的流程，比如姚晨登陆微博首页，假设缓存中没有任何数据，那么我们可以查询比较长时期的feeds表，然后进入缓存。下一次查询，通过查询缓存中的数据的timeline，如果timeline还在最近一个小时内，那么只需要查询最近一个小时的数据的feed表，最近一个小时的feeds表比图四的feeds表可要小很多，查询起来速度肯定快几个数量级了。
改进模式的重点在于feeds的时间分区存储，根据上次查询的timeline来决定查询应该落在那个表。一般情况下，经常在线的用户，频繁使用的客户端扫描操作，经常登录的用户，都会落在最近的feeds表区间，查询都是比较高效的。只有那些十天，半个月才登录一次的用户需要去查询比较长时间的feeds大表，一旦查询过了，就又会落在最近时间区域，所以效率也是非常高的。
