
150
|
第
11
章
模式的例子如图
11-5
所示。
7月 7月 7月 7月 7月 7月 7月 7月 7月7月 7月7月
图 11-5:数据量每日循环的例子
处理此类数据的应用程序会极大地受益于能随着需求的增加而扩容以及随着需求的减少而
缩容的能力。适当的伸缩可以确保应用程序有足够的容量及时处理所有事件,不会因过度
配置而浪费资源。理想情况下,接收事件到完全处理完事件之间的延迟应该尽可能小,尽
管许多应用程序对暂时升高的延迟并不敏感。
伸缩应用程序与伸缩集群是不同的。这里讨论的所有伸缩都是在集群有足够
资源的前提下来提升应用程序的并行度。有关集群资源的伸缩,请参阅框架
文档。
无状态流的应用程序非常易于扩缩容。应用程序的新处理资源可以被轻易地加入消费者组
或从中移除,加入或移除时,消费者组会进行资源再平衡并恢复流处理。处理有状态的应
用程序则要困难得多:不仅要加载状态到分配给应用程序的工作者节点上,还要让加载的
状态匹配输入事件流分区的分配。
伸缩有状态的应用程序有两种主要策略,虽然具体的策略因技术而异,但它们有一个共同
的目标,即最小化应用程序的中断时间。
11.7.1
伸缩运行中的应用程序
第一个策略允许你移除、添加或重新分配应用程序实例,而不会停止应用程序或影响处
理的准确性。只有某些重量级流框架具有这种能力,因为它需要仔细地处理状态和洗牌
事件。实例的添加和移除都需要重新分布所有已分配的流分区并从上一个检查点重新加
载状态。图
1
1-6
展示了一个常规的洗牌,其中每个下游的
reduce
操作都从来自上游的
groupByKey ...