韩淼燃
最近在更新运维专栏。欢迎大家来点赞,关注。
展开
-
Redis6.0的新特性:多线程、客户端缓存与安全
Redis官方在今年5月份正式推出了6.0版本,这个版本中有很多的新特性。所以,6.0刚刚推出,就受到了业界的广泛关注。所以,在课程的最后,我特意安排了这节课,想来和你聊聊Redis6.0中的几个关键新特性,分别是面向网络处理的多IO线程、客户端缓存、细粒度的权限控制,以及RESP3协议的使用。其中,面向网络处理的多IO线程可以提高网络请求处理的速度,而客户端缓存可以让应用直接在客户端本地读取数据,这两个特性可以提升Redis的性能。......原创 2022-07-19 14:18:10 · 499 阅读 · 0 评论 -
通信开销:限制RedisCluster规模的关键因素
RedisCluster能保存的数据量以及支撑的吞吐量,跟集群的实例规模密切相关。Redis官方给出了RedisCluster的规模上限,就是一个集群运行1000个实例。那么,你可能会问,为什么要限定集群规模呢?其实,这里的一个关键因素就是,,在集群超过一定规模时(比如800节点),集群吞吐量反而会下降。所以,集群的实际规模会受到限制。今天这节课,我们就来聊聊,集群实例间的通信开销是如何影响RedisCluster规模的,以及如何降低实例间的通信开销。...原创 2022-07-19 11:45:07 · 250 阅读 · 0 评论 -
数据分布优化:如何应对数据倾斜?
在切片集群中,数据会按照一定的分布规则分散到不同的实例上保存。比如,在使用RedisCluster或Codis时,数据都会先按照CRC算法的计算值对Slot(逻辑槽)取模,同时,所有的Slot又会由运维管理员分配到不同的实例上。这样,数据就被保存到相应的实例上了。虽然这种方法实现起来比较简单,但是很容易导致一个问题数据倾斜。数据倾斜有两类。如果发生了数据倾斜,那么保存了大量数据,或者是保存了热点数据的实例的处理压力就会增大,速度变慢,甚至还可能会引起这个实例的内存资源耗尽,从而崩溃。...原创 2022-07-19 11:31:30 · 423 阅读 · 0 评论 -
Redis支撑秒杀场景的关键技术和实践都有哪些?
秒杀是一个非常典型的活动场景,比如,在双11、618等电商促销活动中,都会有秒杀场景。秒杀场景的业务特点是,业务系统要处理瞬时的大量高并发请求,而Redis就经常被用来支撑秒杀活动。不过,秒杀场景包含了多个环节,可以分成秒杀前、秒杀中和秒杀后三个阶段,每个阶段的请求处理需求并不相同,Redis并不能支撑秒杀场景的每一个环节。那么,Redis具体是在秒杀场景的哪个环节起到支撑作用的呢?又是如何支持的呢?...原创 2022-07-19 10:15:05 · 334 阅读 · 0 评论 -
CodisVSRedisCluster:我该选择哪一个集群方案?
Redis的切片集群使用多个实例保存数据,能够很好地应对大数据量的场景。在第八课中,我们学习了Redis官方提供的切片集群方案RedisCluster,这为你掌握切片集群打下了基础。今天,我再来带你进阶一下,我们来学习下RedisCluster方案正式发布前,业界已经广泛使用的Codis。我会具体讲解Codis的关键技术实现原理,同时将Codis和RedisCluster进行对比,帮你选出最佳的集群方案。好了,话不多说,我们先来学习下Codis的整体架构和流程。...原创 2022-07-18 19:46:33 · 306 阅读 · 0 评论 -
脑裂:一次奇怪的数据丢失
在使用主从集群时,我曾遇到过这样一个问题我们的主从集群有1个主库、5个从库和3个哨兵实例,在使用的过程中,我们发现客户端发送的一些数据丢失了,这直接影响到了业务层的数据可靠性。通过一系列的问题排查,我们才知道,这其实是主从集群中的脑裂问题导致的。所谓的脑裂,就是指在主从集群中,同时有两个主节点,它们都能接收写请求。而脑裂最直接的影响,就是客户端不知道应该往哪个主节点写入数据,结果就是不同的客户端会往不同的主节点上写入数据。而且,严重的话,脑裂会进一步导致数据丢失。那么,主从集群中为什么会发生脑裂?...原创 2022-07-18 15:41:36 · 182 阅读 · 0 评论 -
Redis主从同步与故障切换,有哪些坑?
Redis的主从同步机制不仅可以让从库服务更多的读请求,分担主库的压力,而且还能在主库发生故障时,进行主从库切换,提供高可靠服务。不过,在实际使用主从机制的时候,我们很容易踩到一些坑。这节课,我就向你介绍3个坑,分别是主从数据不一致、读到过期数据,以及配置项设置得不合理从而导致服务挂掉。一旦踩到这些坑,业务应用不仅会读到错误数据,而且很可能会导致Redis无法正常使用,我们必须要全面地掌握这些坑的成因,提前准备一套规避方案。不过,即使不小心掉进了陷阱里,也不要担心,我还会给你介绍相应的解决方案。...原创 2022-07-18 15:10:32 · 385 阅读 · 0 评论 -
事务机制:Redis能实现ACID属性吗?
事务是数据库的一个重要功能。所谓的事务,就是指对数据进行读写的一系列操作。事务在执行时,会提供专门的属性保证,包括原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)和持久性(Durability),也就是ACID属性。这些属性既包括了对事务执行结果的要求,也有对数据库在事务执行前后的数据状态变化的要求。那么,Redis可以完全保证ACID属性吗?...原创 2022-07-18 10:48:52 · 171 阅读 · 0 评论 -
如何使用Redis实现分布式锁?
上节课,我提到,在应对并发问题时,除了原子操作,Redis客户端还可以通过加锁的方式,来控制并发写操作对共享数据的修改,从而保证数据的正确性。但是,Redis属于分布式系统,当有多个客户端需要争抢锁时,我们必须要保证,这把锁不能是某个客户端本地的锁。否则的话,其它客户端是无法访问这把锁的,当然也就不能获取这把锁了。所以,在分布式系统中,当有多个客户端需要获取锁时,我们需要分布式锁。此时,锁是保存在一个共享存储系统中的,可以被多个客户端共享访问和获取。Redis本身可以被多个客户端共享访问,正好就是一个共享存原创 2022-07-14 17:28:31 · 270 阅读 · 0 评论 -
无锁的原子操作:Redis如何应对并发访问?
我们在使用Redis时,不可避免地会遇到并发访问的问题,比如说如果多个用户同时下单,就会对缓存在Redis中的商品库存并发更新。一旦有了并发写操作,数据就会被修改,如果我们没有对并发写请求做好控制,就可能导致数据被改错,影响到业务的正常使用(例如库存数据错误,导致下单异常)。为了保证并发访问的正确性,Redis提供了两种方法,分别是加锁和原子操作。加锁是一种常用的方法,在读取数据前,客户端需要先获得锁,否则就无法进行操作。当一个客户端获得锁后,就会一直持有这把锁,直到客户端完成数据更新,才释放这把锁。看上去原创 2022-07-14 10:34:39 · 259 阅读 · 0 评论 -
Pika-如何基于SSD实现大容量Redis?
我们在应用Redis时,随着业务数据的增加(比如说电商业务中,随着用户规模和商品数量的增加),就需要Redis能保存更多的数据。你可能会想到使用Redis切片集群,把数据分散保存到多个实例上。但是这样做的话,会有一个问题,如果要保存的数据总量很大,但是每个实例保存的数据量较小的话,就会导致集群的实例规模增加,这会让集群的运维管理变得复杂,增加开销。你可能又会说,我们可以通过增加Redis单实例的内存容量,形成大内存实例,每个实例可以保存更多的数据,这样一来,在保存相同的数据总量时,所需要的大内存实例的个数就原创 2022-07-13 10:57:50 · 270 阅读 · 0 评论 -
Redis缓存被污染了,该怎么办?
我们应用Redis缓存时,如果能缓存会被反复访问的数据,那就能加速业务应用的访问。但是,如果发生了缓存污染,那么,缓存对业务应用的加速作用就减少了。那什么是缓存污染呢?在一些场景下,有些数据被访问的次数非常少,甚至只会被访问一次。当这些数据服务完访问请求后,如果还继续留存在缓存中的话,就只会白白占用缓存空间。这种情况,就是缓存污染。当缓存污染不严重时,只有少量数据占据缓存空间,此时,对缓存系统的影响不大。但是,缓存污染一旦变得严重后,就会有大量不再访问的数据滞留在缓存中。如果这时数据占满了缓存空间,我们再往原创 2022-07-12 10:57:08 · 275 阅读 · 0 评论 -
缓存异常(下):如何解决缓存雪崩、击穿、穿透难题?
上节课,我们学习了缓存和数据库的数据不一致问题和应对方法。除了数据不一致问题,我们常常还会面临缓存异常的三个问题,分别是缓存雪崩、缓存击穿和缓存穿透。这三个问题一旦发生,会导致大量的请求积压到数据库层。如果请求的并发量很大,就会导致数据库宕机或是故障,这就是很严重的生产事故了。这节课,我就来和你聊聊这三个问题的表现、诱发原因以及解决方法。俗话说,知己知彼,百战不殆。了解了问题的成因,我们就能够在应用Redis缓存时,进行合理的缓存设置,以及相应的业务应用前端设置,提前做好准备。接下来,我们就先看下缓原创 2022-03-21 14:51:01 · 314 阅读 · 0 评论 -
缓存异常(上):如何解决缓存和数据库的数据不一致问题?
在实际应用Redis缓存时,我们经常会遇到一些异常问题,概括来说有4个方面:缓存中的数据和数据库中的不一致;缓存雪崩;缓存击穿和缓存穿透。只要我们使用Redis缓存,就必然会面对缓存和数据库间的一致性保证问题,这也算是Redis缓存应用中的“必答题”了。最重要的是,如果数据不一致,那么业务应用从缓存中读取的数据就不是最新数据,这会导致严重的错误。比如说,我们把电商商品的库存信息缓存在Redis中,如果库存信息不对,那么业务层下单操作就可能出错,这当然是不能接受的。所以,这节课我就重点和你聊聊这个问题。关原创 2022-03-21 14:48:09 · 579 阅读 · 0 评论 -
替换策略:缓存满了怎么办?
Redis缓存使用内存来保存数据,避免业务应用从后端数据库中读取数据,可以提升应用的响应速度。那么,如果我们把所有要访问的数据都放入缓存,是不是一个很好的设计选择呢?其实,这样做的性价比反而不高。举个例子吧。MySQL中有1TB的数据,如果我们使用Redis把这1TB的数据都缓存起来,虽然应用都能在内存中访问数据了,但是,这样配置并不合理,因为性价比很低。一方面,1TB内存的价格大约是3.5万元,而1TB磁盘的价格大约是1000元。另一方面,数据访问都是有局部性的,也就是我们通常所说的“八二原理”,80原创 2022-03-21 14:46:52 · 236 阅读 · 0 评论 -
旁路缓存:Redis是如何⼯作的?
我们知道,Redis提供了⾼性能的数据存取功能,所以⼴泛应⽤在缓存场景中,既能有效地提升业务应⽤的 响应速度,还可以避免把⾼并发⼤压⼒的请求发送到数据库层。但是,如果Redis做缓存时出现了问题,⽐如说缓存失效,那么,⼤量请求就会直接积压到数据库层,必然 会给数据库带来巨⼤的压⼒,很可能会导致数据库宕机或是故障,那么,业务应⽤就没有办法存取数据、响 应⽤⼾请求了。这种⽣产事故,肯定不是我们希望看到的。正因为Redis⽤作缓存的普遍性以及它在业务应⽤中的重要作⽤,所以,我们需要系统地掌握缓存的⼀系列原创 2022-03-21 14:44:30 · 217 阅读 · 0 评论 -
缓冲区:一个可能引发“惨案”的地方
缓冲区的功能其实很简单,主要就是用一块内存空间来暂时存放命令数据,以免出现因为数据和命令的处理速度慢于发送速度而导致的数据丢失和性能问题。但因为缓冲区的内存空间有限,如果往里面写入数据的速度持续地大于从里面读取数据的速度,就会导致缓冲区需要越来越多的内存来暂存数据。当缓冲区占用的内存超出了设定的上限阈值时,就会出现缓冲区溢出。如果发生了溢出,就会丢数据了。那是不是不给缓冲区的大小设置上限,就可以了呢?显然不是,随着累积的数据越来越多,缓冲区占用内存空间越来越大,一旦耗尽了Redis实例所在机器的可用内存原创 2022-01-12 10:43:21 · 170 阅读 · 0 评论 -
删除数据后,为什么内存占用率还是很高?
在使用Redis时,我们经常会遇到这样一个问题:明明做了数据删除,数据量已经不大了,为什么使用top命令查看时,还会发现Redis占用了很多内存呢?实际上,这是因为,当数据删除后,Redis释放的内存空间会由内存分配器管理,并不会立即返回给操作系统。所以,操作系统仍然会记录着给Redis分配了大量内存。但是,这往往会伴随一个潜在的风险点:Redis释放的内存空间可能并不是连续的,那么,这些不连续的内存空间很有可能处于一种闲置的状态。这就会导致一个问题:虽然有空闲空间,Redis却无法用来保存数据,不原创 2022-01-11 17:11:21 · 393 阅读 · 0 评论 -
波动的响应延迟:如何应对变慢的Redis?(下)
上节课,我介绍了判断Redis变慢的两种方法,分别是响应延迟和基线性能。除此之外,我还给你分享了从Redis的自身命令操作层面排查和解决问题的两种方案。但是,如果在排查时,你发现Redis没有执行大量的慢查询命令,也没有同时删除大量过期keys,那么,我们是不是就束手无策了呢?当然不是!我还有很多“锦囊妙计”,准备在这节课分享给你呢!如果上节课的方法不管用,那就说明,你要关注影响性能的其他机制了,也就是文件系统和操作系统。Redis会持久化保存数据到磁盘,这个过程要依赖文件系统来完成,所以,原创 2022-01-11 16:08:07 · 531 阅读 · 0 评论 -
波动的响应延迟:如何应对变慢的Redis?(上)
在Redis的实际部署应用中,有一个非常严重的问题,那就是Redis突然变慢了。一旦出现这个问题,不仅会直接影响用户的使用体验,还可能会影响到“旁人”,也就是和Redis在同一个业务系统中的其他系统,比如说数据库。举个小例子,在秒杀场景下,一旦Redis变慢了,大量的用户下单请求就会被拖慢,也就是说,用户提交了下单申请,却没有收到任何响应,这会给用户带来非常糟糕的使用体验,甚至可能会导致用户流失。而且,在实际生产环境中,Redis往往是业务系统中的一个环节(例如作为缓存或是作为数据库)。一旦Redi原创 2022-01-11 11:28:51 · 229 阅读 · 0 评论 -
为什么CPU结构也会影响Redis的性能?
很多人都认为Redis和CPU的关系很简单,就是Redis的线程在CPU上运行,CPU快,Redis处理请求的速度也很快。这种认知其实是片面的。CPU的多核架构以及多CPU架构,也会影响到Redis的性能。如果不了解CPU对Redis的影响,在对Redis的性能进行调优时,就可能会遗漏一些调优方法,不能把Redis的性能发挥到极限。今天,我们就来学习下目前主流服务器的CPU架构,以及基于CPU多核架构和多CPU架构优化Redis性能的方法。主流的CPU架构要了解CPU对Redis具体有什么影原创 2021-12-29 16:36:47 · 186 阅读 · 0 评论 -
异步机制:如何避免单线程模型的阻塞?
Redis之所以被广泛应用,很重要的一个原因就是它支持高性能访问。也正因为这样,我们必须要重视所有可能影响Redis性能的因素(例如命令操作、系统配置、关键机制、硬件配置等),不仅要知道具体的机制,尽可能避免性能异常的情况出现,还要提前准备好应对异常的方案。所以,从这节课开始,我会用6节课的时间介绍影响Redis性能的5大方面的潜在因素,分别是:Redis内部的阻塞式操作; CPU核和NUMA架构的影响; Redis关键系统配置; Redis内存碎片; Redis缓冲区。这节课,我们就先学原创 2021-11-10 13:34:31 · 260 阅读 · 0 评论 -
消息队列的考验:Redis有哪些解决方案?
现在的互联网应用基本上都是采用分布式系统架构进行设计的,而很多分布式系统必备的一个基础软件就是消息队列。消息队列要能支持组件通信消息的快速读写,而Redis本身支持数据的高速访问,正好可以满足消息队列的读写性能需求。不过,除了性能,消息队列还有其他的要求,所以,很多人都很关心一个问题:“Redis适合做消息队列吗?”其实,这个问题的背后,隐含着两方面的核心问题:消息队列的消息存取需求是什么? Redis如何实现消息队列的需求?这节课,我们就来聊一聊消息队列的特征和Redis提供的消息队列方案原创 2021-10-27 15:24:25 · 413 阅读 · 0 评论 -
redis如何在Redis中保存时间序列数据?
我们现在做互联网产品的时候,都有这么一个需求:记录用户在网站或者App上的点击行为数据,来分析用户行为。这里的数据一般包括用户ID、行为类型(例如浏览、登录、下单等)、行为发生的时间戳:UserID, Type, TimeStamp我之前做过的一个物联网项目的数据存取需求,和这个很相似。我们需要周期性地统计近万台设备的实时状态,包括设备ID、压力、温度、湿度,以及对应的时间戳:DeviceID, Pressure, Temperature, Humidity, TimeStamp这些原创 2021-10-25 16:05:25 · 483 阅读 · 0 评论 -
Redis,GEO是什么?还可以定义新的数据类型吗?
在第二讲中,我们学习了Redis的5大基本数据类型:String、List、Hash、Set和Sorted Set,它们可以满足大多数的数据存储需求,但是在面对海量数据统计时,它们的内存开销很大,而且对于一些特殊的场景,它们是无法支持的。所以,Redis还提供了3种扩展数据类型,分别是Bitmap、HyperLogLog和GEO。前两种我在上节课已经重点介绍过了,今天,我再具体讲一讲GEO。另外,我还会给你介绍开发自定义的新数据类型的基本步骤。掌握了自定义数据类型的开发方法,当你面临一些复杂的场景时,就原创 2021-10-25 15:19:59 · 401 阅读 · 0 评论 -
Redis有一亿个keys要统计,应该用哪种集合?
在Web和移动应用的业务场景中,我们经常需要保存这样一种信息:一个key对应了一个数据集合。我举几个例子。手机App中的每天的用户登录信息:一天对应一系列用户ID或移动设备ID; 电商网站上商品的用户评论列表:一个商品对应了一系列的评论; 用户在手机App上的签到打卡信息:一天对应一系列用户的签到记录; 应用网站上的网页访问信息:一个网页对应一系列的访问点击。我们知道,Redis集合类型的特点就是一个键对应一系列的数据,所以非常适合用来存取这些数据。但是,在这些场景中,除了记录信息,我们往往还需原创 2021-10-21 15:59:57 · 289 阅读 · 0 评论 -
redis“万金油”的String,为什么不好用了?
从今天开始,我们就要进入“实践篇”了。接下来,我们会用5节课的时间学习“数据结构”。我会介绍节省内存开销以及保存和统计海量数据的数据类型及其底层数据结构,还会围绕典型的应用场景(例如地址位置查询、时间序列数据库读写和消息队列存取),跟你分享使用Redis的数据类型和module扩展功能来满足需求的具体方案。今天,我们先了解下String类型的内存空间消耗问题,以及选择节省内存开销的数据类型的解决方案。先跟你分享一个我曾经遇到的需求。当时,我们要开发一个图片存储系统,要求这个系统能快速地记录图片I原创 2021-10-21 15:26:32 · 258 阅读 · 0 评论 -
redis切片集群:数据增多了,是该加内存还是加实例?
我曾遇到过这么一个需求:要用Redis保存5000万个键值对,每个键值对大约是512B,为了能快速部署并对外提供服务,我们采用云主机来运行Redis实例,那么,该如何选择云主机的内存容量呢?我粗略地计算了一下,这些键值对所占的内存空间大约是25GB(5000万*512B)。所以,当时,我想到的第一个方案就是:选择一台32GB内存的云主机来部署Redis。因为32GB的内存能保存所有数据,而且还留有7GB,可以保证系统的正常运行。同时,我还采用RDB对数据做持久化,以确保Redis实例故障后,还能从RDB原创 2021-10-20 17:11:45 · 176 阅读 · 0 评论 -
redis哨兵集群:哨兵挂了,主从库还能切换吗?
上节课,我们学习了哨兵机制,它可以实现主从库的自动切换。通过部署多个实例,就形成了一个哨兵集群。哨兵集群中的多个实例共同判断,可以降低对主库下线的误判率。但是,我们还是要考虑一个问题:如果有哨兵实例在运行时发生了故障,主从库还能正常切换吗?实际上,一旦多个实例组成了哨兵集群,即使有哨兵实例出现故障挂掉了,其他哨兵还能继续协作完成主从库切换的工作,包括判定主库是不是处于下线状态,选择新主库,以及通知从库和客户端。如果你部署过哨兵集群的话就会知道,在配置哨兵的信息时,我们只需要用到下面的这个配置项,原创 2021-10-14 17:20:01 · 144 阅读 · 0 评论 -
redis哨兵机制:主库挂了,如何不间断服务?
上节课,我们学习了主从库集群模式。在这个模式下,如果从库发生故障了,客户端可以继续向主库或其他从库发送请求,进行相关的操作,但是如果主库发生故障了,那就直接会影响到从库的同步,因为从库没有相应的主库可以进行数据复制操作了。而且,如果客户端发送的都是读操作请求,那还可以由从库继续提供服务,这在纯读的业务场景下还能被接受。但是,一旦有写操作请求了,按照主从库模式下的读写分离要求,需要由主库来完成写操作。此时,也没有实例可以来服务客户端的写操作请求了,如下图所示:无论是写服务中断,还是从库无法进行数据原创 2021-10-14 11:53:58 · 191 阅读 · 0 评论 -
redis数据同步:主从库如何实现数据一致?
前两节课,我们学习了AOF和RDB,如果Redis发生了宕机,它们可以分别通过回放日志和重新读入RDB文件的方式恢复数据,从而保证尽量少丢失数据,提升可靠性。不过,即使用了这两种方法,也依然存在服务不可用的问题。比如说,我们在实际使用时只运行了一个Redis实例,那么,如果这个实例宕机了,它在恢复期间,是无法服务新来的数据存取请求的。那我们总说的Redis具有高可靠性,又是什么意思呢?其实,这里有两层含义:一是数据尽量少丢失,二是服务尽量少中断。AOF和RDB保证了前者,而对于后者,Redis的做法原创 2021-10-14 11:19:46 · 265 阅读 · 0 评论 -
redis内存快照:宕机后,Redis如何实现快速恢复?
上节课,我们学习了Redis避免数据丢失的AOF方法。这个方法的好处,是每次执行只需要记录操作命令,需要持久化的数据量不大。一般而言,只要你采用的不是always的持久化策略,就不会对性能造成太大影响。但是,也正因为记录的是操作命令,而不是实际的数据,所以,用AOF方法进行故障恢复的时候,需要逐一把操作日志都执行一遍。如果操作日志非常多,Redis就会恢复得很缓慢,影响到正常使用。这当然不是理想的结果。那么,还有没有既可以保证可靠性,还能在宕机时实现快速恢复的其他方法呢?当然有了,这就是我们今天要一原创 2021-10-13 20:22:41 · 179 阅读 · 0 评论 -
redis-AOF日志:宕机了,Redis如何避免数据丢失?
如果有人问你:“你会把Redis用在什么业务场景下?”我想你大概率会说:“我会把它当作缓存使用,因为它把后端数据库中的数据存储在内存中,然后直接从内存中读取数据,响应速度会非常快。”没错,这确实是Redis的一个普遍使用场景,但是,这里也有一个绝对不能忽略的问题:一旦服务器宕机,内存中的数据将全部丢失。我们很容易想到的一个解决方案是,从后端数据库恢复这些数据,但这种方式存在两个问题:一是,需要频繁访问数据库,会给数据库带来巨大的压力;二是,这些数据是从慢速数据库中读取出来的,性能肯定比不上从Redis中原创 2021-10-13 19:52:28 · 240 阅读 · 0 评论 -
redis高性能IO模型:为什么单线程Redis能那么快?
今天,我们来探讨一个很多人都很关心的问题:“为什么单线程的Redis能那么快?”首先,我要和你厘清一个事实,我们通常说,Redis是单线程,主要是指Redis的网络IO和键值对读写是由一个线程来完成的,这也是Redis对外提供键值存储服务的主要流程。但Redis的其他功能,比如持久化、异步删除、集群数据同步等,其实是由额外的线程执行的。所以,严格来说,Redis并不是单线程,但是我们一般把Redis称为单线程高性能,这样显得“酷”些。接下来,我也会把Redis称为单线程模式。而且,这也会促使你紧接着原创 2021-10-13 14:24:20 · 159 阅读 · 0 评论 -
redis数据结构:快速的Redis有哪些慢操作?
一提到Redis,我们的脑子里马上就会出现一个词:“快。”但是你有没有想过,Redis的快,到底是快在哪里呢?实际上,这里有一个重要的表现:它接收到一个键值对操作后,能以微秒级别的速度找到数据,并快速完成操作。数据库这么多,为啥Redis能有这么突出的表现呢?一方面,这是因为它是内存数据库,所有操作都在内存上完成,内存的访问速度本身就很快。另一方面,这要归功于它的数据结构。这是因为,键值对是按一定的数据结构来组织的,操作键值对最终就是对数据结构进行增删改查操作,所以高效的数据结构是Redis快速处理数据原创 2021-10-12 20:35:10 · 163 阅读 · 0 评论 -
redis基本架构:一个键值数据库包含什么?
我们知道,Redis是典型的键值数据库,所以今天,我准备手把手地带你构建一个简单的键值数据库。为啥要这么做呢?还记得我在开篇词说过吗?Redis本身比较复杂,如果我们一上来就直接研究一个个具体的技术点,比如“单线程”“缓存”等,虽然可以直接学习到具体的内容,甚至立马就能解决一些小问题,但是这样学,很容易迷失在细枝末节里。从我自己的经验来看,更好的学习方式就是先建立起“系统观”。这也就是说,如果我们想要深入理解和优化Redis,就必须要对它的总体架构和关键模块有一个全局的认知,然后再深入到具体的技术点原创 2021-10-12 20:09:24 · 301 阅读 · 0 评论