(面试踩坑)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 策略可以兼顾速度和安全性。

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

你可能感兴趣的:(java,sql,mysql)