> Hello，我的理解是这样的
> 广播流一般都是为了减少访问外部配置数据，提高性能来使用的，因此如果你是在这种场景下使用播流，我有一个在生产实践过的方法可供参考。
> 可以先在正常数据处理流的open方法中初始化访问一次配置，后续配置变更时再去使用广播中的数据对配置进行更新。如果硬要求某些数据必须在某个广播流配置数据更新后才能进行处理，则可以使用大佬们在上面提供的用state存储的方式进行解决。
> ------------------ 原始邮件 ------------------
> 发件人: Yun Gao < [hidden email] &gt;
> 发送时间: 2020年5月24日 13:56
> 收件人: 462329521 < [hidden email] &gt;, user-zh < [hidden email]
> 主题: 回复：使用广播流要怎么保证广播流比数据流先到？
> Hello，据我了解，现在应该法有办法做到让一个流先到。
> 一种workaround的方法应该是在广播流全部到达之前，通过state先缓存收到的数据；然后等到广播流到达后再进行处理。
> ------------------------------------------------------------------
> Sender:462329521< [hidden email] &gt;
> Date:2020/05/24 11:32:17
> Recipient:user-zh< [hidden email] &gt;
> Theme:使用广播流要怎么保证广播流比数据流先到？
> 你好，我想问一下我们在业务系统中需要广播流比数据流先到，要怎么保证这种先后顺序？
kris.


------------------&nbsp;原始邮件&nbsp;------------------
发件人:&nbsp;"tison"< [hidden email] &gt;;
发送时间:&nbsp;2020年5月24日(星期天) 晚上10:12
收件人:&nbsp;"user-zh"< [hidden email] &gt;;
抄送:&nbsp;"kris wu"< [hidden email] &gt;;
主题:&nbsp;Re: 使用广播流要怎么保证广播流比数据流先到？



高老师的方案应该是比较 make sense 的，你从网络上去限制某个先到后到很麻烦，而且就算可以，也会涉及 Flink
网络层很底层的逻辑。通常来说希望【先到】的含义是【先处理】，那你把物理上先到的缓存起来后处理就可以了。

Best,
tison.


1048262223 < [hidden email] &gt; 于2020年5月24日周日 下午2:08写道：

&gt; Hello，我的理解是这样的
&gt; 广播流一般都是为了减少访问外部配置数据，提高性能来使用的，因此如果你是在这种场景下使用播流，我有一个在生产实践过的方法可供参考。
&gt; 可以先在正常数据处理流的open方法中初始化访问一次配置，后续配置变更时再去使用广播中的数据对配置进行更新。如果硬要求某些数据必须在某个广播流配置数据更新后才能进行处理，则可以使用大佬们在上面提供的用state存储的方式进行解决。
&gt; ------------------ 原始邮件 ------------------
&gt; 发件人: Yun Gao < [hidden email] &amp;gt;
&gt; 发送时间: 2020年5月24日 13:56
&gt; 收件人: 462329521 < [hidden email] &amp;gt;, user-zh < [hidden email]
&gt; &amp;gt;
&gt; 主题: 回复：使用广播流要怎么保证广播流比数据流先到？
&gt; Hello，据我了解，现在应该法有办法做到让一个流先到。
&gt; 一种workaround的方法应该是在广播流全部到达之前，通过state先缓存收到的数据；然后等到广播流到达后再进行处理。
&gt; ------------------------------------------------------------------
&gt; Sender:462329521< [hidden email] &amp;gt;
&gt; Date:2020/05/24 11:32:17
&gt; Recipient:user-zh< [hidden email] &amp;gt;
&gt; Theme:使用广播流要怎么保证广播流比数据流先到？
&gt; 你好，我想问一下我们在业务系统中需要广播流比数据流先到，要怎么保证这种先后顺序？ Hello~ 如果考虑内存大小的话，有没有可能使用像rocksdb statebackend ? 还有一种可能是现在flink也提供了一种spilled heapbackend，它可以控制state使用的最大内存，不过暂时还是预览版本 [1]

[1] https://flink-packages.org/packages/spillable-state-backend-for-flink



------------------Original Mail ------------------
Sender:kris wu < [hidden email] >
Send Date:Sun May 24 23:38:30 2020
Recipients:user-zh < [hidden email] >
Subject:回复： 使用广播流要怎么保证广播流比数据流先到？
我们也想过先把数据缓存起来，等广播流到了再处理。但是这样会有风险，万一时间太长，内存可能就直接扛不住了。


Best,
kris.


------------------&nbsp;原始邮件&nbsp;------------------
发件人:&nbsp;"tison"< [hidden email] &gt;;
发送时间:&nbsp;2020年5月24日(星期天) 晚上10:12
收件人:&nbsp;"user-zh"< [hidden email] &gt;;
抄送:&nbsp;"kris wu"< [hidden email] &gt;;
主题:&nbsp;Re: 使用广播流要怎么保证广播流比数据流先到？



高老师的方案应该是比较 make sense 的，你从网络上去限制某个先到后到很麻烦，而且就算可以，也会涉及 Flink
网络层很底层的逻辑。通常来说希望【先到】的含义是【先处理】，那你把物理上先到的缓存起来后处理就可以了。

Best,
tison.


1048262223 < [hidden email] &gt; 于2020年5月24日周日 下午2:08写道：

&gt; Hello，我的理解是这样的
&gt; 广播流一般都是为了减少访问外部配置数据，提高性能来使用的，因此如果你是在这种场景下使用播流，我有一个在生产实践过的方法可供参考。
&gt; 可以先在正常数据处理流的open方法中初始化访问一次配置，后续配置变更时再去使用广播中的数据对配置进行更新。如果硬要求某些数据必须在某个广播流配置数据更新后才能进行处理，则可以使用大佬们在上面提供的用state存储的方式进行解决。
&gt; ------------------ 原始邮件 ------------------
&gt; 发件人: Yun Gao < [hidden email] &amp;gt;
&gt; 发送时间: 2020年5月24日 13:56
&gt; 收件人: 462329521 < [hidden email] &amp;gt;, user-zh < [hidden email]
&gt; &amp;gt;
&gt; 主题: 回复：使用广播流要怎么保证广播流比数据流先到？
&gt; Hello，据我了解，现在应该法有办法做到让一个流先到。
&gt; 一种workaround的方法应该是在广播流全部到达之前，通过state先缓存收到的数据；然后等到广播流到达后再进行处理。
&gt; ------------------------------------------------------------------
&gt; Sender:462329521< [hidden email] &amp;gt;
&gt; Date:2020/05/24 11:32:17
&gt; Recipient:user-zh< [hidden email] &amp;gt;
&gt; Theme:使用广播流要怎么保证广播流比数据流先到？
&gt; 你好，我想问一下我们在业务系统中需要广播流比数据流先到，要怎么保证这种先后顺序？