公众号openid实时存储mysql_微信--高效解决token及授权用户openid的持久化处理办法...

摘要

关于微信开发的话题，例子确实已经有不少，但大部分都是人云亦云，很多小细节或者需要注意的地方却大多没有讲清楚，这令很多刚开始开发的人感觉大很迷茫。而我今天要说的话题，主要着眼于两个方面。

一：如何存储获取用户信息及调用第三方接口所需要的token.

二 : 第三方页面授权,如何减少从微信服务器获取用户openid的次数以及减少获取用户信息的次数，加速第三方页面的加载速速。

(注：演示所使用的是java语言，其他语言可与此类似)

下面我将开始讲述第一个问题。

如何存储获取用户信息及调用第三方接口所需要的token？

从微信的官方文档上，我们知道，获取token的次数为1天2000次，每两小时token失效一次，对于那种一天没有几个人访问的微信公众号而言，他们可能只是简单的每次调用高级接口都会去获取一遍token.众所周知，这种做法极其的耗费时间。从网上其他网友给出的存储方案大概有如下几种：

数据库：通过微信接口获取到 Token 之后，将 Token存储到数据库，每次需要时从数据库取出。采用定时任务的方法每隔一个固定的时间去获取一次token.

NoSQl：这里以 Redis 为例子。通过微信接口获取到 Token 之后，存入 Redis，可以通过设置redis的过期时间，每次需要token时从redis中取出来，若没有，则证明Token 已过期可重新获取(当然也可采用上面的定时任务的方式定期获取)。

文件存储：这个比较适合单一公众号的情况。通过微信接口获取到 Token 之后，存入文件，采用定时任务的方法每隔一个固定的时间去获取一次token.

(固定的时间：一般设为1小时为宜，如1小时后因网络原因，请求获取token失败，则原有的token还可以在使用1小时，这种方式将错误降低了一半)

大致有这三种方案。当然对于那些将token存储在session或者cookie里面的，这里我只能呵呵一笑了。

基于以上三种方式，我个人比较推崇的一个顺序是NoSQl>数据库>文件存储。

下面我分别来说说他们的优缺点：

采用数据库和文件存储，对于单节点并且用户请求数不是很多的web项目而言，是可以的正常运行的，但是对于分布式多节点的项目，采用这两种方式是行不通的。而我今天要说的第三种通过Redis方法存储，一方面它可以提升获取token的速度，另一方面当分布式项目的多个节点要公用同一个token的时候，我们可以方便的取到。

第三方页面授权,如何减少从微信服务器获取用户openid的次数以及减少获取用户信息的次数，加速第三方页面的加载速速？

从诸多的博客中，我们了解到，第三方页面授权获取用户信息，我们要调用两次微信接口。

第一次：构造应用授权的url,通过返回的code，换取用户的openid.

第二次：通过用户的openid与token获取用户信息。

对于页面比较多的应用，每个页面请求时都需要调用两个方法，于用户而言这是极其耗费时间的。

然而诸多的博客只是告诉我们改如何处理用户信息，诸如将用户信息先拉取下来存储到自己的数据库，然后每次需要时从自己的数据库中通过openid来获取。殊不知这种博客只说了一点，他们没有考虑到的问题是：

用户若修改了自己的信息