Azure 数据工厂中的多线程同步性质

问题描述 投票:0回答:1

对于可能令人困惑的标题,我深表歉意,但我有一个困境,当我是一名 Java 软件开发人员时,我知道如何解决,但在 Azure 数据工厂工作时需要帮助。

我正在访问一个数据源来加载数据(到 SQL 数据库中,但目标与当前的问题无关)。

有两个端点

http://<same-base-url>/abc-endPoint
and
http://<same-base-url>/xyz-endPoint

数据加载彼此独立 - kust 2 个独立的数据加载。 使用我将其外部化到单独管道的三足身份验证。

运行后会提供 新鲜的不记名代币

  • KeyVault 和
  • 在输出变量中。

所以,我以后有两种使用不记名令牌的方法。从密钥保管库获取它,或者运行授权活动并获取输出变量。

因此,我正在运行 2 个管道,每个管道都有一个循环通过分页 REST 响应的 loo(直到活动)。他们从字面上复制另一个,唯一的区别在于基本网址的“abc-endPoint”与“xyz-endPoint”。

问题是这样的: 由于页面很多,并且运行可能需要很长时间,因此我在循环的每次迭代上运行授权。在大多数情况下,事情进展顺利,但是当 2 个管道运行时,有时单独的授权可能会失败并出现错误

Operation on target Get Refresh token failed: {"error":"invalid_grant","error_description":"The refresh token is invalid or expired."}

作为一名程序员,我知道管道授权可能会使刚刚授权但尚未完成的其他管道的刷新令牌无效。

ADF 中是否有选项可以处理此问题?有点像同步对变量的访问(如果用编程语言术语来说)??

multithreading azure synchronization azure-data-factory data-synchronization
1个回答
0
投票

微软不会撤销之前发行的令牌。这适用于访问令牌和刷新令牌。

如果您要为循环的每次迭代进行身份验证并获取访问令牌,则不需要刷新令牌。您通过在某个时刻针对 OAuth 2.0 端点进行身份验证来获取访问令牌。因此,只需在每次迭代中使用服务主体的凭据进行身份验证,并在每个 API 请求中使用新的访问(承载)令牌即可。

但是,找到问题根本原因的真正线索是您向 OAuth 端点过度发出请求,并提到有时第二个管道会导致失败。

听起来您实际上已经达到了 Microsoft Identity Server/OAuth API 的限制。

我建议您正确观察访问令牌的生命周期。当您验证服务主体时,您收到的响应将包含一个

expires_in
值。这是访问令牌过期之前的秒数。这将持续 60 到 90 分钟。刷新令牌的有效期可能在 60 到 90 天之间,除非您有自定义策略或条件访问。

重构您的代码。将局部变量设置为系统时间并添加秒数减去 5 分钟。然后,在循环中,根据变量中的到期时间检查系统时间。如果更大,则只能使用服务主体凭据重新进行身份验证。

如果您坚持使用刷新令牌来获取新的访问令牌,请记住使用新的刷新令牌在 KeyVault 中更新它,新的刷新令牌将随新的访问令牌一起返回。它会在某个时候过期。否则,我认为没有必要将其存储在 KeyVault 中;特别是如果它没有被任何东西检索到的话。

© www.soinside.com 2019 - 2024. All rights reserved.