伙伴匹配项目笔记

伙伴匹配系统总结

伙伴匹配系统应该算烂尾了，前面那些都还好了，问题出在优化的地方了。我想着实现好友以及聊天室等功能的，包括添加好友、同意好友、删除好友，私聊队伍聊大厅聊等等，这些是参考星球众多大佬的，包括但不限于沙鱼、柒木等大佬，这里就不一一列举了，总之非常感谢。

关于项目名，最开始我打算叫友缘的，但我看星球大佬们叫的聚友园，我就打算改成聚友缘了，这里也是借鉴各位大佬的了。

其实按照测试后端的接口来看，我应该也没什么大问题，应该算是优化成功了的。只是我尝试复用星球大佬的前端代码时，就出现各种问题了，而且因为有些字段名包括代码命名习惯上也各种不同，更主要的是我前端不会，导致我花了两天后除了把页面弄出来外，还有的就是大厅聊天了，别的啥也不是，因此我打算放弃这部分优化了，我觉得这不是我目前最具有性价比的事情。而且这次项目就不上线了，我觉得就这么个也没啥必要了，少点真实性就少点吧，我觉得完全吃透项目才是目前更具性价比的事情。

又因为仅仅优化后端接口，而且这部分实在太乱了，我也就没整理了，也就不发出来了，发出来的都是些自用的直播笔记，没什么价值，看星球其他大佬总结的也是一样的。

https://www.yuque.com/hsu4814/gg5tht?# 《https://wx.zsxq.com/mweb/views/weread/search.html?keyword=伙伴匹配系统》

下面的是一些这次的收获：

前端的一些应用（仅存在于笔记中）
数据库表的设计，扩展字段（用户表多加 tags 字段）、添加关联关系表（方便正查反查）
搜索标签的方式：SQL查询、内存查询的优劣及其应用场景（后面几十万百万数据时，SQL查询速度秒杀内存查询）
JSON 序列化库 Gson 的使用
Stream API 的使用，集合通过stream()转为流对象，再通过 filter() 过滤数据，再通过 map() 转为对象，再通过 collect() 收集在集合中。留意 stream() 和 parallelStream() 的区别
接口文档的作用，Swagger、Knife4j 的简单使用
简单爬虫
EasyExcel，通过 Java 处理 Excel
写业务代码校验逻辑时，把需要查数据库的校验写后面一点，这样在前面逻辑有不符的情况时就能少查点数据库
Session 共享后端分布式登录
QuickRedis 的使用
这里可能不太算收获：将 User 的 id 从 Long 改为 long，可以避免频繁判空，但我感觉还好其实
批量插入数据：普通批量插入（5000 条 13s）、并发批量插入（100000 条关闭日志后 39s）
分页查询，MyBatisPlus 配置
分布式缓存 Redis，自己配置 Redis 序列化器，不配置是用Java原生的，不好用。查询缓存后，从 1.26s 变为 20ms左右（除了第一次要 500ms）（前后都用到了分页查询）
缓存预热，定时任务，为了解决第一次加载要 500ms 的问题，现在第一次加载只需要 27ms
接触到了 cron 表达式
分布式锁。普通锁只能处理单个JVM进程内的锁，分布式系统的多个JVM就得分布式锁来解决线程安全问题
Redisson客户端配置，缓存预热实现推荐用户
dto，Data Transfer Object，不同层间传输数据。避免暴露敏感数据，也能简化接口。同理 request、vo（View Object）包装类也是同理，vo 是只传输只读数据，request 是封装请求参数。dto、vo 这部分其实我感觉区别不大，可能只是更好分类吧，网上文章也看不懂
事务注解，方便回滚
匹配算法，编辑距离算法，大数据推荐思想。取 TOP 数据，我这 30w 数据取10个，关闭日志耗时 2.7s
分布式锁解决重复入队问题

说完收获就说点值得反思的事情。这次项目优化不同于上次用户中心的，这次设计到很多我想实现的功能，都需要涉及到数据库表设计什么的，还有一些代码的大改，我觉得这些我需要在最开始就有点大概的想法，就说聊天室这个功能，鱼皮哥直播不说我真没想到，后端部分优化都还好了，最难的是前端。下一个是 API 开放平台，我觉得我在开始前就得看看这个课程计划，看看大概有什么，包括项目名也开始自己就想好，然后下次后端部分功能优化完后，前端代码就不套用大佬的了，要么就自己从0实现，要么就彻底放弃。

只是近期估计先不做项目了，这两天把简历写好后开投，然后就边投边学习测试和设计模式了，设计模式学完才会抽时间开始 API 项目了。我也不知道能不能找到实习，也只能听天由命了，有就去，没有就学技术了，看开点，什么能力匹配什么待遇，挺现实的事情，普通人一个，平平淡淡才是真。后续就是设计模式测试八股算法期末，八股和算法针对性复习了。

伙伴匹配项目 笔记