刷到此贴的友友春招/暑期必上岸！！！鼠鼠在秋招的过程中多次被问到场景题，中大厂的考察频率相当之高，一般会放在最后一个问题用来拖时间，也遇到过上来就问你怎么设计一个系统（面试官以此来决定后面对你的态度）。所以鼠鼠准备开这个场景题栏目，分享在秋招过程中遇到的场景题以及如何进行回答，感兴趣和感觉有帮助的友友点个关注和赞吧，你们的点赞和关注是鼠鼠持续更新下去的最大动力！！！话不多说开启今天的主题，扫码登录吧！！！关于扫码登录是现在PC端登录的常见方式，鼠鼠在面试美团，腾讯等公司的时候都遇到过这个问题，当时面试回答的属于是七零八落了，不过鼠鼠有及时复盘的习惯，所以针对场景题，逐渐有了一套自己的方法论，应对不同的面试官可能提出的不同问题。对于场景题，鼠鼠觉得拿到一道题，首先要思考的是业务逻辑，然后就是在这个业务上会有多大的qps请求量，面试官经常会对你设计的方案和系统提出高并发/大流量的情况下会出现什么问题，你如何去解决，从而考察你设计系统的高可用性和系统性。那么对于扫码登录，其请求量其实并不算大，所以我们侧重于业务流程。大家都有过扫码登录的经历：PC端显示二维码，手机扫描后弹出确认登录页面，点击登录后PC端页面进行跳转。那么扫码的过程其实主要就涉及到手机端、PC 端、服务端这三部分。一、账号登录验证扫码登录相比于传统的输入用户号密码登录，其实本质都是账号认证的过程，相信大家入门的第一个项目里一定会有登录这个功能。输入用户名和密码进行提交。服务端接收到用户名和密码，进行用户名和密码的匹配。如果匹配成功，则登录成功。这里在Java里常用的是使用cookie或session，不过大家做的项目里可能使用使用jwt多一点（对没错，就是外卖和点评），也就是借助token来解决session的一些弊端（这里八股提问，cookie和session还有jwt的区别和应用场景分别是什么），我们这里统一使用token的概念进行解释，服务端在登录完成后会生成一个 TOKEN，与当前登录的用户进行绑定。这个 TOKEN 可以存储在 REDIS 内，并设置在 REDIS 内的过期时间，这也是 TOKEN 的过期时间。最后将 TOKEN 返回给客户端。以上就是整个登录认证的过程。后续接口的请求都要带着这个 TOKEN。服务端会验证 TOKEN 的有效性，如果验证通过，则继续进行服务端内的接口的调用。如果验证不通过，则返回认证失败，或者说 TOKEN 过期了，客户端就会跳转到登录页，重新进行登录。二、扫码登录流程现在换成了扫码登录，换汤不换药，还是需要让 PC 端获取到认证的 ID。 2.1 二维码解释：扫码登录在PC端生成的二维码，里面不光可以存储数字，还可以存储任何的字符，以二维码的形式展示出来。手机扫码的过程，就是解码的过程。划重点！！理解了手机扫码是解码的过程，那这道题就理解了一大半了 PC 端显示的二维码，其实就是PC端向服务端发起请求后，服务端返回的内容。那这个返回内容是什么呢？可以看做是一个唯一请求ID，能够唯一地代表当前的请求，同时这个唯一的ID 是有状态的，表示这个当前二维码是未扫描还是扫描成功，PC端根据服务端返回的唯一请求ID生成一个二维码。同时这个唯一请求ID是有过期时间的。这个二维码过了一段时间，我们不扫描，网页会显示已失效，请刷新。在设计上呢可以将唯一请求ID，作为 KEY 存储到 REDIS 内并设置一个失效时间。综上，这个唯一请求ID最后有三个状态，一个是未扫描，扫描成功还有已失效。已失效就提示它再次进行刷新。 2.2 扫码登录接下来到了扫码登录环节。 2.2.1 手机扫码要进行手机扫码，前提条件是手机的 APP 必须是登录状态的，这个非常重要，也就是手机端已经进行了用户名和密码的登录认证过程。手机端一定会存储登录认证后的 TOKEN。手机扫码识别 PC 端的二维码后会解析出二维码携带的唯一请求ID。也就是PC端向服务端发起请求后，服务端返回的唯一请求ID，手机会显示确认登录的按钮，按下按钮，手机端会将唯一请求ID 和手机认证的 TOKEN 一同发送到服务端进行认证。 2.2.2 服务端验证最后到了服务端。服务端首先会验证手机端的 TOKEN 是否有效，如果有效会验证唯一请求 ID 的状态，如果唯一请求ID 不存在了说明就已经失效了，Redis过期删除（八股提问，Rediskey过期后一定会马上删除吗）。如果唯一请求 ID 存在且当前状态是未扫码的，也就是说 REDIS 存在唯一请求 ID的KEY。此时就会生成一个 PC 端的 TOKEN，与唯一请求 ID进行关联，设置 REDIS 的唯一请求 ID对应的 VALUE 为 PC端登录的 TOKEN。此时 PC 的唯一登录 ID 就产生了，其他情况都是验证失败。到这里我们简单总结一下：PC端发起登录请求，服务端返回唯一请求ID，PC端根据请求ID生成二维码，处于登录态的手机已获得手机端的登录token，扫码解析出唯一请求ID后，将唯一请求ID和token一同发给服务端，服务端验证唯一请求ID和token后，生成PC端的登录唯一ID 2.2.3 PC 端获得TOKEN PC 端在生成完这个二维码之后会启动一个异步请求，向服务端去查询唯一 ID 的状态。 1）如果是未扫描，REDIS 内存在唯一请求ID的 KEY，而且 VALUE 是空的，说明这个二维码是有效的。 2）如果服务端的 REDIS 内已经没有唯一请求ID的 KEY 了，那说明就已经失效，提示二维码已经失效。 3）如果 REDIS 内有唯一请求ID且有对应的 VALUE，则返回扫描成功和关联的 TOKEN，同时 PC 端就会显示登录成功。补充：PC 端通过什么方式来查询唯一请求 ID 的状态？ 1）轮询，PC 通过轮询的方式一次次的向服务端发送请求查询二维码的状态。 2）长轮询，长轮询是指客户端主动给服务端发送二维码状态的查询请求。服务端接收到请求之后会按照情况进行阻塞直至二维码的信息状态更新或者超时。当客户端接收到返回的结果后，若二维码仍未扫描则会继续发送查询的请求，直至状态变化。 3）WEB SOCKET ，WEB SOCKET 是指前端或者客户端在生成二维码后会与后端建立连接。一旦后端发现二维码状态发生变化，可以直接通过建立主动推送二维码的状态给前端。（这里其实很容易考到八股文三者的区别，如果友友们对这一块八股不清楚可以不讲出来，当然可能也有小伙伴在项目里用到了web socket，那么这里就可以和项目做一个关联，把面试官往项目上去引，因为场景设计题我们是很难在短时间内想得很完善的，但是我们的项目是千锤百炼过的）总结：以轮询的方式来获取二维码的状态为例。 1）PC 端展示登录页面，会请求服务端获取唯一请求 ID，然后服务端会生成相应的唯一请求ID，并设置唯一请求 ID 的过期时间和状态，返回唯一请求 ID 给 PC 端。 2）PC 端获取到唯一请求 ID 后生成相应的二维码，PC 端通过轮询的方式请求服务端通过唯一请求 ID 获取二维码的状态。 3）手机端扫描二维码获取唯一请求 ID，将手机端的 TOKEN 和唯一请求 ID 发送给服务端确认登录。 4）服务端验证手机端 TOKEN。然后根据手机端 TOKEN 和唯一请求 ID 生成 PC 端的 TOKEN。此时 PC 端通过轮循的方式请求服务端，就会获得到这个唯一请求 ID 对应的二维码的状态。如果是成功了，服务端就会返回 PC 端的 TOKEN，显示登录成功。 PS：总结部分可以当做这个场景题的精简回答，上面的部分是帮助友友们理解，毕竟八股文如果死记硬背不理解的话稍微变化一下就不会了。其实在整个分析过程中大家可以发现，场景题其实就会把我们背的那些八股和技术运用起来，所以在学习场景题的时候就可以把八股文进行问题，有点像单词背不住就去读阅读文章，在读文章的时候记住八股文，在上面的分析过程中我也有几处进行了随机的八股提问。扫码登录这个过程里Redis用的很多，那友友们是不是可以顺带复习一下Redis的相关八股呢？（1）缓存三剑客是什么？有什么处理方式？（2）Redis缓存删除和内存淘汰策略（3）Redis持久化策略？AOF重写是什么？ …… 以上都是鼠鼠在面试中只要遇到Redis就一定会被问到的，不一定是全部问到，但至少都是三选一了… 好了如果大家有什么问题的话欢迎来评论区交流。包括但不限于文章创作改正意见，后续分享内容（面经，知识输出，经验分享等等），都看到这了，点个免费的关注和赞不过分吧

#大家都开始春招面试了吗##我发现了面试通关密码##暑期实习 ##春招##场景题##八股#

创作者周榜