 |
1
Kyle18Tang Dec 8, 2021  1
同一时间点是日志时间一模一样? 有没有弄链路追踪通过 TraceId 看看链路呢.
|
 |
2
Saxton Dec 8, 2021 1
内部互调为什么要走网关？
|
|
3
Saxton Dec 8, 2021 1
应该先从网关开始排查，如果是用 spring cloud gateway 的话随便找个 filter 打个断点就知道了，靠猜想没用，实践才是唯一真理
|
 |
4
woduzibue OP @Kyle18Tang 不是同一个内部的服务，之前老伙计写的链路追踪不到
@Saxton 不是内部的服务，B 服务是外部服务，就是偶现的不好排查，我后面试试能不能本地复现 现在快速解决问题我说的两种加锁方式可行么？有没有什么其他好的时间方法 |
 |
5
javapythongo Dec 8, 2021 1
每一次请求加上一个随机数吧
|
 |
6
yiheweigui Dec 8, 2021 1
cloud 只会发一个请求，既然发了两个，就是调了两次。
要么就是 a 调了 b 两次，要么就是熔断限流什么的，在补偿的时候多调了一次，估计是用法不当，正常使用也走补偿。 至于你遇到这种问题就想通过幂等性来解决，要看这个业务是不是适合幂等。 至于加锁，就别玩了，动不动就锁，高并发的情况下，人家秒杀的需求就是要并发修改同一行。 搞个分布式，又经常加锁，分布式的意义就是专门花大力气搞得很复杂，只是为了解耦分包开发？什么集群是加倍性能还是减弱性能？ |
|
8
woduzibue OP @javapythongo 意思是通过随机数确认是不是同一个请求是吧
@yiheweigui 我的认知下也觉得请求应该只有一个，可能中间有地方使用错误。当前只是偶现的情况，也不排除是 C 服务同时调用了两次，所以想通过加锁的方式拦截掉相同的请求。当前的业务场景是用户同步一批设置项，数据库里一个用户对应一条记录，之前考虑加锁应该没问题，基本不存在同一个用户同一时间很多次去同步数据库。多谢大佬指点 |
|
10
woduzibue OP @Saxton 对的，现在就是暂时不清楚是 C [同一时间] 调用了两次 A 导致 A 调用了两次 B ， 还是 A 之前写法有问题 这里重复调用了两次 B 。又着急修复，所以想着加锁这种 头痛医脚的方法
|
 |
11
xuanbg Dec 8, 2021 1
内部调用不用走网关
|
 |
14
z960112559 Dec 8, 2021 1
是不是网关的 ribbon 或者 hystrix 做了重试？ hystrix 是不是没设置超时时间（默认 1 秒超时）
|
|
15
z960112559 Dec 8, 2021 1
问题比现的话可以本地 debug 一下
|
 |
16
Amit Dec 8, 2021 1
Feign 默认是有重试机制的,但是如果是重试的话时间应该会差个几秒
|
|
17
woduzibue OP @z960112559 @Amit 被调用方那边有两条秒数都一样的请求 log 是两个线程的，导致他那边服务崩掉了。 主要还是偶现的，不太好复现，所以想找一种兜底的方法。
|
 |
18
kaz10025 Dec 8, 2021 1
两次请求的时间戳都一样吗？感觉还是得找到源头
|
|
19
woduzibue OP @kaz10025 时间戳一毛一样，主要是调用的源头也不在我这，我刚接手 一个多月之前的 log 日志也不太好找。还是偶现的。源头后面等复现了还是要找的。
|
 |
20
cheng6563 Dec 8, 2021 1
如果程序直接写库那就直接用事务加行锁就行了，先把锁都加上解决冲突问题，之后再想办法分离锁提高性能。
|
Select Language