00:00
项目搭建好之后呢,我们接下来呢,来去把它启动起来,然后呢,访问一下,看看有没有什么问题。啊,启动呢,已经启动成功啊启动成功之后呢,我们来看一下这里的端口号码,就是我们配置的10010。然后呢,我们在浏览器地址栏来去访问我们的工程,那么应该是local host,然端口号呢是10010,那路径啊,就是给打开这个路径,那我们呢,直接回车访问。已经访问成功,那访问成功之后呢,我们来去看一下控制台哈,在控制台上咱已经打印出库存余量是4999件。那我们呢,再来去多访问几次,我们去刷新刷新刷新。好,那我们来看这个余量是多少,还剩4996件。那么看上去呢,没什么问题。啊,这是因为啊,我们是个人,就是一个用户,然后通过浏览器啊,单手点击来访问的,此时没有高并发啊,也没有丙发啊,更不要说高丙发了。
01:09
那么啊,我们如果在高并发情况下,会不会出现什么问题呢?注意我们代码中呢,没有加任何机制,难以保证串性化访问啊。好,那我们来就模拟一下,看看高并发情况下,它会不会出什么问题。那怎么模拟高并发呢?我们就需要一些专业的工具了。在我的资料里面给你们提供了一一些工具,那么其中就包含了解密的工具,那我们使用了这个解密的工具来做压力测试。那么这个工具呢,你可以呢,自行去下载,你也可以呢,使用我给你们这个啊。打开这个前面的工具,它这边有一个B目录,B目录里面啊,就有一个BAT文件啊,然我们双击打开就可以了。那最终呢,他会给我们打开一个图形化界面,那操作起来呢,还是比较简单的啊啊非常的直观,来点开这个界面。
02:06
那么这个界面呢,首先是一个测试计划,我们给这个测试计划呀,右键a three three group添加线程组。啊,那这呢,你可以给它起个名字啊。那我现在呢,只有一个线程组,我就不起名字了,那后续如果我有多个线程组,你可以给每个线程组呀,起一个名字啊。那么然后在这里啊,我们这个线程数。啊或者是呢,用户量啊,同时有多少用户来去访问我们的服务,那比如说咱可以设置成100行。那么周期时间呢,是一秒。那么发送多少次呢?哎,咱可以呢,发送50次。相当于呢,有100个用户,每个用户呢,发送50次,那一共发送5000次请求,那注意我现在库存余量啊,还有4000。996家啊。
03:00
那么一旦这5000个请求发出去的话。那我们的库存一定应该只剩负四阶了啊,我并没有加那个负数的控制,应该是负四阶。好,那么如果不是负四级的话,六生会出现问题了啊。好,那我们来去再给这个线程组啊添加啊samples sample了,里面有含的有HTP请求,来添加一个HP请求,这样来我要发一个HP请求过去啊。那么这个请求的协议我们是HTTP,那么呃,服务名或者端口啊,这或者IP地址我们是local host,端口号呢是10010。那么这个请求路径啊,咱们是to dedu这个路径。然后呢,我们,呃,为了监测咱们的测试效果,我们可以呢,可以呢,给他呢去添加一个报表。在这个listen里面啊,有含有aggregate report就是聚合报表。
04:03
那么我们要添加进来,此时这个报表啊,它是空的啊,什么都没有,那我们来去运行这个线程组。那咱可以看到一些数据了啊,啊给它保存一下,直接保存一个地方就行了啊,点击yes。好,那么然后呢,你这5000个请求啊,几乎瞬间就发送完成了啊,吞吐量呢,达到5400多啊,非常高。啊,每秒钟是5400多啊。那么我们来具体看一下,平均时长呢,是三毫秒啊,每个请求让中位数呢是一毫秒,就是大半的啊,一半的请求是在一毫秒以内就发送完了。那90%的请求呢,是在七毫秒之内发送完的,95%的请求呢,是在15毫秒之内发送完的啊。99%的请求呢,是在36毫秒之内发送完的,那么请求耗时最长的一个是60毫秒。那么大概数据呢,咱已经看到了。
05:02
那最终库存有没有减为负四呢?啊,咱看一下这个最终的库存余量啊,你会发现呢,还有100多件库存呢。那么也就是说呢,我后续用户可以继续去购买这个商品。那最终就会导致呀。我们的商品呢,卖出去了很多很多,但是呢,库存呢,只有5000件,就会出现无货可发这种状态啊。若出现超卖现象。那么怎么解决这个问题呢?咱刚才呢,提到过,我们可以使用GVM给咱提供的这种锁机制,那比如说呢,Re lock,比如说synchronized。那也说呢,我们就先使用一下think night,看能不能解决这样的一个问题哈,我就来一个啊central night关键字啊,已经加上去了。那么加上去之后呀,我们需要重启一下咱们的服务啊,来重新启动。嗯。它已经启动成功,那么启动成功之后呢,我们现在浏览器上来去测试一下,那我们来去刷新已经启动啊,应该这个访问成功了,对吧,还剩4999件。
06:11
那我假如说此时我再去发送5000个请求,咱把这个报表呢,给它清空掉啊清掉我再去发送这5000个请求,那这最终会怎么样呢?来点击这个启动按钮啊,你可以发现呢,会稍微慢那么一点点。那么它的吞吐量啊,也变小啊,那还剩四千九百八十八十次每秒啊吞吐量。然后呢,中位数请求啊,都不到一秒一毫秒啊,那平均呢,也不到一毫秒。然后呢,咱们这个最大的一个耗时最长的一个呢,是八毫秒99%的请求啊,在三毫秒以内发送完了。因为它是串性访问的嘛,不存在什么资源增强,所以每一个请求都很快,但虽然每个请求都很快,但吞吐量依然下来了,因为呢,它不是并行访问的,而是串行化访问的啊。
07:06
哎,之前的话呢,每个请求可能会比较长,但是的话呢,它是并行化来去访问的啊啊,虽然每个请求可能长了一点,但是呢,总体时间呢,反而是更短了的啊啊这样子。好,那我们来去看一下咱的最终的库存数应该是负一件,因为刚才呢,我通过浏览器啊,也减了一截啊,来看最终这个数据应该是负一件。那说明呢,它就可以解决我们的这种并发性问题了。那对应的lock该如何去玩呢?其它的玩法呀,也很简单啊,咱可以简单的可以演示一下,来一个private,首先声明一个re lock,那来个lock嘛,等于那就new一个re lock。那么然后呢,我们在这个方法内部呀,我们就可以去使用咱们的这个lock锁了,首先呢,我们在方法执行开始的时候,加一个lock点上的lock方法。
08:04
那么然后呢,在这里啊,咱们要去使用它的使用try finally来去解锁啊,一定要在finally解锁。因为呢,一定要保证呢,咱们解锁代码呀,要能够执行到啊,所以一定要在发里面来解锁啊,再来一个unlock这样子。好,那么这样呢,咱们呢,解锁呀,加锁和解锁呢,哎,通过准称lock也已经改造好了,那么改造之后呢,我们依然把它给重启一下。嗯。啊,重启呢,依然成功了啊。那么重启成功之后呢,我们再在浏览器中来去访问,因为此时呢,我们的。打印结果呀,是4999件,已经减了一件了。那么讲完一遍之后呢,我依然通过解密塔压力测试工具,我来去压一下啊,咱把这个呢日志呀给它清空掉。那么清空掉之后呢,我来去啊运行测试。
09:03
那么这个速度呢,跟其实差不多。你看这呢,是5000啊,每每秒啊,吞吐量啊,其实没多了几次啊,都差不多。你这个最大啊请求啊,最大的一个请求哈,最耗时的一个请求呢,是六毫秒啊。因为99%的请求啊,在两毫秒,两毫秒以内已经发送完了,那中位数呢是啥呢,是零毫秒。啊,反正总之呢都很快,虽然很快,但性能呢,依然比那个没加锁的情况下呀,比没有加锁的情况下呀,还是要有所损耗的啊,因为它是一种串意性化访问啊。OK,那我们来看控制台,那么此时呢,它的这个库存余量啊,应该是变成负一啊。
我来说两句