首先，没有这方面的计划，因为你这是比较高级的需求，有这类需求的公司，需求一定各不相同，我怎么做都不能全满足的。比如机房是不是同城，是不是分成两级（多个地域，每个地域下又有多个机房），地域之间ping延迟多少。光是不同的机房拓扑都能导致方案不一样的，何况各厂还有各厂”国情“。

其次，这种需求，在jetcache这里解决是最下策。应该在更底层有通用的解决方案，比如由中间件团队提供，或者由应用架构的团队统一提供（我猜不是所有的系统都使用jetcache）。

最后，也许你的职责做不到创建公司级别的统一方案，如果一定要自己做，也不建议去jetcache里面改，我不是说不建议改jetcache，而是你这个需求，发送缓存失效的消息到MQ，然后由MQ消费者来处理更好（如果公司有跨机房部署的mq，或者mq的消费者可以跨机房消费）。topic只有一个，有两个机房就创建两个消费组，每个机房运行一个消费组，负责给自己机房的redis做失效操作，程序都是一样的。

最后，我还想提一下，我在2.7里面实现了缓存更新时，使用redis的PUB/SUB，让local cache失效的能力。

并不是说我认为缓存的更新就应该这么干，而是因为有这种需求的人很多，而jetcache只是一个偏业务层面的缓存框架，它不是一个解决方案，所以我只好在不增加依赖的情况下，提供了一个勉强堪用的实现。

缓存的跨机房复制和更新是偏底层的统一需求，在某个公司具体的场景下，好的架构师通常能提供更贴切公司情况的方案。

多谢大佬指点，受益匪浅。
还是决定redis 的 pub/sub 来实现这个需求，原因如下：
1、目前这个需求对于延时（老板说几十秒都可以）和一致性要求都不高。
2、公司原本有跨机房同步MQ，现在因为将本增效砍掉了。这次是打算做一个SDK，所以也不想额外引入相对Redis更重量级的MQ。
3、老板只给了10天时间从方案到项目改造完成，没时间做更多方案。

所以使用pub/sub是比较轻量级的方案