武威建设厅网站网页快照

一，需求

1，发布评论，支持回复楼层，楼中楼

2，评论读取排序，按照点赞数，时间排序

3，置顶评论，显示作者回复过，点赞过，@用户

4，系统敏感词评审

5，删除评论

6，管理平台，搜索，删除，评审等操作

二，分析及难点

量大，怎么存，存哪里，怎么做到高性能查询，及实现高效排序

不能用普通的表来存储，量大，查询效率不高

用redis ZSET，可实现排序

量的问题：这么多评论，可能几万条，甚至更多。导致zset存的量多大，怎么拆分。

怎么接受评论数据，可用mq进行削峰。

持久化，虽然要存redis，表里也需要存储的，可通过异步存储

从业务层级来说，主题对象是作者发布内容，其次是评论，评论也分第一次层级，回下面回复内容，及嵌套回复。

表结构设计

发布内容表：发布内容ID 发布内容 

评论表：评论ID 发布ID 层级标志（ 0代表第一层评论）父层级ID 评论时间

redis zset存储，key 发布ID， number 评论人ID（第一层），sorce点赞数

评论内容呢，number只能用ID标识，需要另外存吗，String key = 发布ID+评论者ID，value=内容

评论回复呢，回复还有点赞数呢，还是用zset存储，key=发布者ID+评论人ID

number=当前回复人ID，sorce还是点赞数据，他的评论内容还是String存储

有层级结构：用hash存储呢，key field value，可以代替String 

key = 发布ID filed 论者ID value=内容，可以批量操作，批量取数据

高并发访问问题，热点评论问题

按理说，数据都放在redis，高并发访问问题不大，可以用多级缓存，和双检查锁

热点评论问题：还是导致，redis大key问题

mq消息积压问题，写入评论，立刻展示，后续逻辑比如落表，写缓存异步处理