2021-01-27 第三方平台授权令牌管理

前言

项目是通过微信第三方平台做的代小程序实现业务，所以会管理已授权的小程序
而在调用小程序授权的接口时，通常需要带上authorizer_access_token，而这个token有效期为2小时，所以过期时需要刷新
现在刷新是获取authorizer_access_token后会记录其过期时间，下次获取后判断是否过期，过期则刷新

authorizer_access_token特点(同小程序开发的access_token)

获取/刷新接口调用令牌

有效时间为2小时，推荐提前刷新(提前刷新后旧token还有效5分钟，我是提前10分钟刷)

目前问题：并发刷新、客户端和服务端都有刷新动作

客户端做消息订阅需要authorizer_access_token
服务端调用授权方接口，因此也需要authorizer_access_token

解决

• 方案一：分布式锁

项目中有用到redis，正好通过其来实现分布式锁，伪代码如下

if (authorizer_access_token expire) {
	String key = "refresh_authorizer_access_token" + appId;
	Boolean setResult = redis.setExNx(key, "", 60);//	set key val ex 60 nx(redis中set key，过期时间60s)
	if(setResult != null && setResult) {
		//	调用接口刷新authorizer_access_token并更新DB
	} else {
		/**
		 * 睡2S
		 * 1、递归自己(返回值为authorizer_access_token)
		 * 2、抛异常(提示网络异常，这样一般再次调用authorizer_access_token会是最新的)
		 */
	}
}

• 方案二：分布式单独一个模块来控制authorizer_access_token

小结

上述我用的是方法一，因为现在项目还没走到分布式这一步，因此采用的是方法一，并发下可以保证只有一个线程负责调用刷新接口，其他线程都是等待获取
起始也考虑了乐观锁来做，但因为是先刷新再更新DB，这样不行，所以没考虑乐观锁了- -。

标签：authorizer,01,过期,调用,access,token,27,2021,刷新
来源： https://blog.csdn.net/qq_42130098/article/details/113246753