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

  • MySQL是关系型数据库，数据储存在磁盘上，数据的格式是我们熟知的二维表格的样式。关系型数据库具有很多强大的功能；大部分都支持SQL语句查询，对事务也有很好的支持。
  • Redis被称作非关系型数据库，属于内存数据库，数据都储存在内存中（Redis有RDB持久化策略），Redis支持的数据类型也比较多，比如字符串，HASH，List等。
  • MySQL和Redis没有竞争的关系，通常当并发访问量比较大的时候，特别是读操作很多，架构中可以引入Redis，帮助提升架构的整体性能，减少Mysql(或其他关系型数据库)的压力；
  • 不是MySQL or Redis；而是MySQL + Redis ；
     

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

  1. 经常要被查询，但是CUD操作频率低的数据；比如数据字典，确定了之后很少被修改，是可以放到缓存中的；还有热点数据，查询极为频繁的数据，放到Redis中可以减少MySQL的压力；
  2. 经常被查询，但是实时性要求不高数据，比如购物网站的热销排行榜，定时统计一次后把统计结果放到Redis中提供查询（请不要每次都使用select top 10 from xxxx）。
  3. 缓存还可以做数据共享（Session共享），在分布式的架构中，把用户的Session数据放到Redis中。
  4. 高并发场景下的计数器，比如秒杀，把商品库存数量放到Redis中（秒杀的场景会比较复杂，Redis只是其中之一，例如如果请求超过某个数量的时候，多余的请求就会被限流）；
  5. 因为Redis对高并发的支持和单线程机智，它也经常用作分布式锁；
     

Redis虽然功能强大、性能高效，但是也不是万能的，项目在引入Redis的时候，需要考虑的问题也比较多，并且会带来额外的开发和运维的工作量。

  1. 首先要判断数据是否适合缓存到Redis中，可以从几个方面考虑：数据会被经常查询么？命中率如何？写操作多么？数据大小？数据一致性如何保证？
  2. 我们经常采用这样的方式将数据刷到Redis中：查询的请求过来，现在Redis中查询，如果查询不到，就查询数据库拿到数据，再放到缓存中，这样第二次相同的查询请求过来，就可以直接在Redis中拿到数据；不过要注意【缓存穿透】的问题。
  3. 缓存的刷新会比较复杂，通常是修改完数据库之后，还需要对Redis中的数据进行操作；代码很简单，但是需要保证这两步为同一事务，或最终的事务一致性。