Spring Boot项目：一个为了找到志同道合的移动端网站（App风格）---伙伴推荐站

项目总结：

伙伴匹配项目实现了用户登录、按标签搜索用户、组队功能。该项目的核心在于使用编辑距离算法来匹配推荐用户和使用redis存储session。再插入数据时，我使用了自定义线程池分批插入数据，并结合AOP技术用于时间统计，使得再插入数据时时间以2min优化到2s.在优化主页数据时，我使用了缓存预加热，将mysql数据读取到redis用于缓存，解决第一个用户读取数据很慢的情况，对这个缓存预加热又使用到了定时任务，避免了手动将数据读取到redis中进行缓存预加热情况。但这个定时任务在本地设置的，只会执行一次，又考虑到分布式情况下会有多个服务器进行定时任务，从而会出现冲突，造成数据不一致问题，于是引入redisson分布式锁来解决冲突问题。

项目运行界面展示：

项目流程

需求分析 => 设计（概要设计、详细设计）=> 技术选型 => 初始化 / 引入需要的技术 => 写 Demo => 写代码（实现业务逻辑） => 测试（单元测试、系统测试）=> 代码提交 / 代码评审 => 部署 => 发布上线

项目简介：

一个为了找到志同道合的移动端网站（App风格），包括用户登录、更新个人信息、按标签搜索用户、推荐相似用户、创建队伍、加入队伍的组队等功能

该项目基本覆盖了常见的需求以及对应的解决方案，如登录注册、批量数据导入、信息检索展示、定时任务等并且涵盖了分布式、并发编程、锁、事务、缓存、性能优化、数据一致性、等相关知识

需求分析：

技术选型（后端）：

Spring Boot+Mysql数据库+MyBatis-Plus+Redis缓存+Redisson分布式锁+Easy Excel数据导入+Spring Scheduler定时任务+Swagger+Knife4j接口文档+Gson:JSON序列化库+相似度匹配算法

数据库表设计

建表

方式一：创建一张包含标签tag字段的用户表，为了存储多个标签使用json存储标签数据

优点：进行查询tag字段很方便

缺点：进行增删改时，需要先将tag字段查询出来，进行tag字段修改，然后把处理完后的字段在写回数据库将原先的tag字段存储的数据进行覆盖

方式二：用户表user 新建tags表和user_tags关联表

优点：进行增删改时，只需要在tag表中进行相关数据的增删改，无需将所有tag标签查询返回并修改后写回数据库覆盖原有数据操作

缺点：在进行查询操作时，会使用到关联表操作，同时多建一张表就需要护一张表

方式选择：

如果标签数量较少，需要将整个标签全部查询出来，选择第一种方式只需要查询一张表就会实现要求，操作方便

如果需要查出某个标签的所有用户，并且需要对标签进行增删改操作，考虑第二种方式。当然标签数据量较大时，选取第二种方式

提示：企业中大项目开发中尽量减少关联查询，很影响扩展性，而且会影响查询性能

综合上述考量，本项目对标签字段建表选择使用第一种方式建表。对组队功能使用的是第二种方式。项目中使用到的表有三个，分别为队伍表（team），用户表(user)，用户与队伍的关联表(user_team)

向库表导入数据：本项目使用的是使用自定义线程池批量导入数据

1. EasyExcel

   两种读取模式：

2. 自定义线程池批量导入数据

   什么是线程池：

   线程池是一种管理和重用线程资源的机制，是利用池化思想设置和管理多线程的工具。线程池维护一定数量的空闲线程，当有任务需要时，就从中选择一个空闲的线程用来执行任务，当使用完成后该线程就会被重新放回线程池中，通过这样循环使用的方式来节省创建线程和销毁线程的各项资源开销。

   线程池核心参数

1. 参数说明：

   1. 核心线程数（Core Pool Size）：想象一座小型工厂，这里有一批核心员工，无论如何都不会被裁员。这些员工代表着核心线程数，始终在工作。

   2. 最大线程数（Maximum Pool Size）：除了核心员工外，工厂还雇佣了一些临时工。最大线程数就像是工厂愿意雇佣的最大员工总数，包括核心员工和临时工。

   3. 存活时间（Keep Alive Time）：假