Memory 伙伴匹配系统-开发文档
本文最后更新于:10 个月前
前端项目初始化
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
数据库表设计
| 1 |  | 
| 1 |  | 
后端接口开发
根据标签查询
| 1 |  | 
| 1 |  | 

| 1 |  | 
前端整合路由
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
- 路由整合完成了呢
- 差点忘记了, 这里有个非常恶心的BUG, 我配完vue-router配置后, 启动服务显示页面为空白, 怎么搞都没反应, 结果把自定义路由那儿的 “/“ 删了改成 “/index”后, 就他妈有页面了, 我他妈给改回去后, 既然能正常显示了?!真奶奶的无语, 还好老子聪明机智哈哈哈, 差点栽这儿出不来了
前端页面开发
- 路由整合完毕之后,接下来就要开发我们的搜索页面了:
搜索页面
- 开发页面之前,我们先把搜索页面的路由配置好吧 (src/config/route.ts)
| 1 |  | 
| 1 |  | 
- 去找到合适的组件,完成页面开发
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
- 在脚本里编写一些逻辑,最终达成了:
- 搜索栏可以筛选标签列表里的标签
- 选中标签列表后可以把标签整合成json字符串,将来可以发送json字符串实现根据标签搜索用户
- 注:这块逻辑比较难,可以多加理解消化,这里不做过多介绍了(因为我自己也看懵了,照着人家的代码写下来的)- 展示一下搜索页最终代码和实现效果吧
| 1 |  | 

用户信息页
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
用户信息修改页
| 1 |  | 
| 1 |  | 
| 1 |  | 

| 1 |  | 
| 1 |  | 
| 1 |  | 
Swagger + knif4j 自动生成接口文档
- 第一步:创建Spring Boot项目并且在pom.xml中引入Knife4j的依赖包,代码如下:
| 1 |  | 
| 1 |  | 
- 然后启动项目即可
- 访问 http://localhost:8081/api/doc.html 成功自动生成接口文档!
- 如果springBoot版本高于2.6,可能会有报错,这是因为 knif4j 不兼容现今高版本的springBoot,这里有两种解决办法:
| 1 |  | 
| 1 |  | 
| 1 |  | 
抓取网页信息
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
根据标签搜索用户
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 

| 1 |  | 
| 1 |  | 

根据标签查询(补充)
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
- 简单介绍一下运作原理
- 钩子函数不用多废话了
- 引入我们的myAxios,发送请求,语法要熟悉
- 引入 userRoute,拿到searchPage页携带的标签列表,语法要熟悉
- 然后就是引入 qs , 可以正确地在axios请求中携带数组参数发送到后端,详情还需去百度了解
- 这里我还踩了两个坑,补充说明一下吧:
- axios配置baseURL时,我给配成了 “https://localhost:8081/api",把http写成了https,导致响应状态码一直是500,唉
- 然后就是 qs 了,坑死我了,先介绍一下 qs 引入流程:
| 1 |  | 
| 1 |  | 
打通前后端查询用户
| 1 |  | 
| 1 |  | 
| 1 |  | 

Session共享实现
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
- 修改 spring-session 存储配置- spring.session.store-type
- 默认是 none,表示存储在单台服务器
- store-type: redis,表示从 redis 读写 session
| 1 |  | 

- 接下来就要实现用户登录、用户信息展示、修改用户信息,但涉及到了跨域问题
- 这块login后,后端种下了session,但axios发送请求时,老是携带不到cookie,getCurrentUser()获取不到当前用户登录态
- 先做后边的功能吧,这一块儿我再研究研究,这个跨域携带cookie好像挺难搞定
- axios不能成功携带cookie的话,上面的需求都做不了
- 三天后老子回来了,爷爷解决问题了!那么接下来,就让我捋一捋这个周末都学到了些什么吧!
后端接口开发
修改用户信息
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
- 顺带的,我们整理了所有的 controller层 和 service层的代码,最终呈现出统一格式:
- controller 层负责:简单校验参数 —> 调用service层的接口代码 —>通用返回结果
- service 层负责:实现全部的业务逻辑代码
- 整个项目结构就变得很清晰了,那我们简单展示一下现在的 项目结构 和 代码规范 吧:
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
展示当前用户信息
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
发送修改信息请求
| 1 |  | 
打通前后端?
- axios 发送请求时,默认不会携带cookie,这就导致了:你登录成功了,你的登录态也在后端写进cookie了,但是之后axios发送请求获取当前登录用户信息,由于没有cookie,是拿不到的
- 拿不到当前登录用户信息,剩下的用户信息展示、信息修改就都是扯淡了
- 这是为什么呢?因为我们前后端分离,虽然前后端服务器都在本地,但前端端口号:7070 后端端口号:8081
- 两个相同域名 但不同端口的服务器 在请求响应,这就是浏览器上的跨域问题:解决跨域问题引起的axios无法正确携带cookie
- 如何解决?这里有最简单的解决方法
- 前端 MyAxios.ts 加一行代码 —— withCredentials: true
| 1 |  | 
| 1 |  | 
- 到这里正常来讲问题就应该解决了,但如果这时你发现你前端所有的请求都报错的话,那说明:前端axios是允许携带cookie了,但后端服务器不接受
- @CrossOrigin没有起作用
- 那就试试第二种解决方案吧:
- config/WebConfig 下编写拦截器
| 1 |  | 
| 1 |  | 
- 好!这样问题就完美解决了!
- 但是我这边还有问题,前端请求仍然报错,最终我怀疑是我的前端域名有问题
- 我的域名一直是http://127.0.0.1:7070,于是我这样干了:
- vite.config.ts下:
| 1 |  | 
- 成功把域名修改为http://localhost:7070了,于是一切都成功了
- 当然我也试过这么改,没什么用
| 1 |  | 
- 好了,以上就是跨域axios携带cookie的解决办法
- 最后还有个小BUG,就是后端接收到前端发送的id时,由于id是long型,在传输过程中可能会有精度丢失,导致前后端的id不一致,这里的解决办法在之前的raggie_take_out里也用过,那便是:
- 提供对象转换器JacksonObjectMapper common 基于Jackson进行Java到json数据的转换
| 1 |  | 
| 1 |  | 
导入用户数据
- 第一种:Export data to file导出数据(CSV格式),再Export data from file导入数据 适用于快速导入少量的数据
- 第二种就是用编程的方式批量插入数据了
- 先简单地写下代码实现方法吧:
- 在once/InsertUser下编写:
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
后端接口开发
查询全部用户
| 1 |  | 
| 1 |  | 
| 1 |  | 
前端页面开发
主页页面开发
| 1 |  | 
| 1 |  | 
- 这块儿逻辑注释已经写得很清楚了,不过还是简单介绍一下吧:
- axios请求,携带currentPage和pageSize发送至后端,响应到对应用户列表
- 之前MyAxios封装过返回值:response.data
- 需注意到,我们使用了vant的分页组件
| 1 |  | 
- 有了这个组件,通过change方法,可以很方便地改变当前页码currentPage,同时执行查询,可以查到每页数据
- 组件其他属性也都标明了,可以控制总记录数、每页记录数
- 这里我们使用response.data?.records、response.data?.size、response.data?.total可分别获取:每页数据记录、每页数据容量、总记录数
- 当然,组件上的总记录数total就可以拿到了,pageSize这边是固定死的,每页10条,暂不支持灵活改变每页显示数
- 以上是对这段逻辑实现的粗略介绍,如有疑问还请研读代码,实现过程是十分清晰的
Redis缓存
- 之前我们给数据库批量插入了大量数据,并且在主页根据展示出所有用户信息
- 为了提高查询效率,我们还采用了分页查询的方式
- 但这种解决办法并不彻底,频繁查询数据库还是很低效,所以我们使用Redis技术来解决查询效率低下的问题
Redis的引入和测试
| 1 |  | 
| 1 |  | 
| 1 |  | 
- 增删改查没有问题
- 这里存在这样的问题:RedisTemplate 底层的序列化方式,会导致存入的序列化后的value值成为乱码
- StringRedisTemplate 继承了 RedisTemplate 有效解决了这个问题,但只能存放<String,String>
- 综上,我们在使用Redis缓存技术时,可以自己自定义(封装一个)RedisTemplate
- 自定义 RedisTemplate<String, Object> (config/RedisTemplateConfig)
| 1 |  | 
| 1 |  | 
| 1 |  | 
分布式锁
- 问题来了,在实际工作中,我们面对的往往是集群服务器,难道在某一刻每台服务器都要执行预热缓存用户吗?
- 显然不需要。我们只需要一台服务器成功缓存到用户就行了。
- 要控制定时任务在同一时间只有 1 个服务器能执行。(怎么做?)
- 分离定时任务程序和主程序,只在 1 个服务器运行定时任务。成本太大 
- 写死配置,每个服务器都执行定时任务,但是只有 ip 符合配置的服务器才真实执行业务逻辑,其他的直接返回。成本最低;但是我们的 IP 可能是不固定的,把 IP 写的太死了 
- 动态配置,配置是可以轻松的、很方便地更新的(代码无需重启),但是只有 ip 符合配置的服务器才真实执行业务逻辑。问题:服务器多了、IP 不可控还是很麻烦,还是要人工修改 
- 数据库
- Redis
- 配置中心(Nacos、Apollo、Spring Cloud Config)
 
- 分布式锁,只有抢到锁的服务器才能执行业务逻辑。坏处:增加成本;好处:不用手动配置,多少个服务器都一样。 
- 单机就会存在单点故障。
- 多的概念在这里不再赘述,可以去看鱼皮的项目笔记,分布式锁实现原理以及注意事项讲的很清楚
Redisson 实现分布式锁
- Redisson 是一个 java 操作 Redis 的客户端
- 提供了大量的分布式数据集来简化对 Redis 的操作和使用,可以让开发者像使用本地集合一样使用 Redis,完全感知不到 Redis 的存在。
- 那我们就使用redission来快速实现分布式锁控制吧
- 导入相关依赖
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
组队功能
后端开发
| 1 |  | 
| 1 |  | 
新增队伍
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
阶段性问题
- 使用 Swagger 接口文档快速测试,这里访问文档还报错了,在启动类上加了 @EnableSwagger2WebMvc 就解决了
- 奶奶的想启动个前端登陆一下还他妈报错启动失败,看了一下是我的node没了(鬼删的?)导致npm环境变量没配好
- 看了眼环境变量,真几把乱,我就纳闷了我记得很整洁来着,很快就搞好了
- 重新捋了一遍通用返回对象,新增了新的异常对象(ErrorCode errorCode,String description)- 实现思路可以看下通用返回对象.Xmind,具体代码还请跳转至用户中心-开发文档,内容已同步更新
- 改了下npm环境变量还手贱删除了nodejs,俺的个人博客都被搞垮啦,之后会总结个人博客部署流程的
- team表添加了join_num字段,存储当前队伍已加人数,记得同步修改更新xml、mapper、domain
查询队伍
| 1 |  | 
- 逻辑还是很简单的,前端传param参数,后端接口封装一个队伍查询信息类,再依次对每个字段校验,最后分页查询实现
- 这里还遇到一个问题,我写成这样:QueryWrapper- tqw = new QueryWrapper<>(team) 它的SQL查询语句就默认自带了 where name = ? 导致 twq.like(“name”, name) 失效了,搞了半天才发现 
- controller层
| 1 |  | 
修改队伍
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
阶段性问题
- 注意到我们查询队伍接收param参数,新增队伍和修改队伍接收JSON参数,记得封装的参数类要实现每个成员属性的get、set方法
- 体会到封装参数接受类request的好处,还是那句话,前后端联调更加方便 –> BeanUtils的用法
- 优化了相关业务的代码,更加简洁易懂了
- 这里应该捋一捋我对相关业务流程的理解的,放到明天啦~
业务流程梳理
| 1 |  | 
| 1 |  | 
| 1 |  | 
用户加入队伍
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
用户退出队伍
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
思考
队长解散队伍
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
获取当前队伍信息
service层
| 1 |  | 
controller层
| 1 |  | 
前端开发
展示用户已创建队伍
展示用户已加入队伍
| 1 |  | 
| 1 |  | 
| 1 |  | 
阶段性问题
- 首先这一段逻辑很简单:登录用户的id做参数,拿到其已加入的队伍
- 一如既往地使用 Card 商品组件
- 我写这一段还是挺轻松的,虽然不熟练,写的慢,但是很轻松快乐哈
- 需要注意的点有这些:
- van-card 的属性使用方法:<template #buttom> 等
- 对了,像咱们这种表单页,还得微调内边距啥的,自己看着用最简单的HTML+CSS做就可以凑合实现
- 奶奶的,打算趁热打铁开发修改队伍页面的,发现这个表单写起来还挺生疏,就先开发新增队伍页面吧
新增队伍
| 1 |  | 
| 1 |  | 
- 他奶奶的,这个页面还真不好搞定呢,踩了无数坑,前后拖了3天可算完成了,我简单总结一番:
- 首先就是把那form表单合适的、好用的拿过来,先别管那些数据交互
- 然后创建一个对象,成员属性跟表单作数据绑定
- 对这些表单的属性都必须有所了解,每个属性是干嘛的都得心知肚明
- 简单的比如label、placeholder、type,计步器的max、min,日期的展示逻辑:showPicker = true
- 日历的@confirm、@cancel实现逻辑,这些自个儿多写多练就能记住了
- 别的不多说了,再说几个注意点
阶段性问题
- 这里的对象要声明为响应式的,即:const teamAdd = ref({ …initTeam });,不然作数据绑定的时候会有问题
- 提交按钮不用写@click=”onSubmit”了,表单上写过了,否则会连续执行两次提交
- POST请求这里参数我写错了,teamAdd.value写成teadAdd了,请求里的json数据一直请求不到接口
- 前端传回的empireTime是yyyy/MM/dd格式的,传到后端还接收不了了,奶奶的测试的时候好端端的
- 解决方法:修改后端empireTime字段的Date格式就可以:(暂时先这样解决)
| 1 |  | 
修改队伍
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
阶段性问题
- 这里解决了之前提到的问题:用户加入和创建队伍还显示不正常,这不是浏览器问题
- 这是因为我删除了队伍team,却没有删除user_team对应记录,查询teamList时查到的队伍出现null值,前端渲染就出现了错误
- 还有teamUpdatePage.vue显示不正常,修改了下文件名为teamEditPage.vue就可以显示了,这浏览器真几把无语
- 整理了下数据库,删除了一些脏数据;整理了下队伍页面,都放进pages/team下了,修改包注意同步修改路由和对其他页面引用
思考
- 这里又明确了下前端axios请求接收到的的响应值response:首先axios封装了response,我们从后台传回的数据都封装在response.data下,这一点毋庸置疑。全局响应拦截器帮我们做了这一点,所以我们使用myAxios发送请求,响应值就是被封装好的response.data了,即后端封装的BaseResponse对象(code、data、message、description),理清这一点后,之后处理响应值的思路就很清晰了
退出队伍
| 1 |  | 
| 1 |  | 
阶段性问题
优化后端逻辑
| 1 |  | 
| 1 |  | 
优化前端逻辑
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
阶段性问题
- 解散队伍逻辑实现不了
- 就是前面提到的问题,队伍页面展示时team.status被硬修改了(0-“公开”,1-“私密”,2-“加密”),而在解散队伍的逻辑当中,需要获取队伍的status,导致请求参数错误。解决办法就是不要直接修改team的status,另找个变量。
- 现在这个问题解决了,改动挺多,听我娓娓道来~
- 这里另找个变量status不好实现,得遍历到所有team,得到的每个team对象中新增变量保存status修改后的状态。(设想这样是挺复杂的,可以实现,但感觉完全没必要)
- 另一个思路很直接,不变team.status,表单在作展示时可以调用一个函数,按(0-“公开”,1-“私密”,2-“加密”)转换显示
- 那我们就在service/function\getStatus.ts下实现一个函数,负责转换status
| 1 |  | 
| 1 |  | 
| 1 |  | 
解散队伍
| 1 |  | 
| 1 |  | 
阶段性问题
| 1 |  | 
| 1 |  | 
- 还要注意这两个操作的后端逻辑校验,那就是:
- 退出队伍时,如果只剩最后一人,要解散队伍和队长直接解散队伍,一定要同时清楚team和user_team中的记录,这样不仅影响业务逻辑,还会在脏数据多的时候,前端队伍显示不正常,这问题你找都找不到
- 哎我真几把服了,还以为teamList1和teamList2没用了,把赋值语句删了。搞得队伍表单连数据都没有,怪不得突然就不显示队伍了
| 1 |  | 
思考
| 1 |  | 
| 1 |  | 
- 数据基本恢复完成!之前的同步工作做的不够好,建个表不是少tags就是缺profile,小问题
- 顺便优化了join_num字段,默认为1,新增队伍时已加人数就默认置为1了
- 当然了,有了数据才解决了上面的解散队伍的问题
- 浅浅记录一下效果吧:


浅浅记录
- 想起来了,上次推送blog老是更新不成功,不知道这机子吃错药了还是,现在就没问题了
- 好几天没有更新内容了,这几天都去做毛概PPT和性交视频剪辑了,基本没精力完善这个(2023/05/18早)
- 今天就完成搜索队伍功能吧
搜索队伍
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 

阶段性问题
- 开发搜索表单页面,就做好两点:搜索条件和搜索结果,把对应数据跟表单绑定好就成
- 注意到后端处理请求的业务逻辑需要变动,之前写的不好,要求为:有值且值正确,就去查询数据库
- 拿到响应数据后,注意分页查询返回的队伍列表是封装在data下的records中的
- 还有一个蛋疼的问题,就是浏览器不自动刷新了,只能重启前端服务才有效果,最后发现是TeamListPage.vue的路由里把Team小写了,服务启动没问题,但修改就有问题了,无语了
思考
随机匹配
- 开始搞随机匹配咯
- 编辑距离算法详解: https://blog.csdn.net/DBC_121/article/details/104198838
用户匹配
| 1 |  | 
| 1 |  | 
匹配用户接口
| 1 |  | 
| 1 |  | 
阶段性问题
- 这里的SortedMap是用来存储用户和匹配度的,且默认按key值升序排序,不允许重复key值,实现起来有点问题,改天看完鱼皮再试一试,先记着 (2023/05/20晚)
- 实现随机匹配的逻辑, 我们要优化两个点: 执行时长为多少? 是否能正确匹配? 
- 首先优化执行时长, 有以下几点可以优化: 
| 1 |  | 
- 然后就是优化能否正确匹配了, 很显然, 昨晚的那个SortedMap并不能完成这个功能, 我就说嘛 
- SortedMap默认按key值升序排列, 把distance做value是不行的, 把distance做key值也不行, 因为SortedMap不允许重复key, 那样的话相同distance就被顶替了. 
- 比较可行的方法是把用户和相应相似度存放进List中, 再按distance升序排序, 最后查出前num条 
- 代码实现的话就明天写吧 (2023/05/21晚) 
- 他妈的连抄带粘写完了, 先不详细解释了, 必做的优化点做到位了, 剩下的逻辑看着真恶心, 放下边慢慢体会吧: 
| 1 |  | 
匹配用户页面
- 之前写过的分页查询所有用户就先保留了
| 1 |  | 
搭建图床
- 搭建过程就不多说了 收藏了好几个CSDN博客教程
- 最重要的是在PicGo里下一个插件 搭建一个Gitee图床 (不用GitHub图床是因为这玩意儿BUG太多了 尤其是网络原因)
- 两个图床的配置都放下面了 我用了Gitee图床








- 操他妈的上个厕所就能显示了
- 总之 图床可以正常使用了 现在把浏览器收藏夹整理一下先 (2023/05/23晚)
- 今天距伙伴匹配系统从零开发 整整俩个月了 简单纪念一下 但是今天不想编码了 干点儿别的吧 (2023/05/24晚)
持续优化
随机匹配优化1.0
| 1 |  | 
| 1 |  | 
页面标题优化
| 1 |  | 
| 1 |  | 


用户标签优化
| 1 |  | 
| 1 |  | 
阶段性问题
- 这里把getTeamStatus.ts也优化了下,结果给网页整空白了,卡了半天发现TeamListPage和TeamPage都调用了这个方法而前者我忘记改过来了,要注意一下
- 第一遍做的时候取了user的status,才反应过来user的是gender,又全改了一遍
- 然后发现数据库中的gender是varchar型,而status是int型,真几把服,谁设计的表,害我前端数据类型不对应,逻辑判断都有问题
- 今天就干到这吧(2023/05/26晚)
加入队伍
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
搜索队伍优化
| 1 |  | 
| 1 |  | 
退出队伍优化
| 1 |  | 
搜索队伍优化2.0
| 1 |  | 
| 1 |  | 
| 1 |  | 
- 当然,我们可以再次使用onSearchTeam来根据搜索表单筛选队伍,分两种情况:
- 公开页激活(active.value === 0)和加密页激活(active.value === 1)
- 根据页面激活情况发送相应请求即可,并将结果绑定到对应表单上
| 1 |  | 
 s
s

| 1 |  | 
- 我们之前是这样实现的,本意是想筛选出>=maxNum的队伍,但MP的每个QueryWrapper后紧跟条件时,会自动使用and来拼接(懂吧,就是SQL中的where语句下的and拼接条件)。当最大人数筛选条件正确填写时,执行情况为:把.or()前的所有条件和.or()后的.eq(“max_num”, maxNum)条件用or连接去查询,结果显然不对,查到了多于预期的数据。
- 那为了实现查询>=maxNum的队伍,我们舍弃了.eq,把maxNum + 1就行了,逻辑上没有问题了
| 1 |  | 
搜索队伍优化3.0
| 1 |  | 
加入队伍优化
- 他妈的好多东西,明天再做吧嘿嘿嘿
- 实现申请加入加密队伍时,需要填写密码
- 这个功能基本实现了,但发现目前后端仅校验password的格式,并没有校验其正确与否,待明日优化完毕这个逻辑后再作记录吧(2023/05/31晚)
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 

分页查询队伍优化
主页优化
| 1 |  | 
阶段性问题
- 前两天给GiHub仓库上推送用户中心和伙伴匹配时,由于近期没有按时推送项目到Gitee上,操作的时候不小心把Gitee上的旧代码拉到本地了。最要命的是,还他妈把本地项目给覆盖了,还好一查发现GitHub仓库里的代码是最新的了,差点以为这几天白干了
- 以后更新项目要及时推送到Gitee和GitHub上(2023/06/08)
定时查询任务优化
- 给重点用户推荐用户:每天00:00定时缓存预热,并保存24小时(好像没啥卵用,给匹配相似用户加这个功能还不错)
- 这个定时查询使用了redisson实现分布式锁,完成了多台服务器中只能有一台抢锁成功并缓存预热的功能,目前这个定时任务只是预热了重点用户的查询用户,用处不大,仅学习定时任务和分布式锁,将来优化(2023/06/08)
随机匹配优化2.0
| 1 |  | 
TODO优化
| 1 |  | 
搜索队伍优化4.0
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 


| 1 |  | 
| 1 |  | 
| 1 |  | 
个人信息页优化
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
退出登录
| 1 |  | 
| 1 |  | 
| 1 |  | 

验证码登录
前端开发
| 1 |  | 
| 1 |  | 
| 1 |  | 
阶段性问题
后端开发
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 
| 1 |  | 

注册功能
前端开发
| 1 |  | 
| 1 |  | 
| 1 |  | 
后端开发
| 1 |  | 
| 1 |  | 

阶段性问题
| 1 |  | 
思考
- 浅浅记录一下,由于英语四六级和临近期末,伙伴匹配系统暂时开发。
- 但基础功能已经完备,这几天也正在了解云服务器领域的知识,为将来的项目的顺利部署打点基础,也要准备接下来项目的学习:API接口开放平台、微服务搜索、BI智能平台(2023/06/26午)
- 今天是个大喜的日子,Memory-伙伴匹配成功部署上线:http://120.55.62.195:7071/#/(2023/07/29晚)
轮播图
- 这功能简直不要太简单,加个组件,放两张图片不就搞定了
- 一个多月前,就已经有这个想法了,不过我想放几张我喜欢的图片,但存储在Gitee图床的图片好像有跨域处理,外界访问不到
- 于是这个想法就被搁置了
- 不过我开通了七牛云对象存储服务,当我的免费图床hhh
- 以下是轮播图的具体代码:(2023/07/31早)
| 1 |  | 
| 1 |  | 


搜索用户优化
TODO
- 新老值一样,无需修改(减少查询数据库)
- 根据队长id查询队伍——>根据队长姓名?(这个也可以不改的,可以把用户星球编号设置为队员id编号)
- 校验老三样:校验登录、校验用户(存在?权限?封号?)、校验队伍(存在?状态?)(√)
- 退出队伍,校验该用户是否为该队伍成员
- 解散加密队伍必须输入密码
- 获取当前用户创建的队伍(√)
- 获取当前用户加入的队伍(√)
- 分页查询用户信息的脱敏
- 分页查询队伍信息的脱敏
- 代码封装性不好,好多重复代码
- 代码思路很清晰,但有些许不整洁
- user_team表join_time冗余字段 (收回这个问题,create_time与业务无关,不能替代join_time)
- createTime、expireTime、updateTime传到前端显示不正常(√)
- 前端的pages、models等目录杂乱了,需要分包管理
- 前端关于页面跳转的问题,router.push()、router.replace()的使用
- axios请求的返回值:response、response.data(√)
- 修改队伍还要扩展支持修改最大人数
- 获取队伍信息team/one我直接返回team了,没有脱敏,其实密码加密就行
- 根据标签搜索用户、根据队伍名、队伍描述等搜索队伍需要优化(√)
- 前端页面的标题 对应每个页面都应该显示对应的标题(√)
- 登录后页面跳转到原先页
- 搜索队伍分为公开和加密两栏,私有队伍不对外显示(√)
- 加入队伍功能,加入加密队伍需要输入密码(√)
- 分布式锁防止单用户加入两次队伍
- 项目打包上线
- 拿到加入队伍的所有队员的信息
- 前台的提示信息不够完善,比如登录时的用户名、密码校验提示,电话号码、验证码校验提示,新增、删除、加入队伍提示等等
- 支持用户上传头像
Memory 伙伴匹配系统-开发文档
      https://test.atomgit.net/memory_blog/2023/03/24/Memory 伙伴匹配系统-开发文档/