网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
在上一小节我们做好了负载均衡来保证集群的可用性,但公司需要需要考虑服务器的成本,不可能无限制的增加服务器数量,一般会经过计算保证日常的使用没问题。
限流的意义就在于我们无法预测未知流量,比如刚提到的抽奖可能遇到的:
- 重复抽奖
- 恶意脚本
其他一些场景:
- 热点事件(微博)
- 大量爬虫
这些情况都是无法预知的,不知道什么时候会有10倍甚至20倍的流量打进来,如果真碰上这种情况,扩容是根本来不及的(弹性扩容都是虚谈,一秒钟你给我扩一下试试)
明确了限流的意义,我们再来看看如何实现限流
防止用户重复抽奖
重复抽奖和恶意脚本可以归在一起,同时几十万的用户可能发出几百万的请求。
如果同一个用户在1分钟之内多次发送请求来进行抽奖,就认为是恶意重复抽奖或者是脚本在刷奖,这种流量是不应该再继续往下请求的,在负载均衡层给直接屏蔽掉。
可以通过nginx
配置ip
的访问频率,或者在在网关层结合sentinel
配置限流策略。
用户的抽奖状态可以通过redis来存储,后面会说。
拦截无效流量
无论是抽奖还是秒杀,奖品和商品都是有限的,所以后面涌入的大量请求其实都是无用的。
举个例子,假设50万人抽奖,就准备了100台手机,那么50万请求瞬间涌入,其实前500个请求就把手机抢完了,后续的几十万请求就没必要让他再执行业务逻辑,直接暴力拦截返回抽奖结束就可以了。
同时前端在按钮置灰上也可以做一些文章。
那么思考一下如何才能知道奖品抽完了呢,也就是库存和订单之前的数据同步问题。
服务降级和服务熔断
有了以上措施就万无一失了吗,不可能的。所以再服务端还有降级和熔断机制。
在此简单做个补充,详细内容请持续关注作者。
有好多人容易混淆这两个概念,通过一个小例子让大家明白:
假设现在一条粉丝数突破100万,冲上微博热搜,粉丝甲和粉丝乙都打开微博观看,但甲看到了一条新闻发布会的内容,乙却看到”系统繁忙“,过了一会,乙也能看到内容了。
(请允许一条幻想一下😎)
在上述过程中,首先是热点时间造成大量请求,发生了服务熔断,为了保证整个系统可用,牺牲了部分用户乙,乙看到的”系统繁忙“就是服务降级(fallback),过了一会有恢复访问,这也是熔断器的一个特性(hystrix)
V3 同步状态
接着回到上一节的问题,如何同步抽奖状态?
这不得不提到redis
,被广泛用于高并发系统的缓存数据库。
我们可以基于Redis来实现这种共享抽奖状态,它非常轻量级,很适合两个层次的系统的共享访问。
当然其实用ZooKeeper也是可以的,在负载均衡层可以基于zk客户端监听某个znode节点状态。一旦抽奖结束,抽奖服务更新zk状态,负载均衡层会感知到。
V4线程优化
对于线上环境,工作线程数量是一个至关重要的参数,需要根据自己的情况调节。
众所周知,对于进入Tomcat的每个请求,其实都会交给一个独立的工作线程来进行处理,那么Tomcat有多少线程,就决定了并发请求处理的能力。
但是这个线程数量是需要经过压测来进行判断的,因为每个线程都会处理一个请求,这个请求又需要访问数据库之类的外部系统,所以不是每个系统的参数都可以一样的,需要自己对系统进行压测。
但是给一个经验值的话,Tomcat的线程数量不宜过多。因为线程过多,普通服务器的CPU是扛不住的,反而会导致机器CPU负载过高,最终崩溃。
同时,Tomcat的线程数量也不宜太少,因为如果就100个线程,那么会导致无法充分利用Tomcat的线程资源和机器的CPU资源。
所以一般来说,Tomcat线程数量在200~500之间都是可以的,但是具体多少需要自己压测一下,不断的调节参数,看具体的CPU负载以及线程执行请求的一个效率。
在CPU负载尚可,以及请求执行性能正常的情况下,尽可能提高一些线程数量。
但是如果到一个临界值,发现机器负载过高,而且线程处理请求的速度开始下降,说明这台机扛不住这么多线程并发执行处理请求了,此时就不能继续上调线程数量了。
V5业务逻辑
抽奖逻辑怎么做?
好了,现在该研究一下怎么做抽奖了
在负载均衡那个层面,已经把比如50万流量中的48万都拦截掉了,但是可能还是会有2万流量进入抽奖服务。
因为抽奖活动都是临时服务,可以阿里云租一堆机器,也不是很贵,tomcat优化完了,服务器的问题也解决了,还剩啥呢?
Mysql,是的,你的Mysql能抗住2万的并发请求吗?
答案是很难,怎么办呢?
把Mysql给替换成redis,单机抗2万并发那是很轻松的一件事情。
而且redis的一种数据结构set
很适合做抽奖,可以随机选择一个元素并剔除。
V6流量削峰
由上至下,还剩中奖通知部分没有优化。
思考这个问题:假设抽奖服务在2万请求中有1万请求抽中了奖品,那么势必会造成抽奖服务对礼品服务调用1万次。
那也要和抽奖服务同样处理吗?
其实并不用,因为发送通知不要求及时性,完全可以让一万个请求慢慢发送,这时就要用到消息中间件,进行限流削峰。
也就是说,抽奖服务把中奖信息发送到MQ,然后通知服务慢慢的从MQ中消费中奖消息,最终完成完礼品的发放,这也是我们会延迟一些收到中奖信息或者物流信息的原因。
假设两个通知服务实例每秒可以完成100个通知的发送,那么1万条消息也就是延迟100秒发放完毕罢了。
同样对MySQL的压力也会降低,那么数据库层面也是可以抗住的。
看一下最终结构图:
答题模板
所谓答题模板,就是高并发问题的几个思考方向和解决方案。
单一职责
一个基本的设计思想,回想高中物理的串联和并联,串联一灭全灭,并联各自有一个通路。
一样的道理,高内聚,低耦合。
微服务之所以兴起就是因为把复杂的功能进行拆分,即使网站崩了,无法下单,但是浏览功能依然健康,而不是所有服务引起连锁反应,像雪崩一样,全面瘫痪。
URL动态加密
这说的是防止恶意访问,有些爬虫或者刷量脚本会造成大量的请求访问你的接口,你更加不知道他会传什么参数给你,所以我们定义接口时一定要多加验证,因为不止是你的朋友调你的接口,敌人也有可能。
静态资源——CDN
CDN全称内容分发网络,是建立并覆盖在承载网之上,由分布在不同区域的边缘节点服务器群组成的分布式网络。
通俗的讲,就是把经常访问又费时的资源放在你附近的服务器上。
淘宝的图片访问,有98%的流量都走了CDN缓存。只有2%会回源到源站,节省了大量的服务器资源。
但是,如果在用户访问高峰期,图片内容大批量发生变化,大量用户的访问就会穿透cdn,对源站造成巨大的压力。
所以,对于图片这种静态资源,尽可能都放入CDN。
服务限流
在上面已有讲解,可分为前端限流和后端限流。
- 前端:按钮禁用,ip黑名单
- 后端:服务熔断,服务降级,权限验证
数据预热
可以采用定时任务(elastic-job)实时查询Druid,把热点数据放入redis缓存中。
思考一个问题:
比如现在库存只剩下1个了,我们高并发嘛,4个服务器一起查询了发现都是还有1个,那大家都觉得是自己抢到了,就都去扣库存,那结果就变成了-3,是的只有一个是真的抢到了,别的都是超卖的。咋办?
回答:
可以用CAS+LUA脚本实现。
Lua脚本是类似Redis事务,有一定的原子性,不会被其他命令插队,可以完成一些Redis事务性的操作。这点是关键。
写一个脚本把判断库存扣减库存的操作都写在一个脚本丢给Redis去做,那到0了后面的都Return False了是吧,一个失败了你修改一个开关,直接挡住所有的请求。
削峰填谷
精通一个中间件会给你加分很多
消息队列已经逐渐成为企业IT系统内部通信的核心手段。
它具有低耦合、可靠投递、广播、流量控制、最终一致性等一系列功能,成为异步RPC的主要手段之一。
当今市面上有很多主流的消息中间件,如老牌的ActiveMQ、RabbitMQ,炙手可热的Kafka,阿里巴巴自主开发RocketMQ等。
最原始的MQ,生产者先将消息投递一个叫做「队列」的容器中,然后再从这个容器中取出消息,最后再转发给消费者,仅此而已。
更详细的MQ下文再续。
今天就学这么多,相信大家都对高并发系统有了初步的认识,面试官问起来也不至于无话可说,但是想要学好任重而道远,希望大家关注一条,带各位一起学习!
最后
⭐今天是坚持刷题更文的第52/100天
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上C C++开发知识点,真正体系化!
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新
而道远,希望大家关注一条,带各位一起学习!
最后
⭐今天是坚持刷题更文的第52/100天
[外链图片转存中…(img-awJj54YY-1715728974368)]
[外链图片转存中…(img-o9Mfv96E-1715728974368)]
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上C C++开发知识点,真正体系化!
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新