这样解决问题亮点不就有了，一个问题证明你是高级开发，抽象能力很重要

咸鱼Kkkkkk1:
菜鸟才火急火燎看环境日志，高手第一时间都是看提交日志[嗑瓜子]

【回复】回复 @xiaoze0820 :[滑稽]先分锅再查问题，防止修完锅都扣自己头上
【回复】回复 @震宇6513 :git提交日志
极海SubChannel:
哥哥讲的真好，又学到了，下次面试就拿这个亮点来吹[喜极而泣]

【回复】面试官：为什么最近来面试的人亮点都一样[妙啊]
【回复】回复 @极海Channel : 单例亮点[doge]
【回复】实际开发中我们做的接口幂等就是拿业务流水号单独存一表中且设置唯一，接口前作这个，重复了抓异常提示勿重复提交
鸣明谦:
为什么几百毫秒就重试了！而且居然是因为时间重试吗！

【回复】回复 @极海Channel :你绝了，记忆力那么好。每次在评论区看到你跟人唠嗑
【回复】回复 @极海Channel :你得发视频，我才能评论是吧[星星眼][星星眼][星星眼][星星眼]
【回复】回复 @海鱼环宇 :[妙啊]卑微的维护粉丝岌岌可危的关系
可乐要多冰2416:
这种方案很常见啊、就是aop加redis分布式锁、加自定义注解、其实可以更抽象就是直接做成starter、

一个巴掌拍你脸上:
感谢，我又解决了一个线上问题[脱单doge]

六边形战士eby:
嗯，这个是我9月秋招简历上写的一处技术亮点，至于为什么简历筛选过不去，我表示很难受

【回复】不过我是根据业务参数生成的分布式锁，因为考虑到接口重复也并非ribben，客户端也能重复发起，traceid肯定是不同的
lombok-:
听明白了，就是抽象到aop切面去做这个接口幂等性？ 但是那个唯一标识是啥，怎么判断哪些接口需要做这个接口幂等性

【回复】一般来说就是traceid，一般保存在ThreadLocal或者MDC里面，分布式系统就用rpc转发一下。每个请求都会生产一个唯一traceid，然后这个请求执行流程的任意位置都可以获取到这个标识，然后通过切面去切某段代码逻辑，将这个标识作为锁，防止这段代码逻辑在一个请求中被多次执行。但不同的请求就没办法了
来一个道术合一:
感觉方案三弊端太多了，完全依赖一种全局通用唯一值才能实现aop层面的幂等，而且其实很多时候其实必须依靠业务唯一id来保证的，或者是某几个业务值来保证唯一性，所以其实方案1才是生产首选，方案三面试的时候吹吹就行了[脱单doge][脱单doge]

【回复】回复 @极海Channel :存在很多业务场景是，traceid不同，但是业务唯一id是相同的
【回复】回复 @Java课表 :就是没看懂所以才请教啊[笑哭]
【回复】回复 @jackson_fang :看和海哥对话就清楚了
shoaky:
注解还需要可以自定义的校验才行 比如充值类的业务需要看订单状态是否被处理过了

ice_liang:
这个情况在好多年前我用dubbo的时候也遇到过[吃瓜]

人生笔记-:
刚才 面试官：你怎么解决接口调用很卡的情况 我：我看看海哥怎么解决的

幸运酋长:
海哥，能不能抽空讲下初级高级专家的分界线，b站初级程序员比较多[打call]

小文110:
想起了dubbo 默认重试两次 不注意就是个坑