第一：大量热Key同时被淘汰，其中到原因是TTL设置时间接近。Redis混合存储版支持动态TTL，每次对Key的访问都会触发TTL更新，保障热数据持久缓存，有效规避缓存密集淘汰，我们通过两个参数配置来实现动态TTL：
value-eviction-policy：设置为time-to-eviction，启用全局动态TTL；
value-time-to-eviction：设施动态TTL的时长，取值范围[1h-180d]。
第二：一个冷Key瞬间产生大量的访问，由于缓存MISS导致大量请求透传到存储层，Redis混合存储版通过合并冷数据缓存的请求，同一个key的请求只访问一次存储层（Ten第三），可以将对存储层的访问降到最低，从而避免存储层过载。
4. 产品试用入口Redis混合存储版已在腾讯云正式上线，扫描下方二维码即可进入免费试用申请页面（目前仅对腾讯云官网注册的企业账户开放申请）。
Q：缓存击穿和缓存穿透有什么区别？
A：缓存击穿和穿透，我们可以理解为缓存层失效了，压力都到了存储层。
Q：还招人么？
A：在大量招，如果有对 Redis 了解的同学更加欢迎。请投至邮箱：lynzou@tencent.com
Q：接入这套解决方案多少钱？看来不是开源的，有计划没？
A：目前是在公有云公开售卖，能看到价格。我们也给大家提供了一个数字，最大可比用纯内存版节省成本 85%。后续有计划做开源，因为这块技术后续会往这个方向发展。
Q：Redis本身的内存及CPU消耗是个什么水平？
A：我把这个问题理解成 Redis 混合存储版对CPU和内存的消耗。你可以把它理解成现在我们混合群组里面缓存这一层的 Redis，会比原来纯 Redis 的消耗高一点点，因为涉及到了在里面引入revision。还有它的缓存和淘汰逻辑会更复杂，因为在这一个层面我们会去做缓存淘汰，所以光Redis 这个层面性能相对纯内存会有所下降。
我们目前能够看到，整个系统的稳定性能大概是在2万到3万，极限压测能够到四五万的样子，但是一旦到高负载压测的时候，磁盘的问题就出现了，在压到三万以上的时候就很可能会出现抖动，抖动带来的问题就是时延加大，甚至写入失败。
Q：数据压缩是否带来CPU的开销影响效率？
A：这是必然的。我们在空间和时间上面肯定都有换算。
目前来看，我们看到压缩的性能消耗还是其次的， Tendis 的主要开销除了传统的写入。RocksDB有一个compaction，它所有的请求都会顺序写入，然后再分级进行合并。这个合并的开销是蛮大的，合并的目的是为了合并存储空间。
所以大家在使用这个版本的时候，可能会碰到磁盘空间是一个曲线不停的在变化，一会大一会小。在写入的时候肯定会变大，过一会儿又会自动变小。这是因为 compaction 在合并时候的一个机制。
Q：这个和Redis本身处理空查询有什么区别？
A：Redis 本身没有处理空查询的能力，通常需要业务去使用布隆过滤器等方案来处理空查询。
目前有一些的业务方案是：如果查到一个缓存是空的，我们把key丢到缓存中，把它置为一个空的value，下一次查询时会查询是命中，并且返回的值是空的，这样就可以解决这个问题，但是需要业务层去开发写逻辑才可以，而我们直接就把这部分的事情做了。
Q：请问冷数据value为空(只缓冲key), 与该key的真实value为空，两者如何判断？
A：我们在做开发的时候有一个逻辑，会有一个标识位，在Redis 中通过这个标识位就可以判断是被淘汰了还是为空。
Q：老师能不能介绍一下备份机制呢？
A：目前混合存储板的主要场景还是存储，这个版本的备份机制是通过RocksDB来实现的。所以备份的是RocksDB 的SST文件。这个备份和MySQL的备份机制是一样的，备份全量的数据和增量的日志。所以混合存储板可以像MySQL一样支持按时间点回档，并且还有一个好处。很多数据库在备份的时候会先锁个表把全量的数据拷出来，不管是用逻辑还是物理的方式，然后再去备份增量的数据。这样备份很耗性能和空间。但RocksDB有一个好处，就是它每一次的写入都是增量的，做全量备份的时候直接切一个快照，然后把在这个点之前的文件全部直接拖走就可以，基本上是秒级就可以实现全量备份。全量备份和存量备份结合起来就可以实现任意时间点的回档。
Q：Redis混合存储适用于哪些应用场景，哪些场景不适用？
A：两个推荐：
需要自带缓存加速的KV存储场景，比如Redis+MySQL的架构，但是你又不需要MySQL的复杂查询，仅仅是通过MySQL实现数据可靠性存储；
分布式大容量KV存储场景，TB甚至数百TB级别的分布式KV存储方案。
两个不推荐：