redis mysql 原子计数器_用redis实现社交产品中计数器

用redis实现计数器

社交产品业务里有很多统计计数的功能，比如：

用户： 总点赞数，关注数，粉丝数

帖子： 点赞数，评论数，热度

消息： 已读，未读，红点消息数

话题： 阅读数，帖子数，收藏数

统计计数的特点

实时性要求高

写的频率很高

写的性能对MySQL是一个挑战

可以采用redis来优化高频率写入的性能要求。

redis优化方案一

对于每一个实体的计数，设计一个hash结构的counter：

//用户

counter:user:{userID}

->praiseCnt: 100//点赞数

->hostCnt: 200//热度

->followCnt: 332//关注数

->fansCnt: 123//粉丝数

//帖子

counter:topic:{topicID}

-> praiseCnt: 100//点赞数

-> commentCnt: 322//评论数

//话题

counter:subject:{subjectID}

-> favoCnt: 312//收藏数

-> viewCnt: 321//阅读数

-> searchCnt: 212//搜索进入次数

-> topicCnt: 312//话题中帖子数

类似这种计数器，随着产品功能的增加，也会越来越多，比如回复数，踩数，转发数什么的。

redis相关的命令

//获取指定userID的所有计数器

HGETALL counter:user:{userID}

//获取指定userID的指定计数器

HMGET counter:user:{userID} praiseCnt hostCnt

//指定userID点赞数+1

HINCRBY counter:user:{userID} praiseCnt

缺点：

这样设计，如果要批量查询多个用户的数据，就比较麻烦，例如一次要查指定20个userID的计数器？只能循环执行 HGETALL counter:user:{userID}。

优点：

以实体聚合数据，方便数据管理

redis优化方案二

方案二是用来解决方案一的缺点的，依然是采用hash，结构设计是这样的：

counter:user:praiseCnt

-> userID_1001: 100

-> userID_1002: 200

-> userID_1003: 332

-> userID_1004: 123

.......

-> userID_9999: 213

counter:user:hostCnt

-> userID_1001: 10

-> userID_1002: 290

-> userID_1003: 322

-> userID_1004: 143

.......

-> userID_9999: 213

counter:user:followCnt

-> userID_1001: 21

-> userID_1002: 10

-> userID_1003: 32

-> userID_1004: 203

.......

-> userID_9999: 130

获取多个指定userID的点赞数的命令变成这样了：

HMGET counter:user:praiseCnt userID_1001 userID_1002

上面命令可以批量获取多个用户的点赞数，时间复杂度为O(n)，n为指定userID的数量。

优点：

解决了批量操作的问题

缺点：

当要获取多个计数器，比如同时需要praiseCnt，hostCnt时，要读多次，不过要比第一种方案读的次数要少。

一个hash里的字段将会非常宠大，HMGET也许会有性能瓶颈。

用redis管道(Pipelining)来优化方案一

对于第一种方案的缺点，可以通过redis管道来优化，一次性发送多个命令给redis执行：

$userIDArray = array(1001, 1002, 1003, 1009);

$pipe = $redis->multi(Redis::PIPELINE);

foreach ($userIDArray as $userID) {

$pipe->hGetAll('counter:user:' . $userID);

}

$replies = $pipe->exec();

print_r($replies);

还有一种方式是在redis上执行lua脚本，前提是你必须要学会写lua。