redis (三)

微博项目的key设计

全局相关的key:

表名	global
列名	操作	备注
Global:userid	incr	产生全局的userid
Global:postid	Incr	产生全局的postid

 

 

用户相关的key(表)

表名	user
Userid	Username	Password	Authsecret
3	Test3	1111111	#U*Q(%_

 

在redis中,变成以下几个key

Key前缀	user
User:Userid:*	User:userid:*Username	User:userid:*Password	User:userid:*:Authsecret
User:userid:3	User:userid:3:Test3	User:userid:3:1111111	User:userid:3:#U*Q(%_

 

 

微博相关的表设计

表名	post
Postid	Userid	Username	Time	Content
4	2	Lisi	1370987654f	测试内容

 

微博在redis中,与表设计对应的key设计

Key前缀	post
Post:Postid:*	Post:postid:*Userid	Post:postid:*:Username	Post:postid:*:Time	Post:postid:*:Content
4	2	Lisi	1370987654f	测试内容

关注表: following

Following:$userid -->

 

 

粉丝表

Follower:$userid --->

 

 

 

推送表:revicepost

 

3

4

7

 

 

 

=================拉模型,改进=====================

 

拉取表

 

3

4

7

 

 

问: 上次我拉取了 A->5,67,三条微博, 下次刷新home.php, 从>7的微博开始拉取

解决: 拉取时,设定一个lastpull时间点, 下次拉取时,取>lastpull的微博

 

问: 有很多关注人,如何取?

解决: 循环自己的关注列表,逐个取他们的新微博

 

问: 取出来之后放在哪儿?

答: pull:$userid的链接里

 

问: 如果个人中心,只有前1000条

答: ltrim,只取前1000条

 

 

问: 如果我关注 A,B两人, 从2人中,各取3条最新信息

,这3+3条信息, 从时间上,是交错的, 如何按时间排序?

答: 我们发布时, 是发布的hash结构, 不能按时间来排序.

 

解决:  同步时,取微博后,记录本次取的微博的最大id,

下次同步时,只取比最大id更大的微博

 

 

Timetaken for tests:   32.690 seconds

Completerequests:      20000

Failedrequests:        0

Writeerrors:           0

Non-2xxresponses:      20000

Totaltransferred:      13520000 bytes

TotalPOSTed:           5340000

HTMLtransferred:       9300000 bytes

Requestsper second:    611.80 [#/sec] (mean)

Time perrequest:       81.726 [ms] (mean)

Time perrequest:       1.635 [ms] (mean, acrossall concurrent requests)

Transferrate:          403.88 [Kbytes/sec]received

                        159.52 kb/s sent

                        563.41 kb/s total

 

ConnectionTimes (ms)

              min  mean[+/-sd] median   max

Connect:        0   0   0.9      0     19

Processing:    14  82   8.4     81    153

Waiting:        4  82   8.4     80    153

Total:         20  82   8.2     81    153

 

Percentageof the requests served within a certain time (ms)

  50%    81

  66%    84

  75%    86

  80%    88

  90%    93

  95%     96

  98%   100

  99%   103

 100%   153 (longest request)

 

 

测试结果:

50个并发, 20000次请求, 虚拟下,未做特殊优化

每次请求redis写操作6次.

30+秒左右完成.

 

平均每秒发布700条微博,4000次redis写入.

后台定时任务,回归冷数据入mysql
Redis配置文件

 daemonize yes # redis是否以后台进程运行

 Requirepass 密码 # 配置redis连接的密码

注:配置密码后,客户端连上服务器,需要先执行授权命令

# auth 密码