我始终管用微信念书阅读的生活习惯，前段时间辨认出微信阅读除了网页版。进占微信阅读的网页版，需要他们用App二维码展开进占。

采用你的微信阅读App扫描器完上面的二维码并点选证实进占后，网页版就能手动进占。进占后会展现你的阅读历史记录，书柜信息等。

我忽然很疑惑，那个二维码进占究竟是是不是同时实现的，因此就去网路上查了下有关的网志数据资料。那边历史记录下当中的一类比较简单好理解的同时实现计划。

同时实现细节#

二维码进占的同时实现需要智能手机端服务器和Web端服务器相互配合同时实现。大体分成下列一百米：

step1：网页端允诺进占二维码

直接Chalancon图吧

要同时实现网页版的二维码进占，用户必须先要允诺两个进占的二维码。Web端服务器接到用户提出申请进占二维码的允诺后，会乱数聚合两个uuid（那个uuid做为网页的惟一URL），因此会将那个uuid当作两个数组对的key取走前台Redis。

取走Redis的那个数组对的value是什么他们待会反正。

需要特别注意的是取走Redis的数组对必须设置两个已过期时间，不然不然拿着那个uuid进占一场后就始终处在进占状况了。

当应用程序端领到Web服务端回到的二维码信息后，导出当中的uuid，并拿那个uuid不断去前台HTTP与否早已进占成功。如果前台早已进占成功，Web端就手动重定向到进占成功网页。不然不然会始终HTTP，直至二维码失灵（这儿他们辨认出给二维码设置有效率时间

吗很有必要性，如果二维码没有有效率时间不然，会不断的HTTP前台，给前台导致非常大的阻力）。

因此上面的关键点是Web端服务器是是不是推论用户与否早已二维码进占成功过的呢？ 请看上面的关键步骤。

step2：智能手机端将用户id取走Redis

用户允诺到二维码后，就开始拿出智能手机，打开相应的App扫描器二维码。扫描器过程中智能手机会将uuid和智能手机端进占后获得的token信息一起提交到智能手机端服务器。

智能手机端服务器会先拿token信息推论那个用户与否合法，与否早已正常进占。如果推论早已正常进占，因此会将那个用户的userId和提交过来的uuid当作两个数组对（uudi-userId）取走Redis。那边回答了关键步骤一类留下的问题。

简单来讲智能手机端做的工作就这么多。让他们继续回到Web端。

step3：web端HTTP成功

关键步骤一中讲到：二维码进占页会不停的HTTP与否进占成功。那边的依据就是Redis中存在uuid-userId数组对。如果那个数组对早已存在，说明智能手机端早已二维码进占过。

Web端服务器一旦推论到智能手机端早已二维码登陆过，就可以拿着userId展开进占。并将必要性的用户信息和token信息回到Web前端。至此Web端进占成功。

简单总结#

本文历史记录了两个二维码进占的简单版本，但是也能描述二维码进占的大体原理。实际开发过程中应该还是有许多细节需要考虑。比如安全问题等。具体的还是需要他们展开实战了。