银行核心背后的落地工程体系丨混沌测试的场景设计与实战演练

本文作者: 张显华、窦智浩、卢进文

与集中式架构相比,分布式架构的系统复杂性呈指数级增长,混沌工程在信创转型、分布式架构转型、小机下移等过程中有效保障了生产的稳定性。本文分享了 TiDB 分布式数据库在银行核心业务系统落地中进行混沌测试的场景设计和实践。

混沌工程概述

混沌工程是一种全面的测试方法,它覆盖了从应用层前端到底层硬件环境的所有环节,确保整个系统在面对各种异常和故障时的稳定性和弹性。本文将聚焦于与 TiDB 分布式数据库相关的混沌工程场景。

混沌工程和普通测试在软件系统工程中都扮演着重要的角色,但它们关注的质量属性和测试实施的方式存在明显差异。混沌工程更侧重于系统的健壮性和在面对异常情况时的响应能力,而普通测试则侧重于验证系统的功能正确性和性能指标。两者的差异详见下表:

在着手进行混沌测试的场景设计和实施之前,有几个关键问题需要我们深思熟虑:

首先,需要明确混沌测试的目标,希望通过测试掌需要关注的能力边界、容错能力、稳定性等。其次,选择合适的混沌测试工具,这些工具能够帮助我们在分布式环境中模拟各种故障和异常情况。接下来,精心设计测试用例,确保它们能够覆盖到可能影响系统稳定性的关键环节。最后,梳理总结混沌测试可能带来的收益,包括提高系统可靠性、优化故障恢复流程、增强团队对系统行为的理解等。通过这些环节的综合考量,我们可以更有效地实施混沌测试演练,为 TiDB 分布式数据库的稳定性提供坚实的保障。

混沌测试目的

TiDB 作为一款原生分布式数据库,其架构设计与银行系统中的传统集中式数据库相比具有显著的差异。银行核心系统对性能、稳定性、跨地域的高可用性都有着严苛的要求。为了满足这些要求,我们计划通过混沌测试来摸底性能边界、评估系统高可用性和容灾能力、验证系统的弹性、检验应急预案有效性、优化监控和告警机制、并准确评估外围作业的影响。

2.1 摸底性能边界

摸底数据库的能力边界,对上线后的运维工作具有重要的参考意义。一个新的业务系统在设计之初,不仅要满足当前的业务需求,还要考虑满足未来的业务发展需求,尤其是在极致稳定性要求下,银行核心系统的设计需要考虑未来 5 年至 10 年以上的业务发展需求。通过混沌测试,在总体设计的配置下,测试数据库的能力边界,将结果作为上线后运维的重要参考指标,并检验系统是否满足总设要求下未来业务的承载体量。

此外,通过混沌测试还可以发现整个业务链路可能存在的一些瓶颈点。

2.2 评估系统高可用和容灾能力

TiDB 的存算分离架构由核心组件和外围组件组成。核心组件包括 TiDB、TiKV、PD 和 TiFlash,用于处理计算和存储任务。外围组件包括 BR 和 TiCDC 等,用于满足备份、数据共享等业务场景的需求。这些组件可以单独部署或混合部署,以满足隔离性和资源利用率的平衡。

在银行核心系统中,常见的部署模式是两地三中心。通过混沌测试,可以在实际的部署架构下模拟各种故障场景,评估系统的高可用能力和灾备接管能力。测试结果可以提供每个场景或多场景组合下的 RTO 和 RPO 指标,并帮助识别应用连接恢复的健壮性和透明性问题,以及发现可能存在的访问链路瓶颈。

2.3 验证系统的弹性

业务发展具有动态性,在突发的高流量高负载业务活动中,可能需要进行系统扩容以兼顾效率和稳定性。此外,X86 服务器相比小型机稳定性差、故障率高、生命周期短,需要通过扩缩容动作完成对硬件的升级和更换。基于这些因素,我们从两个维度对扩展性进行评估:

  • TiDB 的线性扩展能力:评估 TiDB 在扩容后能否保持性能的线性增长,满足业务增长带来的性能需求。
  • 扩缩容调整的便捷性、透明性和对业务的影响:评估扩缩容操作是否简单易行,对应用是否透明,对业务是否有影响以及影响程度。

2.4 检验应急预案有效性

利用混沌测试中涉及的破坏性测试场景,对应急预案进行全面的检验和优化,为上线后的运行维护做好充分准备。

2.5 优化监控和告警机制

利用混沌测试,可以有效检验告警系统的有效性和准确性,并对告警进行全面的查漏补缺和优化。通过测试验证和持续优化,确保告警及时、准确、等级合理、避免过度冗余。

2.6 准确评估外围作业的影响

生产业务系统涉及数据库备份、统计信息收集、TiCDC 数据同步等外围作业,以及版本/补丁升级、重启、扩缩容、硬件替换、容灾切换等运维作业。混沌测试应关注此类作业对系统负载、业务指标、网络流量等方面的影响,并优化相关的作业窗口和并发度,确保业务平稳运行。

混沌测试工具

我们以某商业银行核心场景为例,使用 Chaosd 工具来进行混沌测试的场景设计和演练。Chaosd 组件 ( https://chaos-mesh.org/zh/docs/chaosd-overview/ ) 是 Chaos Mesh ( https://chaos-mesh.org/zh/ ) 提供的一款混沌工程测试工具(需要单独下载和部署 ( https://chaos-mesh.org/zh/docs/chaosd-overview/#下载和部署 )),用于在物理机环境上注入故障,并提供故障恢复功能。

Chaos Mesh 是 PingCAP 自主研发的开源云原生混沌工程平台,提供丰富的故障模拟类型,具有强大的故障场景编排能力,方便用户在开发测试中以及生产环境中模拟现实世界中可能出现的各类异常,帮助用户发现系统潜在问题。

Chaosd 具有以下核心优势:

  • 易用性强:输入简单的 Chaosd 命令即可创建混沌实验,并对实验进行管理。
  • 故障类型丰富:在物理机的不同层次、不同类型上都提供了故障注入的功能,包括进程、网络、压力、磁盘、主机等,且更多的功能在不断扩展中。
  • 支持多种模式:Chaosd 既可作为命令行工具使用,也可以作为服务使用,满足不同场景的使用需求。

Chaosd 提供完善的可视化操作,旨在降低用户进行混沌工程的门槛。用户可以方便地在 Web UI 界面上设计自己的混沌场景,以及监控混沌实验的运行状态。你可以使用 Chaosd 模拟以下故障类型:

  • 进程:对进程进行故障注入,支持进程的 kill、stop 等操作。
  • 网络:对物理机的网络进行故障注入,支持增加网络延迟、丢包、损坏包等操作。
  • 压力:对物理机的 CPU 或内存注入压力。
  • 磁盘:对物理机的磁盘进行故障注入,支持增加读写磁盘负载、填充磁盘等操作。
  • 主机:对物理机本身进行故障注入,支持关机等操作。

对于每种故障类型的详细介绍和使用方式,请参考对应的说明文档 Chaosd 组件简介 | Chaos Mesh ( https://chaos-mesh.org/zh/docs/chaosd-overview/ )。

混沌测试场景设计

混沌测试场景设计的原则是尽可能的模拟真实的生产情况。为了最大程度地模拟真实环境,测试的目标环境推荐使用准生产环境或按照生产环境设计要求搭建 1:1 仿真测试环境,并确保环境配置、部署架构、数据容量和业务负载等方面与预估上线后或系统设计要求一致。

测试从业务压力、故障注入、外围作业和运维操作等多个维度进行全方位测试,包括但不限于:

  • 模拟真实的用户访问量和业务负载,以评估系统在高并发情况下的性能和稳定性。
  • 注入各种硬件故障、软件故障和网络故障,以评估系统的故障处理能力和快速恢复能力。
  • 模拟数据同步、备份作业等相关外围作业对资源使用的影响和 SQL 时延的影响。
  • 模拟运维人员的日常操作,以评估系统的易用性和可维护性。

4.1 业务压力

交易型业务压力

混沌测试建议采用真实业务模型,通过等比例的业务流量进行压测,或者有条件的采用流量回放( 生产环境流量需严格遵循安全管控流程,仅适用于生产域,且需进行脱敏处理 )的形式进行。对于项目前期无法基于真实业务模型进行压力模拟的情况,可以选择部分较为核心(或简化)的业务模型进行压力模拟。

如果上述条件均不具备,也可采用 sysbench 进行压力注入。由于 sysbench 与真实业务模型存在较大差异,对性能边界的评估意义有限,但基本不影响对高可用、容灾能力、扩展性、检验和优化监控告警等其他方面的验证结果。

对于注入压力的大小,建议按梯队逐层加压展开:

  • 生产(预估)TPS 指标
  • 总设要求的 TPS 指标
  • 总设要求的 TPS 指标 * N 倍 (1.5、2、3 ....,截止满足业务时延下的最高压力)
  • 满足业务时延下的最高压力
  • 基础环境负载打满的压力

以上几个梯队可以按需进行,兼顾测试成本,不建议过度细分压力场景 。

对每个压力场景,记录各项基础环境和数据库实例级别的资源使用率、数据库 QPS/TPS、数据库 SQL 时延、端到端的业务时延、业务 TPS 等关键信息,建议将当时的压测场景结合关键的监控信息进行存档。以下登记表供参考(为方便展现,部分信息项简化合并):

批量业务压力

银行核心业务中的日终、日切、日结、报表等批量类业务,并发量大,负载高,需按照真实的用户量和总设要求的承载用户量分别进行压力测试。除了根据用户量维度施加压力外,还需关注此类业务的并发度、作业编排等方面,以探索最佳的业务实践。

长稳压测

长稳压测建议以交易型业务压力为主(总设要求的 TPS 指标压力),结合实际情况周期性注入批量业务压力,开展 7*24 小时长稳压测,全面验证系统整体的可靠性和稳定性。此外,长稳压测还可以有效发现一些容易被忽略的潜在问题,例如基础硬件的质量问题、配置是否合理、全链路中的脆弱点和性能瓶颈等。

其他场景

按需根据实际的业务特点扩展测试场景,针对性地进行验证。例如测试表数据量增长对 SQL 响应时延的影响:

  • 根据实际表结构进行数据量增长压测,模拟从百万级到十亿级数据量(甚至更多,兼顾测试成本按需进行即可,无需过度放大)的变化。
  • 在同等业务压力下,使用实际的业务 SQL 测试响应时延、QPS、TPS 指标的变化。

4.2 故障注入

针对 TiDB 的故障注入测试可以从实际部署架构和故障面积两个维度进行设计,本文以同城双机房双活的 DR Auto-Sync 架构 ( https://docs.pingcap.com/zh/tidb/stable/two-data-centers-in-one-city-deployment#单区域双-az-部署-tidb ) (即 Data Replication Auto Synchronous,简称 DR Auto-Sync)进行介绍,其他部署架构的故障注入测试用例设计思路与此类似。故障注入和恢复后,需要关注的事项有:

  • 对于业务量、QPS、TPS 的影响比例和持续时间
  • 业务端到端的时延变化和持续时间
  • SQL 的时延变化和持续时间
  • 存活节点的资源使用变化
  • 集群自身的负载均衡能力(如 leader 重新选举)
  • 应用连接池重连能力(注意关注并优化连接池配置、负载探活配置)

以下故障注入跟踪表供参考(为方便展现,部分信息项简化合并):

建议采用分级故障注入策略,实例级故障注入时需要根据不同的实例角色进行,服务器级故障注入时需要结合部署架构(尤其是存在混合部署情况下)进行。

4.3 外围作业

外围作业注入应关注相关作业对资源使用和 SQL 延迟的影响,并结合生产实际业务周期性变化的情况,优化作业窗口和并发度等配置。主要的外围作业包括全量物理备份、全量逻辑备份、BR log 备份(常驻作业)、统计信息收集和 TiCDC 数据同步(常驻作业)等。

4.4 运维操作

运维操作注入是模拟真实运维操作对 TiDB 系统的影响,需要关注的事项与故障注入一致,部分运维操作场景和故障注入场景可能存在重叠,主要包括的场景有:滚动重启、 扩容(关注线性扩展比、对应用的透明度) 、缩容、补丁/版本升级、在线 DDL(增、删、修改字段、创建索引)和容灾切换等。其中,容灾切换需要模拟各类场景进行重点测试,如测试系统在计划内切换(主备机房不停机)和计划外切换(主备机房完全失联)场景下的表现。

4.5 DR Auto-Sync 专项场景

DR Auto-Sync 架构 ( https://docs.pingcap.com/zh/tidb/stable/two-data-centers-in-one-city-deployment#单区域双-az-部署-tidb ) 适用于同城双机房 RPO=0 的高可用容灾架构 (本系列后续文章将进行详细介绍,敬请关注)

该方案在同一区域部署两个 AZ (**Availability Zone, AZ),以满足高可用和容灾要求,且成本更低** 。下图为集群部署架构图:

  • 集群采用推荐的 6 副本模式,其中 AZ1 中放 3 个 Voter,AZ2 中放 2 个 Follower 副本和 1 个 Learner 副本。TiKV 按机房的实际情况打上合适的 Label。
  • 副本间通过 Raft 协议保证数据的一致性和高可用,对用户完全透明。

该部署方案定义了三种状态来控制和标示集群的同步状态,该状态约束了 TiKV 的同步方式。集群的复制模式可以自动在三种状态之间自适应切换。

  • sync:同步复制模式,此时从 AZ (DR) 至少有一个副本与主 AZ (PRIMARY) 进行同步,Raft 算法保证每条日志按 Label 同步复制到 DR。
  • async:异步复制模式,此时不保证 DR 与 PRIMARY 完全同步,Raft 算法使用经典的 majority 方式复制日志。
  • sync-recover:恢复同步,此时不保证 DR 与 PRIMARY 完全同步,Raft 逐步切换成 Label 复制,切换成功后汇报给 PD。

针对应用双机房部署的情况,通过混沌测试的场景设计,来验证 TiKV 和 PD leader 的最佳放置位置以及流量分发的最优链路,以期实现最佳的性能。如图所示,根据业务流量访问和数据 Leader 分布分别在单、双中心的四种场景组合进行测试,从而找到最佳方案。

混沌测试的收益和实战举例

5.1 掌握能力边界

混沌测试能够帮助我们全面了解系统的能力边界,为业务上线及后续的运维提供重要的参考依据, 具体包括:获得当前配置和部 署下数据库最高可承载的业务量,为容量规划提供指导;评估数据库的扩展能力,为未来的扩容提供指导;模拟各类故障对数据库服务能力的影响,进而验证和优化应急预案设计;模拟各类运维操作对数据库服务能力的影响,从而指导变更流程设计;模拟单表数据快速增长,评估对数据库性能的影响,并采取相应的优化措施。

实测结 果举例:

  • 系统弹性能力评估:
  • 在线扩容、操作简单,对应用、对表物理模型完全透明。
  • 容量、性能线性扩展比超过 90%。
  • 单表数据量增长对 SQL 时延影响场景:

银行核心业务中,部分业务表(如交易流水表)数据量会随着业务办理而急剧增长,并需在生产集群中保留一定时间(超过一定周期转移到近线库,超过在线查询周期转移到带库存储)。这类表通常体积较大,银行客户基于对集中式数据库的使用经验,会担心单表数据量增长对性能产生影响。

为此,我们通过测试进行了验证。测试结果表明,单表数据(实测多张相关联业务表等比例增长)从百万级到 10 亿 急速增长的情况下,相关业务的 SQL 时延几乎不受影响,打消了客户的疑虑。如下图所示,短时间内少量业务流水表数据量急剧增长,相关业务 SQL 时延非常稳定,无明显变化。

5.2 获得最佳实践

混沌测试可以帮助我们发现系统全链路中的瓶颈点,从而进行针对性的优化,实现最佳实践。通过混沌测试,我们可以识别数据库部署架构和配置、负载均衡和探活配置、应用连接池和探活配置、双活架构下的数据库配置和流量分发、各类外围作业的时间窗口和并发度配置等方面存在的潜在问题,并进行相应的优化,例如调整数据库参数、调整流量分发规则、优化导入导出作业的并发度等。

实测结果举例:

  • Label 标签和服务器物理位置结合可以增强高可用能力:
  • 以 5 副本架构为例,最多可以同时容忍两个 Label 标签下的服务器掉线
  • 结合服务器物理位置规划,即可以同时容忍两组机柜下的服务器掉线
  • 在“DR Auto-Sync 架构 + 应用双活部署”专项场景中我们得出的最佳实践:
  • TiKV Leader 、PD Leader 指定在主机房
  • 主、备机房负载均衡分别访问本机房 TiDB-Server
  • 主、备机房流量按照 9:1 分发分发到本机房负载

5.3 提升高可用能力和优化应急预案

混沌测试能够帮助我们全面了解数据库在不同故障情况下服务能力的变化,从而检验应急预案的有效性,并针对性地进行优化。

实测结果举例:

  • 单点的离线类(实例和服务器级的异常 Crash )故障对 TiDB 数据库服务整体影响面小或者时间短,且可以自愈,基本不需要应急预案。
  • 单点离线类故障针对不同组件的影响程度从大到小排序:PD-Server (Leader) > TiDB-Server > TiKV-Server (主机房) ;其他,不影响在线服务,无感知。
  • 部署架构和 Label 配置结合物理位置设计情况下,机柜级故障约等同于单点故障 (因涉及实例多,影响面积略大,持续时间略久),可自愈,且基本不需要应急预案。
  • 单点的能力恶化类故障(服务器夯 / 实例夯 / IO 时延 / 网络时延等)对 TiDB 数据库服务影响较大,不可自愈,自愈方式可采用强制隔离下线或重启方式,这也符合分布式数据库 Fast-Fail 的应急思路。
  • 跨机房网络能力下降(非中断),对 TiDB 数据库的 DR Auto-Sync 架构的服务影响较大,不可自愈,需要应急预案(如将 Sync 模式降级为 Majority 模式 )。
  • 机房级中断类故障分为两种情况:
  1. 同城 (从) 机房离线(同城网络中断、批量宕机失联等)会导致 TiDB 服务中断,RPO=0,RTO 时间受服务降级参数影响 (通常设置 10s-30s),可自愈,不需要应急预案。
  2. 主机房离线(主机房网络中断,批量宕机失联等)会导致 TiDB 服务中断,可以保证 RPO=0,需要计划外容灾切换的应急预案。

这里的 “应急预案”仅指故障场景中满足 SLA 情况下的应急,不包括集群整体健壮性或健康度的修复。

若兼顾健壮性或健康度的修复,还需要关注的事项:

  1. 存活节点的资源使用率和负载均衡情况;
  2. 基础环境或硬件故障不可恢复情况,事后需要通过扩容、配置调整等手段补齐高可用能力。

常见的故障场景对于 TiDB 数据库服务的影响(下表中的 MTTR、业务影响比例受集群部署架构、故障实例个数、集群规模、业务负载特征、负载均衡探活策略等因素影响):

5.4 优化监控告警机制

混沌测试可以帮助我们检验和优化监控告警,确保监控告警能够及时、有效地发现和识别系统故障。以下是一些对监控告警设置的建议:

  • 确保告警覆盖所有的关键指标和组件,设置合理的探测频率。
  • 设置适度的冗余,保证根因可以通过告警直接发现,提升告警的可靠性。
  • 区别于集中式数据库,TiDB 作为原生分布式数据库具有原生高可用、高并发等特点,设置告警规则时需要考虑这些特点,避免简单的套用集中式数据库的告警思维。
  • 建议以分类法进行告警梳理,确保告警覆盖面,可参考的分类维度有:运行状态类、黄金指标类、资源使用类、阈值类(结合配置参数)、日志和报错类、开发规范管控类(如慢 SQL / 全表扫描 SQL / 非规范语法)等。

过去一年,PingCAP 在金融行业场景累计完成数千个混沌演练测试,发现近百个问题。展望未来,PingCAP 将持续深耕金融行业,积极探索混沌工程在分布式数据库领域的应用,通过不断丰富的故障场景,结合故障诊断、根因分析等技术手段,做好故障沉淀积累,稳步提升 TiDB 处理异常事故及极端场景的应变能力,为金融业务稳健运行提供有力保障。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:/a/626745.html

如若内容造成侵权/违法违规/事实不符,请联系我们进行投诉反馈qq邮箱809451989@qq.com,一经查实,立即删除!

相关文章

【AI学习】对指令微调(instruction tuning)的理解

前面对微调(Fine-tuning)的学习中,提到指令微调。当时,不清楚何为指令微调,也一直没来得及仔细学习。 什么是指令微调?LLM经过预训练后,通过指令微调提升模型的指令遵循能力。所谓指令&#xf…

【微记录】dmidecode是干什么的?常用来做什么?如何查看系统支持的PCIe版本号(本质:标准,Desktop Management Interface)

是什么 dmidecode 是一个在 Linux 系统提取硬件信息的命令行工具。DMI 代表桌面管理接口(Desktop Management Interface),是一种标准,收集桌面计算机的硬件信息,包括系统制造商、序列号、BIOS 信息、系统资产标签等。…

AI图像生成-基本步骤

模型板块 1、新建采样器:新建节点-》采样器-》K采样器 2、拖动模型节点后放开,选择checkpoint加载器(简易),模型新建成功 提示词板块 1、拖动正面条件节点后放开,选择CLIP文本编码器,模型新建…

UV胶的应用场景有哪些?

UV胶是一种特殊的胶水,其固化过程需要紫外光照射。它具有快速固化、高强度、无溶剂挥发等优点,因此在许多应用场景中被广泛使用。UV胶的应用场景非常广泛,包括但不限于以下几个方面: 1.电子产品组装: UV胶在电子产品的组装中扮演…

SHELL-双重循环习题练习

1.99乘法表 #!/bin/bash #99乘法表for ((second1; second<9; second)) dofor ((first1; first<second; first))do echo -n -e "${first}*${second}$[first*second]\t" done echo done ######### 首先定义了一个外循环变量second&#xff0c;初始值为1&am…

【JavaEE】Spring Web MVC入门:掌握Spring的MVC框架基础

目录 Spring Web MVC什么是Spring Web MVCMVC 定义什么是Spring MVC 学习Spring MVC1. 项目准备2. 建立连接 Spring Web MVC 什么是Spring Web MVC 官⽅对于 Spring MVC 的描述是这样的&#xff1a; Spring Web MVC 是基于 Servlet API 构建的原始 Web 框架&#xff0c;从⼀…

【go项目01_学习记录12】

代码组织 1 代码结构2 重构与测试2.1 安装测试功能2.2 testify 的常用断言函数 3 表组测试 1 代码结构 所有的代码写在一个main.go文件里面&#xff0c;GO编译器也是可以正常执行的。但是当代码量很庞大时&#xff0c;很难进行维护。 Go Web 程序的代码组织 单文件——反模式…

C51 单片机编程模板及编码规范

文章目录 一、C51 单片机模板创建1. 新建工程及选型2. 创建主程序文件3. 创建主程序的头文件4. 编译配置5. 其他 二、C51 的编码规范 在查阅了很多关于 C51 单片机的程序后&#xff0c;个人感觉目前网上有关 C51 单片机程序的质量参差不齐&#xff0c;很多程序的代码风格及其糟…

Kubernetes——CNI网络组件

目录 一、Kubernetes三种接口 二、Kubernetes三种网络 三、VLAN与VXLAN 1.VLAN 2.VXLAN 3.区别 3.1作用不同 3.2vxlan支持更多的二层网络 3.3已有的网络路径利用效率更高 3.4防止物理交换机Mac表耗尽 3.5相对VLAN技术&#xff0c;VXLAN技术具有以下优势 四、CNI网…

设计模式-动态代理

目录 定义 代理模式的优缺点 优点 缺点 应用场景 静态代理 动态代理 相关资料 定义 代理模式&#xff08;Proxy Pattern&#xff09;是一种结构型设计模式&#xff0c;它的概念很简单&#xff0c;它通过创建一个代理对象来控制对原始对象的访问。代理模式主要涉及两个…

分布式搜索-elaticsearch基础 概念

什么是elaticsearch: 倒排索引&#xff1a;就是将要查询的内容分成一个个词条&#xff0c;在将词条文档id存入&#xff0c;词条是唯一的。 文档词条总结: mysql和Elasticsearch概念对比: 架构: 基本概念总结:

uniapp 实现下拉刷新 下滑更新

效果图 在app或者小程序中向下滑动 会出现刷新数据 ,而上拉到底 需要更新数据 功能实现 主要俩种方式 依赖生命周期 在page.json中开启 page.json "style" : {"navigationBarTitleText" : "小小练习","backgroundTextStyle": &qu…

Transformer模型详解05-Decoder 结构

文章目录 简介结构原理第一个 Multi-Head Attention第二个 Multi-Head AttentionSoftmax 预测输出单词 简介 Transformer 模型由编码器&#xff08;Encoder&#xff09;和解码器&#xff08;Decoder&#xff09;两部分组成。这里我会着重描述解码器的结构以及在预训练、输入输…

StNet: Local and Global Spatial-Temporal Modeling for Action Recognition 论文阅读

StNet: Local and Global Spatial-Temporal Modeling for Action Recognition 论文阅读 Abstract1 Introduction2 Related Work3 Proposed Approach4 Experiments5 Conclusion 文章信息&#xff1a; 原文链接&#xff1a;https://ojs.aaai.org/index.php/AAAI/article/view/4…

期权(1):基本概念,权利金,定金,买方,卖方,零和游戏,对赌协议

期权是合约&#xff0c;权利金就是定金&#xff01; 合约到期时 买方可以选择行权&#xff0c;也可以选择不行权。代价就是定金损失。因此亏损封顶&#xff0c;但盈利无限。卖方赚的就是买方的定金&#xff0c;盈利封顶&#xff0c;但亏损无限。 从这里&#xff0c;我们看出…

短视频拍摄+直播间搭建视觉艺术实战课:手把手场景演绎 从0-1短视频-8节课

抖音短视频和直播间你是否遇到这些问题? 短视频是用手机拍还是相机拍?画面怎么拍都没有质感 短视频产量低&#xff0c;拍的素材可用率低 看到别人用手机就能把短视频拍好自己却无从下手 明明已经打了好几盏灯了,但是画面还是比较暗 直播软件参数不会设置&#xff0c;电脑…

【Python探索之旅】列表

目录 特点 入门 访问元素 新增元素 修改元素 插入元素 删除元素 完结撒花 前言 在Python中&#xff0c;列表(List)是最常用的数据结构之一&#xff0c;类似于其他语言&#xff0c;如Java&#xff0c;与其不同啊Python中不需要声明数据类型。它提供了一种灵活且高效的方式…

MySQL创建索引报错 Specified key was too long;max key length is 1000 bytes.

MySQL对创建索引的大小有限制&#xff0c;一般索引键最大长度总和不能超过1000个字节。 问题描述 MySQL创建索引时报错 Specified key was too long;max key length is 1000 bytes. 解决办法 (1) 修改存储引擎 InnoDB的索引字段长度限制大于MyISAM&#xff0c;可以尝试改成…

ansible利用playbook 部署lamp架构

搭建参考&#xff1a;ansible批量运维管理-CSDN博客 定义ansible主机清单 [rootansible-server ~]# vim /etc/hosts 192.168.200.129 host01 192.168.200.130 host02 [rootansible-server ~]# vim /etc/ansible/hosts [webserver] host01 host02 在ansible端编写index.html…

【windows小知识#1】ISO镜像,OEM、Retail这些到底是什么意思

汇总一下每个版本windows会衍生哪些镜像出来&#xff0c;以windows7为例 这些文件名代表的是不同版本和不同语言的Windows 7操作系统的安装光盘映像&#xff08;ISO文件&#xff09;。这些文件主要区分为以下几个方面&#xff1a; 语言&#xff1a;这些文件都是中文版&#x…