企业官网建设流程全解析

网站单页面怎么做的,网站设计公司山东烟台,经典软文案例50字,公司网站域名无法解析1. 快速开始#xff1a;依赖与基本骨架 FlinkCEP 不是 Flink binary 的默认组件#xff08;集群跑时需要把 jar 链接/分发到集群#xff09;#xff0c;你的项目里通常先加 Maven 依赖#xff1a; dependencygroupIdorg.apache.flink/groupId…1. 快速开始依赖与基本骨架FlinkCEP 不是 Flink binary 的默认组件集群跑时需要把 jar 链接/分发到集群你的项目里通常先加 Maven 依赖dependencygroupIdorg.apache.flink/groupIdartifactIdflink-cep/artifactIdversion2.2.0/version/dependency一个最小可运行的 CEP 骨架是输入流DataStreamEvent建议 event time watermark定义 Pattern模式图CEP.pattern(input, pattern)得到PatternStream用process(...)/select(...)把匹配输出成业务结果流另外有个容易忽略的要求参与匹配的事件对象需要正确实现equals()/hashCode()因为 CEP 内部会拿它们做比较和匹配。2. Pattern 的本质你在画一张“状态机图”官方说“pattern sequence is a graph”你可以把它理解为你用begin(start) - next(middle) - followedBy(end)这些 API在画一个事件序列状态机当事件流跑过来时CEP 会维护大量“部分匹配”partial match直到完整走完图才输出一个 match。每个 pattern 节点必须有唯一名字后面从MapString, ListEvent里取匹配结果就靠这个名字。注意pattern 名字不能包含:。3. 单个 Pattern 怎么写条件与类型约束3.1 where / or事件是否能“进入”这个节点where(...)必须满足条件才能被该节点接受多次where()连续调用是 ANDor(...)把条件变成 ORstart.where(SimpleCondition.of(e-e.getName().startsWith(foo))).or(SimpleCondition.of(e-e.getId()42));3.2 SimpleCondition vs IterativeCondition要不要看“历史”SimpleCondition只看当前事件本身最快、最简单IterativeCondition可以访问同一个 partial match 中先前已接受的事件功能强但要注意性能middle.oneOrMore().subtype(SubEvent.class).where(newIterativeConditionSubEvent(){Overridepublicbooleanfilter(SubEventvalue,ContextSubEventctx)throwsException{if(!value.getName().startsWith(foo))returnfalse;doublesumvalue.getPrice();for(Eventprev:ctx.getEventsForPattern(middle)){sumprev.getPrice();}returnsum5.0;}});经验建议ctx.getEventsForPattern(...)的成本会随匹配复杂度上涨能不用就不用或者尽量减少遍历次数。3.3 subtype类型过滤如果你的输入流类型是Event但某个节点只接受SubEventpattern.subtype(SubEvent.class).where(SimpleCondition.of(se-se.getVolume()10.0));4. 量词 Quantifier一次、N 次、范围、可选、贪婪CEP 里“单节点”默认只接收 1 条事件singleton。如果你要让一个节点接收多条looping pattern就用量词oneOrMore()至少 1 次btimes(n)恰好 n 次times(from, to)范围次数timesOrMore(n)至少 n 次optional()可出现 0 次greedy()尽可能多地吃当前只支持量词节点不支持 group 贪婪你可以把它当成正则里的 ? {m,n}start.times(2,4).optional().greedy();重要提醒对 looping patternoneOrMore/times强烈建议搭配within()或until()来清理状态不然在高吞吐长时间运行里partial match 会持续增长状态压力会很大。5. Pattern 之间的连续性next / followedBy / followedByAny这是 CEP 最“容易写错”的点因为写出来都能跑但输出差别巨大。5.1 next严格连续Strict Contiguitynext(b)要求 b 必须紧挨着 a中间不能有任何不匹配事件。5.2 followedBy宽松连续Relaxed Contiguity允许中间插入无关事件语义更像“跳过不匹配直到下一个匹配”。5.3 followedByAny非确定性宽松Non-deterministic Relaxed不仅允许插入无关事件还会产生更多组合匹配同一个 start 可以对应多个 middle/end匹配数量可能爆炸式增长。经典对比pattern “a b”输入a, c, b1, b2next无匹配c 破坏连续followedBy只匹配{a b1}followedByAny匹配{a b1}和{a b2}5.4 NOT 模式notNext / notFollowedBynotNext(x)紧接着不能出现 x否则丢弃该 partial matchnotFollowedBy(x)在两段之间任意位置不能出现 x注意两条限制pattern sequence 如果末尾是notFollowedBy()必须配within()NOT pattern 不能跟在 optional pattern 后面6. looping pattern 内部连续性consecutive 与 allowCombinations当你写oneOrMore()这种“多次”节点时节点内部默认是 relaxed contiguity。如果你希望“这些 repeated 事件必须紧挨着”用consecutive().oneOrMore().consecutive()如果你希望“重复节点内部也产生更多组合”类似 followedByAny 的组合爆炸用allowCombinations().oneOrMore().allowCombinations()工程上要谨慎allowCombinations()很容易导致匹配结果数量急剧上升尤其在高基数 key 或热点 key 下会放大状态与 CPU。7. within给整个 pattern sequence 加时间窗口within(Duration.ofSeconds(10))表示从该 partial match 开始到完成匹配必须在 10 秒内否则丢弃并且你可以捕获“超时 partial match”后面会讲。一个 pattern sequence 只能有一个时间约束如果你在不同节点上写多个最终会取最小的那个。8. AfterMatchSkipStrategy控制“一个事件被复用到多少个匹配”CEP 的默认行为是同一条事件可以参与多个成功匹配。为了控制结果数量与业务语义需要 skip strategy。常用五种noSkip()全输出最多skipToNext()输出一个 match 后丢掉“和这个 match 共享同一起点事件”的其他 partial match适合避免同起点产生多结果skipPastLastEvent()输出一个 match 后丢掉“在该 match 覆盖范围内启动的所有 partial match”最激进结果最少skipToFirst(patternName)跳到某节点第一次出现的位置skipToLast(patternName)跳到某节点最后一次出现的位置设置方式AfterMatchSkipStrategyskipAfterMatchSkipStrategy.skipPastLastEvent();PatternEvent,?patternPattern.begin(start,skip).where(...).followedBy(middle).where(...).followedBy(end).where(...);实战建议你只想要“最典型的一条告警”别让同一起点产生一堆结果优先考虑skipToNext()你只想要“完全不重叠的匹配”优先考虑skipPastLastEvent()如果你的模式里有oneOrMore()默认noSkip()可能会让结果量很夸张务必明确选择策略9. 输出与处理推荐用 PatternProcessFunction并处理超时9.1 processMatch每次完整匹配触发一次processMatch收到的是MapString, ListIN matchkey 是 pattern 名字value 是该节点接收的事件列表因为 looping 节点可能接收多条。DataStreamAlertresultpatternStream.process(newPatternProcessFunctionEvent,Alert(){OverridepublicvoidprocessMatch(MapString,ListEventpattern,Contextctx,CollectorAlertout){Eventstartpattern.get(start).get(0);Eventendpattern.get(end).get(0);out.collect(newAlert(start,end));}});Context 里还能拿到时间信息processing time / timestamp 等并支持 side output。9.2 超时 partial matchTimedOutPartialMatchHandler用 side output 旁路只要你用了within(...)就可能发生“开始了但没完成就超时”的 partial match。可以用 mixin 方式实现TimedOutPartialMatchHandlerOutputTagTimeoutEventtimeoutTagnewOutputTag(timeout){};SingleOutputStreamOperatorAlertmainpatternStream.process(newPatternProcessFunctionEvent,Alert()implementsTimedOutPartialMatchHandlerEvent{OverridepublicvoidprocessMatch(MapString,ListEventmatch,Contextctx,CollectorAlertout){out.collect(createAlert(match));}OverridepublicvoidprocessTimedOutMatch(MapString,ListEventmatch,Contextctx){Eventstartmatch.get(start).get(0);ctx.output(timeoutTag,newTimeoutEvent(start));}});DataStreamTimeoutEventtimeoutStreammain.getSideOutput(timeoutTag);注意processTimedOutMatch不能写主输出只能用 side output。9.3 旧 APIselect / flatSelect 仍可用但底层会转成 PatternProcessFunction新项目建议直接用process(...)逻辑更直观能力也更完整。10. Event Time 下迟到数据CEP 假设 watermark 正确CEP 对 event time 的处理逻辑是元素先进入 buffer按 timestamp 排序watermark 到来时处理 timestamp watermark 的元素timestamp 小于“最后看到的 watermark”的事件被认为是 late element不再参与匹配如果你不想让迟到数据悄悄丢掉可以用sideOutputLateDataOutputTagEventlateTagnewOutputTag(late-data){};SingleOutputStreamOperatorAlertoutpatternStream.sideOutputLateData(lateTag).select(newPatternSelectFunctionEvent,Alert(){...});DataStreamEventlateout.getSideOutput(lateTag);工程建议如果业务允许一定乱序一定要把 watermark 策略和 allowed lateness 设计好CEP 本身是“以 watermark 为分界线”的。11. 性能与内存SharedBuffer cache 参数什么时候有用CEP 内部维护 SharedBuffer 来保存 partial matches 与事件引用。官方给了三项 cache 配置pipeline.cep.sharedbuffer.cache.entry-slotspipeline.cep.sharedbuffer.cache.event-slotspipeline.cep.sharedbuffer.cache.statistics-interval关键点是这些 cache 主要在 state backend RocksDB 时用于限制纯内存占用超过 cache 的部分会被“换出”到 RocksDB state 里。反过来如果你不是 RocksDB例如 heap hashmap state开启 cache 反而可能拖慢性能copy-on-write 等开销变重。一句话策略RocksDB可以用 cache slots 控制内存并换取可控的吞吐非 RocksDB谨慎开启先压测再决定12. 一个更完整的示例keyBy within 超时 迟到旁路下面示意一个常见告警同一个 id 的事件流中出现error - critical要求 10 秒内完成。StreamExecutionEnvironmentenvStreamExecutionEnvironment.getExecutionEnvironment();DataStreamEventinput...;// 建议设置 watermarkDataStreamEventkeyedinput.keyBy(Event::getId);AfterMatchSkipStrategyskipAfterMatchSkipStrategy.skipPastLastEvent();PatternEvent,?patternPattern.Eventbegin(start,skip).next(middle).where(SimpleCondition.of(e-error.equals(e.getName()))).followedBy(end).where(SimpleCondition.of(e-critical.equals(e.getName()))).within(Duration.ofSeconds(10));PatternStreamEventpsCEP.pattern(keyed,pattern);OutputTagEventlateTagnewOutputTag(late){};OutputTagTimeoutEventtimeoutTagnewOutputTag(timeout){};SingleOutputStreamOperatorAlertalertsps.sideOutputLateData(lateTag).process(newPatternProcessFunctionEvent,Alert()implementsTimedOutPartialMatchHandlerEvent{OverridepublicvoidprocessMatch(MapString,ListEventmatch,Contextctx,CollectorAlertout){Eventerrmatch.get(middle).get(0);Eventcrimatch.get(end).get(0);out.collect(newAlert(err,cri));}OverridepublicvoidprocessTimedOutMatch(MapString,ListEventmatch,Contextctx){Eventerrmatch.get(middle).get(0);ctx.output(timeoutTag,newTimeoutEvent(err));}});DataStreamEventlatealerts.getSideOutput(lateTag);DataStreamTimeoutEventtimeoutsalerts.getSideOutput(timeoutTag);你可以按业务需要把next/followedBy调整为更严格或更宽松的连续性并且用 skip strategy 控制输出爆炸。13. 迁移提示老版本 savepoint如果你需要从 Flink 1.5 的 savepoint 恢复官方策略是先迁移到 1.6–1.12重新打 savepoint再用 Flink 1.13 恢复因为 1.13 起不再兼容 1.5 的 savepoint。结尾写 CEP 最容易翻车的 3 件事连续性没想清楚followedByAny直接把输出量放大好几倍looping pattern 不加within()/until()状态长期累积event time watermark 设计不当迟到数据悄悄被 CEP 当 late 丢掉建议 sideOutputLateData 兜底