前言
- 在对一个需求进行迭代后，成功上线并且需要策划在gm后台修改相关配置来触发该功能的修改，由于如果直接修改gm后台配置客户端会直接报错，又因为更新客户端会有滞后的问题如果直接更新服务器和配置老客户端就会报错，所以在上线一段时间后再修改配置
问题介绍
- 该模块本来为通行证通过时间配置来循环重置进度，现改为领取一轮后自动重置，并且有经过多少轮次替换的需求，需要记录下更新前的轮次
- 经过多轮测试确定没问题后进行上线，在经历几天后策划在gm对这个时间配置进行了修改，但是发现少部分人的进度被重置了，但在代码层面逻辑正确，并且重置只有在时间配置为循环并且与之前记录的轮次时间不同时进行重置
问题原因
- 看用户日志发现，用户的轮次时间信息进行了两次变更，但是看gm的操作日志确实对时间配置的需求确实只有一次
- 进入代码查看时间配置的获取，发现服务器获取时间配置会在本地进行缓存
- 该项目为分布式，在修改配置后每个服务器的本地缓存都可能不一样，如果用户第一次请求获取到了新的时间配置则会修改一次时间信息，第二次请求到了老的时间配置，此时该时间配置是循环并且时间信息对应不上就会触发重置逻辑
总结
- 对于时间配置使用本地缓存的操作肯定是正确的
- 对于使用了本地缓存的数据如果是可以通过gm后台来修改的则需要判断影响，对不允许修改的配置列出并规范操作
- 本次操作是由于客户端不兼容的情况出现的，对于客户端不兼容的情况下，应该做停服更新或者提前一个版本提前做兼容操作，提前让兼容代码上线
