项目第一次上线前，生产环境调试阶段，项目经理反馈在备机房所在环境验证时报错：id不存在。
我赶紧去排查，查看日志，发现日志里打印的id是旧数据记作A，拿着这个数据去调其他系统提示id不存在。
查看配置表里id是新的，暂且叫做B，就很奇怪，查看代码，直接查库，然后打印数据，想着没有额外的缓存逻辑，不应该拿到的是旧数据呀！
怀疑是不是mybatis的缓存，于是重启服务还是不行......又想是不是mysql自身的缓存，但是没找到验证方法。
也去问了GPT，给了几种原因，验证了一下也无卵用。
可把我愁坏了......临近上线了，那边还催着，当天也是周六来加班眼看着天黑了，更着急了
复盘一下，首先是部署拓扑，做的主备机房异地灾备，主备机房数据库做同步，查看了两边数据是一致的！另外主备机房redis是各自的一套集群，想着去redis上看看是不是缓存了数据，但是又连不上......
更着急了，无从下手只能再去翻代码，静下心来仔细看，发现查数据这块service方法上加了一个@Cacheable注解，瞬间变得豁然开朗了......TMD这不是就用了缓存么！主备机房数据库做同步，redis可没做同步，那如果备机房之前测的时候把旧数据缓存起来了，之后在主机房管理平台修改了配置，数据库数据是改了，主机房redis是清了，数据库也同步到备机房了，但是备机房redis不会触发清除啊！
这不解决了一大半吗！于是登录到备机房的管理平台，编辑配置，原封不动提交一次，就能触发备机房的缓存清理(更新接口上加了缓存失效注解)！果然再去验证，发现打印的日志里id已变为B，调其他系统也不报id不存在了，完美解决问题。
其实这个问题的关键是，备机房也和主机房一起工作了，导致备机房的redis有了缓存数据，按正常使用方式，备机房只有主机房故障才会启用，不会并且也不建议同时使用，因为可能还会有其他问题。
我们在正式环境调试还发现了备机房同步数据库失败的问题，原因就是备机房产生了数据：当id是自增的，两个机房的数据库就会产生相同id，导致备机房同步数据时报主键冲突，后续的数据都卡着同步不了！
所以正常使用时，备机房那套环境，也仅作为备用，不能和主一起使用！并且在主备环境的架构中，数据库做同步的情况下，数据id自增导致的数据同步卡住是一个非常严重的问题，如何解决呢？