redis持久化是否会影响效率

其实redis持久化是否会影响效率的问题并不复杂，但是又很多的朋友都不太了解不建议redis做持久化，因此呢，今天小编就来为大家分享redis持久化是否会影响效率的一些知识，希望可以帮助到大家，下面我们一起来看看这个问题的分析吧！

本文目录

1. redis持久化是否会影响效率
2. 如何改变Redis用不好的误区
3. 数据多的时候为什么要使用redis而不用mysql
4. redis优势这么多,为什么没有吧memcache干掉

redis持久化是否会影响效率

会影响效率还得存储磁盘

如何改变Redis用不好的误区

这个问题有些尴尬，用不好的原因很多，很难一一列举出来，但想用好确实需要一些准备工作：

1.加深对Redis的理解

a.redis可以看成一个很大的map，特殊的事value可以有多种数据类型

b.针对redis所支持的数据类型，提供了一组相关操作

c.redis单进程、单线程，CPU资源使用率不高（集中、集群部署可以解决这个问题），不适合做过多的计算

d.提供了多种自动清理机制

e.提供多种持久化机制

....

2.尽量使用较高级的Redis客户端

尽量避免使用低级的Redis接口，低级接口对使用者的要求偏高，容易出现问题（忘记将redis链接放回连接池），在java中，优先使用spring-data-redis相关接口，特别的是RedisTemplate的时候；如果需要基于Redis构建特殊的数据结构（队列、锁），优先使用Lettuce

数据多的时候为什么要使用redis而不用mysql

通常来说，当数据多、并发量大的时候，架构中可以引入Redis，帮助提升架构的整体性能，减少Mysql(或其他数据库)的压力，但不是使用Redis，就不用MySQL。

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

缓存

经常会被查询，但是不经常被修改或者删除的数据；比如数据字典，业务数据中的热点数据；这样不仅提升查询效率，还可以减少数据库的压力；

经常被查询，实时性要求不高数据，比如网站的最新列表、排行榜之类的数据，只需要定时统计一次，然后把统计结果放到Redis中提供查询（请不要使用selecttop10fromxxxx）。

缓存可以方便数据共享，比如我先用电脑网页打开X东，选了两件商品放到购物车里面，再登录手机APP，也是可以看到购物车里面的商品的。

判断数据是否适合缓存到Redis中，可以从几个方面考虑：会经常查询么？命中率如何？写操作多么？数据大小？

我们经常采用这样的方式将数据刷到Redis中：查询的请求过来，现在Redis中查询，如果查询不到，就查询数据库拿到数据，再放到缓存中，这样第二次相同的查询请求过来，就可以直接在Redis中拿到数据；不过要注意【缓存穿透】的问题。

缓存的刷新会比较复杂，通常是修改完数据库之后，还需要对Redis中的数据进行操作；代码很简单，但是需要保证这两步为同一事务，或最终的事务一致性。

高速读写

常见的就是计数器，比如一篇文章的阅读量，不可能每一次阅读就在数据库里面update一次。

高并发的场景很适合使用Redis，比如双11秒杀，库存一共就一千件，到了秒杀的时间，通常会在极为短暂的时间内，有数万级的请求达到服务器，如果使用数据库的话，很可能在这一瞬间造成数据库的崩溃，所以通常会使用Redis（秒杀的场景会比较复杂，Redis只是其中之一，例如如果请求超过某个数量的时候，多余的请求就会被限流）。

这种高并发的场景，是当请求达到服务器的时候，直接在Redis上读写，请求不会访问到数据库；程序会在合适的时间，比如一千件库存都被秒杀，再将数据批量写到数据库中。

所以通常来说，在必要的时候引入Redis，可以减少MySQL（或其他）数据库的压力，两者不是替代的关系。

我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。

redis优势这么多,为什么没有吧memcache干掉

两者虽然有着子集的关系，但不得不说还有存在很多不同，而且彼此不能互相替代。就像有些面试官会问你【为什么要使用redis】的问题，也是因为有些场合，是根本不需要用到redis，或者说没必要用到哦。

简单说，这两者都是基于内存的数据缓存系统，我认为memcache实现的存储功能是redis的子集，即memcache能实现的存储，redis也能做到，但反之则不行。

比如说，memcache只支持简单的key/value数据结构，但是redis除了String外，还支持list、dict、set、zset、hyperloglog等等数据结构的存储。

其他的类似redis的持久化、redis的读写效率、redis的快照功能，都是比memcache要强大且完善的功能，但为何memcache还是存在，且有很多项目还是使用呢？

其主要的原因，在我看来，是因为场景的需要，比如：

1）项目中使用缓存存储时，只会对String数据结构进行存储，但redis在存储String类型时，会耗费更多的内存，我们需要对数据转换为dict来进行存储的压缩，从而减低内存损耗，在这种情况下，我会优先考虑memcache。

2）redis只支持单线程，其性能受限于CPU性能，即取决于数据结构、数据大小以及服务器硬件性能，其在日常环节中的QPS高峰约为1-2w，而memcache具有多核优势，其单实例的吞吐量极高，性能主要取决于存储的key及value的字节大小以及服务器硬件性能，其在日常环节中的QPS高峰约为4-6w。（但有意思的时，即使如此，memcache的性能比起redis，在实际业务中并没有好多少，但如果看过源码的人会发现，redis的源码及其精致！而memcache的源码则稍显臃肿，可能这一块也会有一定的影响呢？）

总的说：一昧的使用redis来进行数据缓存系统，并不是最佳的选择，如果项目根本就不需要复杂的数据结构呢？如果项目的数据只有一小部分使用了缓存，根本不需要使用持久化和备份呢？如果项目不需要在服务器之间进行数据同步呢？在诸如此类情况下，使用redis反而是增加项目成本，杀鸡焉用宰牛刀~

——没事待在家里不出门的居家程序员敲上。（我不想脱发！）

关于本次redis持久化是否会影响效率和不建议redis做持久化的问题分享到这里就结束了，如果解决了您的问题，我们非常高兴。