时隔一年，重做黑马点评简历模板

先是问了我的一些情况，比如为什么要找实习，后面打不打算读研之类的，然后拷打项目1. 项目是自己做的还是有团队，上线了吗，现在还在用吗2. 项目遇到过什么问题（Redis+Lua脚本预检，乐观锁解决超卖问题）3. 乐观锁怎么解决超卖问题，如果用悲观锁会有什么问题4. 套餐抢购QPS能到多少5. 有测试过用了乐观锁以后性能能到达什么程度吗6. 还遇到过什么问题？（我说了用RabbitMQ优化抢购逻辑，异步下单和数据库扣减库存）7. 我描述这个场景面试官说不理解，让我共享屏幕画一下架构图。但我可没画过这东西，我就画了个顺序图，一开始还画错了。。。8. Lua脚本的流程是什么9. 你这个Redis和Lua脚本预检就相当于避免了超卖问题，为什么还需要在数据库用乐观锁来避免呢？（这个其实我也有点不太明白，我的项目就是黑马点评包装的，有没有佬解释一下）解释了一通之后，面试官说你的系统还没复杂到要用RabbitMQ。。。然后开始拷打下一个10. 项目分工，你的工作?11. 采集股票的数据源？12. 项目里有对这些采集到的数据加入量化分析吗？（好提议，以后看看能不能加上去）13. 有遇到什么问题吗（讲了用线程池来分片采集股票数据入库）14. 线程池怎么处理的15. 最近AI coding很火，你有用过吗？在用的过程中遇到什么问题，怎么解决的？手撕：给一个数组，按从小到大顺序返回其中k个数（这个题太简单了吧，我都怀疑是不是还有其他题，结果没有）

最近在忙着写毕设论文，论文降重和降ai是我遇到的一个非常头疼的问题，后来顺利解决了这件事情，特此发帖分享下论文降重降ai的骚操作。骚操作只有一个，那就是用SpeedAI直接降ai,顺便也能把查重率也给降了。我也试过用gpt,豆包，dicksuck降重，但我的评价是在speedai面前都得往后靠靠，还得是专门的降重ai效果好些。看到这你可能以为我在打广告，笑死，接下来我会教你怎么免费薅资本家羊毛。speedai查ai是免费的，降重降ai要消耗点数，注册就送2500点数，发xhs集赞也可以得免费最高10000点数。什么xhs发帖集赞都多余了，直接去xhs给别人发的集好赞的帖子截图发客服，都不怎么审...

问题1：为什么会使用分库分表，到达了什么样的数据级别才会去加设计，是否对数据量有一个统计我的理解：看星哥之前写过 单表行数超 500 万行或者单表容量超过 2GB，推荐分库分表，但是面试的过程中怕被问自己写的项目会有这么大的数据量吗不要这么硬背，具体情况具体分析，有的表字段少，经常是条件等值查询，这样加个索引，一个亿也不用分表，有的字段多，还是范围查询，可能5000万就得分表，面试官问你你说是自己在学习分库分表应用到项目中，自己造了几千万的数据量问题2：基因法需要分表的一个数量和确定的一个东西（我的理解是分表的依据，例如大麦中是订单编号和用户id），但是正常的生产环境中是可能动态改变的，比如说需要动态扩容的话，怎么解决呢（例如当前有4个分表，但是现在需要扩充到8个分表），是使用双写吗？这个在扩容前就要考虑好能维持多少年内不需要再扩容。转转架构师在分库分表前，通过之前记录的数据增长量，做了256张表，能在7年内不需要再扩容，如果需要扩容的话，可以使用双写，新扩容表写的过程中，用新的分库分表算法问题3：如果在防止超卖的过程中，Redis不可用了，怎么解决我的理解：使用Redis集群和主从复制吗？因为Redis宕机的话数据库的数据也不能保证是最新的版本，所以得尽量保证Redis不宕机？肯定要使用redis集群模式，但可能会有主从延迟，导致从节点数据不是最新的，但关系不大。可以在用户生成订单后，修改数据库的座位和库存，然后用户支付后，再改数据库的座位和库存，每一步都做好验证。这样从节点的数据问题会降到最低。问题4：如果在当前的幂等验证逻辑中，有一个消息所对应的幂等标识符是不存在的，按照现有的逻辑是可以执行的，但是幂等验证之后的业务系统异常了，这个时候应该怎么处理呢（即通过了幂等的验证，但是后面的服务down掉了，比如说下游抛了一个异常出来）【没太明白应该回答什么，是指需要将幂等标识符重新进行设置吗】异常了就异常了呗，把这个请求的标识从redis中删除了，就像分布式锁时，业务异常也要执行解锁一样，让下一个请求进来正常执行，然后设置好标识位问题5：本地缓存为什么使用Caffine呢，为啥不用Guava因为caffine的性能要远高于Guava，没有其他复杂原因我的理解：查了下Caffine就是Guava改进而来的，可以这么说吗- Caffine在读写操作方面的性能更高，是基于异步的操作，将淘汰过期操作与读写进行分离- Caffine采用了一种结合 LRU、LFU的算法W-TinyLFU+，具有高命中率，低内存占用的特点

问题引入这个问题其实是一个非常实际的问题，因为我们在开发需求后，例如：新增了一个接口有一个步骤是值得做的，那就是预估这个接口的QPS因为我们是可以去调配对应服务器的数量和运行配置的例如我可以从2个节点新增为4个节点例如我可以将节点的内存从2G变成4G，2核CPU变成4核CPU如果因为 没有正确的预估 以及 没有正确的调整，导致接口的QPS过高，扛不住系统崩溃，那就是严重的外网事故了注意，这里说的预估QPS，是假设有一个真实的项目、真实的环境，预估这个接口上线后会有多少 QPS而不是在预估我们的系统接口本身能抗住多少QPS而不崩溃