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开发、架构设计、程序员职业发展等方面的见解,希望能得到你的关注。Copyright © 广州京杭网络科技有限公司 2005-2024 版权所有 粤ICP备16019765号
广州京杭网络科技有限公司 版权所有