说一种最简单的做法
1.内容作为key-value存储
为每一条statu生成一个唯一id作为key，将内容结合化编码后当纯字符串作为value，存在key-value存储中。具体key-value存储就多了。缓存层当然可以直接用memcached亦可。
2.关系处理（这里讲最常用的推模式）
通常status有两个大的组织形式：
A 某个人所有的status列表
B 你关注的人的所有status列表
如果采用推的模式，那么每个人只需要在数据库中维护上面两个列表，相当于有一倍的数据冗余，但是两个列表本身都是可以按uid分表的。第一个按作者的uid分表，第二个按查看消息的用户的uid分表。具体操作的时候，你可以选择双写数据库，也可以直接写其中一张表的，然后走异步队列去写另外一张表。
这个方案想起来比较简单，一般人都能理解。但是在大数据量下还是有很多问题（比如一个人有一百万粉丝，那么他发一条消息，你得发给100w个人，100w次的数据库操作）。
改进的方案当然还有很多。比如什么拉模式，按时间分表，按不同活跃程度的用户区分对待等等。
