项目总结 - 红皮书（从 0 到 1 自研）

目录

专辑业务处理

专辑新增或修改（图片的批量新增和修改），体现 @Transation 的使用

评论楼中楼设计（避免递归查询）

搜索推荐（用户画像）

tag 专栏分类（体现 es 分词功能）

专辑访问量、点赞量、收藏量、评论量的统计设计

点赞收藏功能的实现（高性能版本）

数据存储处理（ES 到底需要保存哪些数据）

如何控制 redis 的 list 中每一个元素的声明周期（体现优化业务）

用户业务处理

站内信设计

好友离线消息处理

jwt 令牌 + redis 实现用户信息鉴权

Kotlin 语言设计

DO & Entity 和 Repo 交互 ? 修饰处理

---

专辑业务处理

---

专辑新增或修改（图片的批量新增和修改），体现 @Transation 的使用

a）刚开始是在 service 层编排逻辑如下：

1. 校验图片文件格式
2. 生成图片路径（包含文件名），并且在硬盘上保存或修改图片.
3. 将图片路径保存到 专辑信息dto 中
4. 数据库新增或修改 专辑信息 和 专辑图片信息

这样的编排虽然能实现，但是我测试的有个问题：

有一个种情况，就是硬盘上保存图片成功了，但是数据库出现了异常.  虽然数据库本身是带事务的，可以回滚，但是硬盘的上保存的资源可没法回滚啊（就算是 @Transactional 注解，也只能回滚数据库操作）.  白白浪费了空间.

b）仔细一想可以换个编排方式，因为你需要先保存 专辑信息表 的信息才能拿到 专辑id 嘛