值得学习的项目表达方式，高级开发就是这个标准，设计题有待提升但瑕不掩瑜

进击的小波:
1.redis带宽占用高，查监控是某个key的value很大，一开始是key-filed-value，查询返回所有模块的源，业务增长有几千个模块后，改成key-value，需要什么模块返回什么源就行，然后灰度发布问题 2.第二块没听太懂，集群本来是abc并发统计，加个分布式锁一个60s时间段只有一个模块统计，让我做改进我也不会（定时任务中心高可用？）。 3.本地消息表海哥之前发的视频直接讲过，消费失败后单独存到一张消息表，满足最终一致性即可，然后在事务结束后再发消息海哥的视频也讲过，我记得是海哥优化他团队的代码提了一嘴，那期顺带讲讲了spring的扩展点。 4.随后引出消息重复发送造成的幂等性问题，海哥也讲过，分布式锁+唯一索引，还有一个问题是哪些动作即使重复执行也不用管幂等，这个是我之前实习的老板讲的，订单从0update为1的动作可以不用管。 5.事务里面把锁相关的sql放事务后面，减少锁冲突的概率，海哥发视频讲过 6.mysql八股，事务隔离机制和相应的锁（record lock ,gap lock ,nextkey lock） 消息队列那我只会八股，没经验，聊天室之前好像发过，大概总结下，感觉海哥提问的很多都发视频讲过，分布式锁我看过redisson源码，我可能会引导面试官再追问我锁重入和续期问题。

【回复】2. 估计是负载均衡后，3个都触发定时任务，然后就各自取一部分去更新缓存吧。 其实这里我觉得有个问题，如果有一个1min钟没处理完，下一个定时任务就来了 最后一个聊天室，如果人没那么多，直接使用netty channel组就可以了吧
【回复】这是只有老粉才能写出来的评论[doge]补充一点 分布式锁主要防并发，幂等还要业务判断。
【回复】第二个我表述有问题，abc三台机器本来是并发统计，加了分布式锁就是拿到分布式锁的机器统计，感觉本来是并发，最后又弄成单体的感觉。
极海SubChannel:
学到了，的确在按照STAR法则描述项目，海哥也很好的细化每个问题的设计逻辑，穿插了很多精彩的八股文，甚至还会结合场景去变形，我作为面试官也学到很多！[星星眼][星星眼][星星眼]三连了！

【回复】回复 @极海Channel : 这 [微笑]
水橋こむぎ:
听了海哥那么多期面试，获得的最大收获还是明白了一个道理：在项目里你做了什么不是最重要的，最重要的是你需要向面试官展现你明不明白你做的这些事情解决了项目里的什么问题，这才是区分你懂技术还是背八股的指标。八股好背，融会贯通艰难啊[吃瓜]

【回复】回复 @极海Channel :嗨，关于融会贯通脑子里确实有不少想说的，但是组织语言的过程中，发现要把脑子里的想法组织成别人能理解的语言，真不是一件容易的事情，再次体会到了海哥当up主的不易。 前两次小作文能写的那么顺利，是我对于之前两个视频的内容本身就有挺多的思考，有一些片段自己已经写下来，丢在记事本里了，思路基本已经理通了。看完海哥视频，中间的连接处润色一下基本就直接成文了，这次相当于一个命题作文，看完视频，脑子里关于mysql有一堆想说的，关于融会贯通也有一堆想说的，但是有些东西还没理通[吃瓜]
【回复】回复 @水橋こむぎ :你是懂作文的[妙啊]
【回复】[doge]所以要事先准备好吗，这次不算小作文了还是在酝酿中
Clusters_stars:
两点问题 1.多集群计算任务，能否继续根据原方法，加入监控，如果挂了后再分配剩下的呢 2.消息队列的状态，既然有状态说明已经进存储了，这个是存储在数据库中，为什么不能直接Kafka消息队列发。如果不是存在数据库，难么这个状态怎么获取呢

【回复】所以第一个问题方案有待商榷，但是他把为什么这么做大概讲清楚了，另外就是后面的本地消息表讲的很不错[妙啊]
头发没了可以再长:
最后一道系统设计题：异步线程无法保证消息的有序性吧

底薪农民工:
insert和update这块，想起了很久前的项目亮点视频[吃瓜]

kekeslife:
设计题真的很容易崩溃的，没做过的根本不知道水有多深，如果是同类业务的那还好，如果是跨业务大一点的，真的很懵逼，就像让你设计一个仓储系统

【回复】@底薪农民工 确实是水很深，产品经理设计的很好，代码都写了百分90，才发现产品设计逻辑有问题，又推到重来
【回复】所以必要的讨论需求很重要[妙啊]
瘦了哈:
首页模块，并发很高的，没考虑本地缓存吗？[嗑瓜子]

【回复】感觉最开始为了提速，但是明明一个节点就可以跑，不知道是不是多线程，那所以无故制造问题再解决问题[doge]KPI有了
【回复】回复 @极海Channel :[吃瓜]，侧面看出了，设计是不太好的
【回复】或是页面静态化之类的[吃瓜]
NO丶空の轨迹:
海哥我想问，视频中本地消息表内容中，发送端在业务中也存一份消息，用一个定时任务去扫描库，这种方法会常用在最终一致性吗？

【回复】[妙啊]很常用而且是非常成熟可靠的方式
LeoxPL:
感觉第二块的问题主要出现在锁的粒度问题上。他是通过锁总任务的执行权限去控制谁计算。打个比方十个计算任务三个节点去计算，现在可以将锁加在每个计算任务上，让这三个节点去争抢每个任务的计算权限，就能够将任务平均分布到三个节点上去计算了