这是我参与「第五届青训营 」伴学笔记创作活动的第 14 天
登录模块状态转化
JWT的token一旦发送出去, 就会一直维持到其expireTime结束才会失效, 而在这个过程中对JWT信息的维护是很困难的, 例如要做退出登录 / 修改密码 / 用户黑名单等功能的时候, 就比较困难. 即系统的可维护性不高. 目前流行的可行性方案为:
1、将 JWT 存入内存数据库将 JWT 存入 DB 中，Redis 内存数据库在这里是不错的选择. 如果需要让某个 JWT 失效就直接从 Redis 中删除这个 JWT 即可. 但是，这样会导致每次使用 JWT 发送请求都要先从 DB 中查询 JWT 是否存在的步骤，而且违背了 JWT 的无状态原则.
2、黑名单机制和上面的方式类似， Redis 维护一个黑名单，如果想让某个 JWT 失效的话就直接将这个 JWT 加入到 黑名单 即可. 然后，每次使用 JWT 进行请求的话都会先判断这个 JWT 是否存在于黑名单中 已识别的优化项
点赞功能的优化
在互动模块的架构分析中已经分析: 点赞业务本身并不复杂，实际上就是对数据的update操作, 但是点赞本身是无意识行为而且多用户环境下可能非常频繁，如果直接操作数据库, 无疑会增加数据库io操作. 在应用中, 视频的vedio_id和用户的user_id是可以分别不同的, 我们暂时采用直接作为kv存入redis的方案. 这种情况下redis服务丢失可能会导致点赞数据与MySQL数据的不同步.
- MySQL+定时任务方案: 实践表明: 对于大多数的中小项目，低于千万级的数据量，采用mysql分表+cache，是完全可以胜任的，而且稳定性非常高. 但是缺点是数据量非常大时，一张表在查询时压力巨大，需要分表，这增加了存储空间和维护工作量，还可能有一致性问题.
- Redis 采用redis有两种用途，一种是storage，一种是纯cache，需要+mysql一起. 纯cache就是把数据从mysql先写入redis，用户先读cache，miss后再拉取MySQL，同时cache做同步. 一般两种用途不冲突, 需要同时使用.
