这个问题最终还是要回归到用户的真实场景，假如在全球同步全球多活的场景下，可能会有异地读的需求。比如游戏的排行榜，玩家在国内刷新数值，会立即更新到国内的排行榜，同时也会异步更新到海外的Redis，数据可能会有一点延迟，但最终大家看到排行榜的数据是一致的。
这种场景对数据实时性的要求肯定不是特别高，如果真的特别高就不能够选择这种方案。所以一般是由业务进行选择，业务如果接受全球复制，那么一定能够接受数据的延迟。
Q：用了这个，是不是就没有必要在用关系型数据库像MySQL?
A：这个是我们设计这个产品的一个初衷，因为我们发现很多使用Redis+MySQL的场景，MySQL的作用仅仅是为了保障数据的可靠性，这种场景下我们使用一个混合存储就够了。或者是我们使用MySQL的目的是为了数据落地和做离线的分析，那可以把这个拆开，线上业务使用混合存储版保障业务逻辑简单，存储性能足够高，线下的分析的数据存储在MySQL。但是这个方案不是万能的，因为Redis是一个NoSQL数据库，没有完整的事务支持，不能支持复杂的查询操作，所以最佳的时间是将非结构化的数据存储在混合存储版，结构化数据存储在关系型数据库。
Q：是基于k8s吗，怎么暴露服务的？k8s的网络有优化吗？
A：架构不是基于k8s，暴露服务是一个VIP，每一个实例每一个集群会提供一个vip，像操作单机版一样使用。
Q：集群版是社区版cluster的还是proxy的，性能损失多少？
A：集群版是proxy加cluster的架构，但Redis我们改造的点还蛮多的。因为要解决数据一致性，淘汰value等。
混合存储版本，如果他和纯内存的Redis版本相比，冷数据的读写性能一定是磁盘的性能，而不是Redis的性能，磁盘的性能和Redis的性能不是一个量级的。目前单分片的磁盘性能大概是2-3万，极限压测能够达到4万多的情况。但纯内存版的随便可以跑到10万，所以是有明显的下降，还有时延的问题。