从集群资源管理和任务调度角度看spark_spark集群资源是否紧张-程序员宅基地

技术标签: 分布式计算  spark源码  

讲spark的文章很多,切入点无非就是三个:框架应用、源码和原理讲解、性能优化

个人觉得上面的三个视角切入点都过于偏重细节,比较适合行业工程师(应用开发、研发、维护);对于初入行的学习者和非工程师角色比较不友好,本文尝试从一个更高视角去介绍spark,尽量让大家明白这个东西是个什么,如何演化过来的;为什么它会长成现在模样,包括那些模块。

0. 集群资源管理与任务调度系统出现的背景

(1)出现背景

  • 提高集群资源利用率。

在大数据时代,为了存储和处理海量数据,需要规模较大的服务器集群或者数据中心,一般说来,这些集群上运行着数量众多类型纷杂的应用程序和服务,比如离线作业,流式作业,迭代式作业,crawler server,web server等,传统的做法是,每种类型的作业或者服务对应一个单独的集群,以避免相互干扰。这样,集群被分割成数量众多的小集群,有的集群运行Hadoop,有的运行Storm,有的运行Spark,有的运行web server,然而,由于不同类型的作业/服务需要的资源量不同,因此,这些小集群的利用率通常很不均衡,有的集群满负荷、资源紧张,而另外一些则长时间闲置、资源利用率极低,为了提高资源整体利用率,一种解决方案是将这些小集群合并成一个大集群,让它们共享这个大集群的资源,并由一个资源统一调度系统进行资源管理和分配,这就诞生了Borg,YARN,Mesos,Torca,Corona。从集群共享角度看,这类系统实际上将公司的所有硬件资源抽象成一个台大型计算机,供所有用户使用。

  • 服务自动化部署

一旦将所有计算资源抽象成一个“大型计算机”后,就会产生一个问题:公司的各种服务如何进行部署?同样,Borg/YARN/Mesos/Torca/Corona一类系统需要具备服务自动化部署的功能,因此,从服务部署的角度看,这类系统实际上是服务统一管理系统,这类系统提供服务资源申请,服务自动化部署,服务容错等动能

以上只是简单的介绍了这一类系统的设计动机和产生背景,接下来从两个角度解析这类系统。

角度一:数据中心编程

任何一个公司内部所有的硬件资源均可看做一个数据中心,通过Borg/YARN/Mesos/Torca/Corona一类系统对这些资源进行统一管理后,用户所有的程序和服务将通过一个统一入口进入数据中心,并由这类系统为之分配资源、监控程序和服务运行状态,并在失败时启用必要的容错机制,汇报程序的执行进度等,而至于应用程序或者服务运行在具体哪台机器上,所在机器的ip、端口号是什么,则用户无需管理,全部交由统一管理系统进行管理(用户也许可以查询到)。

具体说来,采用此类系统之后,当用户执行应用程序或者部署服务时,只需通过一个配置文件描述应用程序或服务需要的资源(比如CPU、内存、磁盘、操作系统类型等)、待执行的命令、依赖的外部文件等信息,然后通过一个客户端提交到Borg/YARN/Mesos/Torca/Corona上,剩下的工作则完全交给系统。

角度二:生态系统

从另外一个角度看,Borg/YARN/Mesos/Torca/Corona一类系统可以为公司构建一个内部的生态系统,所有应用程序和服务可以“和平而友好”地运行在该生态系统上。有了这类系统之后,你不必忧愁使用Hadoop的哪个版本,是Hadoop 0.20.2还是 Hadoop 1.0,你也不必为选择何种计算模型而苦恼,因此各种软件版本,各种计算模型可以一起运行在一台“超级计算机”上了。

从开源角度看,YARN的提出,从一定程度上弱化了多计算框架的优劣之争。YARN是在Hadoop MapReduce基础上演化而来的,在MapReduce时代,很多人批评MapReduce不适合迭代计算和流失计算,于是出现了Spark和Storm等计算框架,而这些系统的开发者则在自己的网站上或者论文里与MapReduce对比,鼓吹自己的系统多么先进高效,而出现了YARN之后,则形势变得明朗:MapReduce只是运行在YARN之上的一类应用程序抽象,Spark和Storm本质上也是,他们只是针对不同类型的应用开发的,没有优劣之别,各有所长,合并共处,而且,今后所有计算框架的开发,不出意外的话,也应是在YARN之上。这样,一个以YARN为底层资源管理平台,多种计算框架运行于其上的生态系统诞生了。

(2)目前的挑战

  • 数据中心的负载种类越来越多,有批处理任务、实时查询任务、流式服务等;
  • 异构负载的资源需求越来越多样化,资源约束和偏好越来越复杂,例如:一个任务运行需要考虑CPU、内存、网络、磁盘甚至内存带宽、网络带宽等,还需要考虑数据本地行,对物理机的偏好等;
  • 不同类型任务在实际调度过程中不可避免会调度至相同的数据节点上,这就需要对不同种类的任务进行隔离以减少两者之间的干扰;
  • 调度过程中的动态资源调整;
  • 任务抢占模式下的重调度机制;
  • 故障恢复;
  • 集群中不可知原因的长尾问题;
  • 集群资源利用率低,全球云服务器的平均物理资源利用率低于20%,并且通常在逻辑资源几乎全部分配的前提下实际的物理资源利用量不及资源申请总量的一半;

(3)抽象模型
其实集群资源管理和任务调度系统就是一个复杂的多维混合背包问题,背包问题应该是动态规划问题中最经典的问题。我们可以将集群中的每个数据节点比作一个背包,不同背包不同维度的容量是不同的,将任务比作是需要放置的物品,任务所需要的资源就是其花费,而任务运行产生的租赁费用即为效益。我们需要做的就是在满足任务需求的前提下将其放置在适合的背包中,保证集群利用率最高。但是实际的调度过程和该算法还有很多不同的地方,例如:

  • 背包问题只是一个推演的过程,我们可以使用一些数据结构来保存一些中间结果来推导出最优的分配方式。但是实际的调度中来了一个任务我们要马上根据现有的资源情况进行分配,而不能暂时存留一个分配方案,等多有任务都提交完成之后再根据最优的方案进行任务放置;
  • 不同的任务在实际运行过程中有一定的优先级,需要保证高优先级的任务最先被保证,这就增加了调度的难度;
  • 任务在运行过程中的资源需求不是一成不变的,有时候会随着时间的变化增加资源需求,这就是弹性调度需要解决的问题。
  • 任务之间还会产生干扰,并且不同资源敏感度的任务在不同资源维度上的干扰是不同的;
  • 资源管理和调度系统相当于系统的大脑,其要处理所有数据节点和任务的各种请求,所以其核心的调度逻辑一定不能太过复杂,如果考虑所有的情况后再进行调度,势必会延长调度时间,这是任务执行所不能容忍的;
    因此对于一个资源管理和任务调度系统来说,其的职能就表明其不可能是一个完美的系统,也不可能是一个通用的系统,需要针对不同的业务场景进行改造,因此就在工业界和学术界激起了广泛的研究和探索。

(4)系统演进

  • 整体上来说分为:单层调度系统,两层调度系统,共享状态调度系统,分布式调度系统,混合式调度系统。
  • Google提出MR模型
  • 批处理框架Hadoop的出现
  • 内存计算框架Spark的出现
  • 资源管理框架Mesos、YARN、borg的出现
  • 基于状态共享的Omega
  • 完全的分布式调度器Sparrow
  • 中心式和分布式相结合的混合架构Mercury
  • 支持快速故障恢复的Fuxi
  • 支持在离线混合调度的阿里混布系统
  • 基于容器的集群管理框架kubernetes的出现

(5)一些分配策略演进

  • FIFO方式,先来先分配后来后分配;该方式虽然不能保证调度最优但是因为简单在目前的资源调度系统中也广泛使用;
  • 公平调度,将资源分配为多个不同的资源池,每个资源池中分配一定比例的资源,任务在资源池中按照最大最小策略(例如有三个任务分别需要的资源是2 ,4, 4 个单位,而现在总共有9个单位资源,首先每个任务平均得到3个单位资源,因为第一个任务多了一个单位资源,其将多出的一个单位资源再平均分配给任务二和三,所以最终任务一得到2个单位资源,任务二得到3.5个单位资源,任务三得到3.5个单位资源)或者加权的最大最小策略(不同任务具有不同的优先级,所以在平均分配的时候还需要考虑权重)进行资源分配。
  • DRF主资源优先调度。对于一个任务来说其主资源是其各维度资源申请中占比最大的资源,例如一个任务需要<2CPU,4G>,现在有<4CPU, 10G>,比例为1/2,4/10,那么CPU就是该任务的主资源。在分配时候选择主资源占比最小的任务进行优先分配,目前该方式被广泛的应用在各种调度系统中。有兴趣的可以搜索相关论文查看其详细的论证过程。
  • 最短作业优先调度。有研究表明采用最短作业优先调度的方式可以提高系统资源利用率,其实也比较容易理解,短作业需要的资源少所以在分配的时候可以尽快被满足,另外短作业的执行时间少,所以可以尽快的释放资源,这对于提高集群吞吐量和利用率都有好处。但是这种方式也存在缺点就是长作业会出现长时间得不到资源而饿死的情况;另外任务的执行时间预先是不可预知的;
  • 能力调度器,被默认应用在YARN中。其原理是为不同的用户组构建不同层级的任务队列。在进行分配时,优先选择min{use/分配}的队列进行分配,在队列内部按照FIFO的策略进行选择。所以选择的过程可以总结为下面步骤:(1)根据最小满足比选择一个任务队列;(2)在任务队列中选择一个具体的任务;(3)从该任务中选择一个资源申请请求,因为一个任务可能会对应多个资源申请请求;得到这个请求之后与目前的剩余资源情况进行匹配,然后进行调度;
  • Tetris算法。考虑到任务的资源申请需求越来越多样,需要考虑不同维度资源的权重问题,其核心思想是将资源申请表示为多维向量,进行归一化处理并与集群剩余资源进行点积运算,优先响应权重最大的资源请求。该方法从算法论证的角度来看能够在一定程度提高调度的准确度和效率,但是其在资源分配过程中需要进行较为复杂的运算,采用的并不多。并且目前主流的资源调度系统中在资源申请方面仅考虑了CPU和内存两个维度的资源。
  • 延迟调度策略。如果当前分配的资源不能够满足诸如数据本地行等需求,可以暂时放弃该轮分配,等待下一轮分配,通过设定一个放弃次数阈值来进行。

1. 集群资源管理与任务调度系统架构

集群资源管理和任务调度设计两个方面:(1)集群管理,主要负载集群中资源的管理和调度,给定一个任务需求,其能够在目前情况下给出较优的调度方案;(2)任务调度,来了很多的任务我们应该选择哪个任务来进行分配;这两个方面是相辅相成的关系,任何一个方面的优化都会带来集群整体性能的提升。因为任务调度主要涉及调度策略部分,在上面一节中有一些论述,并且任务调度本身带有一些随机性,所以对其的研究相对较少,下面主要针对资源管理系统进行简要总结。

总的来说目前的调度系统可以分为:单层调度系统、两层调度系统、共享状态调度系统、分布式调度系统和混合式调度系统。每种调度系统的存在都有其背景,下面主要从产生的背景、实现的原理、存在的缺点、典型的系统等方面进行阐述。需要注意的是,虽然有这么多种调度系统,但是目前工业界使用的大部分还是单层或者两层的调度系统,原因是这些架构设计方案成熟,已经经历了多年的线上实践,可以平稳运行;另外就是这些调度系统拥有比较好的生态和社区,能够兼容现有的生态,节省研究的成本。所以一些小型公司大多还是采用Hadoop相关的系统,只有专门针对云计算市场的公司,例如阿里云、腾讯云、华为云等会专门研发自己的调度系统。

1.1 单层调度系统

  • 产生背景:该调度系统是大规模数据分析和云计算出现的雏形,其产生主要就是进行大规模的集群管理以提高数据处理能力。
  • 基本原理:单层调度系统融合了资源管理和任务调度,有一个中心式的JobTracker负责进行集群资源的合理分配、任务的统一调度、集群计算节点信息的统计维护、任务执行过程中的状态管理等。
  • 优点:(1)JobTracker能够感知集群中所有资源和任务的执行状态,能够进行全局最优的资源分配和调度,避免任务间的干扰,适当进行任务抢占,保证任务计算效率和服务质量;(2)架构模型简单,只有一个全局的管理者负责进行所有管理。
  • 缺点:(1)JobTracker作为集群的中心,存在单点瓶颈问题,不能支持大规模集群;(2)内部实现异常复杂,因为一个调度器中需要实现所有的功能模块;(3)负载种类的增加会导致系统需要进行不断的迭代,这将增加系统的复杂性,不利于后期的维护和扩展;(4)只支持单类型的任务,MR类型的批处理任务;
  • 典型的调度系统:Hadoop1.*版本;K8S中的kube-scheduler,Paragon,Quasar。

1.2 双层调度器

  • 产生背景:为了解决单层调度系统的扩展性问题,系统实现负责,需要不断迭代,不能支持不同类型任务等缺点
  • 实现原理:将资源管理和任务调度解耦。集群资源管理器负责维护集群中的资源信息并将资源分配给具体的任务,任务管理器负责申请资源并将申请到的资源根据用户逻辑进行细分和具体的任务调度,节点管理器负责维护节点上的所有信息,包括:任务的运行状况,节点资源剩余情况等。通过三者之间的协调来进行资源资源管理和任务调度。
  • 优点:(1)资源管理器只负责资源分配,任务调度由应用完成,提高了系统的扩展性和模块化设计;(2)任务调度逻辑由具体的任务完成,能够提供对不同类型任务的支持;(3)内部实现模块化,利于维护和扩展;
  • 缺点:(1)任务无法感知全局的资源情况,只能基于request/offer来进行资源获取,无法有效避免异构负载之间的性能干扰问题;(2)任务调度和资源管理解耦不利于实现多任务间的优先级抢占;(3)所有任务的资源请求都需要资源管理器进行处理,此外其还需要与节点管理器之间维持通信,导致资源管理器存在单点问题;
  • 典型系统:
    • Mesos:最先将资源管理和任务调度解耦的offer-based(基于资源供应)方案,其有一个中心的资源管理器,通过采用一些分配策略将资源分配给不同的计算框架,每个计算框架依据自身的逻辑、资源偏好等采取增量或者All-or-Nothing的方式决定接受还是拒绝分配的资源,计算框架根据分配到的资源进行下一步的资源分配和任务执行。优点:实现逻辑简单,两层调度;缺点:(1)调度结果不是全局最优的;(2)存在单点瓶颈,因为中央资源管理器需要逐个询问计算框架是否需要资源;(3)无法支持抢占,资源一旦分配不能够抢占回收;(4)DRF策略过于理想化;(5)并发度不高,因为对于某个slave的资源剩余信息,需要逐个询问计算框架是否需要资源,,基于串行轮询方式;
    • YARN:基本思想与Mesos相同,但其采用requese-based方式进行资源申请,但是在YARN中有三个模块,RM负责资源管理,AM负责任务资源申请和运行;优点:(1)支持不同的调度策略可以保证任务优先级、多租户容量管理、资源公平共享、弹性伸缩(当某个租户需要资源时会抢占共享出去的资源)等;(2)应用扩展方便,只要根据提供的AM 相关API就可以实现用户的任务执行逻辑;缺点:存在单点瓶颈问题;故障处理和容错方面不够完善;对于隔离的支持不够友好;
    • borg:最早融合资源隔离、资源超售、机器打分、多任务优先级于一体的资源管理系统。采用二层调度框架,节点管理器Borglet定期将自己节点的资源和任务执行情况汇报给BorgMaster,每个应用内的调度器根据自身保存的集群信息做调度决策,然后由Master决定是否允许其资源申请。在此基础上其做了一些优化,例如:用户控制访问、节点打分、多任务派遣、多维度资源隔离和进程隔离、可插拔的调度策略等,支持数千种不同的应用和服务,支持数万台规模的集群。但是目前其为闭源系统,这些思想仅能通过论文中获取,具体的实现细节并不清楚。
    • Fuxi。其是阿里云针对离线作业的调度系统,与其相对的是针对在线服务端额调度系统Sigma。伏羲的设计思想与YARN非常相似,具体的资源分配也相似。但是伏羲针对故障恢复和可用性方面记性了优化扩展,能够基于已有的信息进行快速的故障恢复,并提供多级黑名单机制。

1.3 共享状态调度器

  • 产生背景:前面的调度器存在一个问题就是应用在进行资源申请的时候无法获知到集群的全局资源信息,这就导致无法进行全局最优的调度,共享状态调度器就是为了解决这个问题。
  • 基本原理:是一个半分布式的架构,通过共享集群状态为应用提供全局的资源视图,并采用乐观并发机制进行资源申请和释放,来提高系统的并发度。
  • 优点:(1)支持全局最优调度;(2)能够一定程度的提高并发度;
  • 缺点:(1)高并发资源请求下会造成频繁的资源竞争;(2)不利于实现任务的优先级抢占;(3)资源全局副本维护模块存在单点瓶颈;
  • 典型系统:
    • Omega:Omega系统中存在多个调度器,每个调度器中都保存集群资源的副本信息,每个调度器可以按照副本信息进行任务调度,在进行资源申请和调度时采用乐观锁的并发方式进行。目前其只是在模拟环境下进行实验,并没有真正在线上进行测试。
    • Apollo:综合考虑了微软生产平台Scope的扩展性、用户群间的公平调度、提高资源利用率、缩短工作时间(数据本地行、任务特性、任务预测)的解决方案。核心包括两个方面:(1)利用实时系统维护和更新每个任务的等待时间矩阵作为调度的基础和参考,需要考虑子任务调度到哪个计算节点上更合适;(2)在计算节点设置独立的任务等待队列,采集其上的任务执行情况,依次根据相关成本模型进行较优的调度决策。其主要针对海量短作业进行设计。
    • JetScope:在Apollo的基础上对交互式数据分析任务进行了特殊的优化处理,通过Gang调度策略对低延迟交互式作业进行调度优化。
    • Nomad

1.4 分布式调度器

  • 产生背景:提供系统吞吐率和并发度
  • 基本原理:完全分布式的调度系统之间没有通讯协作,每个分布式调度器根据自己最少的先验知识进行最快的决策,每个调度器单独响应任务,总体的执行计划于资源分配服从统计意义。目前还处于学术研究阶段,尚未真正运用至生产环境中。
  • 优点:提高吞吐量和并发度
  • 缺点:(1)调度质量得不到保障;(2)资源非公平分配;(3)不能支持多租户管理;(4)不能避免不同任务之间的性能干扰;
  • 典型系统:Sparrow:是一个完全的去中心化的分布式调度系统,通常用于满足低延迟高吞吐的短任务场景。系统包含多个调度器,这些调度器分布在集群的节点上,作业可以提交给任何一个分布式调度器。其核心是采用随机调度模型,利用二次幂采样原理针对每个任务随机采样出两个服务节点,选择任务等待队列最短的一个作为调度结果,也可以采用异步预定的方式进行资源调度。实验证明近似最优解能够有效的满足大规模毫秒调度性能的需求。

1.5 混合式调度器

  • 出现背景:针对一些特定的混合任务调度场景,某些任务需要比较快的调度响应,而其他任务不需要很快的调度响应,但是需要保证调度质量。
  • 基本原理:设计两条资源请求和任务调度路径,保留两层调度的优点,同时兼顾分布式调度器的优势。对于没有资源偏好且响应要求高的任务采用分布式调度器,对于资源调度质量要求较高的采用中央资源管理器进行资源分配。
  • 优点:(1)能够针对不同类型的任务进行不同方式的调度;(2)为应用层提供灵活的接口和性能保障;
  • 缺点:复杂化了计算框架层的业务逻辑;调度系统内部也需要针对两种不同的调度器进行协同处理;
  • 典型调度系统:
    • Mercury:微软的混合调度机制,中心式调度器对调度质量要求较高的作业进行公平的资源分配,分布式调度器对时间敏感和吞吐率要求高的作业进行调度。
    • Tracil在Sparrow基础上增加了访问控制模型,结合QoS感知对负载进行建模和性能评估指定访问控制策略,确保任务可以快速获取到资源并执行,提升系统并发度和响应时间提高集群资源利用率。

1.6 总结

目前主流的开源调度系统比较(结构,资源维度,多调度器,支持可插拔,优先级抢占,重调度,资源超售,资源评估,避免干扰):

  • Kubernetes:单层,支持多维资源,可插拔,资源超售
  • Swarm:单层,支持多维资源
  • YARN:单层/两层,CPU和内存,多调度器,可插拔
  • Mesos:两层,多维,多调度器,可插拔,资源超售
  • Nomad:共享状态,多维,可插拔
  • Sparrow:完全分布式,固定槽位
  • Borg:优先级抢占,重调度,资源超售,资源评估
  • Omega:支持除了避免干扰的所有特征
  • Apollo:多调度器,可插拔,优先级抢占,重调度
  • 选用何种调度架构需要根据具体的应用场景结合不同调度框架的特点进行判断。目前调度系统存在的问题主要包括:功能缺失、资源利用率不佳、任务特征不可预测、性能干扰降低执行效率、调度器性能较弱。

spark其实就是对borg系统+DGA计算模式的实现,包括了集群的资源管理和调度、存储系统实现、DGA计算模式实现;所以当我们在看spark源码时候会被它几万行代码和各种的依赖包给搞糊涂。因为它已经是一个完整系统,当你把这个系统是怎么构成的解剖开来,划分成几个部件模块,再去阅读代码会发现依然复杂但是代码组织是分层次有章可循的;也慢慢可以理解为什么spark包括那些模块。

 

如上图spark应该包括

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/liangwqi/article/details/104260929

智能推荐

[python刷题模板] 字典树trie、xor-trie(01-trie)_python 字典树-程序员宅基地

文章浏览阅读504次。python刷题模板之字典树_python 字典树

转-程序员致富的若干方法探讨-程序员宅基地

文章浏览阅读1k次。本文来自程序员宅基地,转载请标明出处:http://blog.csdn.net/zhangxiaoxiang/archive/2010/10/27/5969301.aspx 前一阵收到一封网友的来信,信中提到了他在提高个人收入和未来发展中的一些困惑,这也是我们许多学员和网友经常找我咨询的一件事情,颇具普遍性,故写此博与大家探讨和分享一下。 原信内容如下:--------

我的Unity(17)工作中遇到的一些问题总结_unity driveinfo.getdrives()-程序员宅基地

文章浏览阅读355次。一 使用Webservice 1webservice就不用介绍了,各种语言都可以写,服务端和客户端分别来写。个人理解,大致的流程,服务端开发,部署网站上,客户端生成代理类,判断是否可以连接,直接调用。很方便。2写一下客户端的使用吧,用的是C# 将服务转成代理类放在工程项目中直接使用就好,关键就是如何生成代理类,使用Vs中的tool工具打开后就是命令行(1)输入:wsdl.exe/language..._unity driveinfo.getdrives()

allure与pytest集成配置详解_pytest 集成 allure-程序员宅基地

文章浏览阅读2k次。allure是什么有非常多的优秀的测试框架,但却是有非常少优秀的报告工具可以展示非常清楚的用例执行过程和结果。allure是一款开源的,专门用来展示测试结果的工具,目的是希望团队内部每一个人都可以看到非常清楚的测试结果。allure可以与非常多的著名测试框架做集成。 像java语言,可以与junit4,junit5,TestNG测试框架集成。 python语言,可以与pytest,behave,nose测试框架集成。allure会将测试用例的执行数据保存到xml..._pytest 集成 allure

爬虫框架scrapy--5模拟登陆_scrapy session-程序员宅基地

文章浏览阅读96次。一、利用已有的cookies:通过在spiders下的爬虫文件中重写start_requests方法,在回调函数中提取数据class BaiduSpider(scrapy.Spider): name = 'baidu' allowed_domains = ['baidu.com'] start_urls = ['http://baidu.com/'] # 重写start_requests方法 def start_requests(self): _scrapy session

统计假设测验------(四)方差分析(F测验、多重比较原理与方法)_比较假想试验与实际试验结果是否存在实质性差异-程序员宅基地

文章浏览阅读2.4w次,点赞11次,收藏46次。一、方差分析基本原理1、方差分析(analysis of variance):k(k&gt;=3)个样本平均数假设测验方法。 与j无关的变量都看成常数,此时summation代表的是次数 方差分析基本步骤: (1)将资料总变异的自由度和平方和分解为各变异原因的自由度和平方和,并算的其均方 (2)计算均方比,做出F测验,以明了各变异因素的重要程度..._比较假想试验与实际试验结果是否存在实质性差异

随便推点

基于mybatis的增删改查_mybatisutil.closesqlsession(sqlsession);出现异常-程序员宅基地

文章浏览阅读265次。1.db.propertiesmysql.driver=com.mysql.jdbc.Drivermysql.url=jdbc:mysql://127.0.0.1:3306/mybatismysql.username=rootmysql.password=123456oracle.driver=oracle.jdbc.driver.OracleDriveroracle.url=jd_mybatisutil.closesqlsession(sqlsession);出现异常

Spring Cloud 微服务开发:入门、进阶与源码剖析 —— 14.1 分布式事务概述-程序员宅基地

文章浏览阅读636次。14.1 分布式事务概述在构建微服务的过程中,不管是使用什么框架、组件来构建,都绕不开一个问题,跨服务的业务操作如何保持数据一致性。14.1.1 什么是分布式事务?首先,设想一个传统的单体应用,无论多少内部调用,最后终归是在同一个数据库上进行操作来完成一向业务操作,如图14-1:随着业务量的发展,业务需求和架构发生了巨大的变化,整体架构由原来的单体应用逐渐拆分成为了微服务,原来的3个服务...

Unity Shader总结(三)——顶点变换之蕾姆的呆毛在哪里_蕾姆呆毛-程序员宅基地

文章浏览阅读230次。注意,以下求法的原理不再赘述。最简单的求法请直接跳转文末总结。文章目录概述一、模型空间——>世界空间(模型变换)二、世界空间——>观察空间(观察变换)(右手坐标系)法一:法二:三、观察空间——>裁剪空间3.1 透视投影3.2 正交投影四、裁剪空间——>屏幕空间五、总结概述蕾姆睡醒发现头上有跟呆毛,这根呆毛在屏幕上的坐标到底是多少?流程为:模型空间(PmodelP_{model}Pmodel​)——>世界空间(PworldP_{world}Pworld​)——>观_蕾姆呆毛

实时通信技术的架构设计_通讯服务器技术架构图-程序员宅基地

文章浏览阅读1.8k次。一、WEB端实时通信技术对比在WEB端的实时通信技术中,主要有以下几种方式: 1)轮询技术轮询是最简单的一种实时通信技术,易于实现,非常适用于一些小型的应用。其基本原理是这样的,先在客户端设定一个时间间隔,然后在每个间隔里从服务器拉取一次数据,如此反复,进行实时通信。轮询的缺点是显而易见的,若时间间隔过大,则会影响实时性,若时间间隔过小,又会对服务器产生非常大的负担,并_通讯服务器技术架构图

Unix系列shell程序编写_unix bsh-程序员宅基地

文章浏览阅读581次。http://bbs.chinaunix.net/thread-557642-1-1.htmlUnix系列shell程序编写(上) *Shell是什么?   任何发明都具有供用户使用的界面。UNIX供用户使用的界面就是Shell(DOS的command熟悉吧,但UNIX的要强大的多)。 Shell为用户提供了输入命令和参数并可得到命令执行结果的环境。   为了不_unix bsh

谈技术文章翻译的信雅达-下_技术文件翻译 直译 也需要信雅达翻译吗-程序员宅基地

文章浏览阅读4.2k次。 谈技术文章翻译的信雅达-下 Horin|贺勤 Email: [email protected] Blog: http://blog.csdn.net/horin153/ 以前在看国内 Python 达人 limodou 翻译的“Guido van Rossum 博客中文版”中的文章:Python_技术文件翻译 直译 也需要信雅达翻译吗

推荐文章

热门文章

相关标签