前几天，我的一个学员跟我说，在一个Java秋招交流群里，有个小同学正在那凡尔赛地秀自己的3个大厂offer和简历。
简历如下：
这个小同学还在群里说了一下自己的思路，在简历中的项目选型上：
（1）选择业务背景能让面试官秒懂的项目。这样，一天面试20+场的面试官，就不会因为懒得动脑子理解项目背景，而去全程问八股文。
（2）选择技术难度80分的项目。因为技术难度太低了，项目也就没价值了；技术难度太高了，自己如果hold不住，有可能会被经验丰富的面试官全程吊打。
接下来要做的事情，就是把自己擅长的八股文全部堆砌在项目上，这样面试官只要考查项目，那就全部精准命中在这个同学提前设置好的"埋伏"中。
这个同学还补充道："如果某方面的八股文自己不太擅长，但对于这个项目来讲是个好的技术亮点，那也写上，然后自己再花时间硬啃下来。"
不得不说，这个同学是懂面试的，二巴巴的面试官真的会被他玩弄于股掌之上。
并且，985的学历，加上两段大厂实习经历，也着实为他增加了很多的硬核竞争力。
另外，其实他简历项目中的技术解决方案，还是存在很多漏洞的，如果真的拿到3个大厂offer的话，证明面试官也确实是菜的。
下面我们从技术的角度，逐条分析一下，毕竟纯玩儿嘴炮不是我的风格，哈哈~
消息中心项目
1、使用责任链模式开发消息发送前置验证逻辑，完成必填校验、数据校验、黑名单等逻辑
我从未在任何成熟的商业项目中，看到消息前置校验环节用到职责链模式的，场景完全不适合。
（1）职责链模式是校验 + 处理的结合体，而消息前置校验逻辑并不涉及处理。
（2）一个纯的职责链模式要求一个处理者对象只能在两个行为中选择一个，要么全部处理，要么向下传递，不允许出现全部处理 + 向下传递的情况，但消息前置校验逻辑显然不是。
（3）包括职责链模式的这些优点：（处理者间）分离职责、（链条）动态组合、（发起者和处理者）低耦合、（新增处理者）符合开闭原则，在消息前置校验逻辑中根本体现不到，有为了使用而使用之嫌。
2、通过 MySQL BinLog 结合 RocketMQ 异步更新缓存，保证数据库和缓存之间的数据最终一致性
缓存本身可以起到提升系统性能，减轻数据库压力的作用。但从硬币的两面性来讲，引入缓存也就引入了数据一致性的问题，提升了系统复杂度。
可是，如果为了解决最终一致性的问题，再引入MQ，反而继续提升了系统复杂度，违反了系统设计的KISS（Keep It Simple and Stupid）原则。
有经验的面试官，如果问一句"如果MQ挂了怎么办"，就直接可以把一名缺乏经验的校招候选人问到瞠目结舌。
我认为，解决数据库和缓存一致性的问题，最好的方式只有"延时双删"。
3、使用线程池提高消息队列客户端消费性能，并通过 Hippo4j 框架监控线程池&解决消息积压问题
话说，这么高大上的解决方案，用在消息中心的性能优化和防积压上，真的有点儿牛刀杀鸡了。
我们可以这样算一下，假设发消息接口RT是100ms，Tomcat默认线程池是200，且这种场景不会出现CPU和网络瓶颈，那么单服务节点每秒钟能处理的消息数为2000条。
接着算一下，每个小时是3600秒 * 2000条 = 720万条，每天就是720万 * 24 = 1.728亿，如果部署8个节点的话，足够给全国13亿中国人每人发一条消息了。
这个场景还需要做性能优化？？？难不成这小同学开发的这个消息中心是给全银河系用的？
4、通过自定义注解和 Redis 缓存解决 RocketMQ 可能存在的重复消费问题，保障客户端消费正确
MQ的重复消费问题，有且只有一种解法，那就是根据某唯一key进行幂等性校验，这小同学通过自定义注解和Redis缓存如何解决，我不得而知了，哈哈哈~
5、使用 ShardingSphere 中间件，对消息发送业务进行分表处理，并通过复合分片算法满足多种维度查询需求
消息通知类存在非常明显的时效性，通过日期进行分表是最合理的方式，完全没有必要用复合分片。
另外，无论如何进行复合分片，只要在查询条件中没有分表键，都只能所有表全部查一遍，再进行多路归并，把结果聚合出来。
所以，我也不得而知，这小同学如何满足的多种维度查询需求。如果我是他的面试官，倒还真想好好跟他聊聊。
大众点评项目
这个项目中提到的缓存一致性问题，上文已经进行了分析，就不再过多赘述了。
1、秒杀性能优化：MQ消息队列 + Lua脚本实现异步处理下单流程，将同步下单改为异步下单，优化了秒杀业务的流程，平均耗时从400多ms降低到100多ms
这里面应该有表述上的错误，不是"将同步下单改为异步下单"，而是"将同步下单中的部分非核心流程异步化"，比如：下单成功后发消息给结算平台和用户中心（新客变老客）。
只有这样，"平均耗时从400多ms降低到100多ms"才可以解释得通，且整体的技术方案才合理。
2、用户权限的保存：通过Threadlocal配合拦截器来进行token的校验，判断当前用户是否处于登录状态，并解决了HTTP无状态的问题，到服务器记住用户信息的效果
哈哈哈，这条写得有点儿原形毕露了，Threadlocal进行token校验，一看就是应用服务器的大单机模式。
服务器集群模式，如果想要进行token校验的话，只能借助于Redis或MySQL。
另外，小同学还挺厉害的，把HTTP无状态的问题都给解决了，666啊。
我想说的是，人家HTTP本身就是无状态协议好不好，就像环肥燕瘦两相宜一样，这是人家的特性，而那不是人家的问题啊。
结语
当然，毕竟人家小同学还是应届生，按我上文这么针对性地进行分析，还是有些以大欺小之嫌的。
主要也是想借这个机会，阐述一些有关于简历和技术的观点而已，如果大家看着能从中有所收获，那就再好不过了，以后我可以再写几篇类似文章。