项目

推送项目

提到工作流，就说没有用，通过一个待办消息表存储各节点的信息
介绍的时候没有说业务逻辑

用户发送客户端至前端控制器DispatcherServlet，DispatcherServlet接收到请求，调用handlerMapping处理器映射器；处理器映射器扎到具体的处理器，生成处理对象以及处理器拦截器一并返回给DispatcherServlet；然后调用HandlerAdapter处理器适配器；HandlerAdapter处理器适配器经过适配器调用具体的处理器Controller；controller接收到
【有效期，接收方id，发送方id，模板id，消息，发送类型，时间】参数并进行相应的业务处理。首先对接收的参数进行校验，主要是校验参数是否合法，例如根据模板id是否能找到对应的模板。校验完成后再判断redis中是否存在未完成的发送记录，如果存在则说明此时消息正在发送中，并返回提醒。如果redis没有数据则代表没有正在发送的信息，然后将发送方的id+接收方id+发送类型进行md5加密然后存入到redis中。表示该发送类型正在处理中。避免重复发送。
再根据发送类型进行逻辑处理，这里使用到了策略模式，定义了一个统一的接口，根据发送的类型定义了不同的抽象方法，比如发送邮件，短信等，然后根据不同的第三方服务提供商对接口进行实现，重写发送邮件、短信的方法。还使用到了工厂模式。定义了一个方法来创建具体实现对象。方法的参数列表需要传发送类型，然后工厂方法根据类型创建对应的实现对象。创建完实现对象之后调用对应的方法进行发送消息，这里考虑到调用第三方接口可能会失败的情况，所以对发送方法做了’判断，判断是否发送成功，如果发送失败则调用其他第三方的接口，如果都推送失败则返回一个失败信息。如果发送成功了，将敏感数据例如手机号，邮箱账号进行加密后持久化到数据库中。
controller拿到处理完成的逻辑结果返回ModeAndView；HandlerAdapter处理器适配器将controller执行结果ModeAndView返回给前端控制器；前端控制器将ModeAndView传给试图解析器viewReslove;试图解析器解析后返回具体的view；前端控制器根据view进行渲染试图；

即时通讯

提到了feign
介绍的时候也没有说逻辑

首先根据需求我对即时通讯功能进行了表设计，我一共设计了三张表，分别是会话连接表、会话表、会话记录表。其中会话连接表用来存储用户的连接信息例如：用户id，服务id，状态，会话表保存的是双方的用户id，会话记录表记录的是会话内的沟通信息。
首先我使用map结构定义了一个容器用来保存客户端的连接。服务启动后使用ws协议监听指定端口，等待客户端连接，当客户端发起连接后服务端接收到连接请求，从请求头中获取用户信息，拿到用户信息后判断用户信息是否合法，将用户状态调整为在线。等待客户端发送数据。
当服务端监听到已连接的客户端发送的消息后，首先根据定义的格式进行解析，拿到接收方的用户id。然后再通过查询会话表判断用户双方是否发起过通讯，如果没有则新建，如果有则更新表，然后判断接收方是否在线，如果在线则从会话容器中取出接收方的连接，然后调用发送方法将消息进行实时转发，再将沟通信息保存到会话记录表中。如果接收方不在线则等待接收方登录平台后，将消息进行返回。如果客户端断开连接则将用户状态调整为离线。
该模块支持分布式，
还提供了审计功能，档案局管理员可以查看专家与申报单位的通讯消息。

文件管理

文件管理模块都没有说全

专家事务

业务逻辑也没有说

问到了取消请假状态

定时任务

遇到的问题，只说了一个

银行的项目

具体整理下自己的业务，说几点

spring mvc的处理过程

mariadb 与mysql 的区别

spring有哪些依赖注入的方式

Spring框架提供了多种依赖注入的方式，以下是一些常见的依赖注入方式：

构造函数注入（Constructor Injection）
Setter方法注入（Setter Injection）
字段注入（Field Injection）
接口注入（Interface Injection）
注解注入（Annotation-based Injection）
Java配置注入（Java Config Injection）

查询比较慢的话有没有什么优化的方法

首先定位到导致查询慢的SQL

要定位慢查询，可以采取以下方法：
1.使用数据库性能监控工具：使用数据库性能监控工具，例如MySQL的慢查询日志（slow query log）或其他数据库监控工具，来收集和分析查询执行时间和相关统计信息。这些工具可以帮助您识别慢查询，并提供查询的执行计划、访问路径和执行时间等详细信息。
2.分析查询执行计划：通过查看查询执行计划，可以了解数据库是如何执行查询的，包括使用的索引、连接方式、排序操作等。可以使用数据库的内置工具或查询优化器来生成和分析查询执行计划。
3.执行性能测试：通过模拟和执行慢查询，可以测量查询的执行时间，并捕获查询执行期间的资源使用情况。使用性能测试工具来模拟负载，并监控查询的执行时间和系统资源的利用情况。
4.使用数据库查询分析器：使用数据库查询分析器工具，例如MySQL的EXPLAIN语句或其他数据库的类似工具，来解释查询的执行计划和优化建议。这些工具可以帮助您确定慢查询的瓶颈所在，例如缺少索引、不合理的连接方式等。
5.数据库会话跟踪：在数据库会话级别启用跟踪或审计功能，可以记录数据库会话期间执行的所有查询语句和其执行时间。这可以帮助您识别慢查询并确定其来源。
6.代码审查：检查应用程序代码中的查询语句，并评估其性能和优化潜力。确保查询语句合理，避免不必要的连接、子查询或循环。
7.监控系统资源：监控数据库服务器的系统资源使用情况，包括CPU、内存、磁盘和网络等。慢查询可能是由于系统资源瓶颈导致的，因此监控系统资源可以帮助您确定是否存在资源限制。

慢SQL是指执行时间较长的数据库查询语句，可能导致应用程序性能下降。以下是解决慢SQL的一些常见方法：

1.使用索引：确保查询涉及的列上创建了适当的索引。索引可以加速数据检索，特别是在大型表中。分析查询语句和数据访问模式，并使用合适的索引来覆盖常用的查询条件。
2.优化查询语句：审查查询语句，并尽量简化和优化它们。避免不必要的连接、子查询或排序操作。使用合适的查询语句来减少数据检索的数量。
3.分批处理和分页查询：对于返回大量数据的查询，考虑使用分批处理或分页查询来减少单次查询的数据量。这可以提高查询的响应时间，并减轻数据库负载。
4.数据库配置优化：检查数据库的配置参数，如缓冲区大小、并发连接数等。调整这些参数，以适应应用程序的需求和数据库服务器的硬件配置。
5.数据库索引和统计信息的维护：定期进行数据库索引和统计信息的维护，以保持其最佳性能。重新构建索引、更新统计信息可以改善查询执行计划。
6.查询缓存：对于相同的查询，考虑使用查询缓存来缓存查询结果，避免每次都执行相同的查询。但要注意，查询缓存可能会增加内存消耗，并在数据更新时导致缓存不一致。