Redis-消息队列和异步处理

之前公司有个app的项目,里面有即时聊天,需要一个存放聊天记录的接口

每一条聊天记录都直接存放mysql,来一条insert一条,量不大还好说,基本都能应付。但是如果量特别大,一天几百万条,上千万条,这个insert操作就会执行几百万次,会不会响应不过来?用户体验会不会降低?

类似的案例还有

一个帖子,用户每访问一次就要set visitor = visitor+1,每天访问上百万次,就要update上百万次,,这个聊天记录表又是访问请求最高的,会不会锁死?

其实这些都可以优化

Redis读的速度是110000次/s,写的速度是81000次/s 。

第一个案例里面可以用Redis做消息中转站,用一个list存放我们的聊天记录。

利用Redis的性能,我们可以把这些请求都写到缓存。然后后台启用一个crontab定时任务,每分钟执行,把队列里的数据拿出来,存到MySQL,甚至可以每10秒,5秒做一次操作

这里给大家一个简单的demo

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
//插入消息队列
public function actionPush()
{

$key = 'chatLog:' . date("Ymd");
$content = '测试内容';
$data = [
'user_id' => 1,
'create_time' => date("Y-m-d H:i:s"),
'content' => $content
];
RedCache::rPush($key, json_encode($data));
}

//pop插入数据库
public function actionPop()
{

$key = 'chatLog:' . date("Ymd");
$length = RedCache::lLen($key);
if ($length > 0) {
for ($i = 0; $i < $length; $i++) {
$data = RedCache::lPop($key);
TestService::insertChat(json_decode($data, true));
}
}
}

利用linux的crontab定时任务异步的去调用actionPop

因为crontab的最快频率是1分钟调用一次,如果实时性要求很高,比如2秒

可以写个脚本

1
2
3
4
5
6
7
8
step=2 #间隔

for (( i = 0; i < 60; i=(i+step) )); do
$(curl http://127.0.0.1/kxds/web/index.php?r=redis/list/test2)
sleep $step
done

exit 0

然后创建crontab任务

每分钟去执行这个脚本

1
* * * * * /web/chat.sh

这样就实现了每2秒钟去掉我们的pop-insert接口

利用Apache的ab做测试
1000次请求100个并发结果:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
erver Software:         nginx/1.8.1
Server Hostname: 127.0.0.1
Server Port: 80

Document Path: /kxds/web/index.php?r=redis/list/test1
Document Length: 0 bytes

Concurrency Level: 100
Time taken for tests: 9.936 seconds
Complete requests: 1000
Failed requests: 0
Total transferred: 357000 bytes
HTML transferred: 0 bytes
Requests per second: 100.65 [#/sec] (mean)
Time per request: 993.563 [ms] (mean)
Time per request: 9.936 [ms] (mean, across all concurrent requests)
Transfer rate: 35.09 [Kbytes/sec] received

可以看到结果接近10秒钟

而直接接受消息同步存入mysql的测试结果是13.288 seconds

这个响应时间相差还是比较大的

不过这里注意的是,异步更新的内容,属于“丢了其实关系也不大”的数据,如果是非常核心的数据,异步更新要注意数据丢失的危险

第二个案例类似的还有很多

这个数据,其实实时性需要不是那么高,不是每个请求都必须立即处理

这里可以用一个Redis的hash来存放,帖子id对应访问量,每次请求的时候把帖子id对应的值incr增1

同样异步的定时的去从hash里读取数据,update数据库

这样就做到了请求合并和异步更新,可能每次去更新的时候都有几十次上百次增量,这样就合并吊了几十次上百次请求