面试打底稿⑤ 项目一的第一部分

最新推荐文章于 2024-11-01 18:24:51 发布

zrc007007

最新推荐文章于 2024-11-01 18:24:51 发布

阅读量491

点赞数

文章标签：面试职场和发展 java redis spring spring boot 交通物流

本文链接：https://blog.csdn.net/m0_46948660/article/details/133344341

版权

简历原文

抽查部分

项目描述

该项目旨在服务广州地区的快递物流，实现了下单、快递员取派件、订单转运单、线路规划、网点设置等功能。

责任描述

登录系统优化，双token三验证模式实现设置token状态、提高登录安全性的效果

模拟问答

1.能简单介绍一下你这个的项目吗

模板一

好的。我这个项目叫“加驰物流”，服务了广州地区的快递物流。

这个项目分几个功能模块：前端由用户端、快递员端、司机端和后台管理系统四个不同部件组成。然后由统一网关拦截。后端由业务平台和第三方支撑平台组成，业务包括路线规划、运单任务管理和智能调度，以及其他的微服务比如快递员微服务、司机微服务等。这些都连接到了MySQL、MongoDB等组成的数据平台上。第三方支撑平台用到了公司自研的权限系统、地图服务，还使用到了阿里云、RabbitMQ、Seata、xxl-job任务调度等。

这个项目使用了以下技术栈：jdk1.8、MySQL8.0、Spring Boot2.6.6、Nacos1.4.2、SpringCloud Gateway3.1.1、Redis7.0.4、 MyBatis-Plus、knife4j、MongoDB、ElasticSearch、RabbitMQ、xxl-job、Jenkins、seata、Hutool

项目的特色亮点在于，设计优化了物流信息模块，实现了数据精简、流量削峰、提高系统可用性。

在做出亮点的时候，碰到了很多难点，有以下4个：

1.数据量大的问题。我们用MongoDB的单条数据可以多字段存储，替换了MySQL，实现了数据精简；

2.高并发问题。我们用Caffeine和Redis做了多级缓存，解决了这个问题。

3.缓存击穿问题。我们引入了布隆过滤器来解决这个问题。

4.布隆过滤器准确性、效率问题。我们在过滤器内加适当的算法数量，解决了这个矛盾。

这个项目给我的收获就是，更深入的体会到了技术的实际能力。不同的数据库技术，能满足不同的需求，MySQL适合常规化数据存储，MongoDB适合一些特殊情景的使用；多级缓存对高并发问题的较成功的解决；缓存击穿情景下，布隆过滤器的选用与调试。这些实际的技术应用场景，说实话，让我着迷，也让我感觉有源源不断的改变世界的力量。

我可以说说项目难点业务的处理逻辑。物流信息模块中，首先是更新或添加运单详情的逻辑：根据运单id查询运单是否存在，若不存在则创建，若存在则追加。然后设置更新时间，加入MongoDB。

然后引入多级缓存是查询的逻辑，首先查询Caffeine里面有没有数据，如果没有则查询Redis，最后才查询数据库。更新数据，即创建或追加运单详情时，让所有一级缓存节点都订阅二级节点，及时更新。

最后为了解决缓存的三种问题作了如下操作：

解决缓存击穿，我们设置互斥锁；

解决缓存雪崩，我们设置随机过期时间、采用多级缓存、搭建高可用集群；

解决缓存穿透，我们采用布隆过滤器。

模板二

好的。我在项目中是后端开发，负责物流信息模块的性能优化。

这个物流信息模块是后端的业务，后端业务包括路线规划、智能调度、运单任务分配等模块，我负责的物流信息模块也是其中之一。

它要做的就是查询运单信息，然后在用户访问的时候交给前端显示快递到了哪里。

公共部分就是查询显示订单的模块。

我负责的就是修改MySQL存储方式为MongoDB方式，以及采用布隆过滤器解决缓存穿透的问题。

我的技术方案成功精简了数据，达到了流量削峰、提高系统可用性的效果。

好在后期没出什么bug。

（推荐使用模板二。）

2.能说一下你这个登录系统做了什么吗

可以。我登录用了微信登录，流程如下：

首先微信小程序发送登录请求，携带了appid、appsecret还有code，后端接收到后向微信接口传递这些参数进行校验，得到用户的信息openid等。然后若用户、用户手机号存在则直接根据这些信息生成token，不存在则查询到手机号、创建用户信息再生成token，最后返回给前端保存。之后前端就用token访问登录后能访问的资源。

在这个流程中，关于token可能存在两方面的问题：

其一是有效期的长短问题，有效期过短，登录频繁，不方便用户；有效期过长，被黑客截取后系统就不安全。

其二是一个token没办法手动让其失效，这样检测到异常状态后还是能使用，就不合理。

为了解决这两个问题，我们的方案是采用双token三验证的模式来替代单token模式。

双token，意思是设置一个长期token，例如一天的，和一个短期token，例如5分钟的。

面对第一个问题，如果5分钟后短token失效了，只要长token还在有效期，就可以拿长token去重新获取短token，就又可以保持登录状态了；

面对第二个问题，只要我们把长token设置成只能使用一次，例如存入Redis，检测到异常状态后，直接移除Redis中的token信息，这样就能达成设置状态的效果了。