真实记录：实现90%提升的优化策略实录

李致标
83 阅读5分钟

引言

本文旨在探讨如何通过一系列架构升级策略，将一个普通的选课系统转变为一个并发量高且稳定的系统。之前看过许多文章标题可能过于的有点夸张要么就是十几秒级别到毫秒级别的，于是就把我的膝盖送给了他，厉害。

背景

在本人大一期间进行参与校园的选课时，由于学校的选课系统比较“陋”，只要是个人都不想上早八，尽可能的选择线上的课程，毕竟嘛是“线上开黑课”，那在近万人同时参与选课，线上课的概率可能也就是2% ,再加上学校的loubi系统时不时就是500，一卡我就开喷。tmd这么lou的系统怎么能抢到我满意的课程呢？正是基于这样的背景和个人经历，我产生了深入研究并提出改进方案的想法。在《选课风云》专栏中，我将分享我的思考和解决方案，旨在构建一个能够应对高并发、高稳定性的选课系统，让每位早八人都能在公平、高效的环境中选择到自己满意的网课。

技术选型

  • 语言

    • Go

  • 框架

    • Gin

  • 数据库

    • Mysql

  • 缓存

    • Redis

  • 消息队列

    • RabbitMQ

  • 微服务框架

    • go-grpc

  • 服务治理

    • Consul
    • Sentine
    • Jaeger

  • 监控

    • Prometheus
    • Grafana

  • 日志采集

    • ELasticsearch
    • Influxdb
    • Kibana

  • 网关服务

    • Nginx

主要探讨

  • 如何设计选课
  • 如何解决在万人系统上单机做到稳定且容错低
  • 如何解决选课时间冲突
  • 等

涉及知识

  • 锁
  • 事务
  • 位图
  • 位运算
  • Bloom
  • 数据安全
  • 数据一致性
  • 补偿机制
  • 等

并发测试

以下测压通过jemter进行做测压工作，分为：获取用户信息接口、选课接口、退课接口同时进行模拟1000用户和2000用户进行每个接口执行2次操作。其中异常率无需关心（选课没选上返回400）

  • 规格1

    • 1000（thread）用户
    • 2次

  • 规格2

    • 2000（thread）用户
    • 2次

测压一

主要技术

  • Gin
  • MySQL

相关期文

问题

  • 大量请求造成MySQL抗不住

测压二

主要技术

  • Gin
  • MySQL
  • Redis

相关期文

问题

可以看到为什么使用到了Redis竟然吞吐量都没存MySQL高，到这里要说明Redis只是进行了预扣库存的操作，然后通过Go协程后台入库。显然就存在问题了数据的安全和大量的Go协程（最少也有万把个且都是执行长任务）

测压三

主要技术

  • Gin
  • MySQL
  • Redis
  • RabbitMQ

相关期文

问题

当某个服务处理慢请求或大量并发请求时，会占用较多资源，导致其他服务因资源不足而阻塞或响应变慢。单体架构服务死亡，可能导致整个应用都有可能受到影响。

测压四

主要技术

  • Grpc
  • Gin
  • MySQL
  • Redis
  • RabbitMQ
  • Consul
  • Sentine
  • Jaeger
  • ...

相关期文

问题

受限于服务器，由于本测试环境基于vm虚拟机且单台机期服务启动过于多，导致受限。可以看到存在请求丢失的情况。

仓库

若有兴趣可以移步至仓库

github.com/bbz1024/sel…

其中分为多个Tag，对应着每次引入的技术而变化

github.com/bbz1024/sel…

总结

本专栏通过一系列的手段实现了一个可用的选课系统。通过架构升级，系统的吞吐量从MySQL时代的962次/秒显著提升到微服务架构下的1784次/秒，性能提升了近90%。如有疑问还请大佬在评论区交流指点。蟹蟹٩('ω')و

期文

avatar
文章
阅读
粉丝