前言
相信很多在中小型企业或者TO B企业的小伙伴们都未曾接触过限流。举个例子,小伙伴们就会发现,原来软件限流就在身边。相信很多小伙伴们都有12306买票回家的体验吧。如下图大家应该非常熟悉。
这应该是分布式锁演化的最后一个章节了,相信很多小伙伴们看完这个章节之后在应对高并发的情况下,如何保证线程安全心里肯定也会有谱了。在实际的项目中也可以参考一下老猫的github上的例子,当然代码没有经过特意的封装,需要小伙伴们自己再好好封装一下。那么接下来,就和大家分享一下基于zookeeper的分布式锁,由于此篇主要分享的是zk的分布式锁,所以对于zk本身的相关知识点,并不会涉及很多。和分布式锁实现有关的zk知识点会提及。
何为ZK?(为了打字简单,后续老猫均以ZK来代替zookeeper),相信很多接触到Dubbo框架的小伙伴可能听说过ZK,但是具体也没有详细地去学习ZK。那么又如何利用ZK来实现分布式锁呢?以下我们一个个来看。
上一篇老猫和小伙伴们分享了为什么要使用分布式锁以及分布式锁的实现思路原理,目前我们主要采用第三方的组件作为分布式锁的工具。上一篇运用了Mysql中的select …for update实现了分布式锁,但是我们说这种实现方式并不常用,因为当大并发量的时候,会给数据库带来比较大的压力。当然也有小伙伴给老猫留言说“ 在quartz的集群模式中,就是使用了基于mysql的分布式锁,select for update ”。没错,其实quartz的集群模式中,任务执行的节点个数是可预知的,而且没有那么大的量级,所以是没有问题的。但是如果像千万级别的并发秒杀场景的情况下,那么这种方案其实是不可行的。因为mysql操作是需要IO的,IO的速度比内存速度慢,因此mysql如果在那种场景下使用的话是会存在系统瓶颈的。所以本篇就和小伙伴们分享基于内存操作的比较常用的分布式锁——redis分布式锁。
当今社会是一个信息大爆炸的社会,大家都在用各种应用软件,也因此产生了大量的数据,企业把这些数据当做宝贝,然而这些被视为宝贝的数据往往是我们技术人员的烦恼,这些海量的数据存储和访问成为了系统设计与使用的瓶颈,而这些数据往往存储在数据库中,然后传统的数据库又是存在不足的。单个数据库是存在性能瓶颈的,并且扩展起来十分困难,在当今这个大数据的时代,我们就必须要解决这样的问题。如果单机数据库易于扩展,数据可切分,就可以避免这些问题,但是当前的这些数据库厂商,包括开源的数据库MySQL在内,提供这些服务都是要收费的。所以我们一般转向第三方的软件,使用这些软件来给我们的数据做数据切分,将原本一台数据库上的数据,分散到多台数据库中,降低每一个单体数据库的负载。那么我们如何做数据切分呢?接下来,跟着老猫来看一下切分的方案。
从本篇开始,我们来好好梳理一下Java开发中的锁,通过一些具体简单的例子来描述清楚从Java单体锁到分布式锁的演化流程。本篇我们先来看看什么是锁,以下老猫会通过一些日常生活中的例子也说清楚锁的概念。
锁在Java中是一个非常重要的概念,在当今的互联网时代,尤其在各种高并发的情况下,我们更加离不开锁。那么到底什么是锁呢?在计算机中,锁(lock)或者互斥(mutex)是一种同步机制,用于在有许多执行线程的环境中强制对资源的访问限制。锁可以强制实施排他互斥、并发控制策略。举一个生活中的例子,大家都去超市买东西,如果我们带了包的话,要放到储物柜。我们再把这个例子极端一下,假如柜子只有一个,那么此时同时来了三个人A、B、C都要往这个柜子里放东西。那么这个场景就是一个多线程,多线程自然也就离不开锁。简单示意图如下
Update your browser to view this website correctly. Update my browser now