背景
手里接到一个项目，项目存在大量外部页面接口调用（就是嵌入页面）。在获取对方页面链接前，我们需要获取token换取ticket拼接到网关的链接上。然后网关校验ticket是否在他们服务器的缓存中存在，如果存在这通过链接上的页面表示符参数，返回响应的页面给我们。大致如下图： 
看了上图，你不是觉得很完美，没有问题了，还直喷没有技术含量。
问题
然后问题来了，有部分网速比较慢的用户反馈访问带三方页面的服务页面经常出现401或者400。这里400和401是对方封装的权限异常，也就是ticket、token这些有问题。
过程
一开始没有头绪，我们坚持认为我们获取token是成功的，tikect也是成功的，传递过去的参数为什么你们会说权限无效？对！肯定是他们问题，他们有毒！ 就在这样的怀疑下，安心的有过了一个星期，晚上谁的挺香。 但是运营扛不住了，隔三差五反馈用户有反馈了，你们技术行不行啊。 领导直接对我发话，这个问题你不要让开发自己去看，你作为技术经理你要参与分析。 呵呵，我分析了我就觉得是那帮吊炸天的人有问题。 领导来一句你考虑了时间差了吗？
分析
领导不亏是领导，就是牛皮plus，他这一说画了个草图，我才知道自己的见识有多浅薄。 不说了上图： 
上图中的'产生ticket2,并存入ticket1'是笔误，应该是'产生ticket2,并存入ticket2'
原因
远程调用我们忽略两个因素：
用户多次点击，无论是用户手贱还是网络问题，这是客观存在的，我们没有考虑到；
更没有考虑到的是多次请求的时延性，特别在调用外部系统的情况下；解决
问题找到了，原因也分析清楚了，方案就好做了。
-
作为请求方，我们token请求太频繁，因此增加token缓存过期时间设置为30分钟。在每次请求进来时检查token过期时间，如果不到两分钟的时候，再次去网关获取token。
-
上一步只能解决不频繁去获取token的问题，关键解决这个问题是，需要在同一个用户获取网关token时需要在redis缓存中增加分布式锁，防止在第一次获取token或者在更新的时候出现之前时序问题。
-
前端优化，增加每一次请求后增加loading遮罩层，特别是容易出现时序问题的这些业务上，也为了防止其他类似因为网络慢而发起的多次请求。也能一定层度上降低正常用户的幂等性相关问题，特别是后端比较懒或者没有考虑幂等性问题的时候。
解决后大致如下图：
回顾
以上问题真的就解决了吗？不一定还有个问题要考虑。 使用相同的token获取的ticket是否每次都一样，如果不一样，还会出现同样的问题。 解决方法，改为缓存ticket，并加锁？但是页面访问是一次性的，基本不会用第二次。那对获取token和获取ticket整个作为一个整体事务是否可以？我觉得可以。
总结
干了11年的IT，遇到生产上的20%问题多和网络有关，特别是现在分布式微服务。网络问题会导致主从节点频繁切换，还会导致出现服务孤岛，还会出现因分布式事务导致数据不一致，也有可能出现想本文一样因为时延而产生的幂等性问题。
如果本文有什么错误或纰漏欢迎指出一起讨论。