依黛
首先可以明确一点的是：Redis可以对MySQL中的部分数据进行存储，但Redis是无法代替MySQL来做数据存储的。Redis是非关系型数据库，MySQL是关系型数据库，听上去都是数据库，但两者的定位及应用场景是完全不同的。
数据库的目的及功能
数据库是专门用来存储数据的地方，可以理解成是一个电子档案馆。数据库需要具备最基本的新增、更新、查询、删除等操作，另外要在并发操作下保证数据的隔离性和一致性。
为什么会存在非关系型数据库（NoSQL）？
我们知道，传统的关系型数据库都是持久化存储的，数据是存放在硬盘中的。随着数据量的扩大，无论是写入还是查询操作都会产生IO开销。为了解决写读数据带来的IO瓶颈就出现了NoSQL技术。
Redis非关系型数据库的初衷及不足
Redis作为一种非关系型数据库的代表，它是基于内存的高性能Key-Value数据库。它支持每秒十几万次的读写操作，在读写性能上远远超过传统的关系型数据库。
Redis读写速度之所以这么快，是因为它将数据直接存放在内存中进行操作的。但是问题也来了，如果使用Redis来做数据存储，那内存开销是相当大的，出于成本考虑我们一般只使用Redis来存储热点数据。
另外一方面，虽然Redis也支持数据持久化，但是Redis的数据查询能力很差而且事务支持不完善。这样一比较，在数据存储能力上，Redis远远比不上MySQL这类关系型数据库。
综上，Redis一般都是配合MySQL来使用的，也无法代替MySQL来做数据持久存储。
以上就是我的观点，对于这个问题大家是怎么看待的呢？欢迎在下方评论区交流 ~ 我是科技领域创作者，十年互联网从业经验，欢迎关注我了解更多科技知识！网络圈
Redis能不能代替MySQL进行数据存储？怎么样？
这个问题首先得分析应用的场景，技术本身是为业务服务的，不同的场景有着不同的解决方案。一项技术和另一项技术并没有好不好的区分，只有合不合适的区别。但是就目前的应用场景来说，大部分时候Redis是没有办法取代MySQL或其他关系型数据库的。
从两者差异性来看
- 类型
从两者的类型来看，MySQL属于关系型数据库，采用了关系模型来组织数据，由行和列构成，可以简单的理解为二维数组或表格。
而Redis属于非关系型数据库，大多数以哈希表中键值对的方式存储，非关系型数据库不保证满足ACID的特性。
- 存储
从存储来看，MySQL的数据存储在磁盘中，以InnorDB为例，数据库文件默认单页大小一般为16K，数据一般会以拆分开的文件形式存储在磁盘。
而Redis采用的是纯内存存储，内存的读写速度和寻址方式和磁盘相比有较大差异，这也是Redis为什么这么快和能达到较高并发的主要原因之一。
- 性能
从性能上来看，MySQL因为采用的是磁盘存储，不论是在读还是写的情况下都不能避免会进行磁盘寻址，所以从单命令的执行效率上来说，MySQL的性能还是和Redis有所差距的。但是，如果延伸到复杂的查询，那两者在性能上就各有所长了。
- 查询
MySQL采用的磁盘存储，本身关系型数据库的特征结合索引的方式，能更好的支持多种情况的复杂查询。以InnorDB引擎为例，其索引类型分为哈希索引和B+树索引。哈希索引的查询效率除了磁盘和内存的性能差距外，时间复杂度上并无其他差距。而B+树索引无论是聚簇索引还是非聚簇索引，MySQL对于持有索引的复杂条件查询，明显优于Redis。Redis是很难做到多条件或复杂条件查询的。
孰好孰坏
MySQL和Redis，实际上并不是谁取代谁的问题，现在的应用群来说，两者结合构建高容错、高并发的系统是两者之间最好的结合方式。
Redis性能卓越，往往被用来放置在MySQL集群之前增加系统整体的处理性能，挡住大量打往数据库的流量。
而MySQL因为查询、存储方面的优势，往往用于系统最为核心的存储和查找实现。Redis因为基于内存，所以在持久化上采用RDB和AOF两种方式，而我们往往两者相结合，但是在容差方面和MySQL天生的存储相比还是略显不足。
另外，由于Redis不保证具备ACID特性，在事务处理上会略显不足，虽然可以通过类似存储过程一次执行多个命令的方式实现事务，但是在回滚机制等处理上需要客户端进行约束，略显不足。
当然，实际场景中两者还有很多其他方面的差异，这里就不一一细说了，请参照使用场景。
使用场景
1. 热点数据
Redis往往用于存储热点且实时性要求略低的数据，用于拦截大部分的核心流量，从而降低数据库的IO瓶颈。
2. 频繁写
如果是频繁写的场景，Redis的用处明显不如频繁读。而且往往这种情况下我们还需要更多的考虑数据库和缓存间的数据同步，避免脏读等情况的产生。所以如果是频繁写的场景，如果是非实时性同步场景，队列的使用往往优先于缓存。
3. 分布式锁
就目前的分布式系统来说，Redis和Zookeeper通常是被用于分布式锁的方案，通过Redis的setNX命令和Redis集群的Redlock实现分布式锁，用于协同不同系统间对于同一资源的竞争。
4. 其他
除了以上，Redis还经常用于秒杀场景下的计数器、Set集合实现好友关系管理、SortSet实现排行榜、List实现简单队列等等功能。只要区分开了两者各自的优势和特点，运用在不同的场景之下，才能真正发挥不同技术最大的优势。
我是寻心湖，记得关注我。
寻心湖
Redis本身是支持数据持久化的，很多有些程序员都会觉得Redis应该可以替代MySQL，但是我们在使用一项技术的时候，不是看它能不能，而是要看它适合不适合；而在大部分场景下，Redis是无法替代MySQL的。
MySQL是关系型数据库，数据储存在磁盘上，数据的格式是我们熟知的二维表格的样式。关系型数据库具有很多强大的功能；大部分都支持SQL语句查询，对事务也有很好的支持。
Redis被称作非关系型数据库，属于内存数据库，数据都储存在内存中（Redis有RDB持久化策略），Redis支持的数据类型也比较多，比如字符串，HASH，List等。
MySQL和Redis没有竞争的关系，通常当并发访问量比较大的时候，特别是读操作很多，架构中可以引入Redis，帮助提升架构的整体性能，减少Mysql(或其他关系型数据库)的压力；
不是MySQL or Redis；而是MySQL + Redis ；
因为Redis的性能十分优越，可以支持每秒十几万此的读/写操作，并且它还支持持久化、集群部署、分布式、主从同步等，Redis在高并发的场景下数据的安全和一致性，所以它经常用于这些场景：
经常要被查询，但是CUD操作频率低的数据；比如数据字典，确定了之后很少被修改，是可以放到缓存中的；还有热点数据，查询极为频繁的数据，放到Redis中可以减少MySQL的压力；
经常被查询，但是实时性要求不高数据，比如购物网站的热销排行榜，定时统计一次后把统计结果放到Redis中提供查询（请不要每次都使用select top 10 from xxxx）。
缓存还可以做数据共享（Session共享），在分布式的架构中，把用户的Session数据放到Redis中。
高并发场景下的计数器，比如秒杀，把商品库存数量放到Redis中（秒杀的场景会比较复杂，Redis只是其中之一，例如如果请求超过某个数量的时候，多余的请求就会被限流）；
因为Redis对高并发的支持和单线程机智，它也经常用作分布式锁；
Redis虽然功能强大、性能高效，但是也不是万能的，项目在引入Redis的时候，需要考虑的问题也比较多，并且会带来额外的开发和运维的工作量。
首先要判断数据是否适合缓存到Redis中，可以从几个方面考虑：数据会被经常查询么？命中率如何？写操作多么？数据大小？数据一致性如何保证？
我们经常采用这样的方式将数据刷到Redis中：查询的请求过来，现在Redis中查询，如果查询不到，就查询数据库拿到数据，再放到缓存中，这样第二次相同的查询请求过来，就可以直接在Redis中拿到数据；不过要注意【缓存穿透】的问题。
缓存的刷新会比较复杂，通常是修改完数据库之后，还需要对Redis中的数据进行操作；代码很简单，但是需要保证这两步为同一事务，或最终的事务一致性。
我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。
会点代码的大叔
完全可以，但要注意几点：
一、REDIS的两种固化机制，RDB和AOF，都不适合存储大量数据，RDB是全量镜像数据越多对磁盘消耗越大。AOF是增量备份，读写效率比一般关系型数据库低。
二、REDIS运行时所有数据加载到内存中，数据不能无限增长，会耗尽内存，物理内存耗尽之后，Redis就没有速度优势了。
三、没有事务机制，没有数据完整性保障，不适合存放对完整性要求很高的数据。
光明右使8787
这个完全取决于你对数据的要求，是否允许丢失，还是必须要求不允许丢失。我觉得就可以直接存放redis.如果用户去网站买东西，这时候要记录用户的一个在网站操作的操作行为，（看了哪个商品、点击了哪个商品、点击了哪个按钮）日志，可以用来还原当时用户的操作行为这个日志的记录是可以放在redis的，但是用户下单、支付、配送信息等这些是要保持强一致性，并且不允许丢失的所以需要存入mysql.当用户下完单之后想看下自己的订单详情，这时候订单详情一些固定的信息也是可以放redis的，所以redis和mysql是可以结合一起使用的。什么事情都没有绝对的，完全取决于你的业务要求。是业务驱动技术。
JAVA
redis是不可以代替mysql进行数据存储的。redis和mysql不应该是竞争的关系，而是一对好基友。在实际工作中针对不同的场景，根据redis和mysql的各自优点采用不同的存储方案，合理的运用两者才能达到理想的效果。
NoSQL是“Not Only SQL”的意思，本质上是跟SQL形成互补关系的应用。
之所以有“redis是否可以代替mysql进行数据存储”这样的疑问，一定是有很多人认为redis是可以替代mysql的。我也不可否认，在特定的场景下或者说小型web服务的场景下，redis确实可以替代mysql做数据存储。但是这是有前提条件的，绝不能就可以说redis可以代替mysql进行数据存储的。
Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache and message broker. It supports data structures such as strings, hashes, lists, sets, sorted sets with range queries, bitmaps, hyperloglogs, geospatial indexes with radius queries and streams. Redis has built-in replication, Lua>上面是redis的官网描述，redis是一个基于BSD协议开源的内存数据库，可用作数据库、缓存和消息队列，支持strings、hashes、lists、sets、sorted sets、bitmaps...等等数据结构。
每一种数据结构都有适合自己的应用场景，熟悉运用redis的各种数据结构，确实让各位有一种错觉“redis可以替代mysql”。
redis是基于内存存储的，采用IO单路复用模型。一个字就是快！对于并发访问量比较高的场景，使用redis可以避免流量直接冲向数据库层。
下面是个人使用redis和mysql的一些心得：
redis存业务数据，mysql存更细粒度或者基于数据模型对象的数据，redis是中间缓存层，mysql是数据存储层。
mysql中like/in/and/or/join等数据查询检索redis是无法支持的，通常情况下，我们会以mysql数据为基础数据，然后通过一系列的策略或者job跑出业务数据放到redis中存储，这是二者结合使用的典型应用场景。
redis对事务的支持还是比较简单的，所以很多复杂的数据落库场景很难用redis去支持，即便可以支持，那也需要花费高昂的代价，这个时候你突然想起来有一个mysql好像可以完美的支持事务。
大部分的业务请求基本上就到redis这一层就结束了，如果查不到数据那就查不到，不会再去数据库里面去查了，所以也不用考虑“缓存穿透”的问题。
redis中存储的大部分数据是不过期的，所以也没有“缓存雪崩”的问题。
redis能够让你的业务运行的更快，mysql能够让你的数据更安全。
-
那么问题来了，如何保证redis中存储的业务数据能够与mysql中存储的数据保持一致呢？所以我们需要做一套数据一致性的方案来保证这个前提。
![]()
综上，MySQL和redis各自有各自的应用场景，掌握好他们的特性，在不同的场景下应用最适合的存储方案才是编码之道。
欢迎大家积极参与讨论，一起学习，共同成长~
java架构设计
不可以，存储数据类型不一样，都是开源数据库，用redis 代替mysql没意义
凯哥听说
可以，但是成本翻百倍，大型项目以TB为数据容量单位的。而且至少需要双热备，成本翻倍
小刘49568648
不可以！redis是nosql数据库，内存型，单线程，运行时数据暂存内存，而数据库数据是存放在硬盘！虽然有rdb、aof两种持久化，但也只是为了避免掉电数据丢失，而且内存容量也有限，并不能解决数据库的大量数据的持久化，更重要的是，redis虽然也支持事务，但不支持数据库的事务回滚机制，不具有任何维持原子性的机制，虽然也因为单线程的原因有原子性，但不具有数据库的原子性一致性隔离性持久性！
天之道居
不可以，redis存储在缓存空间临时性的，mysql存储在磁盘空间永久性的。
