Q：请问一个更新操作在进行到哪一步会向客户端返回成功？主从架构下，数据同步到slave是异步的吗？如果数据还未同步到slave而master宕机，数据是否有丢失风险？
A：异步复制的版本中，只要写入成功之后就会直接返回，如果是同步复制的逻辑，会在更新Redis并且更新Tendis成功之后，才会返回。
Q：Redis的内存大小和tendis的磁盘大小，两者比例是多少？是否可以配置？
A：目前我们提供的是一个分布式的，也就是多分片的一个架构。Redis的内存和Tendis 的磁盘两者是可配的，而且是可调整的。这个配置是自己可调的，可以在腾讯的控制台直接拖你的磁盘，选择什么样的规格。
Q：compaction的过程会不会出现短暂的相应延时较高？
A：如果存储引擎写入的负载非常高就会出现这种情况。虽然会有一定的延时，但compaction在聚合的时候非常耗CPU，如果层级上下层的比例很大时，它一定回去强行触发合并，这是可能就会短暂的出现延时较高的问题。
Q：如何做到只查cache就知道key也不在下层存储里面？
A：我们会在缓存层里面把所有的key都给存储起来，这样相当于一个过滤器，你的key全部存在缓存就知道了，不用再去查存储。
Q：值是永久存储吗？即使在Redis中过期了
A：过期这个概念需要简单介绍一下。在混合存储版中TTL的语义没有发生改变，TTL到期或者仍然会删除数据，所以说这个版本的正确使用姿势就是，不需要删除的key就不要去设expire，不然你的数据会被删除，我们会在缓存层自动做一个缓存的调配，但是数据是持久化的磁盘，这一点是一个区别。
Q：公有云上，如果是典型的常规网管类应用（设备接入、认证、配置&管理、报表、关联分析），用传统的分布式数据库更有优势还是Redis更有优势？
A：Redis 主要是在互联网产品非结构化的数据和科学存储，它能够支持非常轻量的范围查询。但我理解像网管类的应用设备，还是更偏传统的关系型数据库。Redis还是偏互联网场景，更能够支持的设备都是带模式的表结构的数据库。
Q：大key存储方面有哪些限制？
A：大key存储目前没有限制，但是会在初期的版本上设置一个阈值，就是大于8M的一个value，我们暂时不会把它从内存驱逐。因为我们从把它存储层面捞起来的时候，整个耗时会非常长，也会明显的影响我们的性能。针对这个场景我们后面会优化一个大key场景的缓存，会把结构复杂的key穿透到存储层解决。
Q：现在Redis混合存储版SLA能达到几个9？日常烧内存或SSD损坏频率高吗？
A：混合存储版的SLA和其他存储数据库都是一样的，我们可用性的SLA是三个9，一个月99.95%。
日常烧内存还好，内存主要是SSD，但我们现在用的是分布式的存储，所以这一块暂时不是我们维护。SSD我觉得它有一个优势，就是我们这个版本因为是顺序写入的，肯定比随机写要好一点，IO的频率会低一些。从这个角度来说，它应该会比其他的数据库对SSD的保护更好一些。
Q：哨兵模式不能启用吗？
A：如果选用Redis混合存储版，直接把哨兵的逻辑去掉就可以了。我们会提供一个VIP，直接把它当成单机版使用就可以。
Q：Redis如何保障多中心双活？部署架构是什么样的？
A：我们会提供灾备和多AZ部署的方案。灾备的方案就是在多个地域或者多个AZ去部署单独实例，通过全球复制的功能实现灾备。多中心双活，我们后面会提供一个全球多活这样一个可以多点写入的方案，可以在后面关注我们产品上线的一个进度。
Q：大量数据过期，后台会自动清理吗？
A：如果是混合存储版设置了一个过期的时间，到时间之后后台就会把key删除掉，在缓存和存储同时删除。
Q：范围扫描的操作，性能如何？
A：如果执行的命令不涉及到value，它的性能就和内存版是一样的，如果涉及到value，其实就是磁盘版的性能。
Q：刚提到计划全球同步，面临最大的挑战是什么？个人认为物理延迟是无法避免的，强一致是很难的，物理链路决定了延时。那是否只能保证最终一致性？
A：我们在全球同步的时候，比如国内和海外有100甚至200、300毫秒的时延，如果要求强一致业务肯定是不能接受的。