add .

文亮 · 文亮 · commit a272b4f3ed1b · 2019-08-14T23:19:54.000+08:00
diff --git a/README.md b/README.md
@@ -222,6 +222,10 @@
 - [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)
 
 
 
diff --git a/docs/distributed-system/distributed-lock.md b/docs/distributed-system/distributed-lock.md
@@ -0,0 +1,11 @@
+
+下订单的环节，支付之前，创建一个订单
+
+![distributed-lock](/docs/distributed-system/images/distributed-lock.png)
+创建一个订单，订单里会指定对哪些商品要购买多少件，此时就需要走一个流程，校验一下库存
+
+查库存，确认库存充足，锁定库存
+
+这个过程必须用分布式锁，锁掉这个商品的库存，对一个商品的购买同一时间只能有一个人操作
+
+redis和zookeeper实现分布式锁的原理，在之前面试突击第一季都讲过了，大家没看过的可以去看一下
diff --git a/docs/distributed-system/hitch-redis-distribute-lock.md b/docs/distributed-system/hitch-redis-distribute-lock.md
@@ -0,0 +1,4 @@
+
+瞬时故障问题
+
+彻底解决这个问题，很难，除非你修改一些redis和redisson框架的源码，源码级的二次开发，加锁，必须是master和slave同时写成功，才算是加锁成功
diff --git a/docs/distributed-system/images/distributed-lock.png b/docs/distributed-system/images/distributed-lock.png
diff --git a/docs/distributed-system/images/redis-distribute-lock.png b/docs/distributed-system/images/redis-distribute-lock.png
diff --git a/docs/distributed-system/redis-distribute-lock.md b/docs/distributed-system/redis-distribute-lock.md
@@ -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就消失了，自动释放了宕机客户端之前持有的锁
+
+
+
+
+
+
diff --git a/docs/distributed-system/work-redis-distribute-lock.md b/docs/distributed-system/work-redis-distribute-lock.md
@@ -0,0 +1,2 @@
+
+自己哪个业务可以用分布式锁？用什么框架？有什么生产问题？

-Original file line number
+Diff line change
@@ @@ -0,0 +1,4 @@ @@
++
 +瞬时故障问题
++
 +彻底解决这个问题，很难，除非你修改一些redis和redisson框架的源码，源码级的二次开发，加锁，必须是master和slave同时写成功，才算是加锁成功
Original file line number	Diff line number	Diff line change
`@@ -0,0 +1,2 @@`
	`1`	`+`
	`2`	`+自己哪个业务可以用分布式锁？用什么框架？有什么生产问题？`