Redis简单类twitter网站的实现

数据结构：
1.用户set:
创建用户

INCR next_user_id => 1000  
HMSET user:1000 username antirez password pwd  id 1000

2.用户的follower/following set:
使用有序集合，用粉丝或者关注的用户 ID 作为元素，用户关系创建时的 unix 时间作为分数。
followers:1000 //Sorted Set of uids of all the followers users
following:1000 //Sorted Set of uids of all the following users
添加followers：

ZADD followers:1000 1401267618 5000 //Add user 5000 with time 1401267618 
ZADD following:5000 1401267618 1000 //Add user 1000 with time 1401267618 

我们需要设置了5000关注1000，同时1000被5000关注的双重关系。

3.关注关系:
使用 ZINTERSTORE 两个人的粉丝set或关注set我们可以获得两个不同用户的关注/粉丝的交集，可以知道"你和 xxx 有 34 个共同关注/粉丝"。

4.用户的时间轴:
我们需要按照时间顺序来访问这些数据，同样使用有序集合。
timeline:1000 //Sorted Set of post ids

ZADD timeline:1000 1401267618 1234 //Add posts 1234 with time 1401267618 

5.用户的主页:
储存着用户自己发布的帖子，同样使用有序集合。
home:1000 //Sorted Set of post ids

ZADD home:1000 1401267618 1234 //Add posts 1234 with time 1401267618 

5.发布一条更新:

next_post_id => 1234  
HMSET post:1234 user_id 5000 time 1401269735 "Hello World" id 1234

一条微博通常包括多个字段，比如发表时间、发表用户、正文内容等，通常使用微博id作为key将多个键值对作为hash保存在Redis中。然后将此消息id写入作者所有follower的timeline中（push），也可以是用户读取timline时加载关注者的posts到timeline（pull）。

性能拓展：

• 对于存储post的服务器，随着post的增加我们可以进行分片。还可以把最新发布的消息存储在Redis里，而较旧（也就是较少读取）的消息则存储到以硬盘存储为主的服务器里面，像MySQL等。
• 对于用户的home和timeline信息流通常是无限增长的，一个合乎情理的做法是限制每个用户的home，timeline的长度。
  例：home只能存储大约 200000 条信息，并将最旧的信息删除或者隐藏。而对于timeline如果从内存的使用效率上看，ziplists是唯一之选。ziplist的最大阈值被设置为Timeline的大小，超过的部分采用上文pull方式获得posts。
• 对于关注，一般采用限制关注数量的方式，例：微博普通用户最大允许关注2000个用户。
• 对于粉丝，粉丝的set有可能会非常大，且不会进行数量限制，我们需要将实现这些列表的有序集合划分到多个分片上面，说得更具体一样，也就是根据分片的数量把用户的粉丝划分为多个部分，存在多个zset中。为此，我们需要为ZADD命令、ZREM命令和ZRANGEBYSCORE命令实现特定的分片版本。
• 对于上面提到的新posts，pull还是push的选择。
  如全部采用pull方式，则timeline只存了上次pull操作之后的posts id。pull操作过程：
  1.遍历关注，根据timeline里最新的time找到之后发表过posts的人
  2.找到这些人的新posts，得到id和time
  3.合并到timeline
  而push方式读取效率高，可以看作O(1)的操作。但是当大V发消息是，瞬时写操作开销大，假设每秒1000条新post，每人N个好友，会产生1000*N的QPS，

注:
ziplists

编码的选择
在通过 ZADD 命令添加第一个元素到空 key 时， 程序通过检查输入的第一个元素来决定该创建什么编码的有序集。如果第一个元素符合以下条件的话， 就创建一个 REDIS_ENCODING_ZIPLIST 编码的有序集：

• 服务器属性 server.zset_max_ziplist_entries 的值大于 0 （默认为 128 ）。
• 元素的 member 长度小于服务器属性 server.zset_max_ziplist_value 的值（默认为 64 ）。

否则，程序就创建一个 REDIS_ENCODING_SKIPLIST 编码的有序集。

编码的转换
对于一个 REDIS_ENCODING_ZIPLIST 编码的有序集， 只要满足以下任一条件， 就将它转换为 REDIS_ENCODING_SKIPLIST 编码：

• ziplist 所保存的元素数量超过服务器属性 server.zset_max_ziplist_entries 的值（默认值为 128 ）
• 新添加元素的 member 的长度大于服务器属性 server.zset_max_ziplist_value 的值（默认值为 64 ）