项目简单？烂大街？那是你没有掌握核心技巧！

项目的问题

目前有不少小伙伴在网上学习免费的项目来学习，但有个问题，就是一旦项目热度高了后，使用的人多了。面试官看的多了，也就会有所谓的“烂大街”问题。这要怎么办？

目前网上的项目就已经很多了，各种各样的业务都有，其实最根本的原因不是在项目上，而是项目中要有核心业务亮点和解决复杂问题的落地方案

就拿设计模式来说，不少项目都是没有设计模式，或者强行使用设计模式，结果被人拿去面试了，面试官觉得你说的也不合理啊！明明不适用的场景，非得硬往上扯！

另一个关键性的原因是业务中对于细节的把控不够严谨，让面试官一眼就看出你这个项目是个玩具，根本不是生产上真正使用的。

举一个例子：对于缓存和数据库的一致性的问题，有的方案是说用到延迟双删。说实话，真正做过业务的都会觉得这个方案很扯！延迟删？那具体什么时候延迟删？1s？5s？复杂一点的业务在执行中的耗时没法精确把控啊！一旦耗时超过了这个延迟删的时间，那数据的一致性不就不能保证了吗？

但是！还真的有人拿这个方案去面试，结果当然是挂了。所以真正的项目是一定要贴合的业务来做思考的。有一句话说的非常的好：技术始终是为业务而服务的。

项目的重点

那么如果能有一个好项目，里面的亮点和方案都足够吸引人，使用场景也合理，其实就不存在烂大街的问题了。即使这个项目被很多人用了，我们依然可以把里面的亮点拿出来套用到另一个项目上（前提依旧是要合理！）

举例

就比如说都要被讲烂了的分布式锁，但又有多少人真的算是完全掌握了分布式锁的技术呢？

其实在设计分布式锁时，绝对不是一行lock.lock就可以的。你要考虑它的细节有很多，比如：

• 在方法里还是方法外使用？
• 多个事务存在的话需要去考虑吗？
• 如果利用注解那么要考虑其他切面的关系吗？
• 提供哪些策略呢？
• 锁的超时和拒绝方案怎么处理？
• 锁的粒度该怎么来设计？

我就举了这一个分布式锁的例子，目前网上的项目有几个能考虑真正全面的？但是！一旦能真正的掌握了，那么就可以完全套用在别的项目上，项目业务会烂大街，但你回答这个亮点不会烂大街啊！

所谓的授人以鱼不如授人以渔，正是这个意思，学了再多项目，如果项目本身质量不行，只会常规的CRUD，那么终究还是逃不掉“烂大街”问题。面试时依旧不能让面试官觉得你比较牛逼，技术也依旧得不到提高。

如何找到好项目

到这里，我们知道了问题的根本是能有学习到真正亮点的项目，那么怎么能找到？这里推荐一个很不错的项目：“大麦”

项目优势

大家对于订票时尤其是热门明星的演唱会，第一感觉就是票不好抢，一瞬间票就没有了，而本项目不仅仅是将上述的购票功能实现，并且还要解决这种票不好抢，也就是常说的 高并发 问题

小伙伴通过此项目能够掌握分布式微服务项目的设计、以及 真实生产环境的高并发解决方案。而且项目中遵循了 高内聚，低耦合，设计原则以及使用大量的设计模式来进行架构设计，相信小伙伴学习完此项目后技术会提升几个层次

项目中包括了 微服务、本地缓存/分布式缓存、消息队列、搜索引擎、并发编程、本地锁/分布式锁、设计模式、分库分表 等核心技术

项目中的各个亮点部分

项目的亮点可以分成多个部分，比如涉及到用户服务的业务时，项目在海量并发的场景下的问题：

• 用户服务如何设计分库分表，存在用户邮箱、用户手机号多种方式登录，要怎么设计不会发生读扩散问题？

• 当一瞬间有大量的用户注册请求时，如何防止 缓存穿透问题？网上说的那些方案到底靠谱吗？到底要怎么解决并且不影响用户体验？

• 用户和购票人数据为了应对高并发的场景下，在缓存中要怎么设计？把所有数据都放进去吗？

• 如何设计缓存策略？采取哪种结构来存储？采取哪种维度来存储？哪些数据适合放入缓存？哪些不适合？

在用户进行浏览的过程中，对于问题的存在同样也不少：

• 如何应对高并发下的用户查询请求？在主页列表、类型列表、的请求查看下，如何将设计分库分表的数据查询方案？

• 节目详情要怎么设计缓存？有了Redis就可以了吗？突发性流量激增的问题怎么解决？

• 如何设计多级缓存来应对几十万，甚至几百万的访问压力？如何发生了缓存雪崩要解决解决和提前预防？

而在用户购票的流程中，为了解决高并发的压力，需要考虑的问题和细节就会更多：

• 如何应对高并发下的用户购票压力？在购票流程中怎么考虑缓存和数据库的交互？

• 库存数量在缓存中应该如何设计？用户购票和支付过程中，要怎么正确的扣除库存？异常了怎么回滚？数据库中的余票数量一致性要如何解决？

• 分布式锁使用起来的细节到底有哪些？只要加上一行锁就可以了吗？

• 高并发下的分布式锁如何进一步的优化？锁的粒度？网络请求的性能？

• 幂等功能如何实现？有哪些维度需要考虑？

• 经典的缓存数据库一致性的问题实际生产环境中到底如何解决？直接删除缓存、延迟双删 这些方案到底可行吗？

而在整个项目的架构设计上，也有很多的问题存在：

• 高并发下订单延迟关闭功能如何实现？使用中间件作为延迟队列的问题？使用redis作为延迟队列可以吗？如何提高性能？

• 分布式id如何生成？经典的雪花算法？直接使用MybatisPlus中的生成策略可以吗？有什么问题？

• 订单的分库分表如何设计？既要支持订单详情查询、又要支持订单列表查询而不发生读扩散？

• 如何执行灵活的限流规则？能支持到某个时间段、某个请求、并能记录下异常行为信息？

• 项目的架构配置、服务配置、数据结构要如何统一设计和管理？异常如何捕获？

• ... ... ... ...

这里只是将常见的问题列举了一下，而在本项目中解决的问题远不止上述列举这些，小伙伴可在学习时带着某个问题来思考，在项目中找到问题的答案

技术结构

架构和组件设计

业务流程

项目介绍

• 项目地址： https://gitee.com/java-up-up/damai
• 在线体验： https://www.damai-javaup.chat
• 文档讲解： https://www.javaup.chat/pages/83cf22