Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 13 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -222,6 +222,19 @@
- [46、在搭建好的电商系统里,如何基于RocketMQ最终一致性事务进行落地开发?](/docs/distributed-system/rocketmq-eventual-consistency.md)
- [47、如果公司没有RocketMQ中间件,那你们如何实现最终一致性事务?](/docs/distributed-system/eventual-consistency.md)
- [48、作业:如果对自己的系统落地最终一致性事务,如何落地实现?](/docs/distributed-system/work-eventual-consistency.md)
- [49、你们生产系统中有哪个业务场景是需要用分布式锁的?为什么呢?](/docs/distributed-system/distributed-lock.md)
- [50、你们是用哪个开源框架实现的Redis分布式锁?能说说其核心原理么?](/docs/distributed-system/redis-distribute-lock.md)
- [51、如果Redis是集群部署的,那么集群故障时分布式锁还有效么?](/docs/distributed-system/hitch-redis-distribute-lock.md)
- [52、作业:自己梳理出来Redis分布式锁的生产问题解决方案](/docs/distributed-system/work-redis-distribute-lock.md)
- [53、如果要实现ZooKeeper分布式锁,一般用哪个开源框架?核心原理是什么?](/docs/distributed-system/zookeeper-distribute-lock.md)
- [54、对于ZooKeeper的羊群效应,分布式锁实现应该如何优化?](/docs/distributed-system/zookeeper-distribute-lock-optimize.md)
- [55、如果遇到ZooKeeper脑裂问题,分布式锁应该如何保证健壮性?](/docs/distributed-system/zookeeper-distribute-lock-split-brain.md)
- [56、作业:自己梳理出来ZooKeeper分布式锁的生产问题解决方案](/docs/distributed-system/zookeeper-distribute-lock-scheme.md)
- [57、在搭建好的电商系统中,落地开发分布式锁保证库存数据准确的方案](/docs/distributed-system/floor-distribute-lock.md)
- [58、你们的分布式锁做过高并发优化吗?能抗下每秒上万并发吗?](/docs/distributed-system/highly-concurrent-distribute-lock.md)
- [59、淘宝和京东的库存是怎么实现的?能不能不用分布式锁实现高并发库存更新?](/docs/distributed-system/distributed-lock-taobao-and-jingdong.md)
- [60、作业:自己系统的分布式锁在高并发场景下应该如何优化?](/docs/distributed-system/highly-concurrent-majorization-distributed-lock.md)
- [61、互联网Java工程师面试突击前两季总结以及下一季的规划展望](/docs/distributed-system/java-internet-interview-outlook.md)



Expand Down
Binary file modified docs/distributed-system/code/code3.zip
Binary file not shown.
Original file line number Diff line number Diff line change
@@ -0,0 +1,6 @@

大公司一般有分布式kv存储,tair,redis,mongodb,高并发,每秒几万几十万都没问题,甚至每秒百万

实时库存数据放kv存储里去,先查库存再扣减库存,你在操作库存的时候,直接扣减,如果你发现扣减之后是负数的话,此时就认为库存超卖了,回滚刚才的扣减,返回提示给用户。对kv做的库存修改写MQ,异步同步落数据库,相当于异步双写,用分布式kv抗高并发,做好一致性方案


11 changes: 11 additions & 0 deletions docs/distributed-system/distributed-lock.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,11 @@

下订单的环节,支付之前,创建一个订单

![distributed-lock](/docs/distributed-system/images/distributed-lock.png)
创建一个订单,订单里会指定对哪些商品要购买多少件,此时就需要走一个流程,校验一下库存

查库存,确认库存充足,锁定库存

这个过程必须用分布式锁,锁掉这个商品的库存,对一个商品的购买同一时间只能有一个人操作

redis和zookeeper实现分布式锁的原理,在之前面试突击第一季都讲过了,大家没看过的可以去看一下
2 changes: 2 additions & 0 deletions docs/distributed-system/floor-distribute-lock.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,2 @@

《亿级流量电商详情页系统实战》,部署redis和zookeeper,redisson做分布式锁,curator做分布式锁,试一试
26 changes: 26 additions & 0 deletions docs/distributed-system/highly-concurrent-distribute-lock.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,26 @@

分段加锁

有好多同学出去面试,聊到分布式锁这块,都被人考察分布式锁能不能抗高并发的问题了

对某个商品下单,对一个分布式锁每秒突然有上万请求过来,都要进行加锁,此时怎么办呢?可能就会导致你



比如你的苹果库存有10000个,此时你在数据库中创建10个库存字段

一个表里有10个库存字段,stock_01,stock_02,每个库存字段里放1000个库存

此时这个库存的分布式锁,对应10个key,product_1_stock_01,product_1_stock_02

请求过来之后,你从10个key随机选择一个key,去加锁就可以了,每秒过来1万个请求,此时他们会对10个库存分段key加锁,每个key就1000个请求,每台服务器就1000个请求而已


万一说某个库存分段仅仅剩余10个库存了,此时我下订单要买20个苹果,合并扣减库存,你对product_1_stock_5,加锁了,此时查询对应的数据库中的库存,此时库存是10个,不够买20个苹果

你可以尝试去锁product_1_stock_1,再查询他的库存可能有30个

此时你就可以下订单,锁定库存的时候,就对product_1_stock_5锁定10个库存,对product_1_stock1锁定10个库存,锁定了20个库存


分段加锁 + 合并扣减
Original file line number Diff line number Diff line change
@@ -0,0 +1,2 @@

想想自己的分布式锁用在业务系统中,有没有高并发问题,如果有,如何用分段加锁思路来解决,或者用kv存储来存放实时库存抗并发,直接在kv里扣减,避免用分布式锁
4 changes: 4 additions & 0 deletions docs/distributed-system/hitch-redis-distribute-lock.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,4 @@

瞬时故障问题

彻底解决这个问题,很难,除非你修改一些redis和redisson框架的源码,源码级的二次开发,加锁,必须是master和slave同时写成功,才算是加锁成功
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
27 changes: 27 additions & 0 deletions docs/distributed-system/java-internet-interview-outlook.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,27 @@

快速扫盲,MQ、ES、Dubbo、分布式事务、分布式锁、缓存架构、高并发、高可用,各种常考的技术问题,都拎出来,重点的讲解一下

21天互联网Java工程师面试训练营(分布式篇),互联网Java工程师面试突击训练(第二季)

对第一季的分布式面试题,进一步加深了,分布式这块再抗一堆连环炮都没问题

接着对后面几季的内容,会考虑一下形式,可能会考虑把五季合并为一季,作为面试突击第三季,形式上会综合考虑是继续用视频,还是用文章形式更便于大家日常学习

微服务、海量数据、高性能、高并发、高可用,五季

互联网Java工程师面试突击训练营(第三季)

视频,路上,在公司里不方便看视频,等到回家,晚上来一局王者荣耀

文章,上下班路上,在公司里,支持在PC端可以看文章,自己写写代码,做点实验

狸猫技术窝,知识店铺,有一个文章专栏,救火队队长,《从0开始带你成为JVM实战高手》,一步一图,大白话,通俗易懂,1个多月,将近2000人买了专栏,普遍好评,非常的好,看的浅显易懂,实战型强,就知道生产环境jvm如何优化



后台观察一下购买面试训练营第二季的同学学习的进度,没时间看视频,赶进度一个过程中,学习中,第三季,那一定是观察大部分同学都得把第二季学的差不多,重磅推出第三季,加量不加价


付费微信群,里面有很多我这两年带出来的大厂的同学,滴滴、阿里、百度、美团、美菜、每日优鲜、vipkid,热火朝天聊技术问题

学习+作业+思考+复习+提问+答疑
36 changes: 36 additions & 0 deletions docs/distributed-system/redis-distribute-lock.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,36 @@

面试突击第二季
![distributed-lock](/docs/distributed-system/images/redis-distribute-lock.png)
Redis分布式锁,很少自己撸,Redisson框架,他基于Redis实现了一系列的开箱即用的高级功能,比如说分布式锁

引入maven依赖,他示例代码就几行

比如说,苹果这个商品的id是1

redisson.lock(“product_1_stock”)

key的业务语义,就是针对product_id = 1的商品的库存,也就就是苹果的库存,进行加锁

如果要学习redis技术的,跟我之前录制的《亿级流量商品详情页系统》去学习,在训练营的课程目录里有一个文档,有我之前的课程的地址


product_1_stock: {
“xxxx”: 1
}

生存时间:30s

watchdog,redisson框架后台执行一段逻辑,每隔10s去检查一下这个锁是否还被当前客户端持有,如果是的话,重新刷新一下key的生存时间为30s

其他客户端尝试加锁,这个时候发现“product_1_stock”这个key已经存在了,里面显示被别的客户端加锁了,此时他就会陷入一个无限循环,阻塞住自己,不能干任何事情,必须在这里等待


第一个客户端加锁成功了,此时有两种情况,第一种情况,这个客户端操作完毕之后,主动释放锁;第二种情况,如果这个客户端宕机了,那么这个客户端的redisson框架之前启动的后台watchdog线程,就没了

此时最多30s,key-value就消失了,自动释放了宕机客户端之前持有的锁






2 changes: 2 additions & 0 deletions docs/distributed-system/work-redis-distribute-lock.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,2 @@

自己哪个业务可以用分布式锁?用什么框架?有什么生产问题?
12 changes: 12 additions & 0 deletions docs/distributed-system/zookeeper-distribute-lock-optimize.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,12 @@

![zookeeper-distribute-lock-optimize](/docs/distributed-system/images/zookeeper-distribute-lock-optimize.png)
也可以,羊群效应

如果几十个客户端同时争抢一个锁,此时会导致任何一个客户端释放锁的时候,zk反向通知几十个客户端,几十个客户端又要发送请求到zk去尝试创建锁,所以大家会发现,几十个人要加锁,大家乱糟糟的,无序的

羊群效应

造成很多没必要的请求和网络开销,会加重网络的负载



11 changes: 11 additions & 0 deletions docs/distributed-system/zookeeper-distribute-lock-scheme.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,11 @@

Redis和ZooKeeper,哪种分布式锁更好?

从分布式系统协调语义而言,是ZooKeeper做分布式锁更好一些,因为Redis本身其实是缓存,但是Redis能抗高并发,高并发场景下更好一些

zookeeper本身不适合部署大规模集群,他本身适用的场景就是部署三五台机器,不是承载高并发请求的,仅仅是用作分布式系统的协调的


Redis?ZooKeeper?

有redis集群,没有zookeeper集群,那你当然就选择redis了;如果你们公司两个都有,用哪种分布式锁都可以,高并发场景,redis
Original file line number Diff line number Diff line change
@@ -0,0 +1,6 @@

分布式锁脑裂,重复加锁

分布式系统,主控节点有一个Master,此时因为网络故障,导致其他人以为这个Master不可用了,其他节点出现了别的Master,导致集群里有2个Master同时在运行

curator框架源码,加一些协调机制
10 changes: 10 additions & 0 deletions docs/distributed-system/zookeeper-distribute-lock.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,10 @@

看图说话
![distributed-lock](/docs/distributed-system/images/zookeeper-distribute-lock.png)
一般很少自己手撸,curator,基于zk实现了一整套的高级功能

product_1_stock

curator.lock(“product_1_stock”)

/locks/product_1_stock