架构选型,到底啥时候选redis?
来源:     阅读:514
云上智慧
发布于 2020-04-24 14:34
查看主页
架构选型,到底啥时候选redis?

redis是互联网分层架构中,最常用的KV缓存,但不少同学依然不知道,为啥要选择redis。

画外音:与之比照最多的,是memcache。

一、复杂数据结构,选择redis更合适

value是哈希,列表,集合,有序集合这类复杂的数据结构时,会选择redis,由于mc无法满足这些需求。

最典型的场景,客户订单列表,客户消息,帖子评论列表等。

二、持久化,选择redis更合适

mc无法满足持久化的需求,只得选择redis。

但是,这里要提示的是,真的使用对了redis的持久化功能么?

千万不要把redis当作数据库用:

(1)redis的定期快照不能保证数据不丢失;

(2)redis的AOF会降低效率,并且不能支持太大的数据量;

不要期望redis做固化存储会比mysql做得好,不同的工具做各自擅长的事情,把redis当作数据库用,这样的设计八成是错误的。

缓存场景,开启固化功能,有什么利弊?

假如只是缓存场景,数据存放在数据库,缓存在redis,此时假如开启固化功能:

优点是,redis挂了再重启,内存里能够快速恢复热数据,不会瞬时将压力压到数据库上,没有一个cache预热的过程。

缺点是,在redis挂了的过程中,假如数据库中有数据的修改,可能导致redis重启后,数据库与redis的数据不一致。

因而,只读场景,或者者允许少量不一致的业务场景,可以尝试开启redis的固化功能。

三、高可用,选择redis更合适

redis天然支持集群功能,可以实现主动复制,读写分离。

redis官方也提供了sentinel集群管理工具,能够实现主从服务监控,故障自动转移,这一切,对于用户端都是透明的,无需程序改动,也无需人工介入。

画外音:memcache,要想要实现高可用,需要进行二次开发,例如用户端的双读双写,或者者服务端的集群同步。

但是,这里要提示的是,大部分业务场景,缓存真的需要高可用么?

(1)缓存场景,很多时候,是允许cache miss;

(2)缓存挂了,很多时候可以通过DB读取数据;

所以,需要认真剖析业务场景,高可用,能否真的是对缓存的主要需求?

画外音:即时通讯业务中,客户的在线状态,就有高可用需求。

四、存储的内容比较大,选择redis更合适

memcache的value存储,最大为1M,假如存储的value很大,只能使用redis。

当然,redis与memcache相比,因为底层实现机制的差异,也有少量“劣势”的情况。

情况一:因为内存分配机制的差异,redis可能导致内存碎片

memcache使用预分配内存池的方式管理内存,能够省去内存分配时间。

redis则是临时申请空间,可能导致碎片。

从这一点上,mc会更快少量。

情况二:因为虚拟内存使用的差异,redis可能会刷盘影响性能

memcache把所有的数据存储在物理内存里。

redis有自己的VM机制,理论上能够存储比物理内存更多的数据,当数据超量时,会引发swap,把冷数据刷到磁盘上。Java学习圈子

从这一点上,数据量大时,mc会更快少量。

画外音:新版本redis已经优化。

情况三:因为网络模型的差异,redis可能会由于CPU计算影响IO调度

memcache使用非阻塞IO复用模型,redis也是使用非阻塞IO复用模型。

但因为redis还提供少量非KV存储之外的排序,聚合功能,在执行这些功能时,复杂的CPU计算,会阻塞整个IO调度。

从这一点上,因为redis提供的功能较多,mc会更快少量。

情况四:因为线程模型的差异,redis难以利用多核特效提升性能

memcache使用多线程,主线程监听,worker子线程接受请求,执行读写,这个过程中,可能存在锁冲突。

redis使用单线程,虽无锁冲突,但难以利用多核的特性提升整体吞吐量。

从这一点上,mc会快少量。

情况五:因为缺乏auto-sharding,redis只能手动水平扩展

不论是redis还是memcache,服务端集群没有天然支持水平扩展,需要在用户端进行分片,这其实对调用方并不友好。假如能服务端集群能够支持水平扩展,会更完美少量。

最后说一点,可能是很多人喜欢redis的起因之一:源码可读性高,代码质量很高。

看过redis和memcache的源码,从可读性上说,redis是我见过代码最清新的软件,甚至没有之一,或者许简单是redis设计的初衷,编译redis甚至不需要configure,不需要依赖第三方库,一个make就搞定了。

而memcache源码,可能是考虑了太多的扩展性,多系统的兼容性,代码不清新,看起来吃力。

例如网络IO的部分,redis源码1-2个文件就搞定了,mc使用了libevent,一个fd传过来传过去,又pipe又线程传递的,特别容易把人绕晕。

粉丝福利

最近我也根据上述的技术体系图搜集了几十套阿里、头条、蚂蚁金服等公司19年的面试题,把技术点整理成了视频(实际上比预期多花了不少精力),包含知识脉络 + 诸多细节,因为篇幅有限,这里以图片的形式给大家展现一部分。相信它会给大家带来很多收获。(更全的内容和资料,在文末获取)

Java架构进阶资源

架构选型,到底啥时候选redis?

分析源码

架构选型,到底啥时候选redis?

分布式架构

架构选型,到底啥时候选redis?

Java面试避坑指南

架构选型,到底啥时候选redis?

上图中的资料都是我精心录制视频,感兴趣的可以到我的Java学习圈子: 免费获取。希望能够在你接下来即将应对的的面试过程中能够尽到一份绵薄之力。

免责声明:本文为用户发表,不代表网站立场,仅供参考,不构成引导等用途。 系统环境 服务器应用
相关推荐
文件,视频随意下?“猴赛雷”的插件,用了能有多快乐?
egg.js之处理跨域问题(egg-cors)
如何学好HTML5?HTML5学习中的难点解析
Linux + Java 实现图文识别,图文提取
深度剖析 | 初学者应该如何学习前台?
首页
搜索
订单
购物车
我的