聊聊限流

前言

相信很多在中小型企业或者TO B企业的小伙伴们都未曾接触过限流。举个例子,小伙伴们就会发现,原来软件限流就在身边。相信很多小伙伴们都有12306买票回家的体验吧。如下图大家应该非常熟悉。

程序员的负罪感

这次不聊技术了,老猫最近状态上感觉出了问题。不晓得会不会有铁子和老猫一样。

累了一天,下班后回到家,孩子跟媳妇睡了,一个人傻呆呆坐在沙发上打开电视,按着遥控,翻看各种电影电视剧推荐,却始终无法静下心去看完一部电影或者电视剧。

洗完澡,走到书房,打开电脑,想到明天就是双休日,那就打会游戏吧,没成想玩了不到五分钟,觉得没劲,又默默退出。眼角瞥到鼠标旁的《XXX核心原理》,开始翻看,也不晓得看进去了多少。此时反而会感到踏实。

也不知道从什么时候起,我的生活感觉陷入了矛盾的怪圈。想要放松,想花时间去娱乐,却又满心负罪感。

锁的演化-分布式锁实战(zookeeper)

前言

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

Zookeeper实现分布式锁

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

锁的演化-分布式锁实战(MYSQL篇)

前言

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

单体应用锁的局限性

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

锁的演化-分布式锁实战(REDIS篇)

前言

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

锁的演化-分布式锁实战[MYSQL篇]

前言

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

单体应用锁的局限性

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

锁的演化-Java中锁的解决方案

前言

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

锁的演化-单体架构实战案例

前言

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

超卖的第一种现象案例

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

海量数据的切分

背景

当今社会是一个信息大爆炸的社会,大家都在用各种应用软件,也因此产生了大量的数据,企业把这些数据当做宝贝,然而这些被视为宝贝的数据往往是我们技术人员的烦恼,这些海量的数据存储和访问成为了系统设计与使用的瓶颈,而这些数据往往存储在数据库中,然后传统的数据库又是存在不足的。单个数据库是存在性能瓶颈的,并且扩展起来十分困难,在当今这个大数据的时代,我们就必须要解决这样的问题。如果单机数据库易于扩展,数据可切分,就可以避免这些问题,但是当前的这些数据库厂商,包括开源的数据库MySQL在内,提供这些服务都是要收费的。所以我们一般转向第三方的软件,使用这些软件来给我们的数据做数据切分,将原本一台数据库上的数据,分散到多台数据库中,降低每一个单体数据库的负载。那么我们如何做数据切分呢?接下来,跟着老猫来看一下切分的方案。

什么是锁

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

描述

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

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×