网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
前言
从宏观架构层面去考虑一个抽奖系统的设计,在不涉及过多中间件的情况下,最朴素的想法其实就是一个抽奖服务器(tomcat 或者Springboot搭建)、一个通知服务器、MySQL数据库,可以完成用户抽奖到被通知是否抽到奖的过程。
V1:Base设计
那么这个最简单的demo系统涉及到的问题就比较明显了:
- 单点问题:抽奖和通知服务器都是单点的,有单点风险,可以增加多个节点
- 负载均衡:如果增多节点,会涉及负载均衡问题(节点之间的访问规则,如果去降低服务器的访问压力),负载均衡可以用nginx,可以用轮询、一致性哈希、最近最少访问轮询算法
下面增加多个节点,并使用nginx实现负载均衡。
V2:考虑单点风险
从而将V1版本的单点服务器进化成了集群,提高了高可用(a节点挂了,b节点还能访问),从而避免了单点风险。
V3:考虑流量大
对于一个百万级、千万级的抽奖系统,流量必然非常大,如何进行考虑呢?当然,最暴力的方式就是无限的去横向扩展服务器(增大节点数,增大到十几万太服务器节点),但是这也不是无限制的,完全不现实,如何可以尽可能的用较少的硬件成本去解决问题呢?
流量大之限流
限流
如果流量非常大,应该去考虑限流,可以通过网关层面(gateway/sentinel)做限流,比如集群能承受最大压力为10万QPS(每秒查询率,Queries-per-second),就需要限流到8万QPS,并且一些恶意用户会去刷脚本,攻击服务器,这时候不仅要限流操作。
防攻击(ip限制)
还需要防攻击操作(ip限制),比如某个恶意用户1秒钟发送了很多抽奖请求,认定他为恶意用户,从而拉黑ip(ip限制可以再网关层面或者负载均衡层面去处理)。
拒绝无用流量
还需要去拒绝没必要的流量,比如有总共50万人抢1万个红包,前面1万个红包已经抢完了,后面的流量就要直接拒绝,而不是任由他来请求我们的服务器,这里需要知道什么时候奖抽完了,对应的就是一个抽奖状态,可以用中间件来做(Redis或者Zookeeper)
在负载均衡层面去访问Redis,如果已经抽完了,那么就直接拒绝后面的流量,就不用分发给具体服务器,直接返回给用户了。
如果用zookeeper,可以创建一个节点,在负载均衡或者网关层面去监听zookeeper节点,一旦抽奖结束后,就会更新zookeeper节点状态,进而在网关或者负载均衡层面不再分发流量了,直接拒绝。
前端优化:
也可以把后续用户的按钮置灰色,让用户不能抽奖了,告知已经抽完了。
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!**