分布式常见面试题:如何解决分布式锁的死锁问题
在日常开发中,像常见的秒杀扣库存这种需要访问同一资源的情况,并发读写时如果没有任何防护,很容易出现数据错乱的问题,比如超卖,库里的数据可能会出现负数。为解决此问题,我们引入了分布式锁,通常通过 Redis 来实现。它能让同一时刻只允许一个线程访问资源,超卖问题也就迎刃而解。 然而,分布式锁又带来了不少新麻烦,比如死锁问题,这出现的频率还挺高。常见场景有:加锁……
在日常开发中,像常见的秒杀扣库存这种需要访问同一资源的情况,并发读写时如果没有任何防护,很容易出现数据错乱的问题,比如超卖,库里的数据可能会出现负数。为解决此问题,我们引入了分布式锁,通常通过 Redis 来实现。它能让同一时刻只允许一个线程访问资源,超卖问题也就迎刃而解。 然而,分布式锁又带来了不少新麻烦,比如死锁问题,这出现的频率还挺高。常见场景有:加锁……
今天咱们来聊聊 MyBatis Plus 。从它诞生的初衷来看,是为了简化开发,一些基础的增删改查都给分装好了,少量做些配置就行,这确实给不少程序员减轻了工作负担。 相比之下,MyBatis 就显得稍微繁琐些,得写好 SQL 语句,不管简单还是复杂。从简化开发的角度,MyBatis Plus 略胜一筹。如果项目较小,有时间要求,开发人员水平也不太高,选择 M……
前两天有个小伙伴问了我一个问题,分布式常见面试题里关于微服务的拆分能有几种方案?这可把我难住了,一开始我们也没什么方法论,就是按照业务模块做了些拆解,很自然地形成了微服务模块,像用户中心、商城中心,也没特别的规则。 但后来在微服务拆分的过程中,发现还是有一些规则可以参考的。 一个是基于业务的划分,这比较容易想到,按照提供服务内容的不同做拆解。比如专门提供课程……
各位朋友,今天咱们来聊聊生产环境中不得不考虑的 Nginx 高可用问题。作为系统网关,Nginx 一直扮演着重要角色,比如流量入口、分发拦截、反向代理等等。但很多时候,大家可能会忽略 Nginx 的高可用,因为觉得它比较能扛,理论上能支持 5 万的并发连接,一般系统根本达不到这个量。然而,就像上次遇到的短信验证码攻击一样,黑天鹅事件难以预料,所以还是建议对像……
各位小伙伴们,在面试中经常会被问到消息队列到底是推模式还是拉模式,如果没有研究过消息队列的底层原理,可能就不知道该如何回答了。其实这个问题要一分为二,从生产端到 broker 以及 broker 到消费端这两个路径来分析。 先说说生产端到 broker 这部分。业务端产生消息后,是通过推的模式传递给 broker 的。不管是 RabbitMQ、RocketM……
各位小伙伴们,提到系统的鉴权认证,大家应该都不陌生,比较常见的就是登录模块。输入账号、输入密码传到后台进行登录,认证通过就跳转主页,一般都是这个逻辑。 传统的模式是基于 session 的,登录之后后台接口会返回一个 session ID,然后前端将其保存在 cookie 里。访问页面时会带上 cookie 里的 session 到服务端去做校验,校验成功就……
今天咱们来聊聊分布式数据库中一个基础但又关键的问题,那就是如何生成数据表的记录 ID 。 当数据量越来越大,并发量越来越高,传统的单库单表遇到性能瓶颈时,我们自然会想到分库分表。利用分库分表虽能分摊压力,但在享受性能提升的同时,也会遇到很多问题,比如多表查询、分布式事务等等,这些咱们在前几期重点聊过。本期重点说一说分布式数据库中数据表记录 ID 的生成方案。……
今天咱们来聊聊电商系统中常见的秒杀活动。几乎每一家电商都会搞秒杀,一般在促销活动中,指定一定数量的商品用低价吸引大量用户参与,但只有少数用户能购买成功,这就是电商秒杀的套路,目的是用低价商品引入大批流量。 那对于电商系统来说,怎么设计一套既能满足日常交易,又能扛住高并发的秒杀系统,这可是程序员们重点要考虑的问题。 先说商品购买流程,大家应该都熟悉。比如一个朋……
我相信“严禁在代码中使用 select*”这句话大家应该都不陌生,很多公司都会三令五申强调这一点,就连福报厂的 Java 开发手册也明确表示不得使用“*”作为查询。如果我在 code review 中发现有小伙伴这么写代码,肯定不会让他过试用期。这可不是我狠,而是互联网 SQL 语句的规则,因为这关系到整个系统的性能,在很多面试场合也都会被问到。 那为啥要禁……
今天咱们来聊聊分布式架构中的分布式事务。只要涉及到交易、涉及到多个库,那必然绕不开分布式事务。在很多场景下,我们要保证数据的一致性,这就意味着要么全部成功,要么全部失败。比如说,不能出现支付成功了,但优惠券没抵扣、积分没加上这种情况,后果不堪设想。 总之,事务在整个系统中起着重要作用,也是分布式相关面试重点考察的对象。分布式事务主流的实践方式主要有两种,一种……
在提升数据库性能方面,除了前几期聊到的分库分表,还有一个重要的性能优化策略,那就是数据库的读写分离。 读是一个库,写是另一个库,这样能轻松分摊数据库的访问压力,进而提升整体性能。其原理基于主从复制的架构,简单来说,就是一个主库挂多个从库。我们只在主库进行写操作,像删除、新增等,主库会自动把数据同步到从库。 从实现层面来讲,有两个重要点。其一,是数据的同步问题……
在我们的数据库达到性能瓶颈之后,自然而然会想到分库分表。但分库分表之后,又带来了其他一些问题,比如如何联表查询、如何分页查询,大部分场景还是停留在查询层面。前几期也分析了一些常规的处理方法,像增加冗余字段和重构查询表等等。然而,这些本质上还是基于数据库层面,还是要依赖数据库的性能。过分依赖数据库,其实是存在一些问题的。 在大部分场景下,尤其是高并发的情况下,……