业务-第四天

你们项目是如何是XXL-JOB的

XXL-JOB是一个轻量级分布式任务调度平台，主要功能和特点如下：

• 任务调度：安排任务的执行时间和执行频率，确保任务在规定的时间内完成。
• 任务分发：任务分发到不同的执行器（Executor），实现分布式处理任务，提高效率和可靠性。
• 任务结果存储：将任务执行结果存储在数据库中，随时查看任务执行情况和执行结果。
• 任务失败重试：当任务执行失败时自动重试。配置重试次数和重试间隔来保证任务的成功执行。
• 任务日志查看：查看任务的执行日志，了解任务执行过程中的详细信息和异常处理。
• 执行器管理：方便地添加、删除和修改执行器，实现动态扩展任务处理能力。

一般来说，使用xxl-job的过程大致如下：

• 集成xxl-job：将xxl-job的jar包引入项目中，并进行相应的配置。
• 定义任务：编写需要定时执行的任务代码，并使用xxl-job提供的注解或配置进行标识。
• 注册任务：将定义的任务注册到xxl-job的任务管理中心。
• 启动任务：启动xxl-job的执行器，执行器会定时去任务管理中心拉取任务并执行。

在项目中的点赞功能就用到的了xxl-job来实现定期更新点赞数量到mysql数据中。

说一说你的评论点赞功能是如何完成(reids版本)

在项目中的点赞功能涉及到两个微服务，分别是点赞微服务和学习微服务，同时使用到了redis中的Zset集合作为缓存类型。当然对于点赞数量来说是保证了最终一致。

• 首先当用户进行点赞或取消点赞操作时，会先判断用户的行为。

• 如果是点赞操作，先判断这条评论是否存在点赞记录，如果没有，则会新增点赞记录，会先将用户ID和业务ID缓存到点赞记录的缓存中，不设置score分数，之后根据业务id统计点赞数量缓存到统计的缓存中，数量做为score分数，并返回缓存变更后的数量，否则在这条缓存记录的基础上进行，并返回缓存变更后的数量。

• 如果是取消点赞，则根据业务ID和用户ID从缓存中删除相应的记录。并修改统计缓存中的score分数，返回变更后的数量。

• 如果用户仅仅是查看，直接返回缓存结果即可。

• 最后，通过XXL-JOB定时向MQ投递消息（包括业务ID和点赞数量）到学习微服务，学习微服务将数据同步到数据库中。

这种设计方案考虑了点赞功能的各个方面，包括点赞操作、取消点赞操作、点赞数量的记录和更新，以及消息通知等。通过这样的设计，能够满足高并发环境下的需求，同时也保证了系统的稳定性和一致性。

项目过程有没有难题(业绩)

• 点赞模块前期用的是mysql存储实现，点赞操作波动较大，有可能会在短时间内访问量激增，对数据库造成巨大压力，合理提议之后改用redis实现。
• 对于登录用户信息传递，是基于JWT实现登录的，获取当前登录用户，解析其中的token即可。但每个微服务都可能需要登录用户信息，因此把token解析的动作放到了网关中，然后网关把用户信息放入请求头，传递给下游微服务，再给每个微服务定义了一个HandlerInterceptor，拦截进入微服务的请求微服务从请求头拿出用户信息，存入UserContext(线程局部变量)。通过这种的方式解决了登录用户信息的传递问题。