声网王浩宇:RTE 场景下的 Serverless 架构挑战【RTE 2022】
前言
在「RTE2022 实时互联网大会」中,声网云原生边缘计算团队的负责人 @王浩宇 Dylan 以《RTE 场景下的 Serverless 架构挑战 —— 声网如何兼顾后端服务的可靠、高效和快速迭代》为题进行了主题演讲。
这也是声网第一次在 RTE 大会上,对外分享内部的一些后端技术实践。相信大家也一直比较好奇,声网如何在广泛的 RTE 应用场景下解决服务的高效扩展问题。
以下内容基于 @王浩宇 Dylan 于大会中演讲内容整理,为方便阅读略有删改。
01 实时互动后端技术演进
先看一下三个主要的业务需求:
一是不断爆发的新互动场景。从 RTC 的视频、推流、录制、鉴黄的基础能力,到 RTE 的灵动课堂、互动游戏、一起 KTV、空间音频、AI 声纹等等。现在的互动场景越来越复杂,相比以前仅仅需要满足音视频的互通,已经到了需要同时兼顾复杂的信令过程、复杂的数据交互。
二是追求更加稳定可靠的极致质量。从原本的低延迟、低卡顿率,上升到 RTE 实时互动体验的质量标准 XLA;需要去支持异常情况下的智能容灾,异常自动恢复。
三是敏捷高效的大规模扩展能力。实时扩容,支持超大规模的业务场景弹性,以低成本覆盖全球各个国家和地区。
以上这些,都是让实时互动更加易用、更加普及的能力和需求。
在讲声网如何解决这些场景需求之前,我想先跟大家讲一下这些年在各种边缘云和公有云场景下,当前的一些典型架构模式。
在边缘上最传统也最成熟的模式是 CDN 的分发。这种架构经历了几十年的演进,已经非常的成熟稳定。最常见的场景像基于 CDN 的直播、边缘函数、IoT 等等。
基于 CDN 的场景也能够高效的满足弹性、扩展、覆盖的问题。它的优势在于,这样的一个简单静态配置,一般只用关注一个链路切换就可以实现横向的边缘扩容。但这种场景下只能解决分发、传输和接入能力,没有办法去实现复杂的多项交互的业务。
现在的互联网业务几乎都是云化的,公有云场景经过这些年的发展,几乎能支持一切的互联网业务。它具备完备的储存、计算、事务等各种云服务和中间件的能力,易用性和扩展性良好。但有一个问题是链路很复杂,用了云之后意味着重度依赖基建的可靠性,任何一环都不能出问题。
大家也知道声网基本是不用公有云的,也用不了 CDN。我们提出了自己的实时互动边缘云,希望能在我们的边缘云上同时具备边缘的灵活和云的强健,能够在边缘实现复杂的实时互动逻辑,不依赖专线实现可靠传输,解决数据和状态的全球同步。
我们希望做到又快又好,在任意环境都可以运行,覆盖全球的每一个角落。去支持从密集计算的突发任务,到有状态服务在内的任意负载,能够去 Serverless 化,支持动态的资源分配和弹性伸缩。
不同于传统的中心化模式,声网其实并不需要类似 CDN 的回源这类的核心节点,整体架构都做了去中心化。好处是可以彻底摆脱对机房和运营商的依赖,也不需要对基础设施做很高程度的可用性保障。
另外一方面,云的易用性带来了复杂度的急剧增长,故障概率和影响范围也进一步加剧。这些年不管是国际上的一些巨头还是国内的一些厂商,基本都出现过大范围的故障。并且如果是骨干网或者运营商故障,很多情况下是没有办法挽回的,云网络底层的 BGP 协议一旦在路由层面出问题,可能影响整个大洲。例如北美最近一两年已经遇到过多次公有云几乎整体断网的情况。
声网希望能够在实时互动边缘云上做到真正的反脆弱性,所以会对任何的基础设施去做一定的故障预设。我们的服务至少满足 N-3 的冗余度,意味着不会依赖任何单一的基建或者运营商,在任意区域均可承受 3 个机房故障不影响可用性。
02 实时互动 x 边缘 Serverless
上述几点在过去几年我们反复提及过,今天想要给大家讲的是在边缘云的能力上,Serverless 如何进一步驱动业务创新。
这里主要有几个点:
提供了一致化的云能力
不同的 RTC、RTE,包括录制、推流、RTIC 等业务之间,都需要一个可复制的架构能力,去保障开发者在使用不同云服务的时候,均能享受到相同水平的弹性,可扩展性和健壮性的服务。
完备的调度覆盖和全球扩展能力
想要真正做到完备的调度覆盖和全球扩展,不是单独的某一个业务做到,而是需要所有业务都做到。我们的 Serverless 可以在有服务器和网络的地方完成即刻覆盖,不需要考虑机器的规格如何,通过负载均衡机制都能去实现最优的分配策略,满足质量与负载的平衡。
专注于业务迭代
为了给开发者实现最大程度的价值,我们要满足更快的需求交付。声网内部研发在无需关注底层资源的同时,会享受到丰富的流量调度和灰度能力。对外大家能看到的实际体现,就是声网这些年互动应用的不断爆发。
高性价比
同时,我们也需要给开发者提供最高性价比的服务。声网利用极致的灵活与弹性的边缘资源,能够替代公有云沉重的基建成本,不用去购买昂贵的公有云的带宽以及专线。
在这些需求之外,声网是如何真正在边缘实现所有类似的应用落地,这里面又有什么挑战?我想先用一个稍微有点复杂的小表格,来跟大家讲一下。
在讲挑战之前,我们先提一个传统意义上原生应用架构跟实时互动应用的区别。
云原生应用很多时候大家都在讲无状态性,但所有的实时互动应用几乎都跟流有关。streaming 意味着信息的高效传递,所有的数据都在毫秒级的时间传达到对方。我们没有办法再去做一个无状态协议,把流做切片。
相信大家也知道,如果用 HLS 的协议去拉流,它的延迟比 RTC 会差出一个数量级或更多。所以在实时互动应用场景下,一定会选择用有状态的实时流服务去实现业务,追求在性能、成本、可能性层面,都做到极体验致,但代价就是需要去管理这里的复杂度,无论是扩容、迁移、升级、维护,扩展,一切都变得非常的麻烦。
过去云厂商包括一些互联网大厂,也都在做面向无状态服务的 Serverless 架构,让大家都能有各种各样的函数服务去解决这种短暂无状态应用,包括对冷启动时间不敏感的场景,这是迄今为止 Serverless 的技术白皮书当中推荐的场景应用模式。但这样的 Serverless 方案,从运行环境、API 到运行时间层面,都是层层受限的。
我们在实现一些像音视频之类比较重的业务时,不管是启动时间还是业务的运行时长,或者是需要用到的各种各样的 API,都会对基建能力和 Serverless 能力提出全新的高要求。
以录制场景为例,最早声网在没有提供内部的云能力之前,也是让客户用 SDK 录制,也就是一个 Linux SDK。这种在服务端跑 SDK 的好处就是不受限,想实现各种各样的业务场景都可以,非常灵活。
但是 SDK 录制也有几个非常显著的问题:
机房/云厂商网络波动影响录制质量
扩缩容困难,部署维护复杂
跑起来简单,高可用难
我们发现,如果要想把实时互动场景做好,必须要把各种各样的复杂的有状态服务,帮助客户简化复杂度,基于此我们推出了云录制。
当然除了录制外,声网还有大量其他的业务场景,因为时间关系我们就拿录制这一个例子来举例,也方便大家来理解。
简单来说,开发者不再需要维护一个有状态的服务,只需要调声网的一个无状态的 RESTful 接口,就可以完成频道的录制。
我们来具体看一下,录制场景当中 Serverless 会带来哪些挑战。简单来说这里面有几条:
不确定负载,根据主播人数帧率码率不同实时变化
有状态持续性任务,频道可能持续数小时乃至数天
保障任务唯一性的同时允许更新任务
强实时性和可靠性,无法接受丢路与黑屏
需满足全球化场景,即使主播和最终录制存储区域不同。例如:
° 客户服务器在新加坡发起录制
° 主播在中东接入 RTC
° 录制文件上传到北美
通常来说,这些场景中的传输问题,客户往往没有办法自行搞定。因此在实时互动边缘云场景中,声网提出了如下图所示的架构:
声网有一套叫 UAP 的云原生边缘应用平台,可以就字面意义理解为通用应用平台。开发者可以在上面运行任意的应用代码。
中间是 RTE Runtime,可以理解为声网内部的服务端 SDK。上面的任意应用代码可以被跑在任意位置,UAP 平台会帮大家去管理资源编排、容量规划、迁移管理、负载感知、智能调度、动态组网在内的边缘场景下的问题。
总的来讲,我们希望通过对底层资源包括对边缘复杂度的封装,让业务能够只关注在最上层的应用代码的开发。同时大家也可以把这个平台想象成一个 Linux SDK,可以用来做各种各样的 RTE 的场景。
为了方便大家理解相关概念,给大家看一个简单的例子。
上图左下角是一个 golong 的例子,借助 UAP 可以用一个非常小的 library 快速的把任意的代码逻辑集成进来。这里的运行环境是不受限的,开发者可以用任意的容器负载放进来,同时我们提供一个完全云原生化的应用规范和标准,做到分钟级的部署。
上图右侧是声网内部的一些 CRD。在这个 Demo Serverless 的例子中,我们定义了几个 worker,用了一个自定义的 demo 镜像,Request 的一部分资源。在分钟级的时间内,就可以把这样的一个 Demo Serverless 推广到全球的各个边缘上。
同时业务不需要管节点跑在哪、怎么连到它,整个过程都是有动态注册、动态分配的,这一点后面我们会详细来讲。
当然这是最简单的一个集成的场景,还有很多其他的功能模块可以按需扩展。
下面来讲一下,刚刚说的接入分配的过程。
上图左侧的示例图有些复杂,所以我做了一个简化,大家可以看右边的这三个小圆圈。
我们在做任何边缘业务的时候,第一步要考虑的就是调度,也就是需要满足哪些不同场景。比如说可能有些是对负载比较敏感,有些对时延比较敏感,有些对地理位置比较敏感,这些条件都会由算法规划出来一个最佳的调度策略。
同时业务也可以在上面去自定义想要的业务逻辑。比如可能想要多个不同的版本,想在不同的区域用不同的版本,包括可能精确到不同的业务场景去用不同的版本,又或者可能他有自己的业务属性,在他的业务属性下可以进一步去控制更复杂的策略。
比如说像汇聚,最终在端测声网的 SDK 也会去完成一个动态组网,实现汇聚→迁移→重连的高可能闭环。经过这几个步骤的整合,基本上可以帮业务做到透明化。
在分配的基础上,还有一层是服务部署在哪里,这是一个云原生的资源编排问题。在声网内部有一套叫做 HCI 的底层云原生平台,它是基于 kubernetes 开发的。我们把这整套的云原生架构推广到了声网在全球的所有边缘上。
除 kubernetes 本身有的一些机制外,我们还做了一些特殊的逻辑。
首先是一个基于云原生的全球资源控制面。我们同时有 HCI 核心环境和 HCI 边缘环境,这两个环境同时满足分钟级调度至全球任意边缘节点的能力。
在简单的 Kubernetes 里面,我们认为它是一个裸 API,而我们提供的是经过一定封装的平台,不是让开发者直接在里面裸跑容器,是经过负载封装之后,有一个不受限的运行环境,同时它能在平台上很好的管理长驻进程、有状态的长生命周期任务、动态函数等。
另外是为边缘设计优化。在边缘上使用复杂业务场景具有相当的困难性。比如说有些业务它需要弹性的 IP,IP 需要能够跟着 Pod 进行迁移;又或者说需要一个四层的边缘负载均衡器,针对这些情况我们都实现了软件化的边缘弹性,可以在边缘环境中快速实现各种各样的丰富的网络栈扩展。
同时像复杂业务基本上会有更加麻烦的一些编排策略,比如说可能需要在一组 Pod 之间去共享 Sidecar,多版本灰读等丰富的编排策略,这些都会在内建的 CRD 当中得到支持。
下面再来看一个简单的 DEMO。
上图是我们的 DEMO Serverless,展示了如何一键部署到边集群。在我们内部既有图形化的界面,也有类似图中这样的命令行发布工具,开发者可以用完全云原生的方式一键部署,就像在操作 Kubernetes 一样。在业务负载层面,既然是 Serverless 那肯定是要让业务不去关注资源层面的问题,所以我们有一个高精度的容量预测和动态伸缩能力支持。大家可以看下面这个图:
这是一个线上业务的预测窗口,窗口内的黄色区域是提前 15 分钟预测出来的一个调度线。
从图中前半段的曲线可以看出,预测值和实际情况保持了高度的准确性。我们的动态调度能力可以让开发者在使用云原生边缘平台的时候,更好的实现资源层的灵活性,而不需要去关注到底要在不同的区域中规划多少容量,同时还可以实现容量间的实时调配,为不同的业务实现更好的弹性。
在这些基础上,我们还解决了传统云原生当中非常难以解决的一个问题 —— 动态负载。如果所有资源都做静态分配,没有办法应对实时互动场景下突发的各类场景。我们前面举的例子,是一个频道内主播突然变多了,在这样的场景下,我们调度其实分成了两层。
上图左侧的草图是一个抽象的概念,表示的是在业务的 worker 层面,agent 会实时感知到机器和业务层面的负载情况。并且这是一个全网的对 CPU 内存、GPU 磁盘的使用情况的整体秒级感知,使得我们可以在秒级时间内去规避调度热点,做到完全实时的调度和迁移。
这个层面上和传统的容器静态分配不同,我们可以在动态规划资源池之后,动态的根据负载分配容量。如果出现了超大规模的频道,比如说客户做活动突然涌进了很多人,我们就可以快速的把机器上的其他业务迁移走,避免影响到其他业务场景。
这在本质上相当于实现了 Pod 与 Pod 之间的资源共享,一组相同的业务容器负载可以共享资源,我们就不用担心资源会分配过度或者分配不足。之前我们可能会说 request 2C 有点少、request 8C 有点多,那现在就无所谓了。其实所有的 Pod 之间,只要存在资源就都是可以共享的,但如果资源真的没有了,也会被动态的规划到别的地方。
智能路由是相对高级一些的能力,也相对比较复杂。
智能路由在业务场景中有时会被提到。
我们希望相同的频道一起被处理,比如抓娃娃机场景中,当大家一起在抓娃娃,我们希望用一个 convergeKey 实现任务的汇聚。如果娃娃机需要一个 GPU,那也可以在申请分配资源的时候带一个 GPU 加速。
同样,也可以去指定分配各种不同的版本,实现多版本并行的线上业务,我们会根据实际的业务场景给客户做动态分配。
还有一块是传输和状态管理,这一层面是声网真正的一个边缘大杀器。
边缘会存在非常多的脆弱性和不确定性,要想真正的解决复杂业务场景,不能只是靠分配、部署、托管,不是一个简单的 Serverless 就能搞定的。所以在后台除了 Serverless 能力之外,我们还有大量其他的后台能力,比如说 Worker 状态管理带来的可操作性。目前市面上没有什么 Serverless 场景是可以在任务启动过程中仍然去持续管理它的,这个时候我们的特殊架构便可以带来一些操作上的便利。
最后我们来简单回顾一下声网 UAP 在实时互动边缘云层面,跟现在市面上的其他云厂商相比做了哪些不一样的事儿。
这个表格不算列的很全,我们基本上都是按照遇到的业务场景、业务挑战,去做一些针对性的规划。但我们可以看到大量的第三方,包括云函数、云容器或者边缘函数现在的一些场景支持。
业界现在可能还没有真正意义上的实时互动边缘云,但从表格我们可以看到,声网可能是在 RTC、RTE 领域走的比较靠前的厂商了,并且一直专注给开发者提供开箱即用的是实时互动能力,所以在内部我们会更关注如何合理的解决这些问题。
之所以做这些,是为了什么呢?大致有三点:
进一步降低门槛
在内部我们希望能够降低 RTE 应用的开发门槛,带给大家更多、更快、更好的 RTE 后台服务。当然这是相当艰巨的一个挑战,现在还存在一定的门槛,即使在有了我们这样的一个平台的基础上,也需要开发者有非常强的研发能力,需要能正确的集成,去解决好高可用的故障切换。所以,我们还是希望能够进一步对能力做抽象和封装。
完善解决方案
同时,我们也在声网后台内部不断深化完善内部的基建能力,加强应用性和工具链,最终带给大家更多开箱即用的场景。
与生态和合作伙伴结合
进一步来讲,我们也希望能够跟生态合作伙伴做结合,通过云市场接入更多第三方的互动场景,放到我们的边缘云平台上。我们会针对有开发能力的合作伙伴,一起考虑如何进一步开放我们的实时边缘云的能力。
03 当 RTE 遇见 Serverless
前面讲的是声网内部的一些技术能力和方案,相信大家也会很关心我们的能力除了做了一个云录制之外,还能给大家提供什么?
下面我想从完整的业务场景来讲一讲,RTE 和 Serverless 之间的一些关系和技术展望。
在一个完整的业务场景里,除了前面提到的基础的 PaaS 能力,还有很大部分都是基于每一位开发者身上实现的应用逻辑,如何解决这类业务逻辑的交互问题也至关重要。
如果我们用最简单的方法来看,可以用无服务器的移动端把所有的应用逻辑都放在端测,这对开发者非常友好,简单无后台。但如果应用比较复杂,团队和业务已经到了一定规模,这种方法就很难满足更复杂的场景。
在早期我们能以这种几行代码集成的 RTC 开发很长的时间,帮助开发者把整个互动应用创新做好,但当业务做大做强的时候,就需要一个更加完整的后台。
下图包含一个大致的示意图,是当客户需要管理自己的业务信令、业务事件,结合声网的 SDK、NCS 回调,业绩服务端 RESTful API 并用的一个相对完整的业务场景。
上图中浅色的部分都是客户要实现的,深色的部分是声网的各种模块。如果我们上来就给开发者看这样一个图,很可能会觉得头有点大,看起来好复杂。但实际上这里的复杂结构一定程度上是不必要的。
大家可以看到,我们引入了三个端之间的交互。开发者的端侧以及我们的两套后台,这样势必会带来极大的通信成本,包括中间的交互链路。
假如说项目中声网后台的任意交互都有需要,那中间任何一端出了问题都非常麻烦,比如前面提到的云录制,可能要收一个云录制的回调,才能知道在录的过程中出现了什么样的问题。
但是有可能声网的录制并不能直接满足你的场景,比如说在录的过程中主播和观众需要同时出现,或者说在特定的时刻才开始录制,显然是需要特别关注在自定义的业务场景下的录制是如何实现的。我们过去直接提供的 API 不能直接帮客户实现这个问题,因此我们希望能够进一步的用 Serverless 去简化架构。
前几年大家有看到声网的 aPaaS,某种程度上就是新架构的体现。我们希望能够把我们跟客户之间的交互、客户跟后台之间的交互做简化。
这里我们把它粗略的分成两大类,实时互动场景和非实时互动场景。
非实时互动场景其实就是客户自己的业务端和后台的交互,但我们希望的是把实时互动相关的场景在声网整体做一个闭环。这样的好处是非常大的,因为实时互动相关的功能开发其实都不简单,声网可以帮开发者尽可能的去屏蔽这部分的复杂度,同时实现客户自定义的业务逻辑。比如说互动游戏场景中的仲裁、防作弊,这些都是没有办法单纯在端测去实现的。
整体来看,我们希望能够去赋能开发者,让实时互动触手可及。
我们并不是在做一个 Serverless,也不是传统意义上的云厂商,而是一个专注于做实时互动的平台,希望能通过基于 RTE platform 的开放性框架,让内部的实时互动边缘云更好的孵化 RTE 场景。
从 Serverless 的角度来看,我们更加关注整个生态以及实时互动应用后台能力的发展。
边缘应用正在变得越来越复杂,同样也越来越完善。
从电信运营商的角度看,电话,短信这些大家习以为常的基础服务都可以认为是边缘化的互动场景。
而声网后台今天带给大家的 RTC,RTE 互动能力,其实也是一个分布式的边缘云,未来的十年,我们认为整个实时互动边缘云,还会更多的走进大家的生活,会给开发者带来更多更复杂丰富的业务场景,也希望我们真正能够通过这样的 Serverless 能力,让实时互动变得触手可及,无处不在。
我本次的分享基本就到这里,谢谢大家的关注。也希望今天的这个分享能帮助到大家,欢迎大家持续关注声网未来在 RTE Serverless 应用领域的新进展。
声网王浩宇:RTE 场景下的 Serverless 架构挑战【RTE 2022】的更多相关文章
- API 管理在云原生场景下的机遇与挑战
作者 | 张添翼 来源 | 尔达Erda公众号 云原生下的机遇和挑战 标准和生态的意义 自从 Kubernetes v1.0 于 2015 年 7 月 21 日发布,CNCF 组织随后建立以来,其 ...
- 亿级流量场景下,大型架构设计实现【2】---storm篇
承接之前的博:亿级流量场景下,大型缓存架构设计实现 续写本博客: ****************** start: 接下来,我们是要讲解商品详情页缓存架构,缓存预热和解决方案,缓存预热可能导致整个系 ...
- 亿级流量场景下,大型架构设计实现【全文检索高级搜索---ElasticSearch篇】-- 中
1.Elasticsearch的基础分布式架构: 1.Elasticsearch对复杂分布式机制的透明隐藏特性2.Elasticsearch的垂直扩容与水平扩容3.增减或减少节点时的数据rebalan ...
- Android智能手机中各种音频场景下的audio data path
上一篇文章(Android智能手机上的音频浅析)说本篇将详细讲解Android智能手机中各种音频场景下的音频数据流向,现在我们就开始.智能手机中音频的主要场景有音频播放.音频录制.语音通信等.不同场景 ...
- CI Weekly #11 | 微服务场景下的自动化测试与持续部署
又一周过去了,最近我们的工程师正在搞一个"大事情" --「[flow.ci](http://flow.ci/?utm_source=bokeyuan&utm_medium= ...
- Ironic几种不同的场景下的网络拓扑
最近帮领导做了几页ppt,总结几种场景下ironic管理物理机网络的网络拓扑,简单做成一份文章记录下.只是方便自己记忆,没有认真修改.如果对ironic有一定了解,可以看下,加深理解. 1. vlan ...
- Qunar机票技术部就有一个全年很关键的一个指标:搜索缓存命中率,当时已经做到了>99.7%。再往后,每提高0.1%,优化难度成指数级增长了。哪怕是千分之一,也直接影响用户体验,影响每天上万张机票的销售额。 在高并发场景下,提供了保证线程安全的对象、方法。比如经典的ConcurrentHashMap,它比起HashMap,有更小粒度的锁,并发读写性能更好。线程安全的StringBuilder取代S
Qunar机票技术部就有一个全年很关键的一个指标:搜索缓存命中率,当时已经做到了>99.7%.再往后,每提高0.1%,优化难度成指数级增长了.哪怕是千分之一,也直接影响用户体验,影响每天上万张机 ...
- HashMap在并发场景下踩过的坑
本文来自网易云社区 作者:张伟 关于HashMap在并发场景下的问题有很多人,很多公司遇到过!也很多人总结过,我们很多时候都认为这样都坑距离自己很远,自己一定不会掉入这样都坑.可是我们随时都有就遇到了 ...
- 网页直播、微信直播技术解决方案:EasyNVR与EasyDSS流媒体服务器组合之区分不同场景下的easynvr
近期遇到好多客户咨询关于实现微信直播.或者是将直播页面集成进入自己项目中. 该方案的主要目的:完成在公网一直进行内网摄像头的RTMP/HLS直播! 实现方案的具体实现: EasyNVR+EasyDSS ...
- 超大规模商用 K8s 场景下,阿里巴巴如何动态解决容器资源的按需分配问题?
作者 | 张晓宇(衷源) 阿里云容器平台技术专家 关注『阿里巴巴云原生』公众号,回复关键词"1010",可获取本文 PPT. 导读:资源利用率一直是很多平台管理和研发人员关心的话 ...
随机推荐
- kafka常用命令(zookeeper与bootstrap-server)
在 0.9.0.0 之后的 Kafka,出现了几个新变动,一个是在 Server 端增加了 GroupCoordinator 这个角色,另一个较大的变动是将 topic 的 offset 信息由之前存 ...
- 某星球存在两种生物,A种生物有1个头6条腿,B种生物有3个头4条腿。来自地球的太空船刚刚在该星球降落, 突然发现一大群这两种生物组成的队伍,由于时间紧,只数了头的数量和腿的数量,请帮助宇航员分析A、B两种生物各有多少个。
package competition;import java.util.Scanner;/* 某星球存在两种生物,A种生物有1个头6条腿,B种生物有3个头4条腿.来自地球的太空船刚刚在 ...
- <连城诀>剧情大纲+随笔
--剧情还是偷个懒,从百度百科抄袭一下,红色字体为补充和说明 在湘西沅陵南郊的麻溪乡下,三间小屋之前的晒谷场上,隐居此处多年的剑术名家"铁索横江"戚长发,看着徒弟狄云与女儿戚芳 ...
- 2020-2021第一学期2024"DCDD"小组第十周讨论
2020-2021第一学期"DCDD"第十周讨论 小组名称:DCDD 小组成员:20202403孟凡斌.20202411陈书桓.20202416刘铭睿.20202420黄椿淇 照例 ...
- 在Unity3D中开发的Sketch Shader
Pencil Sketch Shader 特点 此素描渲染风格的Shader是顶点片元Shader,由本人手动编写完成. 此素描渲染风格的Shader已经在移动设备真机上进行过测试,可以直接应用到您的 ...
- Python基础数据类型-Number(数字)
a = -1 # int b = 2.0 # float c = 13.11 # float d = 3.14j # complex print(type(a), type(b), type(c), ...
- python起航之路 Day1
一.Python安装 windows 1.下载安装包 https://www.python.org/downloads/2.安装 默认安装路径:C:\python273.配置环境变量 [右键计算机]- ...
- python读取与处理netcdf数据
netcdf是气候数据中的主流格式,当涉及到大范围的全球数万个格网点数据时,使用python脚本可以较快地读取与处理. import netCDF4 from netCDF4 import Datas ...
- 高并发解决方案之 mysql悲观锁:select ... for update
select ... for update 场景:多个进程都先读后写咋办,需要的是让他们串行执行. 比如库存的减少.一般这些操作都是很长一串并且是开启事务的.如果库存刚开始读的时候是1,而立马另一个进 ...
- 求小于N的最大素数
问题 求小于N的最大素数 分析 枚举:从可能的集合中一一列举各元素 枚举过程中需要考虑的问题: 给出解空间 减少搜索的空间 采用合适的搜索顺序 枚举关键字(枚举核心):减少规模 代码实现 1 impo ...