当前位置: 首页 > news >正文

​网易游戏实时 HTAP 计费风控平台建设

本文整理自网易互娱资深工程师, Flink Contributor, CDC Contributor 林佳,在 FFA 实时风控专场的分享。本篇内容主要分为五个部分:

  1. 实时风控业务会话
  2. 会话关联的 Flink 实现
  3. HTAP 风控平台建设
  4. 提升风控结果数据能效
  5. 发展历程与展望未来

1.jpg

众所周知,网易互娱的核心业务之一是线上互动娱乐应用服务,比如大家耳熟能详的梦幻西游、阴阳师等都是网易互娱的产品。不管是游戏产品还是其他应用,都需要做出好的内容来吸引用户进行应用内购买,进而产生盈利。

2.jpg

当用户在商城里点击商品进行购买的时候,会弹出支付界面,进行验证、支付后,就可以收到道具了。这个过程对于用户来说往往都是一些非常简单的操作,但为了保证这个过程可以正确结算、发货,整个支付流程其实跨越了很多服务提供商和终端,走了一条相当复杂的调用链路。这些不同的业务节点之间会产生很多相互的调用关系,进而产生一些异构的日志、数据、记录。

由于经过了网络,其中的数据可能会有一定时间水位线的不一致、延迟,甚至数据丢失的情况,且本身这些数据又很可能是异构的,就更增大了我们对这些数据进行分析和使用的难度。

如果我们需要用这些数据进行高时效性的故障排查或者风险控制,就势必需要研制一套方案,来适配这样技术需求。为了解决以上的问题,我们以 Flink 为计算引擎构建了一套实时风控平台,并为他起名为 Luna,下面我将为大家进行详细的介绍。

实时风控业务会话

3.png

常见的线上支付逻辑是,当用户在应用上点击商城的道具进行应用内购买的时候,用户的客户端终端就会到计费系统进行下单,获得本次下单的订单信息。

4.jpg

然后我们的客户端会弹出支付界面,用户进行渠道付款。

5.jpg

当支付完成后,我们会把渠道返回给客户端的支付凭证回传给计费系统,计费系统会去渠道验证凭证是否有效。

6.jpg

如果是有效的,就会通知游戏服务器发货,这个时候我们的客户端才会收到道具。这就是从用户点击到最终收到道具的整个流程。

7.jpg

从这个已经极度简化了的支付模型可以看到,不同的公司、服务提供商、部门、服务系统会产生了一系列会话下的数据。如果我们能把这些数据收集起来,进行一定的处理后,还原当时用户操作的现场。这将对运营运维人员在定位故障、排查故障,甚至整个业务环境的宏观分析都有着非常重要的价值。

而分析的关键点是,我们如何还原这个行为的现场,我们把这个行为的现场叫风控业务会话,即由一次用户行为所引发的,需要多个系统协作完成、同时触发多个请求、产生跨越多个服务提供方调用的全过程。

这里需要注意的是,业务会话跨越了多个相互独立的请求链路,且没有统一全局的 trace-id 可以被提前置入所有的数据中。

8.jpg

由于我们的业务会话需要跨越多个请求链路,所以在数据关联分析的时候就存在很多难题。比如

  • 多服务、多请求产生的异构结果难以直接关联。
  • 调用顺序复杂,存在并发、异步的情况。
  • 时间跨度大、业务水位不同步。

以前在解决支付丢单、支付一次重复发货等问题的时候,往往只能通过运营人员去处理,这就非常依赖于运维人员的经验了。并且在这些大量的数据里,会有非常多冗余和无用字段,还有可能会有一些非常复杂的嵌套关系。这些都有可能让运维人员在判断时产生错判和误判。此外,还会给运维人员带来非常多的重复性工作,从而使得人力能效低下,把时间浪费在重复的事情上。

前文也提到了开源 Tracing 方案,往往需要依赖全局的 trace-id。对于新的系统,我们可以提前设计 trace-id 打点。但是对于有历史包袱的系统来说,他们往往不愿意修改跟踪来跟踪打点,那么这个时候传统的方案就走不通了。

9.jpg

在这种情况下,如果我们要进行业务会话还原,就需要设计一套新的方案。这套方案我们希望可以具备以下功能:

  • 实时微观业务会话检索与查错。
  • 实时宏观业务环境统计与风控。
  • 业务会话级数据能效挖掘与提升。

10.jpg

从还原业务会话到使用数据做 HTAP 实时风控平台的全过程,我们使用 Flink 消费原始数据,根据平台上提前配置好的分析模板,实时还原出业务会话。然后把业务会话的结果存储存起来,并为它打上我们提前设置好的一些结论模型,产生的风控结论。

对于存储起来的这些微观会话进一步被聚合,进而产生整个业务环境上的宏观统计量,以支持我们在整个平台上的风控分析需求。

会话关联的 Flink 实现

Flink 是实时计算的实施标准,基于此我们毫无疑问地选择了它。

11.jpg

那么实时业务会话关联在 Flink 系统上,我们希望可以做出怎样的效果呢?

  • 第一,零侵入。即无需对现有业务进行改动,也无需有全局的跟踪 ID,就可以做到业务会话的还原。
  • 第二,跨数据源。因为我们的业务往往需要跨越 n 种数据源,所以我们希望这 n 种数据源都可以被这个系统所支持,比如日志、维表、事实表、REST 接口等。
  • 第三,实时。实时产生结果,无需等待 T+1。
  • 第四,低代码。我们希望基于分析需求,可以通过向导式的配置,来产生实时的分析模板,并对宏观统计报表,可以配置式的进行多维度聚合。

12.jpg

上图展示的是 JFlink-SDK,它是网易自研的一套流管理平台以及它的开发手脚架 SDK。大家可以把它理解成是一套可以模块化配置式开发的流作业手脚架,实时关联分析的引擎就是基于这套手脚架开发出来的。

13.jpg

回到在使用业务会话还原的问题上。来自各个数据源的数据业务点,通过各种方式被同步收集到数据仓库的存储层中,我们有多种数据存储收集这些数据。针对各种各样的数据存储,Flink 有非常丰富的 connect 可以进行消费。然后 JFlink-SDK 又对它进行了二次封装,定义异构数据。使其在读取到 Flink 的时候,可以被转化成统一的视图。

14.jpg

这些数据视图是我们提前建设好的一些数据治理系统和平台,数据治理系统会为 JFlink-SDK 提供数据读取的规范。

15.jpg

当通过 SDK Source 读取后,他们就会被统一转化成业务视图,这样就非常方便我们后续对这些原始异构的数据进行关联了。

16.jpg

它的数据结构是以基准和非基准共同构成的一种设计。在进行业务数据点关联的时候,它的基本思想是基准+补充。所以我们在选择业务时,会选择最为核心的风控阶段作为基准,也就意味着,基准是整个业务中最关键的步骤,可以用唯一的 ID 关联起来。

对于通过业务 ID 关联起来的基准,我们会形成一个类似图的数据结构,这个东西我们称之为基准簇,它由同一种数据来源的基准和补充所关联得到的一个雪花状数据结构。

17.jpg

基准是业务会话中最关键的步骤,它通常是公共携带的某种标志步骤。比如以计费下单为场景,客户端的下单,打开支付界面、上传凭证、支付完成是四个最为关键的步骤。他们都打上了执行这些步骤的订单号,这四个步骤就可以作为整个业务规划的核心步骤,也就是基准。因为数据是不按顺序到达的,所以出现这是个步骤中的任意一个我们都可以开启业务会话。

18.jpg

而下单记录、商品详情、渠道回调记录等等一些辅助性的数据,他们对问题定位起不了关键作用,而且它们可能没有基准中订单号的字段,所以就没有资格被选为基准。

但它们中也有一些字段可以和基准中的字段进行关联。比如渠道回调日志,渠道商在一些辅助性的数据上打了 trans_id 字段。它虽然没有 order_id,但它可以通过 trans_id 与基准中的 trans_id 建立一一映射的关系,也就是我们可以通过 trans_id 关联起这份数据与基准簇的关系。

所以通过基准+补充,我们就可以解决目前线上系统,无法为所有数据打上统一 ID 埋点的痛点。

19.jpg

在 Stream API 中基准关联的实现,我们使用的是 Session Window。它是 Flink 提供给我们的标准时间窗口之一,可以在有数据流入的时候进行窗口时间超时的重置。除此之外,如果整条流的业务水位线,越过了整个超时时间的边界,它就会触发窗口计算。这种结果就非常适合由用户触发的会话窗口,也适合我们基准数据构造的逻辑。

但用户引起的这种行为,往往时间是不固定的,所以带有属性的会话窗口就非常适配这种特性。比如风控业务会话的还原,和浏览商品到最终下单支付的整个支付应用轨迹的追踪,都非常适合用这种模式来进行窗口计算。

这里的 Flink Session Window 其实就是前文提到的构造完毕的基准簇,它包含了所有被关联进来的原始数据,以及按照一定规则处理好的二级字段。至于它怎么在关联的时候进行字段抽取呢,后续再来讨论这个规则,此处就先认为,在窗口完成的时候就把簇计算出来了,并完成了所需字段计算和抽取。

20.jpg

一般用户的支付意愿窗口往往在 10~20 分钟,如果我们直接使用 Event Time Session Window 来进行计算,就会发现如果用户很快完成了下单,但系统仍然需要等待 10~20 分钟,才能使会话窗口进行计算,这就大大降低了数据的时效性。

对此 Flink 也为我们提供了一口入口,我们可以自定义窗口的 Trigger 来设置窗口触发的时机和业务会话提前结束的判定。

举个例子,一些数据量极少的场景,它的水位线可能一直没有向前推动,这种情况我们就可以加上 Process Timeout 和 FIRE & UPDATE 语义。这就可以让业务会话在水位线没有推进的情况下,先进行计算,往后发送。然后在下游进行保证,即当上游重复 fire 的时候,可以进行 update 的语义。

再举个例子,我们可以在风控的分析模板中配置一下。当业务会话满足某些条件的时候,就不用再等待超时了。比如当所有的节点都被关联上时,如果继续等待也不会等到任何节点,这个时候就无需等待超时时间,可以立即 fire 出结果。

21.jpg

当业务会话存在一些特殊且极端的情况,比如客户端支付到一半崩溃了,等了非常久才起来,这个时候很可能就会被拆分为两个业务会话,因为前一个业务会话已经超时了。这种时候我们会选择把两个被分裂的会话 fire 出来,然后由运维人员进行合并或者保持原样。

22.jpg

接下来我们来讨论一下,对于补充的数据我们又是如何构造的。基准数据拥有公共 ID,所以它们可以被 Key By 到数据窗口里进行计算。但是补充数据点往往是各自用各自不同的 ID 进行关联,所以这个时候我们就可以类比数据库里的多表 join 了。不同的补充数据就类似于一张不同的表,通过不同的字段与基准数据簇进行 join 操作。

23.jpg

这就是我们遇到的挑战,它不仅关联字段不同,水位线的推进速度也很可能不一样,这都是无法把它们两者放到同时间窗口中计算的关键因素。

那么如何去解决这个问题呢?如何基于扩展的基准先进知识,关联回没有公共 ID 的补充数据呢?这正是整个解决没有公共 trans_id 还能形成会话的关键所在。

24.jpg

类比 join 操作,Flink 已经为我们提供了非常好用的算子,叫做 Interval Join。即两种输入数据分别取自己的特定字段作为 key,然后通过这个 key 把他们分到同一分组上,进行时间区间内的 join。

Flink Event Time Interval Join 是把当前流和对手输入流里,指定上下边界的区间内数据进行 join,这种特性就非常适用于我们这种场景,因为当我们从基准数据簇中取一个字段,和从非基准的补充中取一个字段,如果它们等值,那就意味着它们属于同业务会话,它们应该进行关联。

这个时候就可以用 Interval Join 算子进行关联,而且 Interval Join 不会打开时间窗口,因为每条流的 GC Watermark 是根据对手流加上我们提前配置的边界时间区间来进行的,这种结构就非常适合两种数据流时间水位线推动不一致的情况。

25.jpg

但是还有另外一种情况,就是当某一条数据来源有延迟的情况下,这笔数据会被丢失,这是 Flink 1.16 正式版之前的情况。在 Flink 1.17 版本中,社区的小伙伴已经把这个代码合并进去了,后续很期待在新版本中使用这个功能。

26.jpg

当数据延迟进行补回的时候,我们的处理方式是,把延迟数据和当时关联的上下文,放到消息队列里,通过流重新消费出来,并根据当时关联的上下文,重新从数据存储里把写进去的会话查回来,然后用同样的逻辑重新把这笔数据补回更新,写回数据库。

这样整个过程中无论是实时关联,还是延迟数据的补回,用的逻辑都是完全一样的,保证了我们处理逻辑的简洁和一致性。

27.jpg

最终我们用 Flink 实时关联出来的业务会话会被存储起来以供检索,并通过 Luna 平台以行为树的形式进行展示。

HTAP 风控平台建设

当我们完成了算法可行性测试,并使用 Flink 实现了技术原型后。接下来就是如何把这一整套框架平台化,使其成为便捷、准确、丰富的风控平台。

28.jpg

风控平台需要做到以下这些功能。

支持微观排障,可以具体查询某一笔订单、业务会话当时的业务场景,把它还原出来;支持从宏观上统计整个环境的各种数据量。且配置和查询都需要是自助、向导式的。

29.jpg

基于以上的考虑,我们设计了 HTAP 实时风控平台 Luna。基于这个平台,用户就可以自己从各种异构数据源中选择,配置业务行为树和分析模板。然后平台会根据配置好的模板,起 Flink 流算出业务会话的结果,形成会话结果存到存储层。且支持用户从平台上进行条件检索,进行多维度的聚合。

30.jpg

分析模板的配置我们是做了自动更新,也就是所有平台上的更新都无需人工运维。

从上图中可以看到,核心组件是计算层的 Flink,加上存储层的 TiDB,加上我们自己基于 JavaScript 的平台服务系统。目前可以达到微观查询是毫秒级,多维度的风控聚合结果在年级别都可以做到秒级查询。

31.jpg

我们的平台支持,用户从不同的数据源中选出,需要参与这一次关联分析的数据和关注抽取的字段进行配置。配置好后,Flink 会根据这些配置,自动生成出 Flink 的 Source 和 Sink。

32.jpg

然后进行行为树的定义。定义整个业务行为会发生的动作,本质就是用人力运维排障方法论进行沉淀和泛化,将配置的形式固化下来。之后这些配置模板就会用于生成 Flink 流的 UDF 配置,并被实时同步到运行中的 Flink 流中。

33.jpg

除此之外,配置界面还提供了预览功能,即可以一边配置一边预览整个行为树。

34.jpg

风控场景上的分析模板修改后,如果不涉及数据源的增减,我们的流可以通过 broadcast stream 的特性进行自动同步和变更。

35.jpg

从架构图中可以看出,我们选择了 TiDB 作为关联结果的存储层。那么我们是如何考虑的呢?

  • 数据结果需要灵活可拓展,且适配索引。这样用户就能快速的自由配置抽取字段。
  • 频繁的更新操作。因为我们的计算逻辑决定了我们会构造基准数据,再构造补充数据,以一种异步的形式写到数据库,所以需要频繁更新。
  • 完备的聚合函数。因为宏观统计需要做各种各样的聚合,以满足我们数据分析统计的需求。
  • 满足业务需求的写入/读取速度。

这样就可以使用列转行的结构,存储到我们的关系数据库里了。

36.jpg

列转行是把会频繁发生增减字段的 DDL 转化为 DML,就可以支持我们灵活的数据结构。

37.jpg

每个字段都需要索引这样的特性,这在数据量持续增大的表上,就有着非常优秀的特性。

38.jpg

在这样一种存储结构上,我们的微观业务会话查询就可以做到毫秒级,灵活结合多种条件进行检索,以帮助运维人员快速查看线上风险和可能发生的故障原因。

39.jpg

当我们点击查看任何具体的业务会话时,公共平台就会展示出当前这个业务会话的业务行为树,并抽取出有助于排障的一些关键字段和二级指标,极大方便了我们的运维人员排查具体问题的场景。对于常见的问题,我们甚至还会用结论模型直接给出风控结论,让我们的运维人员进去就能马上看出问题所在。

40.jpg

对于宏观统计,大家肯定也想到可以使用 SQL 作用在上面来进行统计了,毕竟我们把数据存在了关系型数据库 TiDB 里,但这里还存在着一些坑点。

41.jpg

当我们的数据量超过 10 亿的时候,我们的数据聚合时间会出现一些变化。比如当粒度是一小时,聚合时间是一天的时候,我们数秒可以完成。但当我们把时间拉到 60 天,几乎就出不来了。

在查看数据存储层的时候会发现,TiKV 已经 IO 满了,而且 CPU 飙升,因为我们做的数据量实在是太大了。

42.jpg

通过分析整个执行计划可以看到,TiKV 使用常规的模式进行 SQL 把所有数据捞到 TiDB 层进行聚合计算。这样做获取的数据函数会非常多,随着我们时间区间的增大会越来越缓慢,这样我们肯定是不能接受的。

43.jpg

那么我们来回看一下风控的 AP 需求,我们需要读取大量实时的关联的数据点;支持有复杂的聚合函数,且我们的查询不应该影响到 Flink 流进行 TP 写入。

这个时候就会想到,TiDB 有一个叫 TiFlash 的组件,它可以完成 TiDB 的 HTAP 特性。也就是 AP 和 TP 同样用 SQL 来完成,且它是物理隔离的,这就非常的适用于这样的场景。

44.jpg

TiFlash 伪装成一个 Raft Learner TiKV 节点,加入 Raft Group,参与数据实时、事务性同步。这样就可以做到 AP 和 TP 的物理隔离,并且它还支持事物,这样就可以在执行 SQL 的时候无感进行 HTAP 了。

45.jpg

在进行这样的优化后我们可以看到,当我们的查询包含多层 join,甚至有分位数计算的时候,90 天聚合时间,粒度查询可以在十秒内返回和完成,这可以说是一次质的飞跃。

46.jpg

最后,我们把宏观统计提供给用户。在 TiFlash 的助力下,我们的平台可以做到秒级的 AP 多维度聚合查询。这种聚合查询出来的结果可以让我们的数据分析人员,从更高层次对整个业务环境的风险进行识别。

提升风控结果数据能效

当我们可以实时产生业务会话的结果,并在平台上展示的时候,接下来我们将通过以下几点提高数据效能。

  • 风控结论生成:节约重复人力成本
  • 标签和统计:将详情数据归类统计为宏观数据
  • 数据打宽:增加分析维度
  • 可视化展示:挖掘数据规律

47.jpg

那么我们为什么把数据存储在 TiDB 这样的一种关系型数据库里呢?

因为 TiDB 作为一个分布式数据库,被我们广泛存储各项业务的事实和维度数据了。如果我们把风控数据簇也放在这里面,通过简单的专业操作我们就可以完成数据的拓宽,丰富我们的数据报表。

48.jpg

不仅是产生离线报表的时候可以这么方便的转,我们在实时计算的时候,也进行了 Async Join,通过 Async Join 转 UDF 进行实时数据打宽,同时我们支持多种存储介质。

49.jpg

对于这种 Async Join,我们利用了 Flink 的 Async IO 的特性,并在 join 的时候进行了一些优化。比如进行批的 join,不同时间水位线的缓存 join 以及 timeup 数据的侧输出等等,这些都为数据的准确性提供了保障。

50.jpg

通过数据打宽后,我们的风控统计分析维度就可以更上一层楼了。之前通过 ID 无法做到的特殊聚合,现在把数据打宽,都可以进行可视化的一些分析和展示了。

51.jpg

52.jpg

除此之外,对于常见问题,我们支持预先配置结论模型。当运维人员实时查询微观会话时,直接为他们给出结论。

53.jpg

得到结论后,我们就可以从更高的角度,观察和统计整个业务环境的宏观情况了,甚至可以进行实时的业务环境监控。从而提高故障的发现率、预警率、预警的准确率以及整个运维人力的能效。并且通过可视化的展示可以使我们的风控平台更准确的提供服务。

发展历程与展望未来

54.jpg

早在 2017 年我们就对实时计算开始调研了,并在 2018 年形成了双向发展的规划,分别是平台化和 SDK 手脚架的改造,经过多层的迭代,最终形成我们的一站式运维平台。

55.jpg

随着平台和 SDK 的发展,我们的实时业务线也越来越广泛。比如从最早的日志分析监控,到通用的解析 ETL,到用户画像,到复杂的关联分析,再到如今的实时风控平台,我们也是在实时领域越走越远,这都是 Flink 给我们带来的变革。

未来我们希望,可以实时风控平台可以支持更多的功能。比如我们希望支持用 Flink-SQL 即席查询风控结果;用户反馈驱动的风控模型修正;结合 Flink-ML 挖掘更深层次数据价值。

相关文章:

​网易游戏实时 HTAP 计费风控平台建设

本文整理自网易互娱资深工程师, Flink Contributor, CDC Contributor 林佳,在 FFA 实时风控专场的分享。本篇内容主要分为五个部分: 实时风控业务会话会话关联的 Flink 实现HTAP 风控平台建设提升风控结果数据能效发展历程与展望未来 众所周知&#xff…...

vue组件

文章目录1.vue组件2.非单文件组件2.1组件创建2.2祖册组件2.3使用组件3.组件的嵌套3.1 school组件嵌套student3.2 app组件嵌套school和hellozujain3.3 vm里面引入app组件4.VueCompent5.单文件组件1.vue组件 组件是实现应用中功能的局部代码和资源的集合 2.非单文件组件 2.1组件…...

让mybatis-plus支持null字段全量更新

文章目录背景方案一使用方案二方案二原理介绍背景 如果仅仅只是标题所列的目标,那么mybatis-plus 中可以通过设置 mybatis-plus.global-config.db-config.field-strategyignored 来忽略null判断,达到实体字段为null时也可以更新数据为null 但是一旦使用…...

MASA Stack 1.0 发布会讲稿——生态篇

2022年运营回顾 贡献者 首先感谢贡献者们为MASA Stack社区所作的积极贡献,这些贡献者给我们提出了很多宝贵的建议,更是积极的提交PR帮助我们一起让产品更健壮,更完善,还在各种场合推广我们的解决方案,非常给力&#x…...

华为OD机试 - 火星文计算2(JS)| 真题+思路++考点+代码

火星文计算2 题目 已知火星人使用的运算符号为#;$ 其与地球人的等价公式如下 x#y4*x3*y2 x$y2*xy3 x y是无符号整数 地球人公式按照c语言规则进行计算 火星人公式中#符优先级高于$ 相同的运算符按从左到右的顺序运算 输入 火星人字符串表达式结尾不带回车换行 输入的字符串…...

从春节后央行的首批罚单,看金融反欺诈反洗钱的复杂性

目录 个人信息保护的问题 征信管理的问题 反洗钱与反欺诈的问题 金融欺诈愈加复杂多变 金融机构如何增强反欺诈反洗钱 春节后,央行公示首批罚单。其中,厦门银行被中国人民银行福州中心支行给予警告,并没收违法所得767.17元,处…...

【Hello Linux】Linux工具介绍 (yum vim)

作者:小萌新 专栏:Linux 作者简介:大二学生 希望能和大家一起进步! 本篇博客简介:介绍Linux的常用工具 yum和vim Linux工具介绍Linux中的软件管理工具 -- yum在windows下安装软件的方式在Linux下安装软件的方式认识yum…...

多种充电模式_手持无线充气泵方案

一、手持无线充气泵手持无线充气泵是一个通过锂电池供电达到无需插电就能使用的便携式充气泵,它的适用场景大部分是为身处户外没有办法接通电源的人而设计的,方便人们的出行也可解燃眉之急。不仅如此,为预防手持无线充气泵的锂电池电量用完而…...

【网络基础】DNS是什么

本文不会直接引入复杂枯燥概念,用形象例子通俗讲解,旨在入门理解。 DNS作用 DNS是用来做域名解析的。 相当于把网址翻译成实际ip地址,供其他设备访问。 一个例子 有一个网站的服务器IP地址为1.1.1.1,用电脑访问该网站的话只需…...

二叉树的性质与推导及常见习题整理

目录 一、性质推导 二、常见的二叉树性质习题 1. 某二叉树共有 399 个结点,其中有 199 个度为 2 的结点,则该二叉树中的叶子结点数为()。 2.在具有 2n 个结点的完全二叉树中,叶子结点个数为(&#xff…...

亚马逊卖家测评补单的重要性和缺点

对于亚马逊、沃尔玛、ebay、wish、newegg、速卖通、阿里国际站、shopee、lazada、temu、乐天、toktok、joom、ozon等卖家来说,测评补单是一个比较常见的话题,因为测评可以给自己产品留下优质的评价,让国外真实买家更加明确,便捷的…...

Java类和对象超详细整理,适合新手入门

目录 一、驼峰命名法 二、Java注释 三、转义符 四、Java程序它的基本结构是什么? 五、Java中的类 六、创建类 七、定义main方法 八、执行代码输出语句 九、Java中的对象 十、创建对象 十一、类与对象的关系 一、驼峰命名法 包名:多单词组成所…...

MySQL:连explain的type类型都没搞清楚,怎敢说精通SQL优化?

我们在使用SQL语句查询表数据时,提前用explain进行语句分析是一个非常好的习惯。通过explain输出sql的详细执行信息,就可以针对性的进行sql优化。 今天我们来分析一下,在explain中11种不同type代表的含义以及其应用场景。 1,sys…...

6.11 极分解

文章目录计算方法代码实现计算方法 一个复数可以写成极坐标形式:zreiθzre^{i\theta}zreiθ.这种分解,左边代表长度,右边代表角度。由此为灵感来源,前人对矩阵也有类似的分解。就是猜想一个线性变换对矩阵的作用,是不是可以分解为…...

Spring、SpringMVC、Shiro、Maven

一、SpringSpring是一个为了解决企业应用程序开发复杂性而创建的开源框架,其核心是IOC–控制反转、AOP–面向切面编程。框架的主要优势之一就是其分层架构(WEB层(springMvc)、业务层(Ioc)、持久层&#xff…...

element-plus 使用笔记

npm install element-plus --save自动导入 npm install -D unplugin-vue-components unplugin-auto-import// vite.config.jsimport AutoImport from unplugin-auto-import/vite import Components from unplugin-vue-components/vite import { ElementPlusResolver } from …...

《蓝桥杯每日一题》 前缀和·Acwing 3956. 截断数组

1.题目https://www.acwing.com/problem/content/3959/给定一个长度为 n 的数组a1,a2,…,an。现在,要将该数组从中间截断,得到三个非空子数组。要求,三个子数组内各元素之和都相等。请问,共有多少种不同的截断方法?输入…...

促进关键软件高层次人才培养:平凯星辰与华东师范大学签订联合博士培养合作协议

2022 年年初,平凯星辰入选首批工信部教育部支持联合培养国家关键软件高层次人才计划。该计划旨在探索关键软件产教融合育人模式,超常规加快培养一批急需高层次人才,以及探索关键软件联合技术攻关新模式。2022 年年底,在该计划下 平…...

Java程序员的日常——经验贴

关于文件的解压和压缩 如果你的系统不支持tar -z命令 前往讨论 如果是古老的Unix系统,可能并不认识tar -z命令,因此如果你想要压缩或者解压tar.gz的文件,就需要使用gzip或者gunzip以及tar命令了。 关于tar.gz可以这么理解,tar结…...

电商API社区,商品数据,关键词搜索等

1. 需要做的事情 l 商品详情页实现 1、商品查询服务事项 2、商品详情展示 3、添加缓存 2. 实现商品详情页功能 2.1. 功能分析 1、Taotao-portal接收页面请求,接收到商品id。 2、调用taotao-rest提供的商品详情的服务,把商品id作为参数传递给服务。接…...

LEADTOOLS 22.0.6 UPDATE-Crack

OCR SDK 库 许多 OCR 增强功能 LEAD 行业领先的人工智能 OCR SDK 在以下方面获得了显着的识别优化:斜体、大写和小写字母、文本行组装和单词构建、列检测、基线检测和文本行分割。 LEADTOOLS为.NET 6、. NET Framework、Xamarin、UWP、C#、VB、C/C、Java、Objective…...

什么是OJ? 东方博宜题库部分题解

什么是OJ ? Online Judge 比如这样的:Home - 一本通OJ Q:这个在线裁判系统使用什么样的编译器和编译选项? A:系统运行于Debian/Ubuntu Linux. 使用GNU GCC/G++ 作为C/C++编译器, C: gcc Main.c -o Main -fno-asm -O2 -Wall -lm --static -std=c99 -DONLINE_JUDGE C++: g++ …...

企业工程项目管理系统源码的各模块及其功能点清单

工程项目各模块及其功能点清单 一、系统管理 1、数据字典:实现对数据字典标签的增删改查操作 2、编码管理:实现对系统编码的增删改查操作 3、用户管理:管理和查看用户角色 4、菜单管理:实现对系统菜单的增删改查操…...

【电商开发手册】订单-下单

下单需求 所谓下单,本质上就是买卖双方通过确认一系列信息并且签订电子合同的过程 在电商平台的下单过程中,也需要确定买卖双方的一系列信息: 买方:用户确认收货地址、支付方式、配送方式等等 卖方:卖方需要进行供…...

数据结构 - 优先级队列(堆)

文章目录前言1.介绍优先级队列2. 认识堆3. 实现优先级队列3.1 了解优先级队列的构造方法:3.2 使用优先级队列解决问题:总结前言 本篇PriorityQueue优先级队列的介绍其底层是堆,关于堆的认识,使用优先级队列能解决的一些问题&…...

PDF内容提取器:ByteScout PDF Extractor SDK Crack

ByteScout PDF Extractor SDK – 用于 PDF 到 JSON、PDF 到 Excel、CSV、XML、从 .NET 和 ASP.NET 从 PDF 中提取文本的 PDF 提取器库 ByteScout PDF Extractor SDK – 用于 PDF 到 JSON、PDF 到 Excel、CSV、XML、从 .NET 和 ASP.NET 从 PDF 中提取文本的 PDF 提取器库​ ​ ​…...

字母板上的路径[提取公共代码,提高复用率]

提取公共代码前言一、字母版上的路径二、贪心1、idea2、go3、代码不断拆分复用的过程总结参考文献前言 写代码,在提高效率的同时,要方便人看,这个人包括自己。大函数要拆分成一些小函数,让每个函数的宏观目的和步骤都显得清晰&am…...

c# winform错误大全

c# winform 错误大全为了实现安装包安装完成后,启动程序。System.BadImageFormatException: 未能加载文件或程序集“file:///C:\xxxxxxxxx\xxxxxxx.exe”或它的某一个依赖项。生成此程序集的运行时比当前加载的运行时新,无法加载此程The version of the …...

AI_News周刊:第一期

2023.02.06—2023.02.12 关于ChatGPT的前言: 在去年年末,OpenAI的ChatGPT在技术圈已经火了一次,随着上周它的二次出圈,ChatGPT算得上是人工智能领域的一颗明星,它在聊天机器人领域有着不可忽视的影响力。其准确、快速…...

搭建mysql主从复制

前言: 👏 作者简介:我是笑霸final,一名热爱技术的在校学生。 📝 个人主页:个人主页1 || 笑霸final的主页2 📕 系列专栏:数据库 📧 如果文章知识点有错误的地方&#xff0…...

flash型网站/百度统计app下载

UDP协议是无面向连接的、不可靠的、无序的、无流量控制的传输层协议,UDP发送的每个数据报是记录型的数据报,所谓的记录型数据报就是接收进程可以识别接收到的数据报的记录边界。TCP协议是面向连接的、可靠的、有序的、拥有流量控制的传输层协议&#xff…...

广州最新传染疫情/seo收索引擎优化

大数据 标准库 应用库选择“正确的”数据库通常对于应用程序的成功至关重要。 与考虑供应商的建议或因为已经碰巧已经拥有数据库而使用数据库相比,考虑数据存储的基本目的和需求很有用。 在选择数据库时,这些是最重要的问题: 您希望在应用程…...

做公司网站棋牌/购买友情链接

今天说说以***者的角度去谈谈服务器被干掉后,我们该做的哪些防护和检查工作,高手的话都比较熟悉系统加固和安全的问题,对于我等初学者来说,没有做过从事过安全方面工作,所以只能从***者的角度去说说相对立的工作。因为…...

手机网站开发计划/seo推广是什么意思

#define,typedef,struct,enmu是我们阅读单片机底层代码时最经常碰到几个概念。 首先分开解释一下 宏定义#define与定义别名typedef,它俩一起说,因为它俩的功能十分相似,具体的的用法不说了,注…...

政府采购网站的建设情况/每日财经要闻

这个性质叫“稀缺”。魔法世界里也得有稀缺。《西游记》里的神仙们日子过得好像什么都不缺,可也得定期吃些蟠桃、人参果之类能增寿的东西。谁控制稀缺资源,谁就掌握权力。王母娘娘控制了蟠桃,定期召开蟠桃大会给各路神仙延长寿命,…...

谷歌seo招聘/seo 页面链接优化

书评——《Microsft .NET Framework 3.5 – Windows Forms Application Development》 本文地址:http://www.cnblogs.com/AndersLiu/archive/2009/04/11/book-review-windows-forms.html 作者:Anders Liu 摘要:本文大力吹捧了一下微软的新书《…...