精华内容
下载资源
问答
  • 数据交换技术 概念 作用 结构 缺点 本人亲自整理
  • 微服务概念缺点

    万次阅读 多人点赞 2019-05-29 14:42:09
    随着持续交付概念推广以及容器概念的普及,微服务将这两种理念和技术结合起来,形成新的微服务+API + 容器平台的开发模式,提出了容器化微服务的持续交付概念。 下图为传统单体应用的DevOps开发队伍方式: 这种...

    I. 什么是微服务架构?

    通常而言,微服务架构是一种架构模式或者说是一种架构风格。
    它提倡将单一应用程序划分成一组小的服务,每个服务运行独立的自己的进程中,服务之间互相协调、互相配合,为用户提供最终价值。
    服务之间采用轻量级的通信机制互相沟通(通常是基于 HTTP 的 RESTful API) 。每个服务都围绕着具体业务进行构建,并且能够被独立地部署到生产环境、类生产环境等。

    II. 微服务架构和单体架构的区别

    A. 单体架构

    通俗地讲,“单体应用(monolith application)”就是将应用程序的所有功能都打包成一个独立的单元,可以是JAR、EXE、BIN或其它归档格式。
    单体应用

    单体应用有如下优点:

    1. 开发简单直接,集中式管理, 基本不会重复开发
    2. 功能都在本地,没有分布式的管理开销和调用开销。

    它的缺点也非常明显,特别对于互联网公司来说:

    1. 开发效率低:所有的开发在一个项目改代码,递交代码相互等待,代码冲突不断
    2. 代码维护难:代码功能耦合在一起,新人不知道何从下手
    3. 部署不灵活:构建时间长,任何小修改必须重新构建整个项目,这个过程往往很长
    4. 稳定性不高:一个微不足道的小问题,可以导致整个应用挂掉
    5. 扩展性不够:无法满足高并发情况下的业务需求
      ##B. 微服务架构
      随着业务需求的快速发展变化,敏捷性、灵活性和可扩展性需求不断增长,迫切需要一种更加快速高效的软件交付方式。微服务就是一种可以满足这种需求的软件架构风格。单体应用被分解成多个更小的服务,每个服务有自己的归档文件,单独部署,然后共同组成一个应用程序。这里的“微”不是针对代码行数而言,而是说服务的范围限定到单个功能。

    微服务应用

    微服务有如下优点:

    1. 微服务是松藕合的,无论是在开发阶段或部署阶段都是独立的。
    2. 能够快速响应, 局部修改容易, 一个服务出现问题不会影响整个应用。
    3. 易于和第三方应用系统集成, 支持使用不同的语言开发, 允许你利用融合最新技术。
    4. 每个微服务都很小,足够内聚,足够小,代码容易理解。团队能够更关注自己的工作成果, 聚焦指定的业务功能或业务需求。
    5. 开发简单、开发效率提高,一个服务可能就是专一的只干一件事, 能够被小团队单独开发,这个小团队可以是 2 到 5 人的开发人员组成。
      同样的, 也存在如下缺点:
    6. 微服务架构带来过多的运维操作, 可能需要团队具备一定的 DevOps 技巧.
    7. 分布式系统可能复杂难以管理。因为分布部署跟踪问题难。当服务数量增加,管理复杂性增加。

    III. 微服务架构的主要特点

    微服务架构是一种松耦合的、有一定的有界上下文的面向服务架构。也就是说,如果遇到一个功能变更, 但其要求每个服务都要同时修改,那么它们就不能称之为微服务,因为它们紧耦合在一起;如果你需要掌握一个服务的上下文场景使用条件,那么它就是一个有上下文边界的服务,这个定义一般来自DDD(领域驱动设计)。

    它的主要特点是组件化、松耦合、自治、去中心化,体现在以下几个方面:

    **A. 细粒度的服务分解 **
    服务粒度要小,而每个服务是针对一个单一职责的业务能力的封装,专注做好一件事情。
    **B. 独立部署运行和扩展 **
    每个服务能够独立被部署并运行在一个进程内。这种运行和部署方式能够赋予系统灵活的代码组织方式和发布节奏,使得快速交付和应对变化成为可能。
    **C. 独立开发和演化 **
    技术选型灵活,不受遗留系统技术约束。合适的业务问题选择合适的技术可以独立演化。服务与服务之间采取与语言无关的API进行集成。相对单体架构,微服务架构是更面向业务创新的一种架构模式。
    **D. 独立团队和自治 **
    团队对服务的整个生命周期负责,工作在独立的上下文中,自己决策自己治理,而不需要统一的指挥中心。团队和团队之间通过松散的社区部落进行衔接。

    通过解耦我们所做的事情,分而治之以减少不必要的损耗,使得整个复杂的系统和组织能够快速的应对变化。

    IV. 需要考虑的问题

    1. 单个微服务代码量小,易修改和维护。但是,系统复杂度的总量是不变的,每个服务代码少了,但服务的个数肯定就多了。就跟拼图游戏一样,切的越碎,越难拼出整幅图。一个系统被拆分成零碎的微服务,最后要集成为一个完整的系统,其复杂度肯定比大块的功能集成要高很多。
    2. 单个微服务数据独立,可独立部署和运行。虽然微服务本身是可以独立部署和运行的,但仍然避免不了业务上的你来我往,这就涉及到要对外通信,当微服务的数量达到一定量级的时候,如何提供一个高效的集群通信机制成为一个问题。
    3. 单个微服务拥有自己的进程,进程本身就可以动态的启停,为无缝升级打好了基础,但谁来启动和停止进程,什么时机,选择在哪台设备上做这件事情才是无缝升级的关键。这个能力并不是微服务本身提供的,而是需要背后强大的版本管理和部署能力。
    4. 多个相同的微服务可以做负载均衡,提高性能和可靠性。正是因为相同微服务可以有多个不同实例,让服务按需动态伸缩成为可能,在高峰期可以启动更多的相同的微服务实例为更多用户服务,以此提高响应速度。同时这种机制也提供了高可靠性,在某个微服务故障后,其他相同的微服务可以接替其工作,对外表现为某个设备故障后业务不中断。同样的道理,微服务本身是不会去关心系统负载的,那么什么时候应该启动更多的微服务,多个微服务的流量应该如何调度和分发,这背后也有一套复杂的负载监控和均衡的系统在起作用。
    5. 微服务可以独立部署和对外提供服务,微服务的业务上线和下线是动态的,当一个新的微服务上线时,用户是如何访问到这种新的服务?这就需要有一个统一的入口,新的服务可以动态的注册到这个入口上,用户每次访问时可以从这个入口拿到系统所有服务的访问地址。这个统一的系统入口并不是微服务本身的一部分,所以这种能力需要系统单独提供。
    6. 还有一些企业级关注的系统问题,比如,安全策略如何集中管理?系统故障如何快速审计和跟踪到具体服务?整个系统状态如何监控?服务之间的依赖关系如何管理?等等这些问题都不是单个微服务考虑的范畴,而需要有一个系统性的考虑和设计,让每个微服务都能够按照系统性的要求和约束提供对应的安全性,可靠性,可维护性的能力。

    V. 选择微服务框架的关注点

    1. 服务注册、发现、负载均衡和健康检查,假定采用进程内LB方案,那么服务自注册一般统一做在服务器端框架中,健康检查逻辑由具体业务服务定制,框架层提供调用健康检查逻辑的机制,服务发现和负载均衡则集成在服务客户端框架中。
    2. 监控日志,框架一方面要记录重要的框架层日志、metrics和调用链数据,还要将日志、metrics等接口暴露出来,让业务层能根据需要记录业务日志数据。在运行环境中,所有日志数据一般集中落地到企业后台日志系统,做进一步分析和处理。
    3. REST/RPC和序列化,框架层要支持将业务逻辑以HTTP/REST或者RPC方式暴露出来,HTTP/REST是当前主流API暴露方式,在性能要求高的场合则可采用Binary/RPC方式。针对当前多样化的设备类型(浏览器、普通PC、无线设备等),框架层要支持可定制的序列化机制,例如,对浏览器,框架支持输出Ajax友好的JSON消息格式,而对内部服务及应用程序,框架支持输出性能高的Binary消息格式。
    4. 配置,除了支持普通配置文件方式的配置,框架层还可集成动态运行时配置,能够在运行时针对不同环境动态调整服务的参数和配置。
    5. 限流和容错,框架集成限流容错组件,能够在运行时自动限流和容错,保护服务,如果进一步和动态配置相结合,还可以实现动态限流和熔断。
    6. 管理接口,框架集成管理接口,一方面可以在线查看框架和服务内部状态,同时还可以动态调整内部状态,对调试、监控和管理能提供快速反馈。Spring Boot微框架的Actuator模块就是一个强大的管理接口。
    7. 统一错误处理,对于框架层和服务的内部异常,如果框架层能够统一处理并记录日志,对服务监控和快速问题定位有很大帮助。
    8. 安全,安全和访问控制逻辑可以在框架层统一进行封装,可做成插件形式,具体业务服务根据需要加载相关安全插件。
    9. 文档自动生成,文档的书写和同步一直是一个痛点,框架层如果能支持文档的自动生成和同步,会给使用API的开发和测试人员带来极大便利。Swagger是一种流行Restful API的文档方案。

    一个完整的微服务系统,它最少要包含以下功能:

    1. 日志和审计,主要是日志的汇总,分类和查询
    2. 监控和告警,主要是监控每个服务的状态,必要时产生告警
    3. 消息总线,轻量级的MQ或HTTP
    4. 注册发现
    5. 负载均衡
    6. 部署和升级
    7. 事件调度机制

    以下功能不是最小集的一部分,但也应该在选择时进行考虑:

    1. 认证和鉴权
    2. 多语言支持, 是否支持多种编程语言
    3. 统一服务构建和打包
    4. 统一服务测试
    5. 统一配置文件管理
    6. 服务依赖关系管理
    7. 问题跟踪调试框架
    8. 灰度发布
    9. 蓝绿部署
    10. 资源管理,如:底层的容器, 虚拟机, 物理机和网络管理

    VI. 开发方式影响

    随着持续交付概念推广以及容器概念的普及,微服务将这两种理念和技术结合起来,形成新的微服务+API + 容器平台的开发模式,提出了容器化微服务的持续交付概念。
    下图为传统单体应用的DevOps开发队伍方式:
    在这里插入图片描述
    这种整体型架构要求产品队伍横跨产品管理 Dev开发 QA DBA 以及系统运营管理,而微服务架构引入以后,如下图:
    在这里插入图片描述
    微服务促进了DevOps方式的重组,将一个大臃肿的整体产品开发队伍切分为根据不同微服务的划分的产品队伍,以及一个大的整体的平台队伍负责运营管理,两者之间通过API交互,做到了松耦合隔绝。
    在这里插入图片描述

    微服务的实施是有一定的先决条件:基础的运维能力(如监控、快速配置、快速部署)需提前构建,否则就会陷入较被动的局面。推荐采用CI/CI改进基础设施及运维的实践,通过自动化运维使得可以快速安全的响应和处理微服务对服务部署的要求,通过容器技术保证服务环境之间拥有更高的一致性,降低“在我的环境工作,而你的环境不工作”的可能,也是为后续的发布策略和运维提供更好的支撑。
    想要更好的实施微服务, 首先需要考虑构建团队DevOps能力,这是保证微服务架构在持续交付和应对复杂运维问题的动力之源;
    其次保持服务持续演进,使之能够快速、低成本地被拆分和合并,以快速响应业务的变化;同时要保持团队和架构对齐。微服务看似是技术层面的变革,但它对团队结构和组织文化有很强的要求和影响。识别和构建匹配架构的团队是解决问题的另一大支柱。
    最后,打造持续改进的组织文化是实施微服务的关键基石。只有持续改进,持续学习和反馈,持续打造这样一个文化氛围和团队,微服务架构才能持续发展下去,保持新鲜的生命力,从而实现我们的初衷。

    展开全文
  • 主要为大家介绍了动态路由协议的概念、分类、组成部分和缺点,路由协议的主要好处,只要网络拓扑结构发生了变化,路由器就会相互交换路由信息,不仅能够自动获知新增加的网络,还可以在当前网络连接失败时找出备用...
  • [深度概念]·Softmax缺点解析

    千次阅读 2019-03-26 18:20:35
    [深度概念]·Softmax缺点解析 个人主页-->https://xiaosongshine.github.io/ Softmax是soft(软化)的max。在CNN的分类问题中,我们的ground truth是one-hot形式,下面以四分类为例,理想输出应该是(1,0...

    [深度概念]·Softmax优缺点解析

    个人主页--> https://xiaosongshine.github.io/ 

    Softmax是soft(软化)的max。在CNN的分类问题中,我们的ground truth是one-hot形式,下面以四分类为例,理想输出应该是(1,0,0,0),或者说(100%,0%,0%,0%),这就是我们想让CNN学到的终极目标。

    网络输出的幅值千差万别,输出最大的那一路对应的就是我们需要的分类结果。通常用百分比形式计算分类置信度,最简单的方式就是计算输出占比,假设输出特征是 (x_{1}, x_{2}, x_{3}, x_{4}),这种最直接最最普通的方式,相对于soft的max,在这里我们把它叫做hard的max

    而现在通用的是soft的max,将每个输出x非线性放大到exp(x),形式如下:

    hard的max和soft的max到底有什么区别呢?看几个例子

    相同输出特征情况,soft max比hard max更容易达到终极目标one-hot形式,或者说,softmax降低了训练难度,使得多分类问题更容易收敛。

    到底想说什么呢?Softmax鼓励真实目标类别输出比其他类别要大,但并不要求大很多。对于人脸识别的特征映射(feature embedding)来说,Softmax鼓励不同类别的特征分开,但并不鼓励特征分离很多,如上表(5,1,1,1)时loss就已经很小了,此时CNN接近收敛梯度不再下降。

    Softmax Loss训练CNN,MNIST上10分类的2维特征映射可视化如下:

    不同类别明显分开了,但这种情况并不满足我们人脸识别中特征向量对比的需求。人脸识别中特征向量相似度计算,常用欧式距离(L2 distance)和余弦距离(cosine distance),我们分别讨论这两种情况:

    • L2距离:L2距离越小,向量相似度越高。可能同类的特征向量距离(黄色)比不同类的特征向量距离(绿色)更大

    • cos距离:夹角越小,cos距离越大,向量相似度越高。可能同类的特征向量夹角(黄色)比不同类的特征向量夹角(绿色)更大

    总结来说:

    1. Softmax训练的深度特征,会把整个超空间或者超球,按照分类个数进行划分,保证类别是可分的,这一点对多分类任务如MNIST和ImageNet非常合适,因为测试类别必定在训练类别中。

    2. 但Softmax并不要求类内紧凑和类间分离,这一点非常不适合人脸识别任务,因为训练集的1W人数,相对测试集整个世界70亿人类来说,非常微不足道,而我们不可能拿到所有人的训练样本,更过分的是,一般我们还要求训练集和测试集不重叠。

    3. 所以需要改造Softmax,除了保证可分性外,还要做到特征向量类内尽可能紧凑,类间尽可能分离

    展开全文
  • 电路交换与分组交换基本概念以及缺点简述

    电路交换

    电路交换作为应用最为普遍的一种交换方式,主要用于电话通信网中,完成电话交换。是通信的双方之间建立的一条能被双方独占的物理通路。

    优点

    1. 拥有固定的连接,使得传输时延固定
    2. 通信连接的过程中始终有一条电路被占用 使得 实时性强.通信连接的过程中始终有一条电路被占用 使得 实时性强
    3. 不存在时序问题
    4. 可传输模拟信号,也可以传输数字信号
    5. 电路交换的交换机和控制较为简单

    缺点

    1. 平均连接建立时间较长
    2. 通信连接的过程中始终有一条电路被占用导致 信道利用率低
    3. 传输通路专用的,在没有信息传递时别人也不能利用,所以进行数据通信的效率低
    4. 分配的带宽固定,造成网络资源的利用率低
    5. 不同速率和不同通信协议之间的用户无法接通
    6. 电路交换的存在着呼损

    分组交换

    1、把一份要发送的数据报文分成若干个较短的、按一定格式组成的分组,然后采用统计时分复用将这些分组传送到一个交换节点
    2、采用存储—转发技术
    3、无需为双方先建立一条专用的通信线路

    优点

    1.线路利用率较高分组交换在线路上采用动态统计时分复用的技术传送各个分组,因此提高了传输介质(包括用户线和中继线)的利用率。
    2. 异种终端通信。由于采用存储—转发方式,不需要建立端到端的物理连接,因此不必像电路交换中那样,通信双方的终端必须具有同样的速率和控制规程
    3. 数据传输质量好、可靠性高。每个分组在网络内的中继线和用户线上传输时可以逐段独立地进行差错控制和流量控制,因而网内全程的误码率较低,提高了传送质量且可靠性较高
    4. 负荷控制。分组交换网中进行了逐段的流量控制,因此可以及时发现网络有无过负荷
    5.经济性好。分组交换网是以分组为单元在交换机内进行存储和处理的,因而有利于降低网内设备的费用,提高交换机的处理能力。

    缺点

    1. 信息传送时延大。由于采用存储—转发方式处理分组,分组在每个节点机内都要经历存储、排队、转发的过程,因此分组穿过网络的平均时延可达几百毫秒。
    2. 增加开销,用户的信息被分成了多个分组,每个分组附加的分组头都要交换机分析处理
    3. 分组交换技术的协议和控制比较复杂
    展开全文
  • Django:ORM概念优缺点理解

    千次阅读 2019-05-17 21:06:01
    ORM : ORM概念,ORM特点,ORM 的优点,ORM 的缺点 orm : 对象关系映射 (Object Relational Mapping) ,用于实现面向对象编程语言里不同类型系统的数据之间的转换 [1] 。从效果上说,它其实是创建了一个可在编程语言里...

    ORM : ORM概念,ORM特点,ORM 的优点,ORM 的缺点

    orm : 对象关系映射 (Object Relational Mapping) ,用于实现面向对象编程语言里不同类型系统的数据之间的转换 [1] 。从效果上说,它其实是创建了一个可在编程语言里使用的–“虚拟对象数据库”。
    ORM方法论基于三个核心原则: 简单:以最基本的形式建模数据。 传达性:数据库结构被任何人都能理解的语言文档化。 精确性:基于数据模型创建正确标准化的结构
    概念(百度百科)
    对象-关系映射(Object Relational Mapping,简称ORM),是随着面向对象的[软件开发方法发展而产生的。用来把对象模型表示的对象映射到基于S Q L 的关系模型数据库结构中去。这样,我们在具体的操作实体对象的时候,就不需要再去和复杂的 SQ L 语句打交道,只需简单的操作实体对象的属性和方法 。O R M 技术是在对象和关系之间提供了一条桥梁,前台的对象型数据和数据库中的关系型的数据通过这个桥梁来相互转化 。
    1、数据类型映射模式
    2、类映射模型
    3、关联映射模式
    4、引用映射模式

    一:概念
    简单说,
    ORM 就是通过实例对象的语法,完成关系型数据库的操作的技术是"对象-关系映射"(Object/Relational Mapping) 的缩写。

    ORM 把数据库映射成对象。
    • 数据库的表(table) --> 类对象(class)
    • 记录(record,行数据)–> 对象(object)
    • 字段(field)–> 对象的属性(attribute)

    理解:例如下图

    在这里插入图片描述
    在这里插入图片描述
    二:ORM特点:
    ORM 使用对象,封装了数据库操作,因此可以不碰 SQL 语言。开发者只使用面向对象编程,与数据对象直接交互,不用关心底层数据库
    可以方便实现: 增加(Create)、读取查询(Read)、更新(Update)和删除(Delete)

    三:ORM 的优点。
    • 数据模型都在一个地方定义,更容易更新和维护,也利于重用代码。
    • ORM 有现成的工具,很多功能都可以自动完成,比如数据消毒、预处理、事务等等。
    • 它迫使你使用 MVC 架构,ORM 就是天然的 Model,最终使代码更清晰。
    • 基于 ORM 的业务代码比较简单,代码量少,语义性好,容易理解。
    • 你不必编写性能不佳的 SQL。

    四:ORM 的缺点。
    • ORM 库不是轻量级工具,需要花很多精力学习和设置。
    • 对于复杂的查询,ORM 要么是无法表达,要么是性能不如原生的 SQL。
    • ORM 抽象掉了数据库层,开发者无法了解底层的数据库操作,也无法定制一些特殊的 SQL。

    相关连接:http://www.ruanyifeng.com/blog/2019/02/orm-tutorial.html

    展开全文
  • 闭包的概念,作用,和缺点

    千次阅读 2019-03-27 17:39:46
    闭包的概念 闭包就是能读取其他函数内部变量的函数。 也可以简单的理解为:“定义在一个函数内部的函数” 闭包的形式 //在执行fn1时,其返回值是一个函数,即fn2,所以再一次执行的时候就是返回的a+b的值。 ...
  • 多态的概念,特点和缺点

    千次阅读 多人点赞 2020-06-30 23:28:05
    概念:多态是同一个行为具有不同表现形式或形态的能力,多态性是对象多种表现形式和体现。 多态的前提: 子父类的继承关系或子类实现父类接口 必须有方法的重写 父类引用指向子类对象 package com.itheima; /**...
  • 视图概念,缺点及作用

    万次阅读 2018-05-04 14:42:13
    视图(子查询):是从一个或多个表导出的虚拟的表,其内容由查询定义。具有普通表的结构,但是不实现数据存储。 对视图的修改:单表视图一般用于查询和修改,会改变基本表的数据, 多表视图一般用于查询,不会改变...
  • MVC三层架构 MVC是 模型(Model),视图(View)和控制(Controller)的缩写,其目的实现Web系统的职能分工。其中Model层实现系统中的业务逻辑,通常可以用JavaBean或EJB来实现; View层用于与用户的交互,通常用JSP来实现...
  • mysql缺点,及热备份和冷备份概念

    千次阅读 2018-12-05 13:40:05
    MySQL的优点: 1. 它使用的核心线程是完全多线程,支持多处理器。 2. 有多种列类型:1、2、3、4、和8字节长度自有符号/无符号整数、FLOAT、DOUBLE、CHAR、VARCHAR、TEXT、BLOB、DATE、TIME、DATETIME、 TIMESTAMP...
  • 快速原型模型的概念缺点。

    千次阅读 2020-12-16 11:07:44
    快速原型模型需要迅速建造一个可以运行的软件原型 ,以便理解和澄清问题,使开发人员与用户达成共识,最终在确定的客户需求基础上开发客户满意的软件...缺点 优点:克服瀑布模型的缺点,减少由于软件需求不明确带来的
  • 多继承的概念缺点

    千次阅读 2013-11-03 22:20:30
    实际生活中,一些事物往往会拥有两个或两个以上事物的属性,为了解决这个问题,C++引入了多重继承的概念,C++允许为一个派生类指定多个基类,这样的继承结构被称做多重继承。举个例子: 人(Person)可以派生出作者...
  • PPP,EPC,BOT,DB,DBB等概念缺点分析报告.doc
  • 数据库视图概念,缺点及作用

    千次阅读 2019-05-10 14:47:02
    视图(子查询):是从一个或多个表导出的虚拟的表,其内容由查询定义。具有普通表的结构,但是不实现数据存储。 对视图的修改:单表视图一般用于查询和修改,会改变基本表的数据, 多表视图一般用于查询,不会改变...
  • I . 外观模式概念 II . 外观模式 适用场景 III . 外观模式 缺点 IV . 外观模式与其它设计模式的联系与区别 V . 外观模式 代码示例
  • 继承与组合概念、区别及缺点 (2010-05-21 20:15) 分类: c++ 继承与组合概念、区别及缺点 1.什么是继承 A继承B,说明A是B的一种,并且B的所有行为对A都有意义 eg:A=WOMAN B=HUMAN A=鸵鸟 B=鸟 ...
  • 我在网络上看到的PDM的概念、定义、缺点等相关信息  PDM的确是一种“管得很宽”的软件,凡是最终可以转换成计算机描述和存储的数据,它都可以一概管之,例如:产品结构和配置、零件定义及设计数据、CAD绘图文件...
  • 层次模型,网状模型,关系模型的缺点总结
  • 专供河北省衡水中学高二数学1.1.1算法的概念学案pdf无答案
  • 文章目录一、Linux线程基本概念二、Linux内核线程实现原理三、创建线程四、线程的缺点 一、Linux线程基本概念 linux中,线程又叫做轻量级进程(light-weight process LWP),也有PCB,创建线程使用的底层函数和...
  • 本文主要描述大端小端的概念,分类和区别,还讲述了他们的由来,以及各自的缺点,对初识者具有很大的帮助
  • 白盒测试:是通过程序的源代码进行测试而不使用用户界面。 白盒测试的优点有: 1)帮助软件测试人员增大代码的覆盖率,提高代码的质量,发现代码中隐藏的问题。 白盒测试的缺点有: 2)程序运行会有很多不同的路径,...
  • js之闭包(概念缺点、应用)

    千次阅读 2020-07-20 15:44:50
    4.2.2 闭包缺点 1 闭包的作用(优点) 1)读取另一个函数作用域中的变量; 2)让这些变量始终保持在内存中,即闭包可以使得它诞生环境一直存在。 3)封装对象的私有属性和私有方法。(然后在全局作用域中通过...
  • 存储过程的概念以及缺点是什么?写出一个存储过程的大概代码,你是如何在项目中应用的,又产生了什么问题,你是如何解决的? 存储过程是一套已经预先编译好的SQL代码,是SQL语句和可选控制语句的集合及一个独立的...
  • 专供河北省衡水中学高二数学圆锥曲线的概念及性质二作业pdf无答案
  • 专供河北省衡水中学2016_2017学年高二数学自助餐1.1.1算法的概念pdf
  •  摘要:目前关于处理器的单核、双核和多核已经得到了普遍的运用,今天我们主要说说关于多核处理器的一些相关概念,它的工作与那里以及缺点而展开的分析。  1、多核处理器  多核处理器是指在一枚处理器中集成...
  • 3、存储过程有什么缺点? 3.1 优点 存储过程在创建的时候直接编译,而sql语句每次使用都要编译,提高执行效率 一个存储过程可以被重复使用。(其实sql语句也可以,没什么卵用) 一条sql语句,可能需要...
  • 专供河北省衡水中学2016_2017学年高二数学自助餐3.1三角函数的概念pdf

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 205,741
精华内容 82,296
关键字:

优概念