大麦订票服务系统提供了可以在线上对相应的节目（包括：演唱会、话剧歌剧、体育比赛、儿童亲子）进行订票的功能，用户可以进行注册，登录，然后选择节目和座位后进行购票，支付，以及查询自己的订单功能
除了大麦项目外，还提供了一个用于服务请求流量切换的项目：link-flow，既有着 控制微服务流量的业务功能，又有着 对微服务框架进行定制增强的轮子功能。而且不仅适用于实习，对于社招来说，也是能用到的！
高并发业务的大麦项目，再加上流量切换的link-flow项目，面试可以说是双剑合璧了。
- link-flow项目详细讲解： 👉 点击查看讲解
大家对于订票时尤其是热门明星的演唱会，第一感觉就是票不好抢，一瞬间票就没有了，而本项目不仅仅是将上述的购票功能实现，并且还要解决这种票不好抢，也就是常说的 高并发 问题
小伙伴通过此项目能够掌握分布式微服务项目的设计、以及 真实生产环境的高并发解决方案。而且项目中遵循了 高内聚 低耦合 设计原则以及使用大量的设计模式来进行架构设计，相信小伙伴学习完此项目后技术会提升几个层次
项目中包括了 微服务、本地缓存/分布式缓存、消息队列、搜索引擎、并发编程、本地锁/分布式锁、设计模式、分库分表 等核心技术
本项目由 VTEXS 的「开源项目免费 VPS 计划」提供算力支持。 感谢 VTEXS 对开源社区的支持！
-
使用了 SpringCloud+SpringCloudAlibaba 的微服务结构
-
使用了 Nacos 作为注册中心
-
使用 Redis 不仅仅作为缓存，还使用了
Lua脚本/延迟队列/Stream消息队列等高级特性 -
引入了 Kafka 消息中间件，SpringBootAdmin 作为服务的监控通知
-
ELK 作为日志的记录，ElasticSearch提供搜索和展示功能，
-
Sentinel/Hystrix 作为熔断保护层
-
使用 ShardingSphere 实现分库分表，来存储海量的数据
通过以上设计，来实现应对高并发、高吞吐的能力，以及海量数据的存储和服务状态的监控
通过此业务结构图进一步详细的介绍项目中的服务配置、技术选型、核心业务、基础组件、中间件的使用、监控方式等各个方面，方便大家能够对大麦项目的整体架构和设计有一个清晰的认知
针对于分布式和微服务的项目来说，随着业务的发展，项目的数量上千个都是很正常的，但如何要把这些项目做好配置，做好架构设计，设计出组件库，都是要考虑的因素
既然组件库是要给其他服务提供使用，所以在设计时要考虑的细节非常的多，设计模式和高内聚低耦合的思想更加的重要，而且代码的健壮性和高效率的执行也是同样重要，而在大麦项目中，使用了SpringBoot的自动装配机制来设计组件库
除了组件库外，还有对异常的处理、数据的封装格式、多线程的使用等等也都要进行相应的封装设计，这些在项目中同样具备
对于大麦项目来说，核心的业务就是用户选择节目然后进行购票功能了，项目中不仅完整了对整个业务流程的完整闭环，而且考虑到既然设计此项目是为了应对高并发的特点，那么在从业务的角度上也做了很多的优化设计
我也是一路过来的，所以很清楚大家的心态，希望是能和实际业务结合起来进行学习项目的架构设计技巧以及解决高并发的解决方案，
项目的亮点可以分成多个部分，比如涉及到用户服务的业务时，项目在海量并发的场景下的问题：
-
用户服务如何设计分库分表，存在用户邮箱、用户手机号多种方式登录，要怎么设计不会发生读扩散问题？
-
当一瞬间有大量的用户注册请求时，如何防止 缓存穿透问题？网上说的那些方案到底靠谱吗？到底要怎么解决并且不影响用户体验？
-
用户和购票人数据为了应对高并发的场景下，在缓存中要怎么设计？把所有数据都放进去吗？
-
如何设计缓存策略？采取哪种结构来存储？采取哪种维度来存储？哪些数据适合放入缓存？哪些不适合？
在用户进行浏览的过程中，对于问题的存在同样也不少：
-
如何应对高并发下的用户查询请求？在主页列表、类型列表、的请求查看下，如何将设计分库分表的数据查询方案？
-
节目详情要怎么设计缓存？有了Redis就可以了吗？突发性流量激增的问题怎么解决？
-
如何设计多级缓存来应对几十万，甚至几百万的访问压力？如果发生了缓存雪崩要如何解决和提前预防？
而在用户购票的流程中，为了解决高并发的压力，需要考虑的问题和细节就会更多：
-
如何应对高并发下的用户购票压力？在购票流程中怎么考虑缓存和数据库的交互？
-
库存数量在缓存中应该如何设计？用户购票和支付过程中，要怎么正确的扣除库存？异常了怎么回滚？数据库中的余票数量一致性要如何解决？
-
分布式锁使用起来的细节到底有哪些？只要加上一行锁就可以了吗？
-
高并发下的分布式锁如何进一步的优化？锁的粒度？网络请求的性能？
-
幂等功能如何实现？有哪些维度需要考虑？
-
经典的缓存数据库一致性的问题实际生产环境中到底如何解决？直接删除缓存、延迟双删 这些方案到底可行吗？
而在整个项目的架构设计上，也有很多的问题存在：
-
高并发下订单延迟关闭功能如何实现？使用中间件作为延迟队列的问题？使用redis作为延迟队列可以吗？如何提高性能？
-
分布式id如何生成？经典的雪花算法？直接使用MybatisPlus中的生成策略可以吗？有什么问题？
-
订单的分库分表如何设计？既要支持订单详情查询、又要支持订单列表查询而不发生读扩散？
-
如何执行灵活的限流规则？能支持到某个时间段、某个请求、并能记录下异常行为信息？
-
项目的架构配置、服务配置、数据结构要如何统一设计和管理？异常如何捕获？
-
... ... ... ...
这里只是将常见的问题列举了一下，而在本项目中解决的问题远不止上述列举这些，小伙伴可在学习时带着某个问题来思考，在项目中找到问题的答案
为了尽可能的还原，本项目尽可能贴近官网的页面设计和业务流程，小伙伴可以通过前端项目一边来学习业务，一边体会业务中调取了哪些后端接口，这种学习方式是简单且高效的，也建议小伙伴在学习公司的业务时也使用这种方式
