用发布订阅去做
http 业务逻辑中创建并监听这个 key 的 delete event
在 websocket 处理逻辑中删除这个 key。

@netty 单实例指的是一台机器上只运行一个 redis 实例，不允许一台机器运行多个 redis 进程。

我们公司的 Redis 只允许单实例；
楼上说的多实例，小公司可以这么搞，像我们有突发流量的，一旦其中一个出现资源争抢，都会带来很大的影响。而且运维和排查难度大增。

光讨论 CPU 影响因素的话
我个人认为： 是的

micrometer

@rizon gateway 是基于 netty 的，和 servlet 容器不兼容，https://cloud.spring.io/spring-cloud-static/spring-cloud-gateway/2.2.0.RELEASE/reference/html/#gateway-starter

建议你使用 zuul1，可以和你现在的环境无缝兼容，client 用 okhttp 就好了。

@shihty5 zuul1 是基于 BIO 的，zuul2 基于 NIO，但是与 Spring cloud 没什么关系了。Spring cloud Gateway 是因为 zuul2 跳票太久，自己 spencer gibb 自己搞的基于 NIO 的网关

读的话，如果所有数据都在一个文件里面，效果应该不明显吧。

建议分享一下路径，甚至做这方面的创业工作呢？

Redis 不是有惰性删除吗?

到关于本机中升级一下运营商配置文件，看是不是 40.1 版本

再次挖掘了一下，理解到：事务 A 第 2 步，是快照读，不会加锁，事务 B 第 4 步是当前读，会加 X 锁，紧接着的第 5 步释放了 X 锁。

重新尝试着理解了一下，是不是事务 A 的 select 获取的只是 s 锁，事务 B 的 update 获取的是 x 锁，事务 B 在 commit 以后释放了 x 锁，所以事务 A 可以 update ？我来调换一下 5 和 6 的步骤验证下看看
@zhenhuaYang

@zhenhuaYang 今天看了一下午你发的这篇文章，我还是不能认同你的回复，按照我的理解，A 事务先发起，B 事务后发起，A 事务先 select 以后，会给对应的 rows 以及区间加上行锁以及 gap 锁，这种情况下，B 事务的 update 应该是无法执行的。我看文中对 Next-Key 锁介绍的部分是这么说的。还是我的理解有误？请指教！

记得来个开箱贴

@gzchen 我是昨天推荐的那位，提醒一下，直营店第一年不要发票，第二年可能会要，apple 现在售后也趋向严格了，最好联系店家补开一张。

@wangxiaoaer spring boot 本身也只是一个 bootloader + autoconfiguration 而已，不要把 spring boot 和 spring-boot-starter-web 混为一谈