国内最专业的IT技术学习网

UI设计

当前位置:主页 > UI设计 >

分布式锁用Redis还是Zookeeper?

发布时间:2019/07/29标签:   节点    点击量:

原标题:分布式锁用Redis还是Zookeeper?
为甚么用散布式锁?在探讨这个成绩之前,咱们先来看一个营业场景。图片来自 Pexels为甚么用散布式锁?体系 A 是一个电商体系,现在是一台呆板安排,体系中有一个用户下定单的接口,然而用户下定单之前必定要去检讨一下库存,确保库存充足了才会给用户下单。因为体系有必定的并发,以是会事后将商品的库存保留在 Redis 中,用户下单的时间会更新 Redis 的库存。此时体系架构以下:然而如许一来会发生一个成绩:如果某个时辰,Redis 外面的某个商品库存为 1。此时两个恳求同时到来,此中一个恳求履行到上图的第 3 步,更新数据库的库存为 0,然而第 4 步还没有履行。而别的一个恳求履行到了第 2 步,发觉库存仍是 1,就持续履行第 3 步。如许的成果,是招致卖出了 2 个商品,但是实在库存只要 1 个。很显明错误啊!这就是典范的库存超卖成绩。此时,咱们很轻易想到处理计划:用锁把 2、3、4 步锁住,让他们履行完以后,另一个线程才干出去履行第 2 步。依照下面的图,在履行第 2 步时,应用 Java 供给的 Synchronized 或许 ReentrantLock 来锁住,而后在第 4 步履行完以后才开释锁。如许一来,2、3、4 这 3 个步调就被“锁”住了,多个线程之间只能串行化履行。然而好景不长,全部体系的并发飙升,一台呆板扛不住了。当初要增添一台呆板,以下图:增添呆板以后,体系酿成上图所示,我的天!假定此时两个用户的恳求同时到来,然而落在了差别的呆板上,那末这两个恳求是能够同时履行了,仍是会呈现库存超卖的成绩。为甚么呢?由于上图中的两个 A 体系,运转在两个差别的 JVM 外面,他们加的锁只对属于本人 JVM 外面的线程无效,关于其余 JVM 的线程是有效的。因而,这里的成绩是:Java 供给的原生锁机制在多机安排场景下生效了,这是由于两台呆板加的锁不是统一个锁(两个锁在差别的 JVM 外面)。那末,咱们只有保障两台呆板加的锁是统一个锁,成绩不就处理了吗?此时,就该散布式锁盛大退场了。散布式锁的思绪是:在全部体系供给一个全局、独一的猎取锁的“货色”,而后每个体系在须要加锁时,都去问这个“货色”拿到一把锁,如许差别的体系拿到的便可以以为是统一把锁。至于这个“货色”,能够是 Redis、Zookeeper,也能够是数据库。笔墨描写不太直观,咱们来看下图:

版权信息Copyright © IT技术教程 版权所有    ICP备案编号:鲁ICP备09013610号