场景设计：二维码扫码登录

扫码登陆流程

1 二维码生成

PC端向服务器发送获取二维码的请求。
服务器收到请求后，确保合法性之后，生成一个二维码唯一ID，关联ID的登录状态信息，并且设置过期时间。

服务器返回二维码ID，PC端接收后生成二维码图片展示。
PC端启动轮询，定期查询登录状态。

2 手机扫码认证

手机app扫描二维码，解析二维码中的唯一ID。

app携带自身身份凭证（例如token）和唯一ID向服务器请求。
服务器收到请求后，验证合法性后，将身份信息和二维码ID绑定并生成临时token返回给手机app，同时登录状态修改为已扫描。
手机app收到返回后，弹出确认登陆按钮等待登陆。

PC端轮询到登陆状态状态改变提示已经扫描。

3 登录确认

手机app上点击确认，携带临时token向服务器请求。

服务器收到后，验证合法后，生成PC端token，并和二维码ID绑定，登录状态修改为已确定。

4 信息同步

PC端轮询到状态变为已确认，获取到PC端token。

PC端登录成功，后续使用PC端token和服务器交互，获取到用户基本信息，进入登录成功页面。

问题

如何生成二维码ID，保证生成的ID唯一？

前端状态刷新

轮询方式

很多网站为了实现推送技术，所用的技术都是轮询。轮询是在特定的的时间间隔（如每1秒），由客户端浏览器对服务器发出HTTP请求，然后由服务器返回最新的数据给客户端的浏览器。

优点：后端编码比较简单
缺点：这种传统的模式带来很明显的缺点，即客户端的浏览器需要不断的向服务器发出请求，然而HTTP请求可能包含较长的头部，其中真正有效的数据可能只是很小的一部分，显然这样会浪费很多的带宽等资源。

长轮询

客户端向发起一个到服务端的请求，然后服务端一直保持连接打开，直到数据发送到客户端为止。

优点：避免了服务端在没有信息更新时的频繁请求，节省流量

缺点：服务器一直保持连接会消耗资源，需要同时维护多个线程，而服务器所能承载的 TCP 连接是有上限的，所以这种轮询很容易导致连接上限。

长连接

客户端和服务端建立连接后不进行断开，之后客户端再次访问这个服务端上的内容时，继续使用这一条连接通道

优点：消息即时到达，不发无用请求

缺点：与长轮询一样，服务器一直保持连接是会消耗资源的，如果有大量的长连接的话，对于服务器的消耗是巨大的，而且服务器承受能力是有上限的，不可能维持无限个长连接。

WebSocket

客户端向服务器发送一个携带特殊信息的请求头（Upgrade:WebSocket ）建立连接，建立连接后双方即可实现自由的实时双向通信。

优点：

• 较少的控制开销。在连接创建后，服务器和客户端之间交换数据时，用于协议控制的数据包头部相对较小。
• 更强的实时性。由于协议是全双工的，所以服务器可以随时主动给客户端下发数据。相对于HTTP请求需要等待客户端发起请求服务端才能响应，延迟明显更少；即使是和Comet等类似的长轮询比较，其也能在短时间内更多次地传递数据。
• 保持连接状态。与HTTP不同的是，Websocket需要先创建连接，这就使得其成为一种有状态的协议，之后通信时可以省略部分状态信息。而HTTP请求可能需要在每个请求都携带状态信息（如身份认证等）。

缺点：相对来说，开发成本和难度更高

如何处理二维码的有效期，过期了数据如何处理？

• 数据库设置状态
• redis过期时间