本文详细介绍了微信支付流程，包括设置域名、获取code、换取access_token等步骤，并讨论了金额类型不一致及异步通知可能导致的问题。此外，还探讨了如何使用Redis实现分布式锁，避免多线程操作时的一致性问题。
七：微信支付，查询订单，退款等实现
1.设置域名 使用NATAPP？为什么要用它呢
在进行微信公众号开发时，我们需要搭建网站，并且随时都有可能修改网站内容进行调试。如果能够将内网ip映射到外网上，将大大方便我们的调试。每次发布只需eclipse运行应用即可。通过natapp将内网映射到外网，还可以方便我们其他工作，比如外网展示网站等
内网穿透：当我们在端口映射时设置时，内网穿透起到了地址转换的功能，也就是把公网的地址进行翻译，转成为一种私有的地址，然后再采用路由的方式ADSL的宽带路由器，具有一个动态或者是固定的公网IP，最后ADSL直接在交换机上，这样所有的电脑都可以共享上网。
2.获取code
入参：
| 参数 | 是否必须 | 说明 |
|---|---|---|
| appid | 是 | 公众号的唯一标识 |
| redirect_uri | 是 | 授权后重定向的回调链接地址， 请使用 urlEncode 对链接进行处理 |
| response_type | 是 | 返回类型，请填写code |
| scope | 是 | 应用授权作用域，snsapi_base （不弹出授权页面，直接跳转，只能获取用户openid），snsapi_userinfo （弹出授权页面，可通过openid拿到昵称、性别、所在地。并且， 即使在未关注的情况下，只要用户授权，也能获取其信息 ） |
| state | 否 | 重定向后会带上state参数，开发者可以填写a-zA-Z0-9的参数值，最多128字节 |
| #wechat_redirect | 是 | 无论直接打开还是做页面302重定向时候，必须带此参数 |
如果用户同意授权，页面将跳转至 redirect_uri/?code=CODE&state=STATE，即回调端口
code说明 ： code作为换取access_token的票据，每次用户授权带上的code将不一样，code只能使用一次，5分钟未被使用自动过期。3. 换取access_token
获取code后，请求以下链接获取access_token： https://api.weixin.qq.com/sns/oauth2/access_token?appid=APPID&secret=SECRET&code=CODE&grant_type=authorization_code
参数说明
| 参数 | 是否必须 | 说明 |
|---|---|---|
| appid | 是 | 公众号的唯一标识 |
| secret | 是 | 公众号的appsecret |
| code | 是 | 填写第一步获取的code参数 |
| grant_type | 是 | 填写为authorization_code |
返回说明
正确时返回的JSON数据包如下：
{ "access_token":"ACCESS_TOKEN",
"expires_in":7200,
"refresh_token":"REFRESH_TOKEN",
"openid":"OPENID",
"scope":"SCOPE" }4. 使用sdk方式
七：微信支付，退款等
1. 发起微信支付-后端
2. 在网页发起支付
3. 动态注入参数发起支付
4. 处理微信异步通知
5. 微信退款
微信总结：
授权-支付
在进行访问时，前端代码会判断cookie中是否存在openid，若没有，则会跳转授权Url, returnUrl即为之前的地址，在获取到openid之后会跳到returnUrl
总结：
１．在进行金额比较时，微信支付系统传过来的金额的类型和本身订单中的金额类型不一致，导致比较失败
２．由于微信支付系统的异步通知是不断进行的，所以导致接受通知失败，修改订单支付状态出错
九 使用redis分布式锁
当涉及多个线程访问时，如果保证一致性
如果单单使用synchronzed:
1 . 可以解决这个问题
2. 无法做到细粒度控制(setnx使用id作爲key实现更细粒度的控制value一般是当前时间加超时时间）
3. 只适合单点控制，（多台机器多个进程对一个数据进行操作的互斥）
SETNX
使用SETNX实现分布式锁
多个进程执行以下Redis命令：
SETNX lock.foo <current Unix time + lock timeout + 1>
如果 SETNX 返回1，说明该进程获得锁，SETNX将键 lock.foo 的值设置为锁的超时时间（当前时间 + 锁的有效时间）。
如果 SETNX 返回0，说明其他进程已经获得了锁，进程不能进入临界区。进程可以在一个循环中不断地尝试 SETNX 操作，以获得锁。
- 获取锁的时候，使用setnx加锁，并使用expire命令为锁添加一个超时时间，超过该时间则自动释放锁，锁的value值为一个随机生成的UUID，通过此在释放锁的时候进行判断。
- 获取锁的时候还设置一个获取的超时时间，若超过这个时间则放弃获取锁。
- 释放锁的时候，通过UUID判断是不是该锁，若是该锁，则执行delete进行锁释放。
解决死锁
考虑一种情况，如果进程获得锁后，断开了与 Redis 的连接（可能是进程挂掉，或者网络中断），如果没有有效的释放锁的机制，那么其他进程都会处于一直等待的状态，即出现“死锁”。
上面在使用 SETNX 获得锁时，我们将键 lock.foo 的值设置为锁的有效时间，进程获得锁后，其他进程还会不断的检测锁是否已超时，如果超时，那么等待的进程也将有机会获得锁。
然而，锁超时时，我们不能简单地使用 DEL 命令删除键 lock.foo 以释放锁。考虑以下情况，进程P1已经首先获得了锁 lock.foo，然后进程P1挂掉了。进程P2，P3正在不断地检测锁是否已释放或者已超时，执行流程如下：
- P2和P3进程读取键 lock.foo 的值，检测锁是否已超时（通过比较当前时间和键 lock.foo 的值来判断是否超时）
- P2和P3进程发现锁 lock.foo 已超时
- P2执行 DEL lock.foo命令
- P2执行 SETNX lock.foo命令，并返回1，即P2获得锁
- P3执行 DEL lock.foo命令将P2刚刚设置的键 lock.foo 删除（这步是由于P3刚才已检测到锁已超时）
- P3执行 SETNX lock.foo命令，并返回1，即P3获得锁
- P2和P3同时获得了锁
从上面的情况可以得知，在检测到锁超时后，进程不能直接简单地执行 DEL 删除键的操作以获得锁。
为了解决上述算法可能出现的多个进程同时获得锁的问题，我们再来看以下的算法。
我们同样假设进程P1已经首先获得了锁 lock.foo，然后进程P1挂掉了。接下来的情况：
- 进程P4执行 SETNX lock.foo 以尝试获取锁
- 由于进程P1已获得了锁，所以P4执行 SETNX lock.foo 返回0，即获取锁失败
- P4执行 GET lock.foo 来检测锁是否已超时，如果没超时，则等待一段时间，再次检测
- 如果P4检测到锁已超时，即当前的时间大于键 lock.foo 的值，P4会执行以下操作
GETSET lock.foo <current Unix timestamp + lock timeout + 1> - 由于 GETSET 操作在设置键的值的同时，还会返回键的旧值，通过比较键 lock.foo 的旧值是否小于当前时间，可以判断进程是否已获得锁
- 假如另一个进程P5也检测到锁已超时，并在P4之前执行了 GETSET 操作，那么P4的 GETSET 操作返回的是一个大于当前时间的时间戳，这样P4就不会获得锁而继续等待。注意到，即使P4接下来将键 lock.foo 的值设置了比P5设置的更大的值也没影响。
另外，值得注意的是，在进程释放锁，即执行 DEL lock.foo 操作前，需要先判断锁是否已超时。如果锁已超时，那么锁可能已由其他进程获得，这时直接执行 DEL lock.foo 操作会导致把其他进程已获得的锁释放掉。
GETSET
使用Redis进行缓存
@Cacheable
@Cacheable可以标记在一个方法上，也可以标记在一个类上。当标记在一个方法上时表示该方法是支持缓存的
@Cacheable可以指定三个属性，value、key和condition
1.1.1 value属性指定Cache名称
value属性是必须指定的，其表示当前方法的返回值是会被缓存在哪个Cache上的，对应Cache的名称。其可以是一个Cache也可以是多个Cache，当需要指定多个Cache时其是一个数组。
1.1.2 使用key属性自定义key
key属性是用来指定Spring缓存方法的返回结果时对应的key的。该属性支持SpringEL表达式。当我们没有指定该属性时，Spring将使用默认策略生成key。
1.1.3 condition属性指定发生的条件
有的时候我们可能并不希望缓存一个方法所有的返回结果。通过condition属性可以实现这一功能。condition属性默认为空，表示将缓存所有的调用情形。其值是通过SpringEL表达式来指定的，当为true时表示进行缓存处理；当为false时表示不进行缓存处理，即每次调用该方法时该方法都会执行一次。
@Cachput
支持Spring Cache的环境下，对于使用@Cacheable标注的方法，Spring在每次执行前都会检查Cache中是否存在相同key的缓存元素，如果存在就不再执行该方法，而是直接从缓存中获取结果进行返回，否则才会执行并将返回结果存入指定的缓存中。@CachePut也可以声明一个方法支持缓存功能。与@Cacheable不同的是使用@CachePut标注的方法在执行前不会去检查缓存中是否存在之前执行过的结果，而是每次都会执行该方法，并将执行结果以键值对的形式存入指定的缓存中。
@CacheEvict
@CacheEvict是用来标注在需要清除缓存元素的方法或类上的。当标记在一个类上时表示其中所有的方法的执行都会触发缓存的清除操作。@CacheEvict可以指定的属性有value、key、condition、allEntries和beforeInvocation。其中value、key和condition的语义与@Cacheable对应的属性类似。即value表示清除操作是发生在哪些Cache上的（对应Cache的名称）；key表示需要清除的是哪个key，如未指定则会使用默认策略生成的key；condition表示清除操作发生的条件
扫一扫
441
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
