java面试项目经历说辞（Spring全家桶，mybatis，mybatis-plus，redis，rabbitM.pdf
版权申诉
13 浏览量
2021-12-16
22:03:28
上传
评论
收藏 157KB PDF 举报
以下内容仅为我的某个项目简介说辞，仅供参考以下内容仅为我的某个项目简介说辞，仅供参考
各位面试官下午好：
我叫XX，籍贯是XXXX，于2020年本科毕业，毕业至今一直从事与java开发工程师的相关开发工作，曾在XXXX公司有过一
年多的开发经历。
我熟悉的技术栈有：Spring全家桶，mybatis，mybatis-plus，redis，rabbitMQ，ES，vue等，在之前一年的开发过程中我一
共有着两个项目的开发经验，一个是零食售卖商城，一个是二手手机回购网站，由于我最近几个月主要时间都是开发这个零食
售卖商城，所以我以此项目为中心做一个大致的介绍。
首先，这个零食售卖商城是基于springboot和vue开发的一个B2C类型的商城，主要分为前台的商城系统与后台的管理系统。
前台的主要页面有：登录注册页面，首页，商品详情页面，购物车详情页面，订单结算页面以及最后的订单状态查看页面。
后台的主要模块有：登录注册，用户权限的管理与设置，轮播图、类别、商品、订单详情的管理还有流水的记录等等。
在此项目中我主要负责的是前台的登录，首页的搜索功能，还有支付功能模块的开发。
登录模块中我们主要是有三种登录方式，分别是我们本平台的用户通过用户名和密码登录，手机号验证登录，遵从oAuth协
议第三方平台登录。
对于用户名密码的登录方式，我们采用了验证码与密码的双重认证和jwt生成的双token处理，在双重认证的验证码方面我们
通过Nginx服务器对其采用限流刷新，对于密码我们采用的是springSecurity中的密码加密，主要原理就是对MD5处理后的密码
二次撒盐处理，验证的时候就是将数据库密码取出盐值与用户输入密码MD5加密与一次撒盐处理后的结果进行比对验证，如果
登录成功我们就会对其颁发两个token，对于双token就是access_token和refresh_token，access_token主要作用是保证用户
每一次操作的安全性，而refresh_token就是为了保证access_token的安全性。
对于手机号验证码验证，我们主要通过阿里云短信服务实现，由于大多操作都是阿里云中的授权操作，这里我就不过多阐
述。
对于oAuth的第三方登录方式我们主要是QQ，微信，支付宝这三种，以QQ登录为例大致流程是：用户点击相应的第三方图
标，当我们后端服务器会携带client_id和scope，去调用腾讯的授权服务器，这个时候就会在我们页面出现一个授权页面，接
着用户扫描授权页面中的二维码，或者输入用户名密码的方式同意此登录之后，腾讯的授权服务器将会向我们后端服务器返回
一个code码，然后我们后端服务器通过client_id,code码,client_secret等几个参数获取一个access_token，最后我们就能通
过此token去访问腾讯的资源服务器，获取用户的基本信息从而对相应信息进行处理，这样我们就实现了一个基本的社交登
录。
然后对于首页的搜索功能我们采用的是Elasticsearch，查询主要分为两块内容：
1. 第一个前缀提示，我们做了拼音和中中文的前缀搜索，因为这个功能是项目中用的最多的功能，对速度要求很高，然后
ES针对这种前缀专门提供了一种数据类型叫 completion；首先根据 pinyin和ik分词器提供现有的功能基础上自定了分词器，然
后再定义 mapping，将需要进行前缀提示字段的类型设置为 completion， 分词器使用的是我们自定义的分词器；再通过
logstash 导入现有的数据，然后即可实现前缀提示功能；因为我们词库不完善，所以需要不停的纳入高频词库，我们所采取的
方式，当用户执行搜索的时候，将用户搜索的词库投递 RabbiMQ中，然后消息的消费方，判断目前是否拥有该词，如果没有，
通过使用 redis 的 zset类型增加被搜索到次数；接着在后台管理系统中针对高频词(我们公司定义是100次)进行审核，审核通
过的词就添加数据库中，然后我们借助于阿里的Canla 自定义 starter 同步数据。
2. 搜索功能，首先要定义 mapping，将需要进行搜索的字段的 分词器设置 ik_max_word; 通过 logstash打入全量数据，然后
就是搜索，前端使用高亮展示；对于增量数据我们还是借助于阿里的Canla 自定义 starter 同步数据。
最后我负责的支付模块大致流程是这样的：
当用户点击立即购买或者提交订单的这个时候数据库就会记录一笔订单，同时将此消息存储到rabbitMQ当中并设置的订单超
时时间是一天，当用户一天未支付rabbitMQ就会将次订单号自动转发到死信队列， 然后监控订单状态的系统去对接此死信队
列，判断此订单号是否支付，然后修改对应的支付状态。
当用户点击付款的这个时候，可选择微信支付微信支付或者支付宝支付支付宝支付
以微信支付为例，当用户选中微信支付的时候服务器会调用统一的微信支付接口，而微信支付接口需要与微信服务器建立连
接，其中在建立连接时就需要三个必要的参数，分别是商户账号商户账号AppId，商户编号，商户，商户编号，商户key（秘钥）（秘钥），
通过上述参数来构造PayConfig接口实现类接口实现类，通过此实现类去建立微信的连接，建立连接之后就需要与微信的服务器进行通
信，通过必要的参数来获得，支付链接，通过支付链接来生成二维码，从而实现微信二维码支付，上述提到的必要参数包
括：支付说明、订单号、支付模式、支付金额、交易的类型、支付完成时微信回调方法的接口支付说明、订单号、支付模式、支付金额、交易的类型、支付完成时微信回调方法的接口（需要内网穿透）。
成功调用微信服务器对应接口之后，可得到用户支付的的必要参数，如支付短连接和支付金额，商品信息等等，通过这些
必要参数由前端生成支付界面，然后用户就可自行支付，
当用户扫码并付款后，这个时候会有较为多的消息需要处理
比如(对微信服务器支付后结果的处理、订单状态的修改、支付流水的记录、支付积分的累计、消费劵的领取)，通过上述的
分析我们清晰的意识到如果上述问题用同步的方式处理那将是一个非常耗时的任务，所以当时我们采取了MQ（消息队（消息队
列）列）来处理消息，又基于来处理消息，又基于 rabbitMQ强大的功能性，我们选择了此面向消息的中间件。
此需求的处理显而易见肯定是在高并发的场景之下完成，我们设计了三个系统来保证消息的完整性，有消息的生产系消息的生产系
统统、消息的补偿系统消息的补偿系统、消息消费后后续系统操作消息消费后后续系统操作，
消息的生产系统消息的生产系统：在消息的生产系统包含了crud的大多操作，所以这个时候就需要事务，通过事务的具有的特性来完成以
下步骤：1. 支付相关消息的编写（支付流水的记录，支付状态的修改等等）， 2. 将投递给MQ的消息存储到数据库， 3. 将消
息投递给MQ。完成上述事务之后， 这个时候消息的主要操作就到了rabbitMQ当中，rabbitMQ需要判断消息是否到达了交换机
与队列，如果到达到了最终的队列就将消息消费掉之后进行删除，只要在交换机或者队列的任意一个步骤出错就什么都不做。
消息的补偿系统消息的补偿系统：定时扫描数据库中未被消费的消息，将未被消息的消息进行重复投递。
消息消费的后续系统操作消息消费的后续系统操作：上述两个系统保证了消息的可靠性投递，这最后一个系统就将这些消息来进行业务处理，主要
包含了以下业务：支付流水的记录，消费积分的记录，订单状态的修改，消费劵的领取等等。
上述就是我在此项目中所做的大致流程。
资源评论
