Go最新百万抽奖系统设计架构入门_抽奖系统设计 go(1)，程序设计+Golang+Web+数据库+框架+分布式

2401_84904391

于 2024-05-12 22:24:47 发布

阅读量530

点赞数 16

分类专栏：程序员文章标签： go 学习面试

本文链接：https://blog.csdn.net/2401_84904391/article/details/138770215

版权

程序员专栏收录该内容

60 篇文章 0 订阅

订阅专栏

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Go语言开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以戳这里获取

下面增加多个节点，并使用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节点状态，进而在网关或者负载均衡层面不再分发流量了，直接拒绝。
在这里插入图片描述
前端优化：
也可以把后续用户的按钮置灰色，让用户不能抽奖了，告知已经抽完了。

节点线程数优化之压测

tomcat容器相当于是会启动一个线程去执行，那么线程数如何设置呢？如果设置的线程数太少，就无法利用好CPU资源，造成资源浪费，也处理不了请求，线程数太多，也会对服务器造成压力，极端情况下导致宕机，所以需要对tomcat容器进行压测（一般线程数在200-500之间，具体情况需要测试），看服务器的硬件配置，使得tomcat线程数怎么设置比较好

V4：Mysql优化之读写分离

前面的基础之上，服务器既要往MySQL写中奖记录，又要读中数据，压力是很大的，而且写的过程中又会加写锁，导致效率低下，所以就要用到读写分离，可以直接用Redis代替MySQL数据库，做抽奖逻辑的操作，因为Redis基于内存，速度非常快，如果怕Redis顶不住，还可以给Redis配置集群，那如果说非要用mysql持久化数据咋办呢？很简单，在抽奖完全结束后，将Redis中的数据同步到MySQL中去即可，从而避免了在流量高峰的时候去操作MySQL，这样会有效率问题
在这里插入图片描述