技术派项目源码地址 :
用户的相关统计信息
文章的相关统计信息
Redis Incr 命令将 key 中储存的数字值增一
接下来看下技术派的封装实现
/**
* 自增
*
* @param key
* @param filed
* @param cnt
* @return
*/
public static Long hIncr(String key, String filed, Integer cnt) {
return template.execute((RedisCallback<Long>) con -> con.hIncrBy(keyBytes(key), valBytes(filed), cnt));
}
我们将用户的相关计数,每个用户对应一个hash数据结构
key: user_statistic_${userId}
field:
计数器的核心就在于满足计数条件之后,实现的计数+1/-1
通常的业务场景中,此类计数不太建议直接与业务代码强耦合,举个例子
用户收藏了一个文章,若按照正常的设计,就是再收藏这里,调用计数器执行+1操作
上面的这样实现有问题么?当然没有问题,但是不够优雅
比如现在技术派的设计场景,点赞之后,除了计数器更新之外,还有前面说到的用户活跃度更新,若所有的逻辑都放在业务中,会导致业务的耦合较重
技术派选择消息机制来应对这种场景(扩展一下,为什么大一点的项目,会设计自己的消息总线呢?一个重要的目的就是各自业务逻辑内聚,向外只抛出自己的状态/业务变更消息,实现解耦)
技术派写了如下监听器 :
/**
* 用户操作行为,增加对应的积分
*
* @param msgEvent
*/
@EventListener(classes = NotifyMsgEvent.class)
@Async
public void notifyMsgListener(NotifyMsgEvent msgEvent) {
switch (msgEvent.getNotifyType()) {
// 文章新增评论或回复
case COMMENT:
case REPLY:
CommentDO comment = (CommentDO) msgEvent.getContent();
RedisClient.hIncr(CountConstants.ARTICLE_STATISTIC_INFO + comment.getArticleId(), CountConstants.COMMENT_COUNT, 1);
break;
// 文章删除评论或回复
case DELETE_COMMENT:
case DELETE_REPLY:
comment = (CommentDO) msgEvent.getContent();
RedisClient.hIncr(CountConstants.ARTICLE_STATISTIC_INFO + comment.getArticleId(), CountConstants.COMMENT_COUNT, -1);
break;
// 收藏文章
case COLLECT:
UserFootDO foot = (UserFootDO) msgEvent.getContent();
RedisClient.hIncr(CountConstants.USER_STATISTIC_INFO + foot.getDocumentUserId(), CountConstants.COLLECTION_COUNT, 1);
RedisClient.hIncr(CountConstants.ARTICLE_STATISTIC_INFO + foot.getDocumentId(), CountConstants.COLLECTION_COUNT, 1);
break;
// 取消收藏
case CANCEL_COLLECT:
foot = (UserFootDO) msgEvent.getContent();
RedisClient.hIncr(CountConstants.USER_STATISTIC_INFO + foot.getDocumentUserId(), CountConstants.COLLECTION_COUNT, -1);
RedisClient.hIncr(CountConstants.ARTICLE_STATISTIC_INFO + foot.getDocumentId(), CountConstants.COLLECTION_COUNT, -1);
break;
// 点赞
case PRAISE:
foot = (UserFootDO) msgEvent.getContent();
RedisClient.hIncr(CountConstants.USER_STATISTIC_INFO + foot.getDocumentUserId(), CountConstants.PRAISE_COUNT, 1);
RedisClient.hIncr(CountConstants.ARTICLE_STATISTIC_INFO + foot.getDocumentId(), CountConstants.PRAISE_COUNT, 1);
break;
// 取消点赞
case CANCEL_PRAISE:
foot = (UserFootDO) msgEvent.getContent();
RedisClient.hIncr(CountConstants.USER_STATISTIC_INFO + foot.getDocumentUserId(), CountConstants.PRAISE_COUNT, -1);
RedisClient.hIncr(CountConstants.ARTICLE_STATISTIC_INFO + foot.getDocumentId(), CountConstants.PRAISE_COUNT, -1);
break;
// 关注
case FOLLOW:
UserRelationDO relation = (UserRelationDO) msgEvent.getContent();
// 主用户粉丝数 + 1
RedisClient.hIncr(CountConstants.USER_STATISTIC_INFO + relation.getUserId(), CountConstants.FANS_COUNT, 1);
// 粉丝的关注数 + 1
RedisClient.hIncr(CountConstants.USER_STATISTIC_INFO + relation.getFollowUserId(), CountConstants.FOLLOW_COUNT, 1);
break;
// 取消关注
case CANCEL_FOLLOW:
relation = (UserRelationDO) msgEvent.getContent();
// 主用户粉丝数 + 1
RedisClient.hIncr(CountConstants.USER_STATISTIC_INFO + relation.getUserId(), CountConstants.FANS_COUNT, -1);
// 粉丝的关注数 + 1
RedisClient.hIncr(CountConstants.USER_STATISTIC_INFO + relation.getFollowUserId(), CountConstants.FOLLOW_COUNT, -1);
break;
default:
}
}
不一样的地方则在于用户的文章数统计,因为消息发布时,并没有告知这个文章是从未上线状态到发布,发布到下线/删除,因此无法直接进行+1/-1 我们直接采用的是全量的更新策略
/**
* 发布文章,更新对应的文章计数
*
* @param event
*/
@Async
@EventListener(ArticleMsgEvent.class)
public void publishArticleListener(ArticleMsgEvent<ArticleDO> event) {
ArticleEventEnum type = event.getType();
if (type == ArticleEventEnum.ONLINE || type == ArticleEventEnum.OFFLINE || type == ArticleEventEnum.DELETE) {
Long userId = event.getContent().getUserId();
int count = articleDao.countArticleByUser(userId);
RedisClient.hSet(CountConstants.USER_STATISTIC_INFO + userId, CountConstants.ARTICLE_COUNT, count);
}
}
@Override
public UserStatisticInfoDTO queryUserStatisticInfo(Long userId) {
Map<String, Integer> ans = RedisClient.hGetAll(CountConstants.USER_STATISTIC_INFO + userId, Integer.class);
UserStatisticInfoDTO info = new UserStatisticInfoDTO();
// 关注数
info.setFollowCount(ans.getOrDefault(CountConstants.FOLLOW_COUNT, 0));
// 文章数
info.setArticleCount(ans.getOrDefault(CountConstants.ARTICLE_COUNT, 0));
// 点赞数
info.setPraiseCount(ans.getOrDefault(CountConstants.PRAISE_COUNT, 0));
// 收藏数
info.setCollectionCount(ans.getOrDefault(CountConstants.COLLECTION_COUNT, 0));
// 阅读量
info.setReadCount(ans.getOrDefault(CountConstants.READ_COUNT, 0));
// 粉丝数
info.setFansCount(ans.getOrDefault(CountConstants.FANS_COUNT, 0));
return info;
}
用户统计信息每天全量同步
/**
* 每天4:15分执行定时任务,全量刷新用户的统计信息
*/
@Scheduled(cron = "0 15 4 * * ?")
public void autoRefreshAllUserStatisticInfo() {
Long now = System.currentTimeMillis();
log.info("开始自动刷新用户统计信息");
Long userId = 0L;
// 批量处理的用户数,每次处理 20 个用户
int batchSize = 20;
while (true) {
List<Long> userIds = userDao.scanUserId(userId, batchSize);
userIds.forEach(this::refreshUserStatisticInfo);
// 如果用户数小于 batchSize,说明已经处理完了,退出循环
if (userIds.size() < batchSize) {
userId = userIds.get(userIds.size() - 1);
break;
} else {
userId = userIds.get(batchSize - 1);
}
}
log.info("结束自动刷新用户统计信息,共耗时: {}ms, maxUserId: {}", System.currentTimeMillis() - now, userId);
}
/**
* 更新用户的统计信息
*
* @param userId
*/
@Override
public void refreshUserStatisticInfo(Long userId) {
// 用户的文章点赞数,收藏数,阅读计数
ArticleFootCountDTO count = userFootDao.countArticleByUserId(userId);
if (count == null) {
count = new ArticleFootCountDTO();
}
// 获取关注数
Long followCount = userRelationDao.queryUserFollowCount(userId);
// 粉丝数
Long fansCount = userRelationDao.queryUserFansCount(userId);
// 查询用户发布的文章数
Integer articleNum = articleDao.countArticleByUser(userId);
String key = CountConstants.USER_STATISTIC_INFO + userId;
RedisClient.hMSet(key, MapUtils.create(CountConstants.PRAISE_COUNT, count.getPraiseCount(),
CountConstants.COLLECTION_COUNT, count.getCollectionCount(),
CountConstants.READ_COUNT, count.getReadCount(),
CountConstants.FANS_COUNT, fansCount,
CountConstants.FOLLOW_COUNT, followCount,
CountConstants.ARTICLE_COUNT, articleNum));
}
public void refreshArticleStatisticInfo(Long articleId) {
ArticleFootCountDTO res = userFootDao.countArticleByArticleId(articleId);
if (res == null) {
res = new ArticleFootCountDTO();
} else {
res.setCommentCount(commentReadService.queryCommentCount(articleId));
}
RedisClient.hMSet(CountConstants.ARTICLE_STATISTIC_INFO + articleId,
MapUtils.create(CountConstants.COLLECTION_COUNT, res.getCollectionCount(),
CountConstants.PRAISE_COUNT, res.getPraiseCount(),
CountConstants.READ_COUNT, res.getReadCount(),
CountConstants.COMMENT_COUNT, res.getCommentCount()
)
);
}
基于redis的incr,很容易就可以实现计数相关的需求支撑,但是为啥我们要用redis来实现一个计数器呢?直接用数据库的原始数据进行统计有什么问题吗?
技术派的源码中,对于用户/文章的相关统计,同时给出了基于db计数 + redis计数两套方案
通常而言,项目初期,或者项目本身非常简单,访问量低,只希望快速上线支撑业务时,使用db进行直接统计即可,优势时是简单,叙述,不容易出问题;缺点则是每次都实时统计性能差,扩展性不强
当我们项目发展起来之后,借助redis直接存储最终的结果,在展示层直接获取即可,性能更强,满足各位的高并发的遐想,缺点则是数据的一致性保障难度更高**