Redis
文章平均质量分 91
就要学Java
Java全套进阶资料以及面试题可以后台私信我!!!!!!
展开
-
面试官亲述|如何优雅地介绍自己的项目经历?
其实可能会过犹不及,面试官就会重点考察你说的每个细节,因为怀疑你说的都是你从网上看的,而不是你项目中用到的。不管怎样,一旦回答简单,不主动说出你的擅长点,或没有条理很清楚地说出你的亮点,就算我让你通过面试,也不会写上“框架细节了解比较深,数据库应用比较熟练”等之类的好评语,你即使通过技术和后面的综合面试,工资也是比较低的。在做项目介绍的时候,你可以穿插说出一些你的亮点,但请记得,不论在介绍项目还是在回答问题,你当前的职责不是说明亮点而是介绍项目,一旦你详细说,可能会让面试官感觉你跑题了。原创 2023-06-04 11:17:53 · 594 阅读 · 0 评论 -
圆梦!顺利拿到字节、淘宝、拼多多等大厂 offer!
面经部分都是拿到 offer 或者谈薪阶段主动终止的公司,其他小公司或创业公司都是为了练手,面试题没有普遍性的都没有列举出来,面试问题写的少的都是问项目、业务比较多的。算法题只在 leetcode 上找原题,没有贴出链接的就是 leetcode 上没有的。原创 2023-06-02 15:27:04 · 342 阅读 · 0 评论 -
京东十年老架构:MySQL——GROUP BY详解与优化
以下是GROUP BY子句的基本语法:sql复制代码其中,col1col2, ...是要分组的列名,是用于聚合数据的函数,如SUMAVGMAXMIN等。table_name是要从中检索数据的表的名称,condition是可选的查询条件。原创 2023-06-01 16:09:43 · 531 阅读 · 0 评论 -
面试必问之缓存击穿、穿透、雪崩及常用解决方案
本文介绍了缓存击穿、缓存穿透和缓存雪崩三种问题及解决方案。缓存击穿:先击后穿缓存击穿的解决方案有:设置热点数据永不过期、定时更新、分布式缓存穿透:将缓存穿了个洞缓存穿透的解决方案有:业务层校验、缓存空值、布隆过滤器缓存雪崩:大量失效Key缓存雪崩的解决方案有:设置不同的过期时间、缓存预热、多级缓存、限流熔断、集群和负载均衡结尾金九银十快到了很多朋友对面试不够了解,不知道如何准备,对面试环节的设置以及目的不了解,尤其是面试题还很难,自己看解析都有点不明白。原创 2023-06-01 15:12:55 · 534 阅读 · 0 评论 -
十年老架构带你深入学习Redis(5):集群
集群,即Redis Cluster,是Redis 3.0开始引入的分布式存储方案。集群由多个节点(Node)组成,Redis的数据分布在这些节点中。集群中的节点分为主节点和从节点:只有主节点负责读写请求和集群信息的维护;从节点只进行主节点数据和状态信息的复制。集群的作用,可以归纳为两点:1、数据分区:数据分区(或称数据分片)是集群最核心的功能。集群将数据分散到多个节点,一方面突破了Redis单机内存大小的限制,存储容量大大增加;原创 2023-05-31 15:14:38 · 116 阅读 · 0 评论 -
十年老架构带你深入学习Redis(4):哨兵
哨兵系统的搭建过程,有几点需要注意:(1)哨兵系统中的主从节点,与普通的主从节点并没有什么区别,故障发现和转移是由哨兵来控制和完成的。(2)哨兵节点本质上是redis节点。(3)每个哨兵节点,只需要配置监控主节点,便可以自动发现其他的哨兵节点和从节点。(4)在哨兵节点启动和故障转移阶段,各个节点的配置文件会被重写(config rewrite)。(5)本章的例子中,一个哨兵只监控了一个主节点;实际上,一个哨兵可以监控多个主节点,通过配置多条sentinel monitor即可实现。原创 2023-05-31 15:08:18 · 49 阅读 · 0 评论 -
十年老架构带你深入学习Redis(3):主从复制
在使用读写分离之前,可以考虑其他方法增加Redis的读负载能力:如尽量优化主节点(减少慢查询、减少持久化等其他情况带来的阻塞等)提高负载能力;使用Redis集群同时提高读负载能力和写负载能力等。如果使用读写分离,可以使用哨兵,使主从节点的故障切换尽可能自动化,并减少对应用程序的侵入。下面回顾一下本文的主要内容:1、主从复制的作用:宏观的了解主从复制是为了解决什么样的问题,即数据冗余、故障恢复、读负载均衡等。2、主从复制的操作:即slaveof命令。原创 2023-05-31 15:05:26 · 358 阅读 · 0 评论 -
十年老架构带你深入学习Redis(2):持久化
持久化的功能:Redis是内存数据库,数据都是存储在内存中,为了避免进程退出导致数据的永久丢失,需要定期将Redis中的数据以某种形式(数据或命令)从内存保存到硬盘;当下次Redis重启时,利用持久化文件实现数据恢复。除此之外,为了进行灾难备份,可以将持久化文件拷贝到一个远程位置。Redis持久化分为RDB持久化和AOF持久化:前者将当前数据保存到硬盘,后者则是将每次执行的写命令保存到硬盘(类似于MySQL的binlog);原创 2023-05-31 15:02:40 · 46 阅读 · 0 评论 -
原京东架构师一步步教你如何搭建K8S集群(保姆级教程)
这个命令我在主节点上执行了三次,第一次是工作节点还没加入前,第二次是工作节点加入后,可以看到 node01 状态是 NotReady,过了几分钟后,我又执行了一次,node01 的状态变成了 Ready。此时我再在工作节点执行该命令,还是会发生上面的报错。上面说是 Docker 和 kubelet 的 cgroup driver 不一样,kubelet 的是 systemd,docker 的是 cgroupfs。很遗憾的是我的虚拟机上的主节点突然宕机了,并且之后换了一个 IP,然后我又立马给它起起来了。原创 2023-05-30 16:26:44 · 176 阅读 · 0 评论 -
(差点失业了!)记录一次缓存雪崩的灾难复盘
这是一个典型的数据查询,大概过程如下左侧,访问用户基本信息的时候会先去Redis中查一下,如果不存在,就把大约2W左右的用户数据一次性取出来,保存在Redis中,因为用户基本信息在同一张表上,用户信息表的数据量也很少,所以一直也没什么问题。新发布的系统,缓存池是空的,在早上10点高峰期的时候,大量的人员到IM上进行访问,系统开始初次建立每个人的缓存信息,大量的请求查询不到缓存,直接透过缓存池投向数据库,造成瞬时DB请求量井喷。我们IM原有的一个功能,当鼠标移动到用户头像的时候,会显示出用户的基本信息。原创 2023-05-30 16:06:42 · 42 阅读 · 0 评论 -
月薪15k以下都不会的——分布式锁方案分析
前面的文章我们介绍了分布式系统和它的CAP原理:一致性(Consistency)、可用性(Availability)和分区容错性(Partition tolerance)。参考这篇《分布式事务我们知道,一个分布式系统无法同时满足三个特性,所以在设计系统之初,就有一个特性要被妥协和牺牲,因为分区容错性的不可或缺性,一般我们的选择是AP或者CP,这就要求我们要么舍弃强一致性,要么舍弃高可用。为了达到数据的一致性,或者说至少达到数据的最终一致性,我们需要一些额外的方法来保证,比如分布式事务,分布式锁等等。原创 2023-05-30 15:26:06 · 42 阅读 · 0 评论 -
追求性能的极致:Redis6.0的多线程模型(附面试题)
就会明白,Redis所谓的单线程并不是所有工作都是只有一个线程在执行,而是指Redis的网络IO和键值对读写是由一个线程来完成的,Redis在处理客户端的请求时包括获取 (socket 读)、解析、执行、内容返回 (socket 写) 等都由一个顺序串行的主线程处理。由于Redis在处理命令的时候是单线程作业的,所以会有一个Socket队列,每一个到达的服务端命令来了之后都不会马上被执行,而是进入队列,然后被线程的事件分发器逐个执行。如果并发量很高,达到万级别的 QPS,就会形成瓶颈,影响整体吞吐能力。原创 2023-05-30 11:09:02 · 387 阅读 · 0 评论 -
Mysql数据库和Redis缓存如何实现双写一致性?
方案选型首先确认产品上对延迟性的要求,如果要求极高,且数据有可能变化,别用缓存。通常来说,方案1就够了,笔者咨询过4,5个团队,基本都是用方案1,因为能用缓存方案,通常是读多写少场景,同时业务上对延迟具有一定的包容性。方案1没有开发成本,其实比较实用。如果想增加更新时的即时性,就选择方案2,不过没必要做重试保证之类的。方案3,方案4针对于对延时要求比较高业务,一个是推模式,一个是拉模式,而方案4具备更强的可靠性,既然都愿意花功夫做处理消息的逻辑,不如一步到位,用方案4。结论一般情况,方案1够用。原创 2023-05-25 15:06:24 · 266 阅读 · 0 评论 -
三分钟搞懂Redis持久化机制
在 Redis 中,RDB 持久化就是充分的利用了这项技术,Redis 在持久化时调用 glibc 函数 fork 一个子进程,全权负责持久化工作,这样父进程仍然能继续给客户端提供服务。那么 Redis 服务器在执行 AOF 重写操作时,就会像执行 BGSAVE 命令那样,根据数据库当前的状态生成出相应的 RDB 数据,并将这些数据写入新建的 AOF 文件中,至于那些在 AOF 重写开始之后执行的 Redis 命令,则会继续以协议文本的方式追加到新 AOF 文件的末尾,即已有的 RDB 数据的后面。原创 2023-05-24 11:19:04 · 107 阅读 · 0 评论