非关系型数据库面试都考些啥
最近帮朋友准备跳槽，翻了不少面试题资料，发现非关系型数据库这块问得越来越细。特别是做后端、大数据或者运维的岗位，光说“用过Redis”已经不够了，面试官会直接问你底层怎么实现的，数据一致性怎么处理的。
比如有次朋友去一家电商公司面试，刚坐下就被问：“如果Redis宕机了，数据还能恢复吗？怎么恢复？”他一时没答上来，其实这背后考的是持久化机制——RDB和AOF的区别。
save 900 1
save 300 10
save 60 10000这段配置就是Redis的RDB触发条件，表示900秒内至少1次修改就保存快照。很多人背了命令，但真问到“为什么AOF重写时不阻塞主线程”，就开始卡壳。
为什么选MongoDB存日志
有个运维同事被问到：“你们系统日志原来存在MySQL，现在改用MongoDB，到底解决了啥问题？”他说一开始只答了“读写快”，结果面试官追问：“那为什么不全用MongoDB替代MySQL？”这才意识到，得讲清楚场景差异。
日志这种数据，结构松散、写入频繁、查询时通常按时间范围过滤，正适合MongoDB的BSON格式和分片能力。而订单信息涉及多表关联、强一致性要求，还是得靠关系型数据库兜底。
缓存穿透和雪崩的实际应对
Redis相关的高频题离不开缓存异常。比如“缓存穿透”是指查一个根本不存在的key，每次都会打到数据库。有人答“用布隆过滤器”，可面试官接着问：“如果数据量特别大，布隆过滤器误判率上升怎么办？”这时候就得说出具体参数调整策略，比如根据数据规模预估bit数组长度。
再比如缓存雪崩，多个热点key同时失效。简单回答“加随机过期时间”可能不够，有些公司还会看你有没有实际经验，比如是否用过Redis集群做高可用，或者本地缓存作为二级保护。
文档型 vs 列式 vs 图数据库怎么选
有次面试官甩出三个场景：用户画像分析、社交关系推荐、实时监控仪表盘。让分别选合适的NoSQL类型。这其实在考对数据库分类的理解。
用户画像属性多变，适合MongoDB这类文档数据库；社交关系层层嵌套，图数据库如Neo4j能高效遍历；监控数据时间序列明显，用InfluxDB这类列式存储更合适。光知道名字没用，得说得出为什么。
还有人被问到：“HBase为什么适合海量数据存储？”关键点在于它基于HDFS，支持自动分片和压缩，而且列存储节省空间。但缺点也得提，比如不支持复杂查询，延迟比Redis高不少。