温州专业手机网站制作哪家好下载谷歌浏览器
一，需求
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消息积压问题，写入评论，立刻展示，后续逻辑比如落表，写缓存异步处理