（凯思奥）开发记录3：留言板部分，点赞部分(Set)，消息条目部分(Hash) & 兼容评论留言，分页部分&假分页，资源上传工厂模式&接口大整改

1、留言板部分

留言板采取仿的慧编程

上述三个红框分别代表三个回复的状态。
1、tablet 没有replyId（回复方的ID），判定为扔向一级回复。
2、如果回复的是一级回复，则有replyId,但没有parentId，数据的parentId需指向一级帖子的id。
3、如果回复的是二级回复，则有replyId,有parentId,数据parentId即parentId。

注：上述三个状态为 二级回复层的数据。

2020年3月8日20:58:35 留言板前后联调完毕，为优化体感，打算开设锚点跳转。
但是有header遮挡误差64px，故打算使用document.querySelector获取offsetTop并自行减去64px的方式跳转。

2、点赞部分(Set)

点赞模块设计 - Redis缓存 + 定时写入数据库实现高性能点赞功能
业务需求：
用户每天对同一个作品只能点赞一次，第二天继续。

实现思路：
redis采用: Set类型，
key为点赞关系模型 : zanRelative,
value为点赞对应关系: 43: 10001 // 43号作品被10001号用户赞

服务端暂采用setInterval(…, 24小时) 去重置。

3、消息条目部分(HASH) & 兼容评论留言

消息tbl_user_messages表设计

偏前端渲染：

同样，为减轻服务器压力，比如在12点进行重置（reset），将消息表中所有未读的条目 映射入 redis，客户端通过轮询的方式访问redis。
数据存储类型采用Hash。

2020年2月29日22:24:40。
加油，奥利给~

1、开设作品领域实体。

2020年3月9日10:02:24
评论前后联调结束后，需要推入消息表，思索一番，决定占用title字段，存入tbl_user_pw_comment的id。
其实这里占用title也可以开设新字段，但是开设新字段肯定更耗性能，而且title目前毫无用处，变向理解，title可以用于存储hash的头，比如commet-151 进行跳转

理论上，消息机制应该明确类型，比如回复，评论，留言，但是如果这么一设计，消息表得重构，而且工程量大，这里我大致过了下思路，就不改了。理论类型依据如下：
留言：没有parent_comment_id即是。
回复：commentId,from_uid,to_uid,三者均有关联，大致为from_uid和to_uid为倒置关系，即回复。
评论：三者分析，from_uid和to_uid不为倒置且from_uid不等于to_uid，即评论。

但是我将评论和回复均归为艾特（aite）加上根类留言（comment），降低开发成本。

4、分页部分

实现过程暂略。
保留下MsgPage组件真分页代码片段：（因为目前MsgPage采取假分页实现）

  getUserMsgWithCondition({
	pageSize: PAGE_SIZE,
	   page: pageIndex + 1,
	   userId,
	   type: activeIndex === 1 ? 'system' : 'interaction'
	 }).then(({ errno, data }) => {
	   if (errno !== 0) {
	     // showError('消息数据获取失败');
	     return;
	   }
	   const { total, list } = data;
	   setMsgInfo({
	     list,
	     totalPage: Math.ceil(total / PAGE_SIZE)
	   })
	 });

对于分页我个人前思后想，其实对于个人的数据，没有必要去请求真实分页接口。而是直接拿个人全部数据，通过前端渲染假分页去实现即可。

5、资源上传工厂模式&接口大整改

哎，不才，起初是将资源全部上传至云服务器。
不过也算学习了，原生nodejs 去操作文件模块，进行文件操作。
但是对于业务场景来说，必须放置云存储（对象存储）中。
开设类的工程模式，来区分两者，使两者均能使用。（留个纪念）
仔细一想，若开设子类去区分，使得每条逻辑均得判断，太吃力，而且太没必要。
所以，既然用了OSS，那就接收它，之前的file操作以及接口，全部进行整改（哥们走好！）。