什么是并发竞争
比如我们现在同一个缓存key，test_key = v1。现在有A、B、C三个系统几乎同时来更新，那么原本顺序应该是A系统更新为v2、B系统更新为v3、C系统更新为v4。但是因为A系统没有竞争过来，变成了B、C先更新，也就是v1->v3->v4->v2，最后的值应该是v4现在确是v2。这就是并发竞争产生的问题。
如何解决
我们每次更新的时候，要判断一下这个数据的时间戳，如果缓存中的数据时间戳比自己更晚，那么自己的数据就是历史数据，不需要再更新。
另外，还要通过zk加一个分布式锁，每次更新的时候都去获取这个锁，保证同一时间只有一个进程在更新一个key
————————————————
版权声明：本文为CSDN博主「木小同」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/weixin_41011482/article/details/118311483
文章参考 2：
背景：比如我们有三个系统服务，然后由于某个数据从来没请求过，现在三个系统并发对该数据进行请求和修改的时候就会出现并发竞争问题了，当然由于redis的单线程结构其实这里不存在锁和阻塞问题，这里的问题是可能出现老数据覆盖新数据的问题。
解决方案：
利用分布式锁（zk或者redis）做门，只有一个服务可以进行开门尝试，并且需要用自己的钥匙去匹配，匹配成功再去做下面操作
只有成功获取锁的系统可以进行修改并且要带上数据的版本号，我们要做cas和自旋(自行参考aotomicinteger修改数据方法的源码（compareAndSwap）)只有到了这个版本号才进行修改
标签：竞争,Redis,系统,更新,并发,key,解决方案,数据 From： https://www.cnblogs.com/sword0077/p/17152624.html