# 前言

这应该是分布式锁演化的最后一个章节了，相信很多小伙伴们看完这个章节之后在应对高并发的情况下，如何保证线程安全心里肯定也会有谱了。在实际的项目中也可以参考一下老猫的github上的例子，当然代码没有经过特意的封装，需要小伙伴们自己再好好封装一下。那么接下来，就和大家分享一下基于zookeeper的分布式锁，由于此篇主要分享的是zk的分布式锁，所以对于zk本身的相关知识点，并不会涉及很多。和分布式锁实现有关的zk知识点会提及。

# Zookeeper实现分布式锁

何为ZK?（为了打字简单，后续老猫均以ZK来代替zookeeper），相信很多接触到Dubbo框架的小伙伴可能听说过ZK，但是具体也没有详细地去学习ZK。那么又如何利用ZK来实现分布式锁呢？以下我们一个个来看。

# 前言

之前的文章中通过电商场景中秒杀的例子和大家分享了单体架构中锁的使用方式，但是现在很多应用系统都是相当庞大的，很多应用系统都是微服务的架构体系，那么在这种跨jvm的场景下，我们又该如何去解决并发。

# 单体应用锁的局限性

在进入实战之前简单和大家粗略聊一下互联网系统中的架构演进。

# 前言

上一篇老猫和小伙伴们分享了为什么要使用分布式锁以及分布式锁的实现思路原理，目前我们主要采用第三方的组件作为分布式锁的工具。上一篇运用了Mysql中的select ...for update实现了分布式锁，但是我们说这种实现方式并不常用，因为当大并发量的时候，会给数据库带来比较大的压力。当然也有小伙伴给老猫留言说“ 在quartz的集群模式中，就是使用了基于mysql的分布式锁，select for update ”。没错，其实quartz的集群模式中，任务执行的节点个数是可预知的，而且没有那么大的量级，所以是没有问题的。但是如果像千万级别的并发秒杀场景的情况下，那么这种方案其实是不可行的。因为mysql操作是需要IO的，IO的速度比内存速度慢，因此mysql如果在那种场景下使用的话是会存在系统瓶颈的。所以本篇就和小伙伴们分享基于内存操作的比较常用的分布式锁——redis分布式锁。

# 前言

上一篇分布式锁的文章中，通过超市存放物品的例子和大家简单分享了一下Java锁。本篇文章我们就来深入探讨一下Java锁的种类，以及不同的锁使用的场景，当然本篇只介绍我们常用的锁。我们分为两大类，分别是乐观锁和悲观锁，公平锁和非公平锁。

# 前言

从本篇开始，老猫会通过电商中的业务场景和大家分享锁在实际应用场景下的演化过程。从Java单体锁到分布式环境下锁的实践。

# 超卖的第一种现象案例

其实在电商业务场景中，会有一个这样让人忌讳的现象，那就是“超卖”，那么什么是超卖呢？举个例子，某商品的库存数量只有10件，最终却卖出了15件，简而言之就是商品卖出的数量超过了商品本身的库存数目。“超卖”会导致商家没有商品发货，发货的时间延长，从引起交易双方的纠纷。

从本篇开始，我们来好好梳理一下Java开发中的锁，通过一些具体简单的例子来描述清楚从Java单体锁到分布式锁的演化流程。本篇我们先来看看什么是锁，以下老猫会通过一些日常生活中的例子也说清楚锁的概念。

tes

# 描述

锁在Java中是一个非常重要的概念，在当今的互联网时代，尤其在各种高并发的情况下，我们更加离不开锁。那么到底什么是锁呢？在计算机中，锁(lock)或者互斥(mutex)是一种同步机制，用于在有许多执行线程的环境中强制对资源的访问限制。锁可以强制实施排他互斥、并发控制策略。举一个生活中的例子，大家都去超市买东西，如果我们带了包的话，要放到储物柜。我们再把这个例子极端一下，假如柜子只有一个，那么此时同时来了三个人A、B、C都要往这个柜子里放东西。那么这个场景就是一个多线程，多线程自然也就离不开锁。简单示意图如下