（面试踩坑）redis可以替代MySQL吗？

背景：

面试官：redis你学过吧，听你的语气我想你redis学的不错吧?
我：…
面试官：那好，我问你一个很简答的问题哈，你说一下redis可以替换MySQL吗？你简单说一下就好。
我：（一般面试官让你简单说，我们绝对不能太简单）

下面是我在网上找到，总结到一起的答案。

因为Redis的性能十分优越，可以支持每秒十几万次的读/写操作，并且它还支持持久化、集群部署、分布式、主从同步等，Redis在高并发的场景下数据的安全和一致性，所以它经常用于这些场景：

经常要被查询，但是CUD操作频率低的数据；比如数据字典，确定了之后很少被修改，是可以放到缓存中的；还有热点数据，查询极为频繁的数据，放到Redis中可以减少MySQL的压力；

经常被查询，但是实时性要求不高数据，比如购物网站的热销排行榜，定时统计一次后把统计结果放到Redis中提供查询（请不要每次都使用select
top 10 from xxxx）。

缓存还可以做数据共享（Session共享），在分布式的架构中，把用户的Session数据放到Redis中。

高并发场景下的计数器，比如秒杀，把商品库存数量放到Redis中（秒杀的场景会比较复杂，Redis只是其中之一，例如如果请求超过某个数量的时候，多余的请求就会被限流）；

因为Redis对高并发的支持和单线程机智，它也经常用作分布式锁；

redis是noSql，NoSQL本来就是【Not Only SQL】的意思，显然是跟SQL形成互补关系的应用。
redis可以作为存储的扩展部分，但是不能直接替换掉mysql。
redis对事务的支持还是比较简单的。但是redis的性能和扩展性比较好，使用起来比较方便。 现阶段的 MySQL 和 Redis
各有各的使用场景,在设计上的侧重点不同,谁也不能取代谁。

Redis本身是支持数据持久化的，很多有些程序员都会觉得Redis应该可以替代MySQL，但是我们在
使用一项技术的时候，不是看它能不能，而是要看它适合不适合；而在大部分场景下，Redis是无法替代MySQL的。

MySQL是关系型数据库，数据储存在磁盘上，数据的格式是我们熟知的二维表格的样式。关系型数
据库具有很多强大的功能；大部分都支持SQL语句查询，对事务也有很好的支持。

Redis被称作非关系型数据库，属于内存数据库，数据都储存在内存中（Redis有RDB持久化策略），
Redis支持的数据类型也比较多，比如字符串，HASH，List等。

MySQL和Redis没有竞争的关系，通常当并发访问量比较大的时候，特别是读操作很多，架构中可以引入Redis，帮助提升架构的整体性能，减少Mysql(或其他关系型数据库)的压力；

不是MySQL or Redis；而是MySQL + Redis ；

上面总结的不足以说明我们的问题，评论区有大佬说从关于宕机redis数据丢失的方向思考，作为论证去说明我们要论证的问题，我们看一下是否合适？

首先redis有自己数据集保存操作，当出现一下情况：

用户发送bgsave命令(此时redis会fork一个子进程,子进程负责生成硬盘文件,父进程负责继续接受命令)
用户发送save命令(和bgsave命令不同,发送save命令后,到系统创建快照完成之前系统不会再接收新的命令,换
句话说save命令会阻塞后面的命令,而bgsave不会) 用户在配置文件了配置了类似这样的命令 save 60 1000
这个的意思是说,自从上次快照成功算起,如果满足"60秒内有1000次写入"这个条件,系统就自动调用bgsave,如
果配置文件里有多个save命令,只有满足一个就调用bgsave命令
用户发送shutdown,系统会先执行save命令阻塞客户端,然后关闭服务器
当有主从架构时,从服务器向主服务器发送sync命令来执行复制操作时,只有主服务器当时没有进行bgsave操
作,那么主服务器就会执行bgsave操作。 快照的配置信息

redis会快照内存里的数据
当 Redis 需要保存 dump.rdb 文件时， 服务器执行以下操作: Redis 调用forks. 同时拥有父进程和子进程。

子进程将数据集写入到一个临时 RDB 文件中。

当子进程完成对新 RDB 文件的写入时，Redis 用新 RDB 文件替换原来的 RDB 文件，并删除旧的 RDB 文件。这种工作方式使得 Redis 可以从写时复制（copy-on-write）机制中获益。

快照功能并不是非常耐久（dura ble）： 如果 Redis 因为某些原因而造成故障停机， 那么服务器将丢失最近写入、且仍未保存到快照中的那些数据。 从 1.1 版本开始， Redis 增加了一种完全耐久的持久化方式： AOF 持久化。

你可以配置 Redis 多久才将数据 fsync 到磁盘一次。有三种方式：

每次有新命令追加到 AOF 文件时就执行一次 fsync ：非常慢，也非常安全
每秒 fsync 一次：足够快（和使用 RDB 持久化差不多），并且在故障时只会丢失 1 秒钟的数据。从不 fsync ：将数据交给操作系统来处理。更快，也更不安全的选择。
推荐（并且也是默认）的措施为每秒 fsync 一次， 这种 fsync 策略可以兼顾速度和安全性。

所以从数据丢失的方向去论证这个问题不是特别有说服力，当然顺子上面的论证也不是那么有力，文章仅供参考。