纯缓存场景，混合存储由于引入磁盘引擎，冷数据的访问在高负载情况下可能会存储时延大的问题，没有办法像内存版Redis一样保证稳定的访问时延，同时这个版本的性能要明显的低于内存版本，特别是写入性能会收到磁盘的限制；
计算密集场景，如果你是计算密集的场景，并且数据不存储冷热分界，这个也不推荐。
Q：前面说Redis数据有版本号，如果没有落地就不会失效，防止查询存储层的脏数据。如果这个时候Redis出故障呢？数据丢了呢？
A：这个问题不是一致性的问题，而是可靠性的问题。Redis混合存储版在可靠性方面有两个可选选项。
第一个性能优先是优先，先写缓存，异步去写Tendis。如果这个时候Redis挂了，并且Redis 的从机没有收到最新的数据，这个时候就可能会丢失数据。这就和MySQL异步复制一样，会存在没有同步的数据被丢掉。所以这种场景下的可靠性和MySQL异步复制是一样的。
接下来还会提供一个版本，就是每一次写入的数据后会更新Tendis，Tendis更新OK之后会返回ACK，Redis收到ACK之后才会告诉应用程序更新成功。如果更新Redis成功、更新Tendis失败，就会把更新的数据失效掉。这样就能保证缓存和存储在可靠性上能够做到一致。
Q：在访问缓存层和数据层之前将存在的key用布隆过滤器提前保存起来，做第一层拦截，但是代码维护感觉复杂 有什么别的方案吗？（千万级数据集）
A：空数据查询的时候，通常使用的一个方案是在前面加过滤器，用过滤器拦截掉不存在的key。Redis混合存储版会在内存里面缓存所有的key，空数据在缓存的时候就直接被拦截了，不会到达存储层，这是我们现在的一个解决方案。
Q：灾备是怎么处理的，全依靠腾讯云吗？
A：腾讯云的Redis内存板正在做一个全球同步的版本，无论你的灾备异地只读还是多活都能够支持，在内存版之后，也会逐步去支持混合存储版，也就是把代码同步到混合存储版，到时候混合存储版也能做到存储的灾备、异地的灾备以及异地多活的架构。
Q：是否可以自建机房，对服务器有什么要求，必须是固态硬盘吗？
A：这个问题我理解为混合存储版能不能够支持私有化的部署。后面我们是有私有化部署的计划，在公有云上我们的版本成熟后，就会往专有云的版本去输出。对于是否必须是固态硬盘，目前来看主要是取决于业务需求，如果性能要求高，肯定要求固态硬盘，如果对性能要求不高，传统的机械磁盘也OK。
Q：关于分布式锁咱们的产品有自己的实现方式么？
A：现在大部分都是用redlock用的多，更优雅的是用CAS的原子命令去实现。后面我们也会去支持CAS相关的原子命令。
Q：cache节点是单点吗，cache节点故障检测/容忍和恢复的细节过程是什么？
A：首先，cache节点不是单节点，是个主备的架构。而且我们会支持一组多备去扩展读性能的架构。节点故障的检测/容忍和恢复的细节，Redis是一个Redis cluster，本身自己会进行简单的检查，外部也会有一些机制，比如check物理机或者内存块去检查。和纯内存的Redis高可用架构是一样的。
这里还有一个细节，因为这个版本我们引入了Tendis，所以在Redis HA的时候，我们会去check存储和缓存的数据的版本，有可能会从存储里面去刷数据，也就是我们的缓存版本会低于存储的版本。
Q：Redis更新后什么时候发起Tendis的异步更新，cache节点故障下，在还没有更新Tendis情况下，数据可能丢失吗？
A：Redis 的更新目前是异步更新到Tendis。目前数据的可靠性有两个版本，第一个是我们刚才介绍到的性能优先的版本，它是异步更新的。如果Redis故障并且数据没有刷到Tendis，而且从机也没有复制这个数据，那么这个数据是会被丢掉。原理就等价于MySQL的异步复制，保证数据的可靠性。
Q：同步组件实现目前选择什么方案？
A：目前的同步组件是自研的一个方案，大致的原理是从AOF复制数据，再把一些数据拆分同步到Tendis。