你不知道但会改变你使用它的方式-冷知识-Redis (你不知道但会说话英文)
前言
文章不是一篇具体教程,而是作者对 Redis 的一些思考。在初次接触 Redis 时,作者只是简单地使用了一些命令和背诵了一些面试题,就将 Redis 技能点添加到了自己的简历中。网络上有很多关于 Redis 具体知识点的讲解,但很少有人解释为什么会有这项技术。本文旨在总结作者目前对 Redis 的理解。
初识 Redis
作者最初通过网络上的项目教程了解到 Redis。教程提到将首页数据放入 Redis 可以加快访问速度。作者照做了,发现确实加载速度更快,于是便以为完成了任务。项目完成后,作者将 Redis 添加到简历中,并背诵了几道关于 Redis 数据类型和持久化机制的面试题,便开始寻找实习机会。
在面试中,当被问到为什么使用 Redis 时,作者按照教程中的说法回答了:因为 Redis 可以加快首页数据的加载,首页对产品很重要,加载越快,用户越满意。现在回想起来,这个回答虽然没有错误,但从技术面试的角度来看,应该从技术的角度进行回答。这也是促使作者撰写本文的动机之一。
为什么要有 Redis?
如果再次被问到为什么要使用 Redis,作者会从计算机的存储结构开始谈起。计算机有一幅关于存储结构的经典图片:
这张图展示了计算机存储器的金字塔结构,越上层的存储器存储效率越高,越下层的存储效率越低。内存位于磁盘之上,存储效率高于磁盘。而 Redis 是一个基于内存的存储系统,数据存储在内存中,这就是从 Redis 读取数据比从数据库读取数据快得多的根本原因。
看到这里,你可能会说,将数据存储在内存中没什么了不起的,你可以使用 Guava 或直接使用 HashMap,这些不都是基于内存的吗?这个问题让作者想起了在网上看到的一道面试题:如果让你设计一个缓存,你会怎么做?考虑一下 Guava 和 Map 集合在使用时的缺点。
很明显的一点是,虽然 Guava 和 Map 集合基于内存,但它们使用的是 JVM 的内存。如果 JVM 崩溃或重启,数据就会丢失。这让我们联想到 Redis 的持久化机制。Redis 的持久化机制能够将内存中的数据持久化到磁盘上,解决内存数据掉电易失的问题。Redis 是一款中间件,无需依赖于 JVM。
再换一个角度:既然数据库因为磁盘而慢,为什么不在内存中实现数据库呢?事实上,SAP 公司确实有基于内存的数据库系统。但是,使用内存有一个致命的缺点:昂贵!能够买得起这种软件和巨大内存机器的公司是少数。所以说,使用 Redis 的原因在于它在低效的磁盘和昂贵的内存之间取得了一个折中。
補充:面试时还被问到一个问题:Redis 的内存淘汰机制。这其实是一个很常见的考点:Redis 将数据存储在内存中,而内存空间是有限的,总会有用完的一天。当内存用完后,肯定需要有相应的内存淘汰策略来释放内存。
关于 Redis 的主从复制
在服务器端,Redis 使用了主从复制架构。主服务器存储数据并处理写请求,而从服务器从主服务器同步数据,并处理读请求。这种架构提供了以下优点:
- 提高读性能: 读请求可以分流到从服务器上,缓解了主服务器的压力,提高了读性能。
- 数据冗余: 如果主服务器发生故障,从服务器可以继续提供服务,保证数据不会丢失。
- 弹性伸缩: 可以根据业务需求随时添加或删除从服务器,实现弹性伸缩。
需要注意的是,主从复制存在一个复制延迟问题,即从服务器的数据可能与主服务器的最新数据存在一定的延迟。这个延迟可以通过调整复制策略来优化,但不能完全消除。
Redis Sentinel
Redis Sentinel 作为 Redis 的高可用解决方案,负责监控 Redis 服务器集群,并在主服务器故障时自动进行故障转移,保证服务的连续性。Sentinel 主要具有以下功能:
- 监控: Sentinel 会持续监控 Redis 服务器的健康状态,包括 ping、info 命令的响应时间、主从复制状态等。
- 故障转移: 如果 Sentinel 检测到主服务器故障,它会触发故障转移,选择一个健康的从服务器提升为主服务器,并重新配置集群。
- 高可用性: Sentinel 本身采用集群模式,保证了高可用性,防止单点故障导致整个集群不可用。
使用 Redis Sentinel 可以大大提高 Redis 集群的高可用性,保证业务的连续性,避免因主服务器故障导致服务中断。
![冷知识](https://tyye.cn/zb_users/theme/tpure/style/images/lazyload.png)
结论
Redis 作为一款优秀的内存数据库,在缓存、消息队列、会话管理等场景中有着广泛的应用。它通过将数据存储在内存中,显著提高了数据访问速度。同时,Redis 的主从复制机制提供了数据冗余和读写分离,实现高性能和高可用性。Redis Sentinel 为 Redis 集群提供了故障转移和高可用性保障,确保服务的连续性。
在了解 Redis 的基本原理和应用场景后,开发者可以根据业务需求选择合适的 Redis 部署方案,充分发挥 Redis 的优势,提升应用性能和可靠性。
Redis应用场景?
Redis实际应用场景1、显示最新的项目列表下面这个语句常用来显示最新项目,随着数据多了,查询毫无疑问会越来越慢。 SELECT FROM fOO WHERE ORDER BY time DESC LIMIT 10在Web应用中,“列出最新的回复”之类的查询非常普遍,这通常会带来可扩展性问题。 这令人沮丧,因为项目本来就是按这个顺序被创建的,但要输出这个顺序却不得不进行排序操作。 类似的问题就可以用Redis来解决。 比如说,我们的一个Web应用想要列出用户贴出的最新20条评论。 在最新的评论边上我们有一个“显示全部”的链接,点击后就可以获得更多的评论。 我们假设数据库中的每条评论都有一个唯一的递增的ID字段。 我们可以使用分页来制作主页和评论页,使用Redis的模板,每次新评论发表时,我们会将它的ID添加到一个Redis列表:LPUSH <ID>我们将列表裁剪为指定长度,因此Redis只需要保存最新的5000条评论:LTRIM 0 5000每次我们需要获取最新评论的项目范围时,我们调用一个函数来完成(使用伪代码):FUNCTION get_latest_comments(start,num_items):id list =(,start,start+num items -1) IF id <num itemsid list = SQL DB(SELECT ... ORDER BY time LIMIT ...) ENDRETURN id list END这里我们做的很简单。 在Redis中我们的最新ID使用了常驻缓存,这是一直更新的。 但是我们做了限制不能超过5000个ID,因此我们的获取ID函数会一直询问Redis。 只有在start/count参数超出了这个范围的时候,才需要去访问数据库。 我们的系统不会像传统方式那样“刷新”缓存,Redis实例中的信息永远是一致的。 SQL数据库(或是硬盘上的其他类型数据库)只是在用户需要获取“很远”的数据时才会被触发,而主页或第一个评论页是不会麻烦到硬盘上的数据库了。
Redis 和 Memcached 各有什么优缺点,主要的应用场景是什么样的
Redis的作者Salvatore Sanfilippo曾经对这两种基于内存的数据存储系统进行过比较:
1、Redis支持服务器端的数据操作:Redis相比Memcached来说,拥有更多的数据结构和并支持更丰富的数据操作,通常在Memcached里,你需要将数据拿到客户端来进行类似的修改再set回去。这大大增加了网络IO的次数和数据体积。在Redis中,这些复杂的操作通常和一般的GET/SET一样高效。所以,如果需要缓存能够支持更复杂的结构和操作,那么Redis会是不错的选择。
2、内存使用效率对比:使用简单的key-value存储的话,Memcached的内存利用率更高,而如果Redis采用hash结构来做key-value存储,由于其组合式的压缩,其内存利用率会高于Memcached。
3、性能对比:由于Redis只使用单核,而Memcached可以使用多核,所以平均每一个核上Redis在存储小数据时比Memcached性能更高。而在100k以上的数据中,Memcached性能要高于Redis,虽然Redis最近也在存储大数据的性能上进行优化,但是比起Memcached,还是稍有逊色。
具体为什么会出现上面的结论,以下为收集到的资料:
1、数据类型支持不同
与Memcached仅支持简单的key-value结构的数据记录不同,Redis支持的数据类型要丰富得多。最为常用的数据类型主要由五种:String、Hash、List、Set和Sorted Set。Redis内部使用一个redisObject对象来表示所有的key和value。redisObject最主要的信息如图所示:
type代表一个value对象具体是何种数据类型,encoding是不同数据类型在redis内部的存储方式,比如:type=string代表value存储的是一个普通字符串,那么对应的encoding可以是raw或者是int,如果是int则代表实际redis内部是按数值型类存储和表示这个字符串的,当然前提是这个字符串本身可以用数值表示,比如:”123″ “456”这样的字符串。只有打开了Redis的虚拟内存功能,vm字段字段才会真正的分配内存,该功能默认是关闭状态的。
免责声明:本文转载或采集自网络,版权归原作者所有。本网站刊发此文旨在传递更多信息,并不代表本网赞同其观点和对其真实性负责。如涉及版权、内容等问题,请联系本网,我们将在第一时间删除。同时,本网站不对所刊发内容的准确性、真实性、完整性、及时性、原创性等进行保证,请读者仅作参考,并请自行核实相关内容。对于因使用或依赖本文内容所产生的任何直接或间接损失,本网站不承担任何责任。