• 关于

    抽象类中的小问题

    的搜索结果

回答

单一职责原则(Single-Responsibility Principle) 其核心思想为:一个类,最好只做一件事,只有一个引起它的变化。单一职责原则可以看做是低耦合、高内聚在面向对象原则上的引申,将职责定义为引起变化的原因,以提高内聚性来减少引起变化的原因。职责过多,可能引起它变化的原因就越多,这将导致职责依赖,相互之间就产生影响,从而大大损伤其内聚性和耦合度。通常意义下的单一职责,就是指只有一种单一功能,不要为类实现过多的功能点,以保证实体只有一个引起它变化的原因。 专注,是一个人优良的品质;同样的,单一也是一个类的优良设计。交杂不清的职责将使得代码看起来特别别扭牵一发而动全身,有失美感和必然导致丑陋的系统错误风险。 开放封闭原则(Open-Closed principle) 其核心思想是:软件实体应该是可扩展的,而不可修改的。也就是,对扩展开放,对修改封闭的。开放封闭原则主要体现在两个方面1、对扩展开放,意味着有新的需求或变化时,可以对现有代码进行扩展,以适应新的情况。2、对修改封闭,意味着类一旦设计完成,就可以独立完成其工作,而不要对其进行任何尝试的修改。 实现开放封闭原则的核心思想就是对抽象编程,而不对具体编程,因为抽象相对稳定。让类依赖于固定的抽象,所以修改就是封闭的;而通过面向对象的继承和多态机制,又可以实现对抽象类的继承,通过覆写其方法来改变固有行为,实现新的拓展方法,所以就是开放的。 “需求总是变化”没有不变的软件,所以就需要用封闭开放原则来封闭变化满足需求,同时还能保持软件内部的封装体系稳定,不被需求的变化影响。 Liskov替换原则(Liskov-Substitution Principle) 其核心思想是:子类必须能够替换其基类。这一思想体现为对继承机制的约束规范,只有子类能够替换基类时,才能保证系统在运行期内识别子类,这是保证继承复用的基础。在父类和子类的具体行为中,必须严格把握继承层次中的关系和特征,将基类替换为子类,程序的行为不会发生任何变化。同时,这一约束反过来则是不成立的,子类可以替换基类,但是基类不一定能替换子类。 Liskov替换原则,主要着眼于对抽象和多态建立在继承的基础上,因此只有遵循了Liskov替换原则,才能保证继承复用是可靠地。实现的方法是面向接口编程:将公共部分抽象为基类接口或抽象类,通过Extract Abstract Class,在子类中通过覆写父类的方法实现新的方式支持同样的职责。 Liskov替换原则是关于继承机制的设计原则,违反了Liskov替换原则就必然导致违反开放封闭原则。 Liskov替换原则能够保证系统具有良好的拓展性,同时实现基于多态的抽象机制,能够减少代码冗余,避免运行期的类型判别。 依赖倒置原则(Dependecy-Inversion Principle) 其核心思想是:依赖于抽象。具体而言就是高层模块不依赖于底层模块,二者都同依赖于抽象;抽象不依赖于具体,具体依赖于抽象。 我们知道,依赖一定会存在于类与类、模块与模块之间。当两个模块之间存在紧密的耦合关系时,最好的方法就是分离接口和实现:在依赖之间定义一个抽象的接口使得高层模块调用接口,而底层模块实现接口的定义,以此来有效控制耦合关系,达到依赖于抽象的设计目标。 抽象的稳定性决定了系统的稳定性,因为抽象是不变的,依赖于抽象是面向对象设计的精髓,也是依赖倒置原则的核心。 依赖于抽象是一个通用的原则,而某些时候依赖于细节则是在所难免的,必须权衡在抽象和具体之间的取舍,方法不是一层不变的。依赖于抽象,就是对接口编程,不要对实现编程。 接口隔离原则(Interface-Segregation Principle) 其核心思想是:使用多个小的专门的接口,而不要使用一个大的总接口。 具体而言,接口隔离原则体现在:接口应该是内聚的,应该避免“胖”接口。一个类对另外一个类的依赖应该建立在最小的接口上,不要强迫依赖不用的方法,这是一种接口污染。 接口有效地将细节和抽象隔离,体现了对抽象编程的一切好处,接口隔离强调接口的单一性。而胖接口存在明显的弊端,会导致实现的类型必须完全实现接口的所有方法、属性等;而某些时候,实现类型并非需要所有的接口定义,在设计上这是“浪费”,而且在实施上这会带来潜在的问题,对胖接口的修改将导致一连串的客户端程序需要修改,有时候这是一种灾难。在这种情况下,将胖接口分解为多个特点的定制化方法,使得客户端仅仅依赖于它们的实际调用的方法,从而解除了客户端不会依赖于它们不用的方法。 分离的手段主要有以下两种:1、委托分离,通过增加一个新的类型来委托客户的请求,隔离客户和接口的直接依赖,但是会增加系统的开销。2、多重继承分离,通过接口多继承来实现客户的需求,这种方式是较好的。 以上就是5个基本的面向对象设计原则,它们就像面向对象程序设计中的金科玉律,遵守它们可以使我们的代码更加鲜活,易于复用,易于拓展,灵活优雅。不同的设计模式对应不同的需求,而设计原则则代表永恒的灵魂,需要在实践中时时刻刻地遵守。就如ARTHUR J.RIEL在那边《OOD启示录》中所说的:“你并不必严格遵守这些原则,违背它们也不会被处以宗教刑罚。但你应当把这些原则看做警铃,若违背了其中的一条,那么警铃就会响起。”

montos 2020-06-01 17:04:26 0 浏览量 回答数 0

回答

一、OOP三大基本特性 OOP 面向对象程序设计(Object Oriented Programming)作为一种新方法,其本质是以建立模型体现出来的抽象思维过程和面向对象的方法。模型是用来反映现实世界中事物特征的。任何一个模型都不可能反映客观事物的一切具体特征,只能对事物特征和变化规律的一种抽象,且在它所涉及的范围内更普遍、更集中、更深刻地描述客体的特征。通过建立模型而达到的抽象是人们对客体认识的深化。 封装 封装,也就是把客观事物封装成抽象的类,并且类可以把自己的属性和方法只让可信的类操作,对不可信的进行信息隐藏。 继承 继承是指这样一种能力,它可以使用现有的类的所有功能,并在无需重新编写原来类的情况下对这些功能进行扩展。 多态 多态指一个类实例的相同方法在不同情形有不同的表现形式。具体来说就是不同实现类对公共接口有不同的实现方式,但这些操作可以通过相同的方式(公共接口)予以调用。 二、OOD七大原则 面向对象设计(OOD)有七大原则,它们互相补充 开-闭原则 Open-Close Principle(OCP),即开-闭原则。开,指的是对扩展开放,即要支持方便地扩展;闭,指的是对修改关闭,即要严格限制对已有内容的修改。开-闭原则是最抽象也是最重要的OOD原则。简单工厂模式、工厂方法模式、抽象工厂模式中都提到了如何通过良好的设计遵循开-闭原则。 里氏替换原则 Liskov Substitution Principle(LSP),即里氏替换原则。该原则规定“子类必须能够替换其父类,否则不应当设计为其子类”。换句话说,父类出现的地方,都应该能由其子类代替。所以,子类只能去扩展基类,而不是隐藏或者覆盖基类。 依赖倒置原则 Dependence Inversion Principle(DIP),依赖倒置原则。它讲的是“设计和实现要依赖于抽象而非具体”。一方面抽象化更符合人的思维习惯;另一方面,根据里氏替换原则,可以很容易将原来的抽象替换为扩展后的具体,这样可以很好的支持开-闭原则。 接口隔离原则 Interface Segration Principle(ISP),接口隔离原则,“将大的接口打散成多个小的独立的接口”。由于Java类支持实现多个接口,可以很容易的让类具有多种接口的特征,同时每个类可以选择性地只实现目标接口。 单一职责原则 Single Responsibility Principle(SRP),单一职责原则。它讲的是,不要存在多于一个导致类变更的原因,是高内聚低耦合的一个体现。 迪米特法则/最少知道原则 Law of Demeter or Least Knowledge Principle(LoD or LKP),迪米特法则或最少知道原则。它讲的是“一个对象就尽可能少的去了解其它对象”,从而实现松耦合。如果一个类的职责过多,由于多个职责耦合在了一起,任何一个职责的变更都可能引起其它职责的问题,严重影响了代码的可维护性和可重用性。 合成/聚合复用原则 Composite/Aggregate Reuse Principle(CARP / CRP),合成/聚合复用原则。如果新对象的某些功能在别的已经创建好的对象里面已经实现,那么应当尽量使用别的对象提供的功能,使之成为新对象的一部分,而不要再重新创建。新对象可通过向这些对象的委派达到复用已有功能的效果。简而言之,要尽量使用合成/聚合,而非使用继承。

景凌凯 2020-03-19 23:49:30 0 浏览量 回答数 0

回答

内核是1指最基本最核心的基础模块部分,微内核具有概念极少、通用性极强、代码量极少的特征。 内核要做到"微"极端困难。微内核必定是建立在一个极端高明的抽象之上。第一个难点在于抽象的普适性,一个框架提出或主张一套概念,如果这个抽象概念体系能够涵盖尽可能广泛普遍的需求与场景,才能说具有普适性。从某种意义上讲,普适性也就是 "完备性"。 第二个难点在于抽象概念数量的极少化。例如某套抽象概念具有普适性,但却使用了 100 个概念去描述我们所面对的真实世界。这显然会增加学习成本,降低用户体验。抽象的普适性与极小化缺一不可。 具体到 jfinal 项目,核心只使用了 Controller、Model、Render、Interceptor、Handler、Plugin这六个概念,但却可以满足无限的需求场景,在保障了概念极小化的同时,具有极高的普适性。这六个抽象概念,删掉任何一个都不可以,添加新概念就显得多余(Plugin已经涵盖了大粒度类型的无穷扩展性)。这也是 "大道至简"、"少即是多" 的美妙诠释。 回过头去看一些其它框架,例如一个 AOP 的实现,用到的概念通常有:Aspect、 Advice、 Joinpoint、 Poincut、Introduction、Weaving、Around 等等,而 jfinal 用 Interceptor 这个概念就打完收工了。 JFinal 的 API 引导式配置,是指用 api 调用的形式进行配置,但并不是说将配置写死在程序中,例如看下面的例子: public void configConstant(Constants me) { boolean devMode = PropKit.getBoolean("devMode"); me.setDevMode(devMode); } 上例中的devMode 配置的值是从外部配置文件中加载进来的,并不是写死在程序中的,而这个外部配置文件,你可以采用你自己喜欢的方式,例如 jfinal 提供的 PropKit 工具加载 key=value形式的配置,也可以使用自己心爱的 xml 配置方式,自主定义配置格式。强调一下:API 引导式配置与配置写死在程序中毫无关系可言。 上例中API 引导配置部分是指 me.setDevMode(...) 这个方法,之所以称之为引导式配置,是指当你输入 "me." 这三个字符时,IDE 的代码提示会引导你有哪些可以用于配置的方法,而且方法上面有注释说明配置的含义。除了注释上有说明,方法名称以及方法参数名也在告诉你这个参数的意义。 总的来说 API 引导式配置的目的就是降低学习成本、提升开发效率,但同时也极度自由化地兼顾了外部XML、properties 配置。 通过这种方式就不仅可以降学习成本,而且也可以避免手误输错配置项。上面的例子表明,jfinal 引导式配置不是说将配置写在代码中,上例中的 devMode 这个值是从外部配置文件中得到的。 ######说下我的理解。jfinal作为框架,用代码来配置没问题的。而你说的也对,那么其实只要你在你的代码中留出给xml配置的 必要接口就可以了。一个项目哪用得框架级那么细致的配置,基本上大方向能配就可以了。######微内核指jar包小,依赖少。API 引导式配置有代码提示,xml写好dtd也有提示,缺点就是不直观,写在properties文件里,没有上下文,只有一个key-value。不知道哪个类要用到这个配置。把jfinalconfig这个类里面的每个方法都做成一个spring的bean###### 微内核就是jfinal2.2核心包300k. 你看看其他框架300k能够么。 ###### 微 就是小, jfinal 只是在web开发过程中,封装了MVC,数据库操作等必须功能,相对原来传统的spring,更简单,拓展性更强,相对spring等框架的过度设计,代码简洁明了; 在jfinal的插件基础上,你可以继续封装适合自己的业务框架,实现你自己所为的xml配置开发。 研究jfinal 参考设计模式之后 ,对自己的代码功底很有帮助。 ######你们有看过jfinal的源码吗?

爱吃鱼的程序员 2020-06-03 13:43:45 0 浏览量 回答数 0

阿里云试用中心,为您提供0门槛上云实践机会!

0元试用32+款产品,最高免费12个月!拨打95187-1,咨询专业上云建议!

问题

未来产品:具体信息系统防护罩:报错

kun坤 2020-06-20 11:37:35 1 浏览量 回答数 1

问题

未来产品:具体信息系统防护罩:配置报错 

kun坤 2020-06-02 17:58:08 1 浏览量 回答数 1

回答

选择一门编程语言,例如C之类的。如果不想学编程,就尝试下Excel里面的公式。-------------------------算法的定义 算法(Algorithm)是一系列解决问题的清晰指令,也就是说,能够对一定规范的输入,在有限时间内获得所要求的输出。如果一个算法有缺陷,或不适合于某个问题,执行这个算法将不会解决这个问题。不同的算法可能用不同的时间、空间或效率来完成同样的任务。一个算法的优劣可以用空间复杂度与时间复杂度来衡量。 算法可以理解为有基本运算及规定的运算顺序所构成的完整的解题步骤。或者看成按照要求设计好的有限的确切的计算序列,并且这样的步骤和序列可以解决一类问题。 一个算法应该具有以下五个重要的特征: 1、有穷性: 一个算法必须保证执行有限步之后结束; 2、确切性: 算法的每一步骤必须有确切的定义; 3、输入:一个算法有0个或多个输入,以刻画运算对象的初始情况,所谓0个输入是指算法本身定除了初始条件; 4、输出:一个算法有一个或多个输出,以反映对输入数据加工后的结果。没有输出的算法是毫无意义的; 5、可行性: 算法原则上能够精确地运行,而且人们用笔和纸做有限次运算后即可完成。 计算机科学家尼克劳斯-沃思曾著过一本著名的书《数据结构十算法= 程序》,可见算法在计算机科学界与计算机应用界的地位。 [编辑本段]算法的复杂度 同一问题可用不同算法解决,而一个算法的质量优劣将影响到算法乃至程序的效率。算法分析的目的在于选择合适算法和改进算法。一个算法的评价主要从时间复杂度和空间复杂度来考虑。 时间复杂度 算法的时间复杂度是指算法需要消耗的时间资源。一般来说,计算机算法是问题规模n 的函数f(n),算法的时间复杂度也因此记做 T(n)=Ο(f(n)) 因此,问题的规模n 越大,算法执行的时间的增长率与f(n) 的增长率正相关,称作渐进时间复杂度(Asymptotic Time Complexity)。 空间复杂度 算法的空间复杂度是指算法需要消耗的空间资源。其计算和表示方法与时间复杂度类似,一般都用复杂度的渐近性来表示。同时间复杂度相比,空间复杂度的分析要简单得多。 详见百度百科词条"算法复杂度" [编辑本段]算法设计与分析的基本方法 1.递推法 递推法是利用问题本身所具有的一种递推关系求问题解的一种方法。它把问题分成若干步,找出相邻几步的关系,从而达到目的,此方法称为递推法。 2.递归 递归指的是一个过程:函数不断引用自身,直到引用的对象已知 3.穷举搜索法 穷举搜索法是对可能是解的众多候选解按某种顺序进行逐一枚举和检验,并从众找出那些符合要求的候选解作为问题的解。 4.贪婪法 贪婪法是一种不追求最优解,只希望得到较为满意解的方法。贪婪法一般可以快速得到满意的解,因为它省去了为找最优解要穷尽所有可能而必须耗费的大量时间。贪婪法常以当前情况为基础作最优选择,而不考虑各种可能的整体情况,所以贪婪法不要回溯。 5.分治法 把一个复杂的问题分成两个或更多的相同或相似的子问题,再把子问题分成更小的子问题……直到最后子问题可以简单的直接求解,原问题的解即子问题的解的合并。 6.动态规划法 动态规划是一种在数学和计算机科学中使用的,用于求解包含重叠子问题的最优化问题的方法。其基本思想是,将原问题分解为相似的子问题,在求解的过程中通过子问题的解求出原问题的解。动态规划的思想是多种算法的基础,被广泛应用于计算机科学和工程领域。 7.迭代法 迭代是数值分析中通过从一个初始估计出发寻找一系列近似解来解决问题(一般是解方程或者方程组)的过程,为实现这一过程所使用的方法统称为迭代法。 [编辑本段]算法分类 算法可大致分为基本算法、数据结构的算法、数论与代数算法、计算几何的算法、图论的算法、动态规划以及数值分析、加密算法、排序算法、检索算法、随机化算法、并行算法。 算法可以宏泛的分为三类: 有限的,确定性算法 这类算法在有限的一段时间内终止。他们可能要花很长时间来执行指定的任务,但仍将在一定的时间内终止。这类算法得出的结果常取决于输入值。 有限的,非确定算法 这类算法在有限的时间内终止。然而,对于一个(或一些)给定的数值,算法的结果并不是唯一的或确定的。 无限的算法 是那些由于没有定义终止定义条件,或定义的条件无法由输入的数据满足而不终止运行的算法。通常,无限算法的产生是由于未能确定的定义终止条件。 [编辑本段]举例 经典的算法有很多,如:"欧几里德算法,割圆术,秦九韶算法"。 [编辑本段]算法经典专著 目前市面上有许多论述算法的书籍,其中最著名的便是《计算机程序设计艺术》(The Art Of Computer Programming) 以及《算法导论》(Introduction To Algorithms)。 [编辑本段]算法的历史 “算法”即演算法的大陆中文名称出自《周髀算经》;而英文名称Algorithm 来自于9世纪波斯数学家al-Khwarizmi,因为al-Khwarizmi在数学上提出了算法这个概念。“算法”原为"algorism",意思是阿拉伯数字的运算法则,在18世纪演变为"algorithm"。欧几里得算法被人们认为是史上第一个算法。 第一次编写程序是Ada Byron于1842年为巴贝奇分析机编写求解解伯努利方程的程序,因此Ada Byron被大多数人认为是世界上第一位程序员。因为查尔斯·巴贝奇(Charles Babbage)未能完成他的巴贝奇分析机,这个算法未能在巴贝奇分析机上执行。 因为"well-defined procedure"缺少数学上精确的定义,19世纪和20世纪早期的数学家、逻辑学家在定义算法上出现了困难。20世纪的英国数学家图灵提出了著名的图灵论题,并提出一种假想的计算机的抽象模型,这个模型被称为图灵机。图灵机的出现解决了算法定义的难题,图灵的思想对算法的发展起到了重要作用的。

马铭芳 2019-12-02 01:19:58 0 浏览量 回答数 0

回答

主要回答为什么要使用CSS预处理器。 (下面未指明的预编译预言都是LESS) 1# CSS无法递归式定义 CSS语法不支持递归定义的表达式,所以你没有办法用一个语句定义一个启发式的规则。 比如这样的需求:“.w后面跟着一个数字,这个数字代表着width为百分之多少”(bootstrap的栅格系统就包含12种相对父级宽度的类定义)。 尽管完全是一个规则里定义出的,但你只能这样写CSS: .w1 { width: 1% } .w2 { width: 2% } /** .w3 ... ... .w99 **/ .w100 { width: 100% } 这样将造成很大的冗余,修改费时费力。但如果预编译CSS,就非常简单了 @maxnumber : 100 ; .makeWidthRules(@number) when(@number <= @maxnumber ){ .w@{number}{ width: 1% * @number ; } .makeWidthRules(@number + 1) ; } .makeWidthRules(1) ; 2# CSS的mixin式复用性支持不够 使用纯CSS,我们可以抽象出一些常用的布局CSS属性组合,通过CSS的类组合来达成常见的mixin式复用。 比如这样: <style> .tc { text-align: center; } .m { margin-left: auto; margin-right: auto; } .w50p { width: 50%; } .db { display: block; } </style> <div class="tc m w50p"> <img class="db"> </div> 这种方案有几个问题:•页面重构时,需要频繁修改class name; 这个问题在后端人员掌握着视图层的时候格外突出,前后端耗费很多沟通成本。•要约束上下文的时候非常无力 比如“只有在ul下面的img.db允许是display:block”的规则,写成ul img.db { display: block; }就完全跑偏了——它违背了你创建这个.db类时的本意,造成了代码的可读性和可维护性下降。如果你要改动规则,需要同时修改HTML和CSS,也可能造成新的样式问题。 如果我们想要建立一种代码风格,只允许CSS Class代表UI模块的抽象——改动样式时不至于通知后端改模板——我们就要将上面这个例子的tc m w50p换用一个有实际语义的类名如headwrap,然后在CSS内部实现mixin。——而这正是CSS的短板,CSS体系内的用法只有复制粘贴。 至于如何用预编译语言做mixin,一个非常好的SASS示例由 @nightire 在这个回答里给出,容我摘录一小段: .btn-standout { @extend .btn; @extend .btn-block; @media (max-width: $screen-xs-max) { @include button-size( $padding-large-vertical, $padding-large-horizontal, $font-size-large, $line-height-large, $border-radius-large ); } &.sell { @extend .btn-primary; } } 3# 预编译可缓解多浏览器兼容造成的冗余 进入CSS3的时代,旧式CSS hack如filter,新式兼容前缀如-webkit-等,都是冗余,修改的时候也需要修改多处,不容易维护。 比如对rgba背景的兼容: .bg { filter: progid:DXImageTransform.Microsoft.gradient(startcolorstr=#ccff825b,endcolorstr=#ccff825b); } :root .bg { -ms-filter: none; background: rgba(255,130,91,0.8) } 在LESS里面,写个函数就能解决,多次复用也不需要看到如此之多的hack: .rgbaBG(@c , @a){ @rgba : rgba(red(@c),green(@c),blue(@c),@a); @shim : argb(@rgba) ; filter: ~"progid:DXImageTransform.Microsoft.gradient(startcolorstr=@{shim},endcolorstr=@{shim})" ; :root & { -ms-filter: none ; background: @rgba ; } } .bg { .rgbaBG(#ff825b, 0.8) ; } 此外,使用LESS时,可以很方便地使用base64 data uri的方案。不需要直接面临在CSS中一大坨字符:``.bg { background: data-uri('../data/image.jpg'); } SASS的类似方案见评论。 N# 预编译不是万金油 预编译不是万金油,CSS的好处在于简便、随时随地被使用和调试。预编译CSS步骤的加入,让我们开发工作流中多了一个环节,调试也变得更麻烦了。 举个例子:原先我们只需要在chrome/firebug里面找到相应的选择器,如.popup .popup-wrap .head,源文件里面ctrl+F查找.popup .popup-wrap .head就可以快速定位语句。现在我们无法直接在预编译文件中查找,而需要寻找上下文,因为它在LESS中通常是这样被定义的: .popup { .popup-wrap { .head { } } } 更大的问题在于,预编译很容易造成后代选择器的滥用。 曾经有一个观点是预编译可以解决样式覆写的问题,而我觉得,正是预编译语言模糊了样式覆写的问题,而导致要解决样式相互覆写的问题时,问题已经变得规模庞大而难以解决。 举个极端的例子: .popup { font-size: 12px; a { font-size: 13px; } .head { font-size: 18px; } }.informative { font-size: 14px; .head { font-size: 16px; } } 如果我有这么一个文档结构.popup.informative > .head > a,需要a的font-size为17px,你能快速想明白怎么改吗?叠罗汉式地再叠一层?还是再糊一层墙皮,加一行样式?还是干脆用!important轰炸一番?

杨冬芳 2019-12-02 02:32:48 0 浏览量 回答数 0

问题

使用 ASM 实现 Java 语言的“多重继承”:报错

kun坤 2020-06-06 15:29:41 0 浏览量 回答数 1

问题

线性表 7月8日 【今日算法】

游客ih62co2qqq5ww 2020-07-09 07:47:37 504 浏览量 回答数 1

回答

我们是否还需要另外一个新的数据处理引擎?当我第一次听到flink的时候这是我是非常怀疑的。在大数据领域,现在已经不缺少数据处理框架了,但是没有一个框架能够完全满足不同的处理需求。自从Apache spark出现后,貌似已经成为当今把大部分的问题解决得最好的框架了,所以我对另外一款解决类似问题的框架持有很强烈的怀疑态度。 不过因为好奇,我花费了数个星期在尝试了解flink。一开始仔细看了flink的几个例子,感觉和spark非常类似,心理就倾向于认为flink又是一个模仿spark的框架。但是随着了解的深入,这些API体现了一些flink的新奇的思路,这些思路还是和spark有着比较明显的区别的。我对这些思路有些着迷了,所以花费了更多的时间在这上面。 flink中的很多思路,例如内存管理,dataset API都已经出现在spark中并且已经证明 这些思路是非常靠谱的。所以,深入了解flink也许可以帮助我们分布式数据处理的未来之路是怎样的 在后面的文章里,我会把自己作为一个spark开发者对flink的第一感受写出来。因为我已经在spark上干了2年多了,但是只在flink上接触了2到3周,所以必然存在一些bias,所以大家也带着怀疑和批判的角度来看这篇文章吧。 Apache Flink是什么 flink是一款新的大数据处理引擎,目标是统一不同来源的数据处理。这个目标看起来和spark和类似。没错,flink也在尝试解决spark在解决的问题。这两套系统都在尝试建立一个统一的平台可以运行批量,流式,交互式,图处理,机器学习等应用。所以,flink和spark的目标差别并不大,他们最主要的区别在于实现的细节。 后面我会重点从不同的角度对比这两者。 Apache Spark vs Apache Flink 1.抽象 Abstraction spark中,对于批处理我们有RDD,对于流式,我们有DStream,不过内部实际还是RDD.所以所有的数据表示本质上还是RDD抽象。 后面我会重点从不同的角度对比这两者。在flink中,对于批处理有DataSet,对于流式我们有DataStreams。看起来和spark类似,他们的不同点在于: 一)DataSet在运行时是表现为运行计划(runtime plans)的 在spark中,RDD在运行时是表现为java objects的。通过引入Tungsten,这块有了些许的改变。但是在flink中是被表现为logical plan(逻辑计划)的,听起来很熟悉?没错,就是类似于spark中的dataframes。所以在flink中你使用的类Dataframe api是被作为第一优先级来优化的。但是相对来说在spark RDD中就没有了这块的优化了。 flink中的Dataset,对标spark中的Dataframe,在运行前会经过优化。 在spark 1.6,dataset API已经被引入spark了,也许最终会取代RDD 抽象。 二)Dataset和DataStream是独立的API 在spark中,所有不同的API,例如DStream,Dataframe都是基于RDD抽象的。但是在flink中,Dataset和DataStream是同一个公用的引擎之上两个独立的抽象。所以你不能把这两者的行为合并在一起操作,当然,flink社区目前在朝这个方向努力( https://issues.apache.org/jira/browse/FLINK-2320),但是目前还不能轻易断言最后的结果。 2.内存管理 一直到1.5版本,spark都是试用java的内存管理来做数据缓存,明显很容易导致OOM或者gc。所以从1.5开始,spark开始转向精确的控制内存的使用,这就是tungsten项目了 flink从第一天开始就坚持自己控制内存试用。这个也是启发了spark走这条路的原因之一。flink除了把数据存在自己管理的内存以外,还直接操作二进制数据。在spark中,从1.5开始,所有的dataframe操作都是直接作用在tungsten的二进制数据上。 3.语言实现 spark是用scala来实现的,它提供了Java,Python和R的编程接口。 flink是java实现的,当然同样提供了Scala API 所以从语言的角度来看,spark要更丰富一些。因为我已经转移到scala很久了,所以不太清楚这两者的java api实现情况。 4.API spark和flink都在模仿scala的collection API.所以从表面看起来,两者都很类似。下面是分别用RDD和DataSet API实现的word count // Spark wordcount object WordCount { def main(args: Array[String]) { val env = new SparkContext("local","wordCount") val data = List("hi","how are you","hi") val dataSet = env.parallelize(data) val words = dataSet.flatMap(value => value.split("\\s+")) val mappedWords = words.map(value => (value,1)) val sum = mappedWords.reduceByKey(_+_) println(sum.collect()) } } // Flink wordcount object WordCount { def main(args: Array[String]) { val env = ExecutionEnvironment.getExecutionEnvironment val data = List("hi","how are you","hi") val dataSet = env.fromCollection(data) val words = dataSet.flatMap(value => value.split("\\s+")) val mappedWords = words.map(value => (value,1)) val grouped = mappedWords.groupBy(0) val sum = grouped.sum(1) println(sum.collect()) } } 不知道是偶然还是故意的,API都长得很像,这样很方便开发者从一个引擎切换到另外一个引擎。我感觉以后这种Collection API会成为写data pipeline的标配。 Steaming spark把streaming看成是更快的批处理,而flink把批处理看成streaming的special case。这里面的思路决定了各自的方向,其中两者的差异点有如下这些: 实时 vs 近实时的角度 flink提供了基于每个事件的流式处理机制,所以可以被认为是一个真正的流式计算。它非常像storm的model。 而spark,不是基于事件的粒度,而是用小批量来模拟流式,也就是多个事件的集合。所以spark被认为是近实时的处理系统。 Spark streaming 是更快的批处理,而Flink Batch是有限数据的流式计算。 虽然大部分应用对准实时是可以接受的,但是也还是有很多应用需要event level的流式计算。这些应用更愿意选择storm而非spark streaming,现在,flink也许是一个更好的选择。 流式计算和批处理计算的表示 spark对于批处理和流式计算,都是用的相同的抽象:RDD,这样很方便这两种计算合并起来表示。而flink这两者分为了DataSet和DataStream,相比spark,这个设计算是一个糟糕的设计。 对 windowing 的支持 因为spark的小批量机制,spark对于windowing的支持非常有限。只能基于process time,且只能对batches来做window。 而Flink对window的支持非常到位,且Flink对windowing API的支持是相当给力的,允许基于process time,data time,record 来做windowing。 我不太确定spark是否能引入这些API,不过到目前为止,Flink的windowing支持是要比spark好的。 Steaming这部分flink胜 SQL interface 目前spark-sql是spark里面最活跃的组件之一,Spark提供了类似Hive的sql和Dataframe这种DSL来查询结构化数据,API很成熟,在流式计算中使用很广,预计在流式计算中也会发展得很快。 至于flink,到目前为止,Flink Table API只支持类似DataFrame这种DSL,并且还是处于beta状态,社区有计划增加SQL 的interface,但是目前还不确定什么时候才能在框架中用上。 所以这个部分,spark胜出。 Data source Integration Spark的数据源 API是整个框架中最好的,支持的数据源包括NoSql db,parquet,ORC等,并且支持一些高级的操作,例如predicate push down Flink目前还依赖map/reduce InputFormat来做数据源聚合。 这一场spark胜 Iterative processing spark对机器学习的支持较好,因为可以在spark中利用内存cache来加速机器学习算法。 但是大部分机器学习算法其实是一个有环的数据流,但是在spark中,实际是用无环图来表示的,一般的分布式处理引擎都是不鼓励试用有环图的。 但是flink这里又有点不一样,flink支持在runtime中的有环数据流,这样表示机器学习算法更有效而且更有效率。 这一点flink胜出。 Stream as platform vs Batch as Platform Spark诞生在Map/Reduce的时代,数据都是以文件的形式保存在磁盘中,这样非常方便做容错处理。 Flink把纯流式数据计算引入大数据时代,无疑给业界带来了一股清新的空气。这个idea非常类似akka-streams这种。 成熟度 目前的确有一部分吃螃蟹的用户已经在生产环境中使用flink了,不过从我的眼光来看,Flink还在发展中,还需要时间来成熟。 结论 目前Spark相比Flink是一个更为成熟的计算框架,但是Flink的很多思路很不错,Spark社区也意识到了这一点,并且逐渐在采用Flink中的好的设计思路,所以学习一下Flink能让你了解一下Streaming这方面的更迷人的思路。 答案来源网络,供参考,希望对您有帮助

问问小秘 2019-12-02 02:19:11 0 浏览量 回答数 0

回答

成为一名合格的开发工程师不是一件简单的事情,需要掌握从开发到调试到优化等一系列能力,这些能力中的每一项掌握起来都需要足够的努力和经验。而要成为一名合格的机器学习算法工程师(以下简称算法工程师)更是难上加难,因为在掌握工程师的通用技能以外,还需要掌握一张不算小的机器学习算法知识网络。 下面我们就将成为一名合格的算法工程师所需的技能进行拆分,一起来看一下究竟需要掌握哪些技能才能算是一名合格的算法工程师。 1.基础开发能力 所谓算法工程师,首先需要是一名工程师,那么就要掌握所有开发工程师都需要掌握的一些能力。 有些同学对于这一点存在一些误解,认为所谓算法工程师就只需要思考和设计算法,不用在乎这些算法如何实现,而且会有人帮你来实现你想出来的算法方案。这种思想是错误的,在大多数企业的大多数职位中,算法工程师需要负责从算法设计到算法实现再到算法上线这一个全流程的工作。 笔者曾经见过一些企业实行过算法设计与算法实现相分离的组织架构,但是在这种架构下,说不清楚谁该为算法效果负责,算法设计者和算法开发者都有一肚子的苦水,具体原因不在本文的讨论范畴中,但希望大家记住的是,基础的开发技能是所有算法工程师都需要掌握的。 2.概率和统计基础 概率和统计可以说是机器学习领域的基石之一,从某个角度来看,机器学习可以看做是建立在概率思维之上的一种对不确定世界的系统性思考和认知方式。学会用概率的视角看待问题,用概率的语言描述问题,是深入理解和熟练运用机器学习技术的最重要基础之一。 概率论内容很多,但都是以具体的一个个分布为具体表现载体体现出来的,所以学好常用的概率分布及其各种性质对于学好概率非常重要。 对于离散数据,伯努利分布、二项分布、多项分布、Beta分布、狄里克莱分布以及泊松分布都是需要理解掌握的内容; 对于离线数据,高斯分布和指数分布族是比较重要的分布。这些分布贯穿着机器学习的各种模型之中,也存在于互联网和真实世界的各种数据之中,理解了数据的分布,才能知道该对它们做什么样的处理。 此外,假设检验的相关理论也需要掌握。在这个所谓的大数据时代,最能骗人的大概就是数据了,掌握了假设检验和置信区间等相关理论,才能具备分辨数据结论真伪的能力。例如两组数据是否真的存在差异,上线一个策略之后指标是否真的有提升等等。这种问题在实际工作中非常常见,不掌握相关能力的话相当于就是大数据时代的睁眼瞎。 在统计方面,一些常用的参数估计方法也需要掌握,典型的如最大似然估计、最大后验估计、EM算法等。这些理论和最优化理论一样,都是可以应用于所有模型的理论,是基础中的基础。 3.机器学习理论 虽然现在开箱即用的开源工具包越来越多,但并不意味着算法工程师就可以忽略机器学习基础理论的学习和掌握。这样做主要有两方面的意义: 掌握理论才能对各种工具、技巧灵活应用,而不是只会照搬套用。只有在这个基础上才能够真正具备搭建一套机器学习系统的能力,并对其进行持续优化。否则只能算是机器学习搬砖工人,算不得合格的工程师。出了问题也不会解决,更谈不上对系统做优化。 学习机器学习的基础理论的目的不仅仅是学会如何构建机器学习系统,更重要的是,这些基础理论里面体现的是一套思想和思维模式,其内涵包括概率性思维、矩阵化思维、最优化思维等多个子领域,这一套思维模式对于在当今这个大数据时代做数据的处理、分析和建模是非常有帮助的。如果你脑子里没有这套思维,面对大数据环境还在用老一套非概率的、标量式的思维去思考问题,那么思考的效率和深度都会非常受限。 机器学习的理论内涵和外延非常之广,绝非一篇文章可以穷尽,所以在这里我列举了一些比较核心,同时对于实际工作比较有帮助的内容进行介绍,大家可在掌握了这些基础内容之后,再不断探索学习。 4.开发语言和开发工具 掌握了足够的理论知识,还需要足够的工具来将这些理论落地,这部分我们介绍一些常用的语言和工具。 5.架构设计 最后我们花一些篇幅来谈一下机器学习系统的架构设计。 所谓机器学习系统的架构,指的是一套能够支持机器学习训练、预测、服务稳定高效运行的整体系统以及他们之间的关系。 在业务规模和复杂度发展到一定程度的时候,机器学习一定会走向系统化、平台化这个方向。这个时候就需要根据业务特点以及机器学习本身的特点来设计一套整体架构,这里面包括上游数据仓库和数据流的架构设计,以及模型训练的架构,还有线上服务的架构等等。这一套架构的学习就不像前面的内容那么简单了,没有太多现成教材可以学习,更多的是在大量实践的基础上进行抽象总结,对当前系统不断进行演化和改进。但这无疑是算法工程师职业道路上最值得为之奋斗的工作。在这里能给的建议就是多实践,多总结,多抽象,多迭代。 6.机器学习算法工程师领域现状 现在可以说是机器学习算法工程师最好的时代,各行各业对这类人才的需求都非常旺盛。典型的包括以下一些细分行业: 推荐系统。推荐系统解决的是海量数据场景下信息高效匹配分发的问题,在这个过程中,无论是候选集召回,还是结果排序,以及用户画像等等方面,机器学习都起着重要的作用。 广告系统。广告系统和推荐系统有很多类似的地方,但也有着很显著的差异,需要在考虑平台和用户之外同时考虑广告主的利益,两方变成了三方,使得一些问题变复杂了很多。它在对机器学习的利用方面也和推荐类似。 搜索系统。搜索系统的很多基础建设和上层排序方面都大量使用了机器学习技术,而且在很多网站和App中,搜索都是非常重要的流量入口,机器学习对搜索系统的优化会直接影响到整个网站的效率。 风控系统。风控,尤其是互联网金融风控是近年来兴起的机器学习的又一重要战场。不夸张地说,运用机器学习的能力可以很大程度上决定一家互联网金融企业的风控能力,而风控能力本身又是这些企业业务保障的核心竞争力,这其中的关系大家可以感受一下。 但是所谓“工资越高,责任越大”,企业对于算法工程师的要求也在逐渐提高。整体来说,一名高级别的算法工程师应该能够处理“数据获取数据分析模型训练调优模型上线”这一完整流程,并对流程中的各种环节做不断优化。一名工程师入门时可能会从上面流程中的某一个环节做起,不断扩大自己的能力范围。 除了上面列出的领域以外,还有很多传统行业也在不断挖掘机器学习解决传统问题的能力,行业的未来可谓潜力巨大。

寒凝雪 2019-12-02 01:21:12 0 浏览量 回答数 0

回答

Arraylist和Vector是采用数组方式存储数据,此数组元素数大于实际存储的数据以便增加插入元素,都允许直接序号索引元素,但是插入数据要涉及到数组元素移动等内存操作,所以插入数据慢,查找有下标,所以查询数据快,Vector由于使用了synchronized方法-线程安全,所以性能上比ArrayList要差,LinkedList使用双向链表实现存储,按序号索引数据需要进行向前或向后遍历,但是插入数据时只需要记录本项前后项即可,插入数据较快。线性表,链表,哈希表是常用的数据结构,在进行java开发时,JDK已经为我们提供了一系列相应的类实现基本的数据结构,这些结构均在java.util包中,collection├List│├LinkedList│├ArrayList│└Vector│ └Stack└SetMap├Hashtable├HashMap└WeakHashMapCollection接口Collection是最基本的集合接口,一个Collection代表一组Object,即Collection的元素(elements),一些Collection允许相同的元素而另一些不行。一些能排序而另一些不行。Java SDK不提供直接继承自Collection的类,Java SDK提供的类都是继承自Collection的“子接口”如List和Set。所有实现Collection接口的类都必须提供两个标准的构造函数:无参数的构造函数用于创建一个空的Collection,有一个Collection参数的构造函数用于创建一个新的Collection,这个新的Collection与传入的Collection有相同的元素。后一个构造函数允许用户复制一个Collection。如何遍历Collection中的每一个元素?不论Collection的实际类型如何,它都支持一个iterator()的方法,该方法返回一个迭代子,使用该迭代子即可逐一访问Collection中每一个元素。典型的用法如下:    Iterator it = collection.iterator(); // 获得一个迭代子    while(it.hasNext()) {      Object obj = it.next(); // 得到下一个元素    }  由Collection接口派生的两个接口是List和Set。List接口  List是有序的Collection,使用此接口能够精确的控制每个元素插入的位置。用户能够使用索引(元素在List中的位置,类似于数组下标)来访问List中的元素,这类似于Java的数组。和下面要提到的Set不同,List允许有相同的元素。  除了具有Collection接口必备的iterator()方法外,List还提供一个listIterator()方法,返回一个ListIterator接口,和标准的Iterator接口相比,ListIterator多了一些add()之类的方法,允许添加,删除,设定元素,还能向前或向后遍历。  实现List接口的常用类有LinkedList,ArrayList,Vector和Stack。ArrayList类  ArrayList实现了可变大小的数组。它允许所有元素,包括null。ArrayList没有同步。size,isEmpty,get,set方法运行时间为常数。但是add方法开销为分摊的常数,添加n个元素需要O(n)的时间。其他的方法运行时间为线性。  每个ArrayList实例都有一个容量(Capacity),即用于存储元素的数组的大小。这个容量可随着不断添加新元素而自动增加,但是增长算法并没有定义。当需要插入大量元素时,在插入前可以调用ensureCapacity方法来增加ArrayList的容量以提高插入效率。  和LinkedList一样,ArrayList也是非同步的(unsynchronized)。Vector类  Vector非常类似ArrayList,但是Vector是同步的。由Vector创建的Iterator,虽然和ArrayList创建的Iterator是同一接口,但是,因为Vector是同步的,当一个Iterator被创建而且正在被使用,另一个线程改变了Vector的状态(例如,添加或删除了一些元素),这时调用Iterator的方法时将抛出ConcurrentModificationException,因此必须捕获该异常。Stack 类  Stack继承自Vector,实现一个后进先出的堆栈。Stack提供5个额外的方法使得Vector得以被当作堆栈使用。基本的push和pop方法,还有peek方法得到栈顶的元素,empty方法测试堆栈是否为空,search方法检测一个元素在堆栈中的位置。Stack刚创建后是空栈。Map接口  请注意,Map没有继承Collection接口,Map提供key到value的映射。一个Map中不能包含相同的key,每个key只能映射一个value。Map接口提供3种集合的视图,Map的内容可以被当作一组key集合,一组value集合,或者一组key-value映射。Hashtable类  Hashtable继承Map接口,实现一个key-value映射的哈希表。任何非空(non-null)的对象都可作为key或者value。  添加数据使用put(key, value),取出数据使用get(key),这两个基本操作的时间开销为常数。Hashtable通过initial capacity和load factor两个参数调整性能。通常缺省的load factor 0.75较好地实现了时间和空间的均衡。增大load factor可以节省空间但相应的查找时间将增大,这会影响像get和put这样的操作。使用Hashtable的简单示例如下,将1,2,3放到Hashtable中,他们的key分别是”one”,”two”,”three”:    Hashtable numbers = new Hashtable();    numbers.put(“one”, new Integer(1));    numbers.put(“two”, new Integer(2));    numbers.put(“three”, new Integer(3));  要取出一个数,比如2,用相应的key:    Integer n = (Integer)numbers.get(“two”);    System.out.println(“two = ” + n);  由于作为key的对象将通过计算其散列函数来确定与之对应的value的位置,因此任何作为key的对象都必须实现hashCode和equals方法。hashCode和equals方法继承自根类Object,如果你用自定义的类当作key的话,要相当小心,按照散列函数的定义,如果两个对象相同,即obj1.equals(obj2)=true,则它们的hashCode必须相同,但如果两个对象不同,则它们的hashCode不一定不同,如果两个不同对象的hashCode相同,这种现象称为冲突,冲突会导致操作哈希表的时间开销增大,所以尽量定义好的hashCode()方法,能加快哈希表的操作。  如果相同的对象有不同的hashCode,对哈希表的操作会出现意想不到的结果(期待的get方法返回null),要避免这种问题,只需要牢记一条:要同时复写equals方法和hashCode方法,而不要只写其中一个。  Hashtable是同步的。HashMap类  HashMap和Hashtable类似,不同之处在于HashMap是非同步的,并且允许null,即null value和null key。,但是将HashMap视为Collection时(values()方法可返回Collection),其迭代子操作时间开销和HashMap的容量成比例。因此,如果迭代操作的性能相当重要的话,不要将HashMap的初始化容量设得过高,或者load factor过低。WeakHashMap类  WeakHashMap是一种改进的HashMap,它对key实行“弱引用”,如果一个key不再被外部所引用,那么该key可以被GC回收。总结  如果涉及到堆栈,队列等操作,应该考虑用List,对于需要快速插入,删除元素,应该使用LinkedList,如果需要快速随机访问元素,应该使用ArrayList。  如果程序在单线程环境中,或者访问仅仅在一个线程中进行,考虑非同步的类,其效率较高,如果多个线程可能同时操作一个类,应该使用同步的类。  要特别注意对哈希表的操作,作为key的对象要正确复写equals和hashCode方法。  尽量返回接口而非实际的类型,如返回List而非ArrayList,这样如果以后需要将ArrayList换成LinkedList时,客户端代码不用改变。这就是针对抽象编程。同步性Vector是同步的。这个类中的一些方法保证了Vector中的对象是线程安全的。而ArrayList则是异步的,因此ArrayList中的对象并不是线程安全的。因为同步的要求会影响执行的效率,所以如果你不需要线程安全的集合那么使用ArrayList是一个很好的选择,这样可以避免由于同步带来的不必要的性能开销。数据增长从内部实现机制来讲ArrayList和Vector都是使用数组(Array)来控制集合中的对象。当你向这两种类型中增加元素的时候,如果元素的数目超出了内部数组目前的长度它们都需要扩展内部数组的长度,Vector缺省情况下自动增长原来一倍的数组长度,ArrayList是原来的50%,所以最后你获得的这个集合所占的空间总是比你实际需要的要大。所以如果你要在集合中保存大量的数据那么使用Vector有一些优势,因为你可以通过设置集合的初始化大小来避免不必要的资源开销。使用模式在ArrayList和Vector中,从一个指定的位置(通过索引)查找数据或是在集合的末尾增加、移除一个元素所花费的时间是一样的,这个时间我们用O(1)表示。但是,如果在集合的其他位置增加或移除元素那么花费的时间会呈线形增长:O(n-i),其中n代表集合中元素的个数,i代表元素增加或移除元素的索引位置。为什么会这样呢?以为在进行上述操作的时候集合中第i和第i个元素之后的所有元素都要执行位移的操作。这一切意味着什么呢?这意味着,你只是查找特定位置的元素或只在集合的末端增加、移除元素,那么使用Vector或ArrayList都可以。如果是其他操作,你最好选择其他的集合操作类。比如,LinkList集合类在增加或移除集合中任何位置的元素所花费的时间都是一样的?O(1),但它在索引一个元素的使用缺比较慢-O(i),其中i是索引的位置.使用ArrayList也很容易,因为你可以简单的使用索引来代替创建iterator对象的操作。LinkList也会为每个插入的元素创建对象,所有你要明白它也会带来额外的开销。最后,在《Practical Java》一书中Peter Haggar建议使用一个简单的数组(Array)来代替Vector或ArrayList。尤其是对于执行效率要求高的程序更应如此。因为使用数组(Array)避免了同步、额外的方法调用和不必要的重新分配空间的操作。

wangccsy 2019-12-02 01:48:37 0 浏览量 回答数 0

问题

Netty实现原理浅析 1、总体结构 2、网络模型 3、 buffer 4、Ch?400报错

爱吃鱼的程序员 2020-06-04 11:53:36 3 浏览量 回答数 1

问题

对症下药:Tomcat停机过程分析与线程处理方法

驻云科技 2019-12-01 21:36:46 4001 浏览量 回答数 0

回答

触及 multiple inheritance (MI)(多继承)的时候,C++ 社区就会鲜明地分裂为两个基本的阵营。一个阵营认为如果 single inheritance (SI)(单继承)是有好处的,multiple inheritance(多继承)一定更有好处。另一个阵营认为 single inheritance(单继承)有好处,但是多继承引起的麻烦使它得不偿失。在本文中,我们的主要目的是理解在 MI 问题上的这两种看法。   首要的事情之一是要承认当将 MI 引入设计领域时,就有可能从多于一个的 base class(基类)中继承相同的名字(例如,函数,typedef,等等)。这就为歧义性提供了新的时机。例如: class BorrowableItem { // something a library lets you borrowpublic: void checkOut(); // check the item out from the library ..}; class ElectronicGadget {private: bool checkOut() const; // perform self-test, return whether ... // test succeeds}; class MP3Player: // note MI herepublic BorrowableItem, // (some libraries loan MP3 players)public ElectronicGadget{ ... }; // class definition is unimportant MP3Player mp; mp.checkOut(); // ambiguous! which checkOut?    注意这个例子,即使两个函数中只有一个是可访问的,对 checkOut 的调用也是有歧义的。(checkOut 在 BorrowableItem 中是 public(公有)的,但在 ElectronicGadget 中是 private(私有)的。)这与 C++ 解析 overloaded functions(重载函数)调用的规则是一致的:在看到一个函数的是否可访问之前,C++ 首先确定与调用匹配最好的那个函数。只有在确定了 best-match function(最佳匹配函数)之后,才检查可访问性。这目前的情况下,两个 checkOuts 具有相同的匹配程度,所以就不存在最佳匹配。因此永远也不会检查到 ElectronicGadget::checkOut 的可访问性。   为了消除歧义性,你必须指定哪一个 base class(基类)的函数被调用: mp.BorrowableItem::checkOut(); // ah, that checkOut...   当然,你也可以尝试显式调用 ElectronicGadget::checkOut,但这样做会有一个 "you're trying to call a private member function"(你试图调用一个私有成员函数)错误代替歧义性错误。    multiple inheritance(多继承)仅仅意味着从多于一个的 base class(基类)继承,但是在还有 higher-level base classes(更高层次基类)的 hierarchies(继承体系)中出现 MI 也并不罕见。这会导致有时被称为 "deadly MI diamond"(致命的多继承菱形)的后果。 class File { ... };class InputFile: public File { ... };class OutputFile: public File { ... };class IOFile: public InputFile,public OutputFile{ ... };    在一个“在一个 base class(基类)和一个 derived class(派生类)之间有多于一条路径的 inheritance hierarchy(继承体系)”(就像上面在 File 和 IOFile 之间,有通过 InputFile 和 OutputFile 的两条路径)的任何时候,你都必须面对是否需要为每一条路径复制 base class(基类)中的 data members(数据成员)的问题。例如,假设 File class 有一个 data members(数据成员)fileName。IOFile 中应该有这个 field(字段)的多少个拷贝呢?一方面,它从它的每一个 base classes(基类)继承一个拷贝,这就暗示 IOFile 应该有两个 fileName data members(数据成员)。另一方面,简单的逻辑告诉我们一个 IOFile object(对象)应该仅有一个 file name(文件名),所以通过它的两个 base classes(基类)继承来的 fileName field(字段)不应该被复制。   C++ 在这个争议上没有自己的立场。它恰当地支持两种选项,虽然它的缺省方式是执行复制。如果那不是你想要的,你必须让这个 class(类)带有一个 virtual base class(虚拟基类)的数据(也就是 File)。为了做到这一点,你要让从它直接继承的所有的 classes(类)使用 virtual inheritance(虚拟继承): class File { ... };class InputFile: virtual public File { ... };class OutputFile: virtual public File { ... };class IOFile: public InputFile,public OutputFile{ ... };    标准 C++ 库包含一个和此类似的 MI hierarchy(继承体系),只是那个 classes(类)是 class templates(类模板),名字是 basic_ios,basic_istream,basic_ostream 和 basic_iostream,而不是 File,InputFile,OutputFile 和 IOFile。   从正确行为的观点 看,public inheritance(公有继承)应该总是 virtual(虚拟)的。如果这是唯一的观点,规则就变得简单了:你使用 public inheritance(公有继承)的任何时候,都使用 virtual public inheritance(虚拟公有继承)。唉,正确性不是唯一的视角。避免 inherited fields(继承来的字段)复制需要在编译器的一部分做一些 behind-the-scenes legerdemain(幕后的戏法),而结果是从使用 virtual inheritance(虚拟继承)的 classes(类)创建的 objects(对象)通常比不使用 virtual inheritance(虚拟继承)的要大。访问 virtual base classes(虚拟基类)中的 data members(数据成员)也比那些 non-virtual base classes(非虚拟基类)中的要慢。编译器与编译器之间有一些细节不同,但基本的要点很清楚:virtual inheritance costs(虚拟继承要付出成本)。   它也有一些其它方面的成本。支配 initialization of virtual base classes(虚拟基类初始化)的规则比 non-virtual bases(非虚拟基类)的更加复杂而且更不直观。初始化一个 virtual base(虚拟基)的职责由 hierarchy(继承体系)中 most derived class(层次最低的派生类)承担。这个规则中包括的含义:   (1) 从需要 initialization(初始化)的 virtual bases(虚拟基)派生的 classes(类)必须知道它们的 virtual bases(虚拟基),无论它距离那个 bases(基)有多远;   (2) 当一个新的 derived class(派生类)被加入继承体系时,它必须为它的 virtual bases(虚拟基)(包括直接的和间接的)承担 initialization responsibilities(初始化职责)。    我对于 virtual base classes(虚拟基类)(也就是 virtual inheritance(虚拟继承))的建议很简单。首先,除非必需,否则不要使用 virtual bases(虚拟基)。缺省情况下,使用 non-virtual inheritance(非虚拟继承)。第二,如果你必须使用 virtual base classes(虚拟基类),试着避免在其中放置数据。这样你就不必在意它的 initialization(初始化)(以及它的 turns out(清空),assignment(赋值))规则中的一些怪癖。值得一提的是 Java 和 .NET 中的 Interfaces(接口)不允许包含任何数据,它们在很多方面可以和 C++ 中的 virtual base classes(虚拟基类)相比照。   现在我们使用下面的 C++ Interface class(接口类)(参见《C++箴言:最小化文件之间的编译依赖》)来为 persons(人)建模: class IPerson {public: virtual ~IPerson();  virtual std::string name() const = 0; virtual std::string birthDate() const = 0;};    IPerson 的客户只能使用 IPerson 的 pointers(指针)和 references(引用)进行编程,因为 abstract classes(抽象类)不能被实例化。为了创建能被当作 IPerson objects(对象)使用的 objects(对象),IPerson 的客户使用 factory functions(工厂函数)(再次参见 Item 31)instantiate(实例化)从 IPerson 派生的 concrete classes(具体类): // factory function to create a Person object from a unique database ID;// see Item 18 for why the return type isn't a raw pointerstd::tr1::shared_ptr makePerson(DatabaseID personIdentifier); // function to get a database ID from the userDatabaseID askUserForDatabaseID(); DatabaseID id(askUserForDatabaseID());std::tr1::shared_ptr pp(makePerson(id)); // create an object// supporting the// IPerson interface ... // manipulate *pp via// IPerson's member// functions   但是 makePerson 怎样创建它返回的 pointers(指针)所指向的 objects(对象)呢?显然,必须有一些 makePerson 可以实例化的从 IPerson 派生的 concrete class(具体类)。    假设这个 class(类)叫做 CPerson。作为一个 concrete class(具体类),CPerson 必须提供它从 IPerson 继承来的 pure virtual functions(纯虚拟函数)的 implementations(实现)。它可以从头开始写,但利用包含大多数或全部必需品的现有组件更好一些。例如,假设一个老式的 database-specific class(老式的数据库专用类)PersonInfo 提供了 CPerson 所需要的基本要素: class PersonInfo {public: explicit PersonInfo(DatabaseID pid); virtual ~PersonInfo();  virtual const char * theName() const; virtual const char * theBirthDate() const; ... private: virtual const char * valueDelimOpen() const; // see virtual const char * valueDelimClose() const; // below ...};    你可以看出这是一个老式的 class(类),因为 member functions(成员函数)返回 const char*s 而不是 string objects(对象)。尽管如此,如果鞋子合适,为什么不穿呢?这个 class(类)的 member functions(成员函数)的名字暗示结果很可能会非常合适。   你突然发现 PersonInfo 是设计用来帮助以不同的格式打印 database fields(数据库字段)的,每一个字段的值的开始和结尾通过指定的字符串定界。缺省情况下,字段值开始和结尾定界符是方括号,所以字段值 "Ring-tailed Lemur" 很可能被安排成这种格式: [Ring-tailed Lemur]   根据方括号并非满足 PersonInfo 的全体客户的期望的事实,virtual functions(虚拟函数)valueDelimOpen 和 valueDelimClose 允许 derived classes(派生类)指定它们自己的开始和结尾定界字符串。PersonInfo 的 member functions(成员函数)的 implementations(实现)调用这些 virtual functions(虚拟函数)在它们返回的值上加上适当的定界符。作为一个例子使用 PersonInfo::theName,代码如下: const char * PersonInfo::valueDelimOpen() const{ return "["; // default opening delimiter} const char * PersonInfo::valueDelimClose() const{ return "]"; // default closing delimiter} const char * PersonInfo::theName() const{ // reserve buffer for return value; because this is // static, it's automatically initialized to all zeros static char value[Max_Formatted_Field_Value_Length];  // write opening delimiter std::strcpy(value, valueDelimOpen());  append to the string in value this object's name field (being careful to avoid buffer overruns!)  // write closing delimiter std::strcat(value, valueDelimClose());  return value;}    有人可能会质疑 PersonInfo::theName 的陈旧的设计(特别是一个 fixed-size static buffer(固定大小静态缓冲区)的使用,这样的东西发生 overrun(越界)和 threading(线程)问题是比较普遍的——参见《C++箴言:必须返回对象时别返回引用》),但是请把这样的问题放到一边而注意这里:theName 调用 valueDelimOpen 生成它要返回的 string(字符串)的开始定界符,然后它生成名字值本身,然后它调用 valueDelimClose。   因为 valueDelimOpen 和 valueDelimClose 是 virtual functions(虚拟函数),theName 返回的结果不仅依赖于 PersonInfo,也依赖于从 PersonInfo 派生的 classes(类)。    对于 CPerson 的实现者,这是好消息,因为当细读 IPerson documentation(文档)中的 fine print(晦涩的条文)时,你发现 name 和 birthDate 需要返回未经修饰的值,也就是,不允许有定界符。换句话说,如果一个人的名字叫 Homer,对那个人的 name 函数的一次调用应该返回 "Homer",而不是 "[Homer]"。   CPerson 和 PersonInfo 之间的关系是 PersonInfo 碰巧有一些函数使得 CPerson 更容易实现。这就是全部。因而它们的关系就是 is-implemented-in-terms-of,而我们知道有两种方法可以表现这一点:经由 composition(复合)(参见《C++箴言:通过composition模拟“has-a”》)和经由 private inheritance(私有继承)(参见《C++箴言:谨慎使用私有继承》)。《C++箴言:谨慎使用私有继承》 指出 composition(复合)是通常的首选方法,但如果 virtual functions(虚拟函数)要被重定义,inheritance(继承)就是必不可少的。在当前情况下,CPerson 需要重定义 valueDelimOpen 和 valueDelimClose,所以简单的 composition(复合)做不到。最直截了当的解决方案是让 CPerson 从 PersonInfo privately inherit(私有继承),虽然 《C++箴言:谨慎使用私有继承》 说过只要多做一点工作,则 CPerson 也能用 composition(复合)和 inheritance(继承)的组合有效地重定义 PersonInfo 的 virtuals(虚拟函数)。这里,我们用 private inheritance(私有继承)。   但 是 CPerson 还必须实现 IPerson interface(接口),而这被称为 public inheritance(公有继承)。这就引出一个 multiple inheritance(多继承)的合理应用:组合 public inheritance of an interface(一个接口的公有继承)和 private inheritance of an implementation(一个实现的私有继承): class IPerson { // this class specifies thepublic: // interface to be implemented virtual ~IPerson();  virtual std::string name() const = 0; virtual std::string birthDate() const = 0;}; class DatabaseID { ... }; // used below; details are// unimportant class PersonInfo { // this class has functionspublic: // useful in implementing explicit PersonInfo(DatabaseID pid); // the IPerson interface virtual ~PersonInfo();  virtual const char * theName() const; virtual const char * theBirthDate() const;  virtual const char * valueDelimOpen() const; virtual const char * valueDelimClose() const; ...}; class CPerson: public IPerson, private PersonInfo { // note use of MIpublic: explicit CPerson( DatabaseID pid): PersonInfo(pid) {} virtual std::string name() const // implementations { return PersonInfo::theName(); } // of the required // IPerson member virtual std::string birthDate() const // functions { return PersonInfo::theBirthDate(); }private: // redefinitions of const char * valueDelimOpen() const { return ""; } // inherited virtual const char * valueDelimClose() const { return ""; } // delimiter}; // functions   在 UML 中,这个设计看起来像这样:   这个例子证明 MI 既是有用的,也是可理解的。    时至今日,multiple inheritance(多继承)不过是 object-oriented toolbox(面向对象工具箱)里的又一种工具而已,典型情况下,它的使用和理解更加复杂,所以如果你得到一个或多或少等同于一个 MI 设计的 SI 设计,则 SI 设计总是更加可取。如果你能拿出来的仅有的设计包含 MI,你应该更加用心地考虑一下——总会有一些方法使得 SI 也能做到。但同时,MI 有时是最清晰的,最易于维护的,最合理的完成工作的方法。在这种情况下,毫不畏惧地使用它。只是要确保谨慎地使用它。   Things to Remember   ·multiple inheritance(多继承)比 single inheritance(单继承)更复杂。它能导致新的歧义问题和对 virtual inheritance(虚拟继承)的需要。    ·virtual inheritance(虚拟继承)增加了 size(大小)和 speed(速度)成本,以及 initialization(初始化)和 assignment(赋值)的复杂度。当 virtual base classes(虚拟基类)没有数据时它是最适用的。   ·multiple inheritance(多继承)有合理的用途。一种方案涉及组合从一个 Interface class(接口类)的 public inheritance(公有继承)和从一个有助于实现的 class(类)的 private inheritance(私有继承)。 关于虚拟继承的思考虚拟继承在一般的应用中很少用到,所以也往往被忽视,这也主要是因为在C++中,多重继承是不推荐的,而一旦离开了多重继承,虚拟继承就完全失去了存在的必要(因为这样只会降低效率和占用更多的空间,实在是一无是处)。  以下面的一个例子为例:  #include   #include   class CA  {   int k; //为了便于说明后面的内存结构特别添加  public:   void f() {cout << "CA::f" << endl;}  };  class CB : public CA  {  };  class CC : public CA  {  };  class CD : public CB, public CC  {  };  void main()  {   CD d;   d.f();  }  当编译上述代码时,我们会收到如下的错误提示:  error C2385: 'CD::f' is ambiguous  即编译器无法确定你在d.f()中要调用的函数f到底是哪一个。这里可能会让人觉得有些奇怪,命名只定义了一个CA::f,既然大家都派生自CA,那自然就是调用的CA::f,为什么还无法确定呢?  这是因为编译器在进行编译的时候,需要确定子类的函数定义,如CA::f是确定的,那么在编译CB、CC时还需要在编译器的语法树中生成CB::f,CC::f等标识,那么,在编译CD的时候,由于CB、CC都有一个函数f,此时,编译器将试图生成两个CD::f标识,显然这时就要报错了。(当我们不使用CD::f的时候,以上标识都不会生成,所以,如果去掉d.f()一句,程序将顺利通过编译)  要解决这个问题,有两个方法:  1、重载函数f():此时由于我们明确定义了CD::f,编译器检查到CD::f()调用时就无需再像上面一样去逐级生成CD::f标识了;  此时CD的元素结构如下:  --------  |CB(CA)|  |CC(CA)|  --------  故此时的sizeof(CD) = 8;(CB、CC各有一个元素k)  2、使用虚拟继承:虚拟继承又称作共享继承,这种共享其实也是编译期间实现的,当使用虚拟继承时,上面的程序将变成下面的形式:  #include   #include   class CA  {   int k;  public:   void f() {cout << "CA::f" << endl;}  };  class CB : virtual public CA  {  };  class CC : virtual public CA  {  };  class CD : public CB, public CC  {  };  void main()  {   CD d;   d.f();  }  此时,当编译器确定d.f()调用的具体含义时,将生成如下的CD结构:  ----  |CB|  |CC|  |CA|  ----  同时,在CB、CC中都分别包含了一个指向CA的vbptr(virtual base table pointer),其中记录的是从CB、CC的元素到CA的元素之间的偏移量。此时,不会生成各子类的函数f标识,除非子类重载了该函数,从而达到“共享”的目的。  也正因此,此时的sizeof(CD) = 12(两个vbptr + sizoef(int));

a123456678 2019-12-02 01:58:07 0 浏览量 回答数 0

问题

算法工程师必知必会10大基础算法! 6月23日 【今日算法】

游客ih62co2qqq5ww 2020-06-23 13:36:00 6 浏览量 回答数 1

回答

在开始谈我对架构本质的理解之前,先谈谈对今天技术沙龙主题的个人见解,千万级规模的网站感觉数量级是非常大的,对这个数量级我们战略上 要重 视 它 , 战术上又 要 藐 视 它。先举个例子感受一下千万级到底是什么数量级?现在很流行的优步(Uber),从媒体公布的信息看,它每天接单量平均在百万左右, 假如每天有10个小时的服务时间,平均QPS只有30左右。对于一个后台服务器,单机的平均QPS可以到达800-1000,单独看写的业务量很简单 。为什么我们又不能说轻视它?第一,我们看它的数据存储,每天一百万的话,一年数据量的规模是多少?其次,刚才说的订单量,每一个订单要推送给附近的司机、司机要并发抢单,后面业务场景的访问量往往是前者的上百倍,轻松就超过上亿级别了。 今天我想从架构的本质谈起之后,希望大家理解在做一些建构设计的时候,它的出发点以及它解决的问题是什么。 架构,刚开始的解释是我从知乎上看到的。什么是架构?有人讲, 说架构并不是一 个很 悬 乎的 东西 , 实际 上就是一个架子 , 放一些 业务 和算法,跟我们的生活中的晾衣架很像。更抽象一点,说架构其 实 是 对 我 们 重复性业务 的抽象和我 们 未来 业务 拓展的前瞻,强调过去的经验和你对整个行业的预见。 我们要想做一个架构的话需要哪些能力?我觉得最重要的是架构师一个最重要的能力就是你要有 战 略分解能力。这个怎么来看呢: 第一,你必须要有抽象的能力,抽象的能力最基本就是去重,去重在整个架构中体现在方方面面,从定义一个函数,到定义一个类,到提供的一个服务,以及模板,背后都是要去重提高可复用率。 第二, 分类能力。做软件需要做对象的解耦,要定义对象的属性和方法,做分布式系统的时候要做服务的拆分和模块化,要定义服务的接口和规范。 第三, 算法(性能),它的价值体现在提升系统的性能,所有性能的提升,最终都会落到CPU,内存,IO和网络这4大块上。 这一页PPT举了一些例子来更深入的理解常见技术背后的架构理念。 第一个例子,在分布式系统我们会做 MySQL分 库 分表,我们要从不同的库和表中读取数据,这样的抽象最直观就是使用模板,因为绝大多数SQL语义是相同的,除了路由到哪个库哪个表,如果不使用Proxy中间件,模板就是性价比最高的方法。 第二看一下加速网络的CDN,它是做速度方面的性能提升,刚才我们也提到从CPU、内存、IO、网络四个方面来考虑,CDN本质上一个是做网络智能调度优化,另一个是多级缓存优化。 第三个看一下服务化,刚才已经提到了,各个大网站转型过程中一定会做服务化,其实它就是做抽象和做服务的拆分。第四个看一下消息队列,本质上还是做分类,只不过不是两个边际清晰的类,而是把两个边际不清晰的子系统通过队列解构并且异步化。新浪微博整体架构是什么样的 接下我们看一下微博整体架构,到一定量级的系统整个架构都会变成三层,客户端包括WEB、安卓和IOS,这里就不说了。接着还都会有一个接口层, 有三个主要作用: 第一个作用,要做 安全隔离,因为前端节点都是直接和用户交互,需要防范各种恶意攻击; 第二个还充当着一个 流量控制的作用,大家知道,在2014年春节的时候,微信红包,每分钟8亿多次的请求,其实真正到它后台的请求量,只有十万左右的数量级(这里的数据可能不准),剩余的流量在接口层就被挡住了; 第三,我们看对 PC 端和移 动 端的需求不一样的,所以我们可以进行拆分。接口层之后是后台,可以看到微博后台有三大块: 一个是 平台服 务, 第二, 搜索, 第三, 大数据。到了后台的各种服务其实都是处理的数据。 像平台的业务部门,做的就是 数据存储和读 取,对搜索来说做的是 数据的 检 索,对大数据来说是做的数据的 挖掘。微博其实和淘宝是很类似 微博其实和淘宝是很类似的。一般来说,第一代架构,基本上能支撑到用户到 百万 级别,到第二代架构基本能支撑到 千万 级别都没什么问题,当业务规模到 亿级别时,需要第三代的架构。 从 LAMP 的架构到面向服 务 的架构,有几个地方是非常难的,首先不可能在第一代基础上通过简单的修修补补满足用户量快速增长的,同时线上业务又不能停, 这是我们常说的 在 飞 机上 换 引擎的 问题。前两天我有一个朋友问我,说他在内部推行服务化的时候,把一个模块服务化做完了,其他部门就是不接。我建议在做服务化的时候,首先更多是偏向业务的梳理,同时要找准一个很好的切入点,既有架构和服务化上的提升,业务方也要有收益,比如提升性能或者降低维护成本同时升级过程要平滑,建议开始从原子化服务切入,比如基础的用户服务, 基础的短消息服务,基础的推送服务。 第二,就是可 以做无状 态 服 务,后面会详细讲,还有数据量大了后需要做数据Sharding,后面会将。 第三代 架构 要解决的 问题,就是用户量和业务趋于稳步增加(相对爆发期的指数级增长),更多考虑技术框架的稳定性, 提升系统整体的性能,降低成本,还有对整个系统监控的完善和升级。 大型网站的系统架构是如何演变的 我们通过通过数据看一下它的挑战,PV是在10亿级别,QPS在百万,数据量在千亿级别。我们可用性,就是SLA要求4个9,接口响应最多不能超过150毫秒,线上所有的故障必须得在5分钟内解决完。如果说5分钟没处理呢?那会影响你年终的绩效考核。2015年微博DAU已经过亿。我们系统有上百个微服务,每周会有两次的常规上线和不限次数的紧急上线。我们的挑战都一样,就是数据量,bigger and bigger,用户体验是faster and faster,业务是more and more。互联网业务更多是产品体验驱动, 技 术 在 产 品 体验上最有效的贡献 , 就是你的性能 越来越好 。 每次降低加载一个页面的时间,都可以间接的降低这个页面上用户的流失率。微博的技术挑战和正交分解法解析架构 下面看一下 第三代的 架构 图 以及 我 们 怎么用正交分解法 阐 述。 我们可以看到我们从两个维度,横轴和纵轴可以看到。 一个 维 度 是 水平的 分层 拆分,第二从垂直的维度会做拆分。水平的维度从接口层、到服务层到数据存储层。垂直怎么拆分,会用业务架构、技术架构、监控平台、服务治理等等来处理。我相信到第二代的时候很多架构已经有了业务架构和技术架构的拆分。我们看一下, 接口层有feed、用户关系、通讯接口;服务层,SOA里有基层服务、原子服务和组合服务,在微博我们只有原子服务和组合服务。原子服务不依赖于任何其他服务,组合服务由几个原子服务和自己的业务逻辑构建而成 ,资源层负责海量数据的存储(后面例子会详细讲)。技 术框架解决 独立于 业务 的海量高并发场景下的技术难题,由众多的技术组件共同构建而成 。在接口层,微博使用JERSY框架,帮助你做参数的解析,参数的验证,序列化和反序列化;资源层,主要是缓存、DB相关的各类组件,比如Cache组件和对象库组件。监 控平台和服 务 治理 , 完成系统服务的像素级监控,对分布式系统做提前诊断、预警以及治理。包含了SLA规则的制定、服务监控、服务调用链监控、流量监控、错误异常监控、线上灰度发布上线系统、线上扩容缩容调度系统等。 下面我们讲一下常见的设计原则。 第一个,首先是系统架构三个利器: 一个, 我 们 RPC 服 务组 件 (这里不讲了), 第二个,我们 消息中 间 件 。消息中间件起的作用:可以把两个模块之间的交互异步化,其次可以把不均匀请求流量输出为匀速的输出流量,所以说消息中间件 异步化 解耦 和流量削峰的利器。 第三个是配置管理,它是 代码级灰度发布以及 保障系统降级的利器。 第二个 , 无状态 , 接口 层 最重要的就是无状 态。我们在电商网站购物,在这个过程中很多情况下是有状态的,比如我浏览了哪些商品,为什么大家又常说接口层是无状态的,其实我们把状态从接口层剥离到了数据层。像用户在电商网站购物,选了几件商品,到了哪一步,接口无状态后,状态要么放在缓存中,要么放在数据库中, 其 实 它并不是没有状 态 , 只是在 这 个 过 程中我 们 要把一些有状 态 的 东 西抽离出来 到了数据层。 第三个, 数据 层 比服 务层 更需要 设计,这是一条非常重要的经验。对于服务层来说,可以拿PHP写,明天你可以拿JAVA来写,但是如果你的数据结构开始设计不合理,将来数据结构的改变会花费你数倍的代价,老的数据格式向新的数据格式迁移会让你痛不欲生,既有工作量上的,又有数据迁移跨越的时间周期,有一些甚至需要半年以上。 第四,物理结构与逻辑结构的映射,上一张图看到两个维度切成十二个区间,每个区间代表一个技术领域,这个可以看做我们的逻辑结构。另外,不论后台还是应用层的开发团队,一般都会分几个垂直的业务组加上一个基础技术架构组,这就是从物理组织架构到逻辑的技术架构的完美的映射,精细化团队分工,有利于提高沟通协作的效率 。 第五, www .sanhao.com 的访问过程,我们这个架构图里没有涉及到的,举个例子,比如当你在浏览器输入www.sanhao网址的时候,这个请求在接口层之前发生了什么?首先会查看你本机DNS以及DNS服务,查找域名对应的IP地址,然后发送HTTP请求过去。这个请求首先会到前端的VIP地址(公网服务IP地址),VIP之后还要经过负载均衡器(Nginx服务器),之后才到你的应用接口层。在接口层之前发生了这么多事,可能有用户报一个问题的时候,你通过在接口层查日志根本发现不了问题,原因就是问题可能发生在到达接口层之前了。 第六,我们说分布式系统,它最终的瓶颈会落在哪里呢?前端时间有一个网友跟我讨论的时候,说他们的系统遇到了一个瓶颈, 查遍了CPU,内存,网络,存储,都没有问题。我说你再查一遍,因为最终你不论用上千台服务器还是上万台服务器,最终系统出瓶颈的一定会落在某一台机(可能是叶子节点也可能是核心的节点),一定落在CPU、内存、存储和网络上,最后查出来问题出在一台服务器的网卡带宽上。微博多级双机房缓存架构 接下来我们看一下微博的Feed多级缓存。我们做业务的时候,经常很少做业务分析,技术大会上的分享又都偏向技术架构。其实大家更多的日常工作是需要花费更多时间在业务优化上。这张图是统计微博的信息流前几页的访问比例,像前三页占了97%,在做缓存设计的时候,我们最多只存最近的M条数据。 这里强调的就是做系统设计 要基于用 户 的 场 景 , 越细致越好 。举了一个例子,大家都会用电商,电商在双十一会做全国范围内的活动,他们做设计的时候也会考虑场景的,一个就是购物车,我曾经跟相关开发讨论过,购物车是在双十一之前用户的访问量非常大,就是不停地往里加商品。在真正到双十一那天他不会往购物车加东西了,但是他会频繁的浏览购物车。针对这个场景,活动之前重点设计优化购物车的写场景, 活动开始后优化购物车的读场景。 你看到的微博是由哪些部分聚合而成的呢?最右边的是Feed,就是微博所有关注的人,他们的微博所组成的。微博我们会按照时间顺序把所有关注人的顺序做一个排序。随着业务的发展,除了跟时间序相关的微博还有非时间序的微博,就是会有广告的要求,增加一些广告,还有粉丝头条,就是拿钱买的,热门微博,都会插在其中。分发控制,就是说和一些推荐相关的,我推荐一些相关的好友的微博,我推荐一些你可能没有读过的微博,我推荐一些其他类型的微博。 当然对非时序的微博和分发控制微博,实际会起多个并行的程序来读取,最后同步做统一的聚合。这里稍微分享一下, 从SNS社交领域来看,国内现在做的比较好的三个信息流: 微博 是 基于弱关系的媒体信息流 ; 朋友圈是基于 强 关系的信息流 ; 另外一个做的比 较 好的就是今日 头 条 , 它并不是基于关系来构建信息流 , 而是基于 兴趣和相关性的个性化推荐 信息流 。 信息流的聚合,体现在很多很多的产品之中,除了SNS,电商里也有信息流的聚合的影子。比如搜索一个商品后出来的列表页,它的信息流基本由几部分组成:第一,打广告的;第二个,做一些推荐,热门的商品,其次,才是关键字相关的搜索结果。 信息流 开始的时候 很 简单 , 但是到后期会 发现 , 你的 这 个流 如何做控制分发 , 非常复杂, 微博在最近一两年一直在做 这样 的工作。刚才我们是从业务上分析,那么技术上怎么解决高并发,高性能的问题?微博访问量很大的时候,底层存储是用MySQL数据库,当然也会有其他的。对于查询请求量大的时候,大家知道一定有缓存,可以复用可重用的计算结果。可以看到,发一条微博,我有很多粉丝,他们都会来看我发的内容,所以 微博是最适合使用 缓 存 的系统,微博的读写比例基本在几十比一。微博使用了 双 层缓 存,上面是L1,每个L1上都是一组(包含4-6台机器),左边的框相当于一个机房,右边又是一个机房。在这个系统中L1缓存所起的作用是什么? 首先,L1 缓 存增加整个系 统 的 QPS, 其次 以低成本灵活扩容的方式 增加 系统 的 带宽 。想象一个极端场景,只有一篇博文,但是它的访问量无限增长,其实我们不需要影响L2缓存,因为它的内容存储的量小,但它就是访问量大。这种场景下,你就需要使用L1来扩容提升QPS和带宽瓶颈。另外一个场景,就是L2级缓存发生作用,比如我有一千万个用户,去访问的是一百万个用户的微博 ,这个时候,他不只是说你的吞吐量和访问带宽,就是你要缓存的博文的内容也很多了,这个时候你要考虑缓存的容量, 第二 级缓 存更多的是从容量上来 规划,保证请求以较小的比例 穿透到 后端的 数据 库 中 ,根据你的用户模型你可以估出来,到底有百分之多少的请求不能穿透到DB, 评估这个容量之后,才能更好的评估DB需要多少库,需要承担多大的访问的压力。另外,我们看双机房的话,左边一个,右边一个。 两个机房是互 为 主 备 , 或者互 为热备 。如果两个用户在不同地域,他们访问两个不同机房的时候,假设用户从IDC1过来,因为就近原理,他会访问L1,没有的话才会跑到Master,当在IDC1没找到的时候才会跑到IDC2来找。同时有用户从IDC2访问,也会有请求从L1和Master返回或者到IDC1去查找。 IDC1 和 IDC2 ,两个机房都有全量的用户数据,同时在线提供服务,但是缓存查询又遵循最近访问原理。还有哪些多级缓存的例子呢?CDN是典型的多级缓存。CDN在国内各个地区做了很多节点,比如在杭州市部署一个节点时,在机房里肯定不止一台机器,那么对于一个地区来说,只有几台服务器到源站回源,其他节点都到这几台服务器回源即可,这么看CDN至少也有两级。Local Cache+ 分布式 缓 存,这也是常见的一种策略。有一种场景,分布式缓存并不适用, 比如 单 点 资 源 的爆发性峰值流量,这个时候使用Local Cache + 分布式缓存,Local Cache 在 应用 服 务 器 上用很小的 内存资源 挡住少量的 极端峰值流量,长尾的流量仍然访问分布式缓存,这样的Hybrid缓存架构通过复用众多的应用服务器节点,降低了系统的整体成本。 我们来看一下 Feed 的存 储 架构,微博的博文主要存在MySQL中。首先来看内容表,这个比较简单,每条内容一个索引,每天建一张表,其次看索引表,一共建了两级索引。首先想象一下用户场景,大部分用户刷微博的时候,看的是他关注所有人的微博,然后按时间来排序。仔细分析发现在这个场景下, 跟一个用户的自己的相关性很小了。所以在一级索引的时候会先根据关注的用户,取他们的前条微博ID,然后聚合排序。我们在做哈希(分库分表)的时候,同时考虑了按照UID哈希和按照时间维度。很业务和时间相关性很高的,今天的热点新闻,明天就没热度了,数据的冷热非常明显,这种场景就需要按照时间维度做分表,首先冷热数据做了分离(可以对冷热数据采用不同的存储方案来降低成本),其次, 很容止控制我数据库表的爆炸。像微博如果只按照用户维度区分,那么这个用户所有数据都在一张表里,这张表就是无限增长的,时间长了查询会越来越慢。二级索引,是我们里面一个比较特殊的场景,就是我要快速找到这个人所要发布的某一时段的微博时,通过二级索引快速定位。 分布式服务追踪系统 分布式追踪服务系统,当系统到千万级以后的时候,越来越庞杂,所解决的问题更偏向稳定性,性能和监控。刚才说用户只要有一个请求过来,你可以依赖你的服务RPC1、RPC2,你会发现RPC2又依赖RPC3、RPC4。分布式服务的时候一个痛点,就是说一个请求从用户过来之后,在后台不同的机器之间不停的调用并返回。 当你发现一个问题的时候,这些日志落在不同的机器上,你也不知道问题到底出在哪儿,各个服务之间互相隔离,互相之间没有建立关联。所以导致排查问题基本没有任何手段,就是出了问题没法儿解决。 我们要解决的问题,我们刚才说日志互相隔离,我们就要把它建立联系。建立联系我们就有一个请求ID,然后结合RPC框架, 服务治理功能。假设请求从客户端过来,其中包含一个ID 101,到服务A时仍然带有ID 101,然后调用RPC1的时候也会标识这是101 ,所以需要 一个唯一的 请求 ID 标识 递归迭代的传递到每一个 相关 节点。第二个,你做的时候,你不能说每个地方都加,对业务系统来说需要一个框架来完成这个工作, 这 个框架要 对业务 系 统 是最低侵入原 则 , 用 JAVA 的 话 就可以用 AOP,要做到零侵入的原则,就是对所有相关的中间件打点,从接口层组件(HTTP Client、HTTP Server)至到服务层组件(RPC Client、RPC Server),还有数据访问中间件的,这样业务系统只需要少量的配置信息就可以实现全链路监控 。为什么要用日志?服务化以后,每个服务可以用不同的开发语言, 考虑多种开发语言的兼容性 , 内部定 义标 准化的日志 是唯一且有效的办法。最后,如何构建基于GPS导航的路况监控?我们刚才讲分布式服务追踪。分布式服务追踪能解决的问题, 如果 单一用 户发现问题 后 , 可以通 过请 求 ID 快速找到 发 生 问题 的 节 点在什么,但是并没有解决如何发现问题。我们看现实中比较容易理解的道路监控,每辆车有GPS定位,我想看北京哪儿拥堵的时候,怎么做? 第一个 , 你肯定要知道每个 车 在什么位置,它走到哪儿了。其实可以说每个车上只要有一个标识,加上每一次流动的信息,就可以看到每个车流的位置和方向。 其次如何做 监 控和 报 警,我们怎么能了解道路的流量状况和负载,并及时报警。我们要定义这条街道多宽多高,单位时间可以通行多少辆车,这就是道路的容量。有了道路容量,再有道路的实时流量,我们就可以基于实习路况做预警? 对应于 分布式系 统 的话如何构建? 第一 , 你要 定义 每个服 务节 点它的 SLA A 是多少 ?SLA可以从系统的CPU占用率、内存占用率、磁盘占用率、QPS请求数等来定义,相当于定义系统的容量。 第二个 , 统计 线 上 动态 的流量,你要知道服务的平均QPS、最低QPS和最大QPS,有了流量和容量,就可以对系统做全面的监控和报警。 刚才讲的是理论,实际情况肯定比这个复杂。微博在春节的时候做许多活动,必须保障系统稳定,理论上你只要定义容量和流量就可以。但实际远远不行,为什么?有技术的因素,有人为的因素,因为不同的开发定义的流量和容量指标有主观性,很难全局量化标准,所以真正流量来了以后,你预先评估的系统瓶颈往往不正确。实际中我们在春节前主要采取了三个措施:第一,最简单的就是有降 级 的 预 案,流量超过系统容量后,先把哪些功能砍掉,需要有明确的优先级 。第二个, 线上全链路压测,就是把现在的流量放大到我们平常流量的五倍甚至十倍(比如下线一半的服务器,缩容而不是扩容),看看系统瓶颈最先发生在哪里。我们之前有一些例子,推测系统数据库会先出现瓶颈,但是实测发现是前端的程序先遇到瓶颈。第三,搭建在线 Docker 集群 , 所有业务共享备用的 Docker集群资源,这样可以极大的避免每个业务都预留资源,但是实际上流量没有增长造成的浪费。 总结 接下来说的是如何不停的学习和提升,这里以Java语言为例,首先, 一定要 理解 JAVA;第二步,JAVA完了以后,一定要 理 解 JVM;其次,还要 理解 操作系统;再次还是要了解一下 Design Pattern,这将告诉你怎么把过去的经验抽象沉淀供将来借鉴;还要学习 TCP/IP、 分布式系 统、数据结构和算法。

hiekay 2019-12-02 01:39:25 0 浏览量 回答数 0

问题

10个迷惑新手的Cocoa,Objective-c开发难点和问题? 400 报错

爱吃鱼的程序员 2020-05-31 00:44:29 0 浏览量 回答数 1

回答

转自:阿里云官网 — 知乎 写好代码,阿里专家沉淀了一套“如何写复杂业务代码”的方法论,在此分享给大家,相信同样的方法论可以复制到大部分复杂业务场景。 一文教会你如何写复杂业务代码 了解我的人都知道,我一直在致力于应用架构和代码复杂度的治理。 这两天在看零售通商品域的代码。面对零售通如此复杂的业务场景,如何在架构和代码层面进行应对,是一个新课题。针对该命题,我进行了比较细致的思考和研究。结合实际的业务场景,我沉淀了一套“如何写复杂业务代码”的方法论,在此分享给大家。 我相信,同样的方法论可以复制到大部分复杂业务场景。 一个复杂业务的处理过程 业务背景 简单的介绍下业务背景,零售通是给线下小店供货的B2B模式,我们希望通过数字化重构传统供应链渠道,提升供应链效率,为新零售助力。阿里在中间是一个平台角色,提供的是Bsbc中的service的功能。 在商品域,运营会操作一个“上架”动作,上架之后,商品就能在零售通上面对小店进行销售了。是零售通业务非常关键的业务操作之一,因此涉及很多的数据校验和关联操作。 针对上架,一个简化的业务流程如下所示: 过程分解 像这么复杂的业务,我想应该没有人会写在一个service方法中吧。一个类解决不了,那就分治吧。 说实话,能想到分而治之的工程师,已经做的不错了,至少比没有分治思维要好很多。我也见过复杂程度相当的业务,连分解都没有,就是一堆方法和类的堆砌。 不过,这里存在一个问题:即很多同学过度的依赖工具或是辅助手段来实现分解。比如在我们的商品域中,类似的分解手段至少有3套以上,有自制的流程引擎,有依赖于数据库配置的流程处理: 本质上来讲,这些辅助手段做的都是一个pipeline的处理流程,没有其它。因此,我建议此处最好保持KISS(Keep It Simple and Stupid),即最好是什么工具都不要用,次之是用一个极简的Pipeline模式,最差是使用像流程引擎这样的重方法。 除非你的应用有极强的流程可视化和编排的诉求,否则我非常不推荐使用流程引擎等工具。第一,它会引入额外的复杂度,特别是那些需要持久化状态的流程引擎;第二,它会割裂代码,导致阅读代码的不顺畅。大胆断言一下,全天下估计80%对流程引擎的使用都是得不偿失的。 回到商品上架的问题,这里问题核心是工具吗?是设计模式带来的代码灵活性吗?显然不是,问题的核心应该是如何分解问题和抽象问题,知道金字塔原理的应该知道,此处,我们可以使用结构化分解将问题解构成一个有层级的金字塔结构: 按照这种分解写的代码,就像一本书,目录和内容清晰明了。以商品上架为例,程序的入口是一个上架命令(OnSaleCommand), 它由三个阶段(Phase)组成。 @Command public class OnSaleNormalItemCmdExe { @Resource private OnSaleContextInitPhase onSaleContextInitPhase; @Resource private OnSaleDataCheckPhase onSaleDataCheckPhase; @Resource private OnSaleProcessPhase onSaleProcessPhase; @Override public Response execute(OnSaleNormalItemCmd cmd) { OnSaleContext onSaleContext = init(cmd); checkData(onSaleContext); process(onSaleContext); return Response.buildSuccess(); } private OnSaleContext init(OnSaleNormalItemCmd cmd) { return onSaleContextInitPhase.init(cmd); } private void checkData(OnSaleContext onSaleContext) { onSaleDataCheckPhase.check(onSaleContext); } private void process(OnSaleContext onSaleContext) { onSaleProcessPhase.process(onSaleContext); } } 每个Phase又可以拆解成多个步骤(Step),以OnSaleProcessPhase为例,它是由一系列Step组成的: @Phase public class OnSaleProcessPhase { @Resource private PublishOfferStep publishOfferStep; @Resource private BackOfferBindStep backOfferBindStep; //省略其它step public void process(OnSaleContext onSaleContext){ SupplierItem supplierItem = onSaleContext.getSupplierItem(); // 生成OfferGroupNo generateOfferGroupNo(supplierItem); // 发布商品 publishOffer(supplierItem); // 前后端库存绑定 backoffer域 bindBackOfferStock(supplierItem); // 同步库存路由 backoffer域 syncStockRoute(supplierItem); // 设置虚拟商品拓展字段 setVirtualProductExtension(supplierItem); // 发货保障打标 offer域 markSendProtection(supplierItem); // 记录变更内容ChangeDetail recordChangeDetail(supplierItem); // 同步供货价到BackOffer syncSupplyPriceToBackOffer(supplierItem); // 如果是组合商品打标,写扩展信息 setCombineProductExtension(supplierItem); // 去售罄标 removeSellOutTag(offerId); // 发送领域事件 fireDomainEvent(supplierItem); // 关闭关联的待办事项 closeIssues(supplierItem); } } 看到了吗,这就是商品上架这个复杂业务的业务流程。需要流程引擎吗?不需要,需要设计模式支撑吗?也不需要。对于这种业务流程的表达,简单朴素的组合方法模式(Composed Method)是再合适不过的了。 因此,在做过程分解的时候,我建议工程师不要把太多精力放在工具上,放在设计模式带来的灵活性上。而是应该多花时间在对问题分析,结构化分解,最后通过合理的抽象,形成合适的阶段(Phase)和步骤(Step)上。 过程分解后的两个问题的确,使用过程分解之后的代码,已经比以前的代码更清晰、更容易维护了。不过,还有两个问题值得我们去关注一下: 1、领域知识被割裂肢解什么叫被肢解? 因为我们到目前为止做的都是过程化拆解,导致没有一个聚合领域知识的地方。每个Use Case的代码只关心自己的处理流程,知识没有沉淀。相同的业务逻辑会在多个Use Case中被重复实现,导致代码重复度高,即使有复用,最多也就是抽取一个util,代码对业务语义的表达能力很弱,从而影响代码的可读性和可理解性。 2、代码的业务表达能力缺失 试想下,在过程式的代码中,所做的事情无外乎就是取数据--做计算--存数据,在这种情况下,要如何通过代码显性化的表达我们的业务呢? 说实话,很难做到,因为我们缺失了模型,以及模型之间的关系。脱离模型的业务表达,是缺少韵律和灵魂的。 举个例子,在上架过程中,有一个校验是检查库存的,其中对于组合品(CombineBackOffer)其库存的处理会和普通品不一样。原来的代码是这么写的: boolean isCombineProduct = supplierItem.getSign().isCombProductQuote(); // supplier.usc warehouse needn't check if (WarehouseTypeEnum.isAliWarehouse(supplierItem.getWarehouseType())) { // quote warehosue check if (CollectionUtil.isEmpty(supplierItem.getWarehouseIdList()) && !isCombineProduct) { throw ExceptionFactory.makeFault(ServiceExceptionCode.SYSTEM_ERROR, "亲,不能发布Offer,请联系仓配运营人员,建立品仓关系!"); } // inventory amount check Long sellableAmount = 0L; if (!isCombineProduct) { sellableAmount = normalBiz.acquireSellableAmount(supplierItem.getBackOfferId(), supplierItem.getWarehouseIdList()); } else { //组套商品 OfferModel backOffer = backOfferQueryService.getBackOffer(supplierItem.getBackOfferId()); if (backOffer != null) { sellableAmount = backOffer.getOffer().getTradeModel().getTradeCondition().getAmountOnSale(); } } if (sellableAmount < 1) { throw ExceptionFactory.makeFault(ServiceExceptionCode.SYSTEM_ERROR, "亲,实仓库存必须大于0才能发布,请确认已补货.\r[id:" + supplierItem.getId() + "]"); } } 然而,如果我们在系统中引入领域模型之后,其代码会简化为如下: if(backOffer.isCloudWarehouse()){ return; } if (backOffer.isNonInWarehouse()){ throw new BizException("亲,不能发布Offer,请联系仓配运营人员,建立品仓关系!"); } if (backOffer.getStockAmount() < 1){ throw new BizException("亲,实仓库存必须大于0才能发布,请确认已补货.\r[id:" + backOffer.getSupplierItem().getCspuCode() + "]"); } 有没有发现,使用模型的表达要清晰易懂很多,而且也不需要做关于组合品的判断了,因为我们在系统中引入了更加贴近现实的对象模型(CombineBackOffer继承BackOffer),通过对象的多态可以消除我们代码中的大部分的if-else。 过程分解+对象模型 通过上面的案例,我们可以看到有过程分解要好于没有分解,过程分解+对象模型要好于仅仅是过程分解。对于商品上架这个case,如果采用过程分解+对象模型的方式,最终我们会得到一个如下的系统结构: 写复杂业务的方法论 通过上面案例的讲解,我想说,我已经交代了复杂业务代码要怎么写:即自上而下的结构化分解+自下而上的面向对象分析。 接下来,让我们把上面的案例进行进一步的提炼,形成一个可落地的方法论,从而可以泛化到更多的复杂业务场景。 上下结合 所谓上下结合,是指我们要结合自上而下的过程分解和自下而上的对象建模,螺旋式的构建我们的应用系统。这是一个动态的过程,两个步骤可以交替进行、也可以同时进行。这两个步骤是相辅相成的,上面的分析可以帮助我们更好的理清模型之间的关系,而下面的模型表达可以提升我们代码的复用度和业务语义表达能力。其过程如下图所示: 使用这种上下结合的方式,我们就有可能在面对任何复杂的业务场景,都能写出干净整洁、易维护的代码。 能力下沉 一般来说实践DDD有两个过程: 1. 套概念阶段 了解了一些DDD的概念,然后在代码中“使用”Aggregation Root,Bonded Context,Repository等等这些概念。更进一步,也会使用一定的分层策略。然而这种做法一般对复杂度的治理并没有多大作用。 2. 融会贯通阶段 术语已经不再重要,理解DDD的本质是统一语言、边界划分和面向对象分析的方法。 大体上而言,我大概是在1.7的阶段,因为有一个问题一直在困扰我,就是哪些能力应该放在Domain层,是不是按照传统的做法,将所有的业务都收拢到Domain上,这样做合理吗?说实话,这个问题我一直没有想清楚。 因为在现实业务中,很多的功能都是用例特有的(Use case specific)的,如果“盲目”的使用Domain收拢业务并不见得能带来多大的益处。相反,这种收拢会导致Domain层的膨胀过厚,不够纯粹,反而会影响复用性和表达能力。 鉴于此,我最近的思考是我们应该采用能力下沉的策略。 所谓的能力下沉,是指我们不强求一次就能设计出Domain的能力,也不需要强制要求把所有的业务功能都放到Domain层,而是采用实用主义的态度,即只对那些需要在多个场景中需要被复用的能力进行抽象下沉,而不需要复用的,就暂时放在App层的Use Case里就好了。 注:Use Case是《架构整洁之道》里面的术语,简单理解就是响应一个Request的处理过程 通过实践,我发现这种循序渐进的能力下沉策略,应该是一种更符合实际、更敏捷的方法。因为我们承认模型不是一次性设计出来的,而是迭代演化出来的。 下沉的过程如下图所示,假设两个use case中,我们发现uc1的step3和uc2的step1有类似的功能,我们就可以考虑让其下沉到Domain层,从而增加代码的复用性。 指导下沉有两个关键指标:代码的复用性和内聚性。 复用性是告诉我们When(什么时候该下沉了),即有重复代码的时候。 内聚性是告诉我们How(要下沉到哪里),功能有没有内聚到恰当的实体上,有没有放到合适的层次上(因为Domain层的能力也是有两个层次的,一个是Domain Service这是相对比较粗的粒度,另一个是Domain的Model这个是最细粒度的复用)。 比如,在我们的商品域,经常需要判断一个商品是不是最小单位,是不是中包商品。像这种能力就非常有必要直接挂载在Model上。 public class CSPU { private String code; private String baseCode; //省略其它属性 /** * 单品是否为最小单位。 * */ public boolean isMinimumUnit(){ return StringUtils.equals(code, baseCode); } /** * 针对中包的特殊处理 * */ public boolean isMidPackage(){ return StringUtils.equals(code, midPackageCode); } } 之前,因为老系统中没有领域模型,没有CSPU这个实体。你会发现像判断单品是否为最小单位的逻辑是以StringUtils.equals(code, baseCode)的形式散落在代码的各个角落。这种代码的可理解性是可想而知的,至少我在第一眼看到这个代码的时候,是完全不知道什么意思。 业务技术要怎么做 写到这里,我想顺便回答一下很多业务技术同学的困惑,也是我之前的困惑:即业务技术到底是在做业务,还是做技术?业务技术的技术性体现在哪里? 通过上面的案例,我们可以看到业务所面临的复杂性并不亚于底层技术,要想写好业务代码也不是一件容易的事情。 业务技术和底层技术人员唯一的区别是他们所面临的问题域不一样。业务技术面对的问题域变化更多、面对的人更加庞杂。而底层技术面对的问题域更加稳定、但对技术的要求更加深。比如,如果你需要去开发Pandora,你就要对Classloader有更加深入的了解才行。 但是,不管是业务技术还是底层技术人员,有一些思维和能力都是共通的。比如,分解问题的能力,抽象思维,结构化思维等等。 用我的话说就是:“做不好业务开发的,也做不好技术底层开发,反之亦然。业务开发一点都不简单,只是我们很多人把它做“简单”了因此,如果从变化的角度来看,业务技术的难度一点不逊色于底层技术,其面临的挑战甚至更大。 因此,我想对广大的从事业务技术开发的同学说:沉下心来,夯实自己的基础技术能力、OO能力、建模能力... 不断提升抽象思维、结构化思维、思辨思维... 持续学习精进,写好代码。我们可以在业务技术岗做的很”技术“!。

茶什i 2020-01-10 11:53:44 0 浏览量 回答数 0

回答

初识 MyBatis MyBatis 是第一个支持自定义 SQL、存储过程和高级映射的类持久框架。MyBatis 消除了大部分 JDBC 的样板代码、手动设置参数以及检索结果。MyBatis 能够支持简单的 XML 和注解配置规则。使 Map 接口和 POJO 类映射到数据库字段和记录。 MyBatis 的特点 那么 MyBatis 具有什么特点呢?或许我们可以从如下几个方面来描述 MyBatis 中的 SQL 语句和主要业务代码分离,我们一般会把 MyBatis 中的 SQL 语句统一放在 XML 配置文件中,便于统一维护。 解除 SQL 与程序代码的耦合,通过提供 DAO 层,将业务逻辑和数据访问逻辑分离,使系统的设计更清晰,更易维护,更易单元测试。SQL 和代码的分离,提高了可维护性。 MyBatis 比较简单和轻量 本身就很小且简单。没有任何第三方依赖,只要通过配置 jar 包,或者如果你使用 Maven 项目的话只需要配置 Maven 以来就可以。易于使用,通过文档和源代码,可以比较完全的掌握它的设计思路和实现。 屏蔽样板代码 MyBatis 回屏蔽原始的 JDBC 样板代码,让你把更多的精力专注于 SQL 的书写和属性-字段映射上。 编写原生 SQL,支持多表关联 MyBatis 最主要的特点就是你可以手动编写 SQL 语句,能够支持多表关联查询。 提供映射标签,支持对象与数据库的 ORM 字段关系映射 ORM 是什么?对象关系映射(Object Relational Mapping,简称ORM) ,是通过使用描述对象和数据库之间映射的元数据,将面向对象语言程序中的对象自动持久化到关系数据库中。本质上就是将数据从一种形式转换到另外一种形式。 提供 XML 标签,支持编写动态 SQL。 你可以使用 MyBatis XML 标签,起到 SQL 模版的效果,减少繁杂的 SQL 语句,便于维护。 MyBatis 整体架构 MyBatis 最上面是接口层,接口层就是开发人员在 Mapper 或者是 Dao 接口中的接口定义,是查询、新增、更新还是删除操作;中间层是数据处理层,主要是配置 Mapper -> XML 层级之间的参数映射,SQL 解析,SQL 执行,结果映射的过程。上述两种流程都由基础支持层来提供功能支撑,基础支持层包括连接管理,事务管理,配置加载,缓存处理等。 接口层 在不与Spring 集成的情况下,使用 MyBatis 执行数据库的操作主要如下: InputStream is = Resources.getResourceAsStream("myBatis-config.xml"); SqlSessionFactoryBuilder builder = new SqlSessionFactoryBuilder(); SqlSessionFactory factory = builder.build(is); sqlSession = factory.openSession(); 其中的SqlSessionFactory,SqlSession是 MyBatis 接口的核心类,尤其是 SqlSession,这个接口是MyBatis 中最重要的接口,这个接口能够让你执行命令,获取映射,管理事务。 数据处理层 配置解析 在 Mybatis 初始化过程中,会加载 mybatis-config.xml 配置文件、映射配置文件以及 Mapper 接口中的注解信息,解析后的配置信息会形成相应的对象并保存到 Configration 对象中。之后,根据该对象创建SqlSessionFactory 对象。待 Mybatis 初始化完成后,可以通过 SqlSessionFactory 创建 SqlSession 对象并开始数据库操作。 SQL 解析与 scripting 模块 Mybatis 实现的动态 SQL 语句,几乎可以编写出所有满足需要的 SQL。 Mybatis 中 scripting 模块会根据用户传入的参数,解析映射文件中定义的动态 SQL 节点,形成数据库能执行的SQL 语句。 SQL 执行 SQL 语句的执行涉及多个组件,包括 MyBatis 的四大核心,它们是: Executor、StatementHandler、ParameterHandler、ResultSetHandler。SQL 的执行过程可以用下面这幅图来表示 MyBatis 层级结构各个组件的介绍(这里只是简单介绍,具体介绍在后面): SqlSession: ,它是 MyBatis 核心 API,主要用来执行命令,获取映射,管理事务。接收开发人员提供 Statement Id 和参数。并返回操作结果。Executor :执行器,是 MyBatis 调度的核心,负责 SQL 语句的生成以及查询缓存的维护。StatementHandler : 封装了JDBC Statement 操作,负责对 JDBC Statement 的操作,如设置参数、将Statement 结果集转换成 List 集合。ParameterHandler : 负责对用户传递的参数转换成 JDBC Statement 所需要的参数。ResultSetHandler : 负责将 JDBC 返回的 ResultSet 结果集对象转换成 List 类型的集合。TypeHandler : 用于 Java 类型和 JDBC 类型之间的转换。MappedStatement : 动态 SQL 的封装SqlSource : 表示从 XML 文件或注释读取的映射语句的内容,它创建将从用户接收的输入参数传递给数据库的 SQL。Configuration: MyBatis 所有的配置信息都维持在 Configuration 对象之中。 基础支持层 反射模块 Mybatis 中的反射模块,对 Java 反射进行了很好的封装,提供了简易的 API,方便上层调用,并且对反射操作进行了一系列的优化,比如,缓存了类的 元数据(MetaClass)和对象的元数据(MetaObject),提高了反射操作的性能。 类型转换模块 Mybatis 的别名机制,能够简化配置文件,该机制是类型转换模块的主要功能之一。类型转换模块的另一个功能是实现 JDBC 类型与 Java 类型的转换。在 SQL 语句绑定参数时,会将数据由 Java 类型转换成 JDBC 类型;在映射结果集时,会将数据由 JDBC 类型转换成 Java 类型。 日志模块 在 Java 中,有很多优秀的日志框架,如 Log4j、Log4j2、slf4j 等。Mybatis 除了提供了详细的日志输出信息,还能够集成多种日志框架,其日志模块的主要功能就是集成第三方日志框架。 资源加载模块 该模块主要封装了类加载器,确定了类加载器的使用顺序,并提供了加载类文件和其它资源文件的功能。 解析器模块 该模块有两个主要功能:一个是封装了 XPath,为 Mybatis 初始化时解析 mybatis-config.xml配置文件以及映射配置文件提供支持;另一个为处理动态 SQL 语句中的占位符提供支持。 数据源模块 Mybatis 自身提供了相应的数据源实现,也提供了与第三方数据源集成的接口。数据源是开发中的常用组件之一,很多开源的数据源都提供了丰富的功能,如连接池、检测连接状态等,选择性能优秀的数据源组件,对于提供ORM 框架以及整个应用的性能都是非常重要的。 事务管理模块 一般地,Mybatis 与 Spring 框架集成,由 Spring 框架管理事务。但 Mybatis 自身对数据库事务进行了抽象,提供了相应的事务接口和简单实现。 缓存模块 Mybatis 中有一级缓存和二级缓存,这两级缓存都依赖于缓存模块中的实现。但是需要注意,这两级缓存与Mybatis 以及整个应用是运行在同一个 JVM 中的,共享同一块内存,如果这两级缓存中的数据量较大,则可能影响系统中其它功能,所以需要缓存大量数据时,优先考虑使用 Redis、Memcache 等缓存产品。 Binding 模块 在调用 SqlSession 相应方法执行数据库操作时,需要制定映射文件中定义的 SQL 节点,如果 SQL 中出现了拼写错误,那就只能在运行时才能发现。为了能尽早发现这种错误,Mybatis 通过 Binding 模块将用户自定义的Mapper 接口与映射文件关联起来,系统可以通过调用自定义 Mapper 接口中的方法执行相应的 SQL 语句完成数据库操作,从而避免上述问题。注意,在开发中,我们只是创建了 Mapper 接口,而并没有编写实现类,这是因为 Mybatis 自动为 Mapper 接口创建了动态代理对象。 MyBatis 核心组件 在认识了 MyBatis 并了解其基础架构之后,下面我们来看一下 MyBatis 的核心组件,就是这些组件实现了从 SQL 语句到映射到 JDBC 再到数据库字段之间的转换,执行 SQL 语句并输出结果集。首先来认识 MyBatis 的第一个核心组件 SqlSessionFactory 对于任何框架而言,在使用该框架之前都要经历过一系列的初始化流程,MyBatis 也不例外。MyBatis 的初始化流程如下 String resource = "org/mybatis/example/mybatis-config.xml"; InputStream inputStream = Resources.getResourceAsStream(resource); SqlSessionFactory sqlSessionFactory = new SqlSessionFactoryBuilder().build(inputStream); sqlSessionFactory.openSession(); 上述流程中比较重要的一个对象就是SqlSessionFactory,SqlSessionFactory 是 MyBatis 框架中的一个接口,它主要负责的是 MyBatis 框架初始化操作 为开发人员提供SqlSession 对象 SqlSessionFactory 有两个实现类,一个是 SqlSessionManager 类,一个是 DefaultSqlSessionFactory 类 DefaultSqlSessionFactory : SqlSessionFactory 的默认实现类,是真正生产会话的工厂类,这个类的实例的生命周期是全局的,它只会在首次调用时生成一个实例(单例模式),就一直存在直到服务器关闭。 SqlSessionManager : 已被废弃,原因大概是: SqlSessionManager 中需要维护一个自己的线程池,而使用MyBatis 更多的是要与 Spring 进行集成,并不会单独使用,所以维护自己的 ThreadLocal 并没有什么意义,所以 SqlSessionManager 已经不再使用。 ####SqlSessionFactory 的执行流程 下面来对 SqlSessionFactory 的执行流程来做一个分析 首先第一步是 SqlSessionFactory 的创建 SqlSessionFactory sqlSessionFactory = new SqlSessionFactoryBuilder().build(inputStream); 1 从这行代码入手,首先创建了一个 SqlSessionFactoryBuilder 工厂,这是一个建造者模式的设计思想,由 builder 建造者来创建 SqlSessionFactory 工厂 然后调用 SqlSessionFactoryBuilder 中的 build 方法传递一个InputStream 输入流,Inputstream 输入流中就是你传过来的配置文件 mybatis-config.xml,SqlSessionFactoryBuilder 根据传入的 InputStream 输入流和environment、properties属性创建一个XMLConfigBuilder对象。SqlSessionFactoryBuilder 对象调用XMLConfigBuilder 的parse()方法,流程如下。 XMLConfigBuilder 会解析/configuration标签,configuration 是 MyBatis 中最重要的一个标签,下面流程会介绍 Configuration 标签。 MyBatis 默认使用 XPath 来解析标签,关于 XPath 的使用,参见 https://www.w3school.com.cn/xpath/index.asp 在 parseConfiguration 方法中,会对各个在 /configuration 中的标签进行解析 重要配置 说一下这些标签都是什么意思吧 properties,外部属性,这些属性都是可外部配置且可动态替换的,既可以在典型的 Java 属性文件中配置,亦可通过 properties 元素的子元素来传递。 <properties> <property name="driver" value="com.mysql.jdbc.Driver" /> <property name="url" value="jdbc:mysql://localhost:3306/test" /> <property name="username" value="root" /> <property name="password" value="root" /> </properties> 一般用来给 environment 标签中的 dataSource 赋值 <environment id="development"> <transactionManager type="JDBC" /> <dataSource type="POOLED"> <property name="driver" value="${driver}" /> <property name="url" value="${url}" /> <property name="username" value="${username}" /> <property name="password" value="${password}" /> </dataSource> </environment> 还可以通过外部属性进行配置,但是我们这篇文章以原理为主,不会介绍太多应用层面的操作。 settings ,MyBatis 中极其重要的配置,它们会改变 MyBatis 的运行时行为。 settings 中配置有很多,具体可以参考 https://mybatis.org/mybatis-3/zh/configuration.html#settings 详细了解。这里介绍几个平常使用过程中比较重要的配置 一般使用如下配置 <settings> <setting name="cacheEnabled" value="true"/> <setting name="lazyLoadingEnabled" value="true"/> </settings> typeAliases,类型别名,类型别名是为 Java 类型设置的一个名字。 它只和 XML 配置有关。 <typeAliases> <typeAlias alias="Blog" type="domain.blog.Blog"/> </typeAliases> 当这样配置时,Blog 可以用在任何使用 domain.blog.Blog 的地方。 typeHandlers,类型处理器,无论是 MyBatis 在预处理语句(PreparedStatement)中设置一个参数时,还是从结果集中取出一个值时, 都会用类型处理器将获取的值以合适的方式转换成 Java 类型。 在 org.apache.ibatis.type 包下有很多已经实现好的 TypeHandler,可以参考如下 你可以重写类型处理器或创建你自己的类型处理器来处理不支持的或非标准的类型。 具体做法为:实现 org.apache.ibatis.type.TypeHandler 接口, 或继承一个很方便的类 org.apache.ibatis.type.BaseTypeHandler, 然后可以选择性地将它映射到一个 JDBC 类型。 objectFactory,对象工厂,MyBatis 每次创建结果对象的新实例时,它都会使用一个对象工厂(ObjectFactory)实例来完成。默认的对象工厂需要做的仅仅是实例化目标类,要么通过默认构造方法,要么在参数映射存在的时候通过参数构造方法来实例化。如果想覆盖对象工厂的默认行为,则可以通过创建自己的对象工厂来实现。 public class ExampleObjectFactory extends DefaultObjectFactory { public Object create(Class type) { return super.create(type); } public Object create(Class type, List constructorArgTypes, List constructorArgs) { return super.create(type, constructorArgTypes, constructorArgs); } public void setProperties(Properties properties) { super.setProperties(properties); } public boolean isCollection(Class type) { return Collection.class.isAssignableFrom(type); } } 然后需要在 XML 中配置此对象工厂 <objectFactory type="org.mybatis.example.ExampleObjectFactory"> <property name="someProperty" value="100"/> </objectFactory> plugins,插件开发,插件开发是 MyBatis 设计人员给开发人员留给自行开发的接口,MyBatis 允许你在已映射语句执行过程中的某一点进行拦截调用。MyBatis 允许使用插件来拦截的方法调用包括:Executor、ParameterHandler、ResultSetHandler、StatementHandler 接口,这几个接口也是 MyBatis 中非常重要的接口,我们下面会详细介绍这几个接口。 environments,MyBatis 环境配置,MyBatis 可以配置成适应多种环境,这种机制有助于将 SQL 映射应用于多种数据库之中。例如,开发、测试和生产环境需要有不同的配置;或者想在具有相同 Schema 的多个生产数据库中 使用相同的 SQL 映射。 这里注意一点,虽然 environments 可以指定多个环境,但是 SqlSessionFactory 只能有一个,为了指定创建哪种环境,只要将它作为可选的参数传递给 SqlSessionFactoryBuilder 即可。 SqlSessionFactory factory = new SqlSessionFactoryBuilder().build(reader, environment); SqlSessionFactory factory = new SqlSessionFactoryBuilder().build(reader, environment, properties); databaseIdProvider ,数据库厂商标示,MyBatis 可以根据不同的数据库厂商执行不同的语句,这种多厂商的支持是基于映射语句中的 databaseId 属性。 <databaseIdProvider type="DB_VENDOR"> <property name="SQL Server" value="sqlserver"/> <property name="DB2" value="db2"/> <property name="Oracle" value="oracle" /> </databaseIdProvider> mappers,映射器,这是告诉 MyBatis 去哪里找到这些 SQL 语句,mappers 映射配置有四种方式 上面的一个个属性都对应着一个解析方法,都是使用 XPath 把标签进行解析,解析完成后返回一个 DefaultSqlSessionFactory 对象,它是 SqlSessionFactory 的默认实现类。这就是 SqlSessionFactoryBuilder 的初始化流程,通过流程我们可以看到,初始化流程就是对一个个 /configuration 标签下子标签的解析过程。 SqlSession 在 MyBatis 初始化流程结束,也就是 SqlSessionFactoryBuilder -> SqlSessionFactory 的获取流程后,我们就可以通过 SqlSessionFactory 对象得到 SqlSession 然后执行 SQL 语句了。具体来看一下这个过程‘ 在 SqlSessionFactory.openSession 过程中我们可以看到,会调用到 DefaultSqlSessionFactory 中的 openSessionFromDataSource 方法,这个方法主要创建了两个与我们分析执行流程重要的对象,一个是 Executor 执行器对象,一个是 SqlSession 对象。执行器我们下面会说,现在来说一下 SqlSession 对象 SqlSession 对象是 MyBatis 中最重要的一个对象,这个接口能够让你执行命令,获取映射,管理事务。SqlSession 中定义了一系列模版方法,让你能够执行简单的 CRUD 操作,也可以通过 getMapper 获取 Mapper 层,执行自定义 SQL 语句,因为 SqlSession 在执行 SQL 语句之前是需要先开启一个会话,涉及到事务操作,所以还会有 commit、 rollback、close 等方法。这也是模版设计模式的一种应用。 MapperProxy MapperProxy 是 Mapper 映射 SQL 语句的关键对象,我们写的 Dao 层或者 Mapper 层都是通过 MapperProxy 来和对应的 SQL 语句进行绑定的。下面我们就来解释一下绑定过程 这就是 MyBatis 的核心绑定流程,我们可以看到 SqlSession 首先调用 getMapper 方法,我们刚才说到 SqlSession 是大哥级别的人物,只定义标准(有一句话是怎么说的来着,一流的企业做标准,二流的企业做品牌,三流的企业做产品)。 SqlSession 不愿意做的事情交给 Configuration 这个手下去做,但是 Configuration 也是有小弟的,它不愿意做的事情直接甩给小弟去做,这个小弟是谁呢?它就是 MapperRegistry,马上就到核心部分了。MapperRegistry 相当于项目经理,项目经理只从大面上把握项目进度,不需要知道手下的小弟是如何工作的,把任务完成了就好。最终真正干活的还是 MapperProxyFactory。看到这段代码 Proxy.newProxyInstance ,你是不是有一种恍然大悟的感觉,如果你没有的话,建议查阅一下动态代理的文章,这里推荐一篇 (https://www.jianshu.com/p/95970b089360) 也就是说,MyBatis 中 Mapper 和 SQL 语句的绑定正是通过动态代理来完成的。 通过动态代理,我们就可以方便的在 Dao 层或者 Mapper 层定义接口,实现自定义的增删改查操作了。那么具体的执行过程是怎么样呢?上面只是绑定过程,别着急,下面就来探讨一下 SQL 语句的执行过程。 MapperProxyFactory 会生成代理对象,这个对象就是 MapperProxy,最终会调用到 mapperMethod.execute 方法,execute 方法比较长,其实逻辑比较简单,就是判断是 插入、更新、删除 还是 查询 语句,其中如果是查询的话,还会判断返回值的类型,我们可以点进去看一下都是怎么设计的。 很多代码其实可以忽略,只看我标出来的重点就好了,我们可以看到,不管你前面经过多少道关卡处理,最终都逃不过 SqlSession 这个老大制定的标准。 我们以 selectList 为例,来看一下下面的执行过程。 这是 DefaultSqlSession 中 selectList 的代码,我们可以看到出现了 executor,这是什么呢?我们下面来解释。 Executor 还记得我们之前的流程中提到了 Executor(执行器) 这个概念吗?我们来回顾一下它第一次出现的位置。 由 Configuration 对象创建了一个 Executor 对象,这个 Executor 是干嘛的呢?下面我们就来认识一下 Executor 的继承结构 每一个 SqlSession 都会拥有一个 Executor 对象,这个对象负责增删改查的具体操作,我们可以简单的将它理解为 JDBC 中 Statement 的封装版。 也可以理解为 SQL 的执行引擎,要干活总得有一个发起人吧,可以把 Executor 理解为发起人的角色。 首先先从 Executor 的继承体系来认识一下 如上图所示,位于继承体系最顶层的是 Executor 执行器,它有两个实现类,分别是BaseExecutor和 CachingExecutor。 BaseExecutor 是一个抽象类,这种通过抽象的实现接口的方式是适配器设计模式之接口适配 的体现,是Executor 的默认实现,实现了大部分 Executor 接口定义的功能,降低了接口实现的难度。BaseExecutor 的子类有三个,分别是 SimpleExecutor、ReuseExecutor 和 BatchExecutor。 SimpleExecutor : 简单执行器,是 MyBatis 中默认使用的执行器,每执行一次 update 或 select,就开启一个Statement 对象,用完就直接关闭 Statement 对象(可以是 Statement 或者是 PreparedStatment 对象) ReuseExecutor : 可重用执行器,这里的重用指的是重复使用 Statement,它会在内部使用一个 Map 把创建的Statement 都缓存起来,每次执行 SQL 命令的时候,都会去判断是否存在基于该 SQL 的 Statement 对象,如果存在 Statement 对象并且对应的 connection 还没有关闭的情况下就继续使用之前的 Statement 对象,并将其缓存起来。因为每一个 SqlSession 都有一个新的 Executor 对象,所以我们缓存在 ReuseExecutor 上的 Statement作用域是同一个 SqlSession。 BatchExecutor : 批处理执行器,用于将多个 SQL 一次性输出到数据库 CachingExecutor: 缓存执行器,先从缓存中查询结果,如果存在就返回之前的结果;如果不存在,再委托给Executor delegate 去数据库中取,delegate 可以是上面任何一个执行器。 Executor 的创建和选择 我们上面提到 Executor 是由 Configuration 创建的,Configuration 会根据执行器的类型创建,如下 这一步就是执行器的创建过程,根据传入的 ExecutorType 类型来判断是哪种执行器,如果不指定 ExecutorType ,默认创建的是简单执行器。它的赋值可以通过两个地方进行赋值: 可以通过 标签来设置当前工程中所有的 SqlSession 对象使用默认的 Executor <settings> <!--取值范围 SIMPLE, REUSE, BATCH --> <setting name="defaultExecutorType" value="SIMPLE"/> </settings> 另外一种直接通过Java对方法赋值的方式 session = factory.openSession(ExecutorType.BATCH); Executor 的具体执行过程 Executor 中的大部分方法的调用链其实是差不多的,下面是深入源码分析执行过程,如果你没有时间或者暂时不想深入研究的话,给你下面的执行流程图作为参考。 我们紧跟着上面的 selectList 继续分析,它会调用到 executor.query 方法。 当有一个查询请求访问的时候,首先会经过 Executor 的实现类 CachingExecutor ,先从缓存中查询 SQL 是否是第一次执行,如果是第一次执行的话,那么就直接执行 SQL 语句,并创建缓存,如果第二次访问相同的 SQL 语句的话,那么就会直接从缓存中提取。 上面这段代码是从 selectList -> 从缓存中 query 的具体过程。可能你看到这里有些觉得类都是什么东西,我想鼓励你一下,把握重点,不用每段代码都看,从找到 SQL 的调用链路,其他代码想看的时候在看,看源码就是很容易发蒙,容易烦躁,但是切记一点,把握重点。 上面代码会判断缓存中是否有这条 SQL 语句的执行结果,如果没有的话,就再重新创建 Executor 执行器执行 SQL 语句,注意, list = doQuery 是真正执行 SQL 语句的过程,这个过程中会创建我们上面提到的三种执行器,这里我们使用的是简单执行器。 到这里,执行器所做的工作就完事了,Executor 会把后续的工作交给 StatementHandler 继续执行。下面我们来认识一下 StatementHandler 上面代码会判断缓存中是否有这条 SQL 语句的执行结果,如果没有的话,就再重新创建 Executor 执行器执行 SQL 语句,注意, list = doQuery 是真正执行 SQL 语句的过程,这个过程中会创建我们上面提到的三种执行器,这里我们使用的是简单执行器。 到这里,执行器所做的工作就完事了,Executor 会把后续的工作交给 StatementHandler 继续执行。下面我们来认识一下 StatementHandler StatementHandler 的继承结构 有没有感觉和 Executor 的继承体系很相似呢?最顶级接口是四大组件对象,分别有两个实现类 BaseStatementHandler 和 RoutingStatementHandler,BaseStatementHandler 有三个实现类, 他们分别是 SimpleStatementHandler、PreparedStatementHandler 和 CallableStatementHandler。 RoutingStatementHandler : RoutingStatementHandler 并没有对 Statement 对象进行使用,只是根据StatementType 来创建一个代理,代理的就是对应Handler的三种实现类。在MyBatis工作时,使用的StatementHandler 接口对象实际上就是 RoutingStatementHandler 对象。 BaseStatementHandler : 是 StatementHandler 接口的另一个实现类,它本身是一个抽象类,用于简化StatementHandler 接口实现的难度,属于适配器设计模式体现,它主要有三个实现类 SimpleStatementHandler: 管理 Statement 对象并向数据库中推送不需要预编译的SQL语句。PreparedStatementHandler: 管理 Statement 对象并向数据中推送需要预编译的SQL语句。CallableStatementHandler:管理 Statement 对象并调用数据库中的存储过程。 StatementHandler 的创建和源码分析 我们继续来分析上面 query 的调用链路,StatementHandler 的创建过程如下 MyBatis 会根据 SQL 语句的类型进行对应 StatementHandler 的创建。我们以预处理 StatementHandler 为例来讲解一下 执行器不仅掌管着 StatementHandler 的创建,还掌管着创建 Statement 对象,设置参数等,在创建完 PreparedStatement 之后,我们需要对参数进行处理了。 如 如果用一副图来表示一下这个执行流程的话我想是这样 这里我们先暂停一下,来认识一下第三个核心组件 ParameterHandler ParameterHandler - ParameterHandler 介绍 ParameterHandler 相比于其他的组件就简单很多了,ParameterHandler 译为参数处理器,负责为 PreparedStatement 的 sql 语句参数动态赋值,这个接口很简单只有两个方法 ParameterHandler 只有一个实现类 DefaultParameterHandler , 它实现了这两个方法。 getParameterObject: 用于读取参数setParameters: 用于对 PreparedStatement 的参数赋值ParameterHandler 的解析过程 上面我们讨论过了 ParameterHandler 的创建过程,下面我们继续上面 parameterSize 流程 这就是具体参数的解析过程了,下面我们来描述一下 下面用一个流程图表示一下 ParameterHandler 的解析过程,以简单执行器为例 我们在完成 ParameterHandler 对 SQL 参数的预处理后,回到 SimpleExecutor 中的 doQuery 方法 上面又引出来了一个重要的组件那就是 ResultSetHandler,下面我们来认识一下这个组件 ResultSetHandler - ResultSetHandler 简介 ResultSetHandler 也是一个非常简单的接口 ResultSetHandler 是一个接口,它只有一个默认的实现类,像是 ParameterHandler 一样,它的默认实现类是DefaultResultSetHandler ResultSetHandler 解析过程 MyBatis 只有一个默认的实现类就是 DefaultResultSetHandler,DefaultResultSetHandler 主要负责处理两件事 处理 Statement 执行后产生的结果集,生成结果列表 处理存储过程执行后的输出参数 按照 Mapper 文件中配置的 ResultType 或 ResultMap 来封装成对应的对象,最后将封装的对象返回即可。 其中涉及的主要对象有: ResultSetWrapper : 结果集的包装器,主要针对结果集进行的一层包装,它的主要属性有 ResultSet : Java JDBC ResultSet 接口表示数据库查询的结果。 有关查询的文本显示了如何将查询结果作为java.sql.ResultSet 返回。 然后迭代此ResultSet以检查结果。 TypeHandlerRegistry: 类型注册器,TypeHandlerRegistry 在初始化的时候会把所有的 Java类型和类型转换器进行注册。 ColumnNames: 字段的名称,也就是查询操作需要返回的字段名称 ClassNames: 字段的类型名称,也就是 ColumnNames 每个字段名称的类型 JdbcTypes: JDBC 的类型,也就是 java.sql.Types 类型 ResultMap: 负责处理更复杂的映射关系 在 DefaultResultSetHandler 中处理完结果映射,并把上述结构返回给调用的客户端,从而执行完成一条完整的SQL语句。 内容转载自:CSDN博主:cxuann 原文链接:https://blog.csdn.net/qq_36894974/article/details/104132876?depth_1-utm_source=distribute.pc_feed.none-task&request_id=&utm_source=distribute.pc_feed.none-task

问问小秘 2020-03-05 15:44:27 0 浏览量 回答数 0

回答

有编程能力和数据挖掘能力的工程师最火,包括:数据挖掘工程师、机器学习工程师,算法工程师。 今年3月份时,谷歌开发的人工智能AlphaGo打败了全球最顶尖的围棋高手,轰动全世界,AI时代正式拉开序幕。实际上,人工智能这一概念早在上世纪一大批科幻小说陆续发表时,就已被人们接受,而随着科技的发展,人工智能的发展前景更是日益清晰。一个人工智能的诞生需要无数个工程师挥洒汗水。其中,负责开发学习算法、使机器能像人类一样思考问题的数据挖掘工程师更是无比重要。什么人能完成人工智能的开发任务呢。必须指出,人工智能和一般的计算机程序有极大的差别,它应当具有“能够自主学习知识”这一特点,这一特点也被称为“机器学习”。而自学习模型(或者说机器学习能力开发)正是数据挖掘工程师的强项,人工智能的诞生和普及需要一大批数据挖掘工程师。  那么在AI时代,如何才能掌握相关的技能,成为企业需要的数据挖掘人才呢。 第一个门槛是数学 首先,机器学习的第一个门槛是数学知识。机器学习算法需要的数学知识集中在微积分、线性代数和概率与统计当中,具有本科理工科专业的同学对这些知识应该不陌生,如果你已经还给了老师,我还是建议你通过自学或大数据学习社区补充相关知识。所幸的是如果只是想合理应用机器学习算法,而不是做相关方向高精尖的研究,需要的数学知识啃一啃教科书还是基本能理解下来的。 第二个门槛是编程 跨过了第一步,就是如何动手解决问题。所谓工欲善其事必先利其器,如果没有工具,那么所有的材料和框架、逻辑、思路都给你,也寸步难行。因此我们还是得需要合适的编程语言、工具和环境帮助自己在数据集上应用机器学习算法。对于有计算机编程基础的初学者而言,Python是很好的入门语言,很容易上手,同时又活跃的社区支持,丰富的工具包帮助我们完成想法。没有编程基础的同学掌握R或者平台自带的一些脚本语言也是不错的选择。 Make your hands dirty 接下来就是了解机器学习的工作流程和掌握常见的算法。一般机器学习步骤包括: 数据建模:将业务问题抽象为数学问题; 数据获取:获取有代表性的数据,如果数据量太大,需要考虑分布式存储和管理; 特征工程:包括特征预处理与特征选择两个核心步骤,前者主要是做数据清洗,好的数据清洗过程可以使算法的效果和性能得到显著提高,这一步体力活多一些,也比较耗时,但也是非常关键的一个步骤。特征选择对业务理解有一定要求,好的特征工程会降低对算法和数据量的依赖。 模型调优:所谓的训练数据都是在这个环节处理的,简单的说就是通过迭代分析和参数优化使上述所建立的特征工程是最优的。 这些工作流程主要是工程实践上总结出的一些经验。并不是每个项目都包含完整的一个流程,只有大家自己多实践,多积累项目经验,才会有自己更深刻的认识。 翻过了数学和编程两座大山,就是如何实践的问题,其中一个捷径就是积极参加国内外各种数据挖掘竞赛。国外的Kaggle和国内的阿里天池比赛都是很好的平台,你可以在上面获取真实的数据和队友们一起学习和进行竞赛,尝试使用已经学过的所有知识来完成这个比赛本身也是一件很有乐趣的事情。 另外就是企业实习,可以先从简单的统计分析和数据清洗开始做起,积累自己对数据的感觉,同时了解企业的业务需求和生产环境。我们通常讲从事数据科学的要”Make your hands dirty”,就是说要通过多接触数据加深对数据和业务的理解,好厨子都是食材方面的专家,你不和你的“料”打交道,怎么能谈的上去应用好它。 摆脱学习的误区 初学机器学习可能有一个误区,就是一上来就陷入到对各种高大上算法的追逐当中。动不动就讨论我能不能用深度学习去解决这个问题啊。实际上脱离业务和数据的算法讨论是毫无意义的。上文中已经提到,好的特征工程会大大降低对算法和数据量的依赖,与其研究算法,不如先厘清业务问题。任何一个问题都可以用最传统的的算法,先完整的走完机器学习的整个工作流程,不断尝试各种算法深挖这些数据的价值,在运用过程中把数据、特征和算法搞透。真正积累出项目经验才是最快、最靠谱的学习路径。 自学还是培训 很多人在自学还是参加培训上比较纠结。我是这么理解的,上述过程中数学知识需要在本科及研究生阶段完成,离开学校的话基本上要靠自学才能补充这方面的知识,所以建议那些还在学校里读书并且有志于从事数据挖掘工作的同学在学校把数学基础打好,书到用时方恨少,希望大家珍惜在学校的学习时间。 除了数学以外,很多知识的确可以通过网络搜索的方式自学,但前提是你是否拥有超强的自主学习能力,通常拥有这种能力的多半是学霸,他们能够跟据自己的情况,找到最合适的学习资料和最快学习成长路径。如果你不属于这一类人,那么参加职业培训也许是个不错的选择,在老师的带领下可以走少很多弯路。另外任何学习不可能没有困难,也就是学习道路上的各种沟沟坎坎,通过老师的答疑解惑,可以让你轻松迈过这些障碍,尽快实现你的“小”目标。 机器学习这个领域想速成是不太可能的,但是就入门来说,如果能有人指点一二还是可以在短期内把这些经典算法都过一遍,这番学习可以对机器学习的整体有个基本的理解,从而尽快进入到这个领域。师傅领进门,修行靠个人,接下来就是如何钻进去了,好在现在很多开源库给我们提供了实现的方法,我们只需要构造基本的算法框架就可以了,大家在学习过程中应当尽可能广的学习机器学习的经典算法。 学习资料 至于机器学习的资料网上很多,大家可以找一下,我个人推荐李航老师的《统计机器学习》和周志华老师的《机器学习》这两门书,前者理论性较强,适合数学专业的同学,后者读起来相对轻松一些,适合大多数理工科专业的同学。

管理贝贝 2019-12-02 01:21:46 0 浏览量 回答数 0

问题

【精品问答】Java实战200例(附源码)

珍宝珠 2020-02-14 11:55:46 16104 浏览量 回答数 10

回答

排序(Sorting) 是计算机程序设计中的一种重要操作,它的功能是将一个数据元素(或记录)的任意序列,重新排列成一个关键字有序的序列。稳定度(稳定性)一个排序算法是稳定的,就是当有两个相等记录的关键字R和S,且在原本的列表中R出现在S之前,在排序过的列表中R也将会是在S之前。当相等的元素是无法分辨的,比如像是整数,稳定度并不是一个问题。然而,假设以下的数对将要以他们的第一个数字来排序。(4,1)(3,1)(3,7)(5,6)在这个状况下,有可能产生两种不同的结果,一个是依照相等的键值维持相对的次序,而另外一个则没有:(3,1)(3,7)(4,1)(5,6) (维持次序)(3,7)(3,1)(4,1)(5,6) (次序被改变)不稳定排序算法可能会在相等的键值中改变纪录的相对次序,但是稳定排序算法从来不会如此。不稳定排序算法可以被特别地实现为稳定。作这件事情的一个方式是人工扩充键值的比较,如此在其他方面相同键值的两个对象间之比较,就会被决定使用在原先数据次序中的条目,当作一个同分决赛。然而,要记住这种次序通常牵涉到额外的空间负担。在计算机科学所使用的排序算法通常被分类为:(a)计算的复杂度(最差、平均、和最好性能),依据列表(list)的大小(n)。一般而言,好的性能是 O(nlogn),且坏的性能是 O(n^2)。对于一个排序理想的性能是 O(n)。而仅使用一个抽象关键比较运算的排序算法总平均上总是至少需要 O(nlogn)。(b)存储器使用量(空间复杂度)(以及其他电脑资源的使用)(c)稳定度:稳定的排序算法会依照相等的关键(换言之就是值)维持纪录的相对次序。(d)一般的方法:插入、交换、选择、合并等等。交换排序包含冒泡排序和快速排序。插入排序包含希尔排序,选择排序包括堆排序等。

小哇 2019-12-02 01:17:19 0 浏览量 回答数 0

回答

快不了。 广义上的数据挖掘工程师还包括算法工程师、机器学习工程师、深度学习工程师等,这些职位负责建立和优化算法模型,并进行算法的工程化实施。一般来说,数据挖掘有两个门槛: 第一个门槛是数学 首先,机器学习的第一个门槛是数学知识。机器学习算法需要的数学知识集中在微积分、线性代数和概率与统计当中,具有本科理工科专业的同学对这些知识应该不陌生,如果你已经还给了老师,我还是建议你通过自学或大数据学习社区补充相关知识。所幸的是如果只是想合理应用机器学习算法,而不是做相关方向高精尖的研究,需要的数学知识啃一啃教科书还是基本能理解下来的。 第二个门槛是编程 跨过了第一步,就是如何动手解决问题。所谓工欲善其事必先利其器,如果没有工具,那么所有的材料和框架、逻辑、思路都给你,也寸步难行。因此我们还是得需要合适的编程语言、工具和环境帮助自己在数据集上应用机器学习算法。对于有计算机编程基础的初学者而言,Python是很好的入门语言,很容易上手,同时又活跃的社区支持,丰富的工具包帮助我们完成想法。没有编程基础的同学掌握R或者平台自带的一些脚本语言也是不错的选择。 那么数据挖掘如何入行呢。我们的建议如下: Make your hands dirty 数据挖掘和机器学习的工作流程: 数据建模:将业务问题抽象为数学问题; 数据获取:获取有代表性的数据,如果数据量太大,需要考虑分布式存储和管理; 特征工程:包括特征预处理与特征选择两个核心步骤,前者主要是做数据清洗,好的数据清洗过程可以使算法的效果和性能得到显著提高,这一步体力活多一些,也比较耗时,但也是非常关键的一个步骤。特征选择对业务理解有一定要求,好的特征工程会降低对算法和数据量的依赖。 模型调优:所谓的训练数据都是在这个环节处理的,简单的说就是通过迭代分析和参数优化使上述所建立的特征工程是最优的。 这些工作流程主要是工程实践上总结出的一些经验。并不是每个项目都包含完整的一个流程,只有大家自己多实践,多积累项目经验,才会有自己更深刻的认识。 翻过了数学和编程两座大山,就是如何实践的问题,其中一个捷径就是积极参加国内外各种数据挖掘竞赛。国外的Kaggle和国内的阿里天池比赛都是很好的平台,你可以在上面获取真实的数据和队友们一起学习和进行竞赛,尝试使用已经学过的所有知识来完成这个比赛本身也是一件很有乐趣的事情。 另外就是企业实习,可以先从简单的统计分析和数据清洗开始做起,积累自己对数据的感觉,同时了解企业的业务需求和生产环境。我们通常讲从事数据科学的要”Make your hands dirty”,就是说要通过多接触数据加深对数据和业务的理解,好厨子都是食材方面的专家,你不和你的“料”打交道,怎么能谈的上去应用好它。 摆脱学习的误区 初学机器学习可能有一个误区,就是一上来就陷入到对各种高大上算法的追逐当中。动不动就讨论我能不能用深度学习去解决这个问题啊。实际上脱离业务和数据的算法讨论是毫无意义的。上文中已经提到,好的特征工程会大大降低对算法和数据量的依赖,与其研究算法,不如先厘清业务问题。任何一个问题都可以用最传统的的算法,先完整的走完机器学习的整个工作流程,不断尝试各种算法深挖这些数据的价值,在运用过程中把数据、特征和算法搞透。真正积累出项目经验才是最快、最靠谱的学习路径。 自学还是培训 很多人在自学还是参加培训上比较纠结。我是这么理解的,上述过程中数学知识需要在本科及研究生阶段完成,离开学校的话基本上要靠自学才能补充这方面的知识,所以建议那些还在学校里读书并且有志于从事数据挖掘工作的同学在学校把数学基础打好,书到用时方恨少,希望大家珍惜在学校的学习时间。 除了数学以外,很多知识的确可以通过网络搜索的方式自学,但前提是你是否拥有超强的自主学习能力,通常拥有这种能力的多半是学霸,他们能够跟据自己的情况,找到最合适的学习资料和最快学习成长路径。如果你不属于这一类人,那么参加职业培训(www.ppvke.com)也许是个不错的选择,在老师的带领下可以走少很多弯路。另外任何学习不可能没有困难,也就是学习道路上的各种沟沟坎坎,通过老师的答疑解惑,可以让你轻松迈过这些障碍,尽快实现你的“小”目标。 数据挖掘和机器学习这个领域想速成是不太可能的,但是就入门来说,如果能有人指点一二还是可以在短期内把这些经典算法都过一遍,这番学习可以对机器学习的整体有个基本的理解,从而尽快进入到这个领域。师傅领进门,修行靠个人,接下来就是如何钻进去了,好在现在很多开源库给我们提供了实现的方法,我们只需要构造基本的算法框架就可以了,大家在学习过程中应当尽可能广的学习机器学习的经典算法。 学习资料 至于机器学习的资料网上很多,大家可以找一下,我个人推荐李航老师的《统计机器学习》和周志华老师的《机器学习》这两门书,前者理论性较强,适合数学专业的同学,后者读起来相对轻松一些,适合大多数理工科专业的同学。 搜索“AI时代就业指南”可了解更多大数据相关职业规划信息------------------------- 楼上推荐的书,我只能呵呵了,把他介绍的两本看完你还是一头雾水。 数据挖掘:说白了,就是高级的回归,但残差已经没有假设分布了,衡量模型好坏也不用p值了,就是高级的回归技术(对于因变量是离散的情况,是高级的分类技术),当然还有无指导的机器学习方法。 数据挖掘一定要结合软件来学,目前国内这方面最新的比较精炼的书当推吴喜之的《复杂数据统计方法》,这本书是结合R软件来实现的,如果你想做应用,这本书配合R软件,结合回归分析和广义回归模型,我认为应该够用了。 如果你想做这方面的研究,那《统计学习基础》,范明翻译的,黑斯蒂写的这本书那是必须得看的,绝对的经典。建议买一本收藏。。

青衫无名 2019-12-02 01:21:43 0 浏览量 回答数 0

回答

我一直在做很多关于可用选项的阅读。我还亲自推荐了高性能MySQL第二版。 这是我设法拼凑而成的: 聚类 一般而言,集群是将负载分布在许多服务器上,这些服务器在外部应用程序中似乎是一台服务器。 MySQL NDB集群 MySQL NDB Cluster是一个具有同步复制和自动数据分割功能的分布式,无内存的,无共享的存储引擎(对不起,我从高性能书上借来的字面意思是,但它们放在那儿很好)。对于某些应用程序来说,这可能是一个高性能的解决方案,但是Web应用程序通常无法在其上很好地工作。 主要问题在于,除了非常简单的查询(仅涉及一个表)之外,群集通常还必须在多个节点上搜索数据,从而使网络延迟蔓延,并显着减慢查询的完成时间。由于该应用程序将群集视为一台计算机,因此无法告诉它从哪个节点获取数据。 此外,内存需求对于许多大型数据库而言并不可行。 连续红杉 这是MySQL的另一种群集解决方案,它充当MySQL服务器之上的中间件。它提供同步复制,负载平衡和故障转移。它还可以确保请求始终从最新副本中获取数据,并自动选择具有新数据的节点。 我读了一些不错的东西,总的来说,这听起来很有希望。 联邦 联合类似于集群,因此我也在这里进行了介绍。MySQL通过联合存储引擎提供联合。与NDB群集解决方案类似,它仅适用于简单查询-但对于复杂查询,群集甚至更糟(因为网络延迟要高得多)。 复制和负载平衡 MySQL具有在不同服务器上创建数据库复制的内置功能。这可用于许多用途-在服务器之间分配负载,热备份,创建测试服务器和故障转移。 复制的基本设置涉及一台主服务器主要处理写操作,而一个或多个从服务器仅处理读操作。master-master配置的更高级的变化是,它允许通过同时写入多个服务器来扩展写入。 每种配置都有其优缺点,但是它们共同面临的一个问题是复制滞后-由于MySQL复制是异步的,因此并非所有节点始终都具有最新数据。这要求应用程序了解复制,并结合复制感知查询才能按预期工作。对于某些应用程序来说,这可能不是问题,但是如果您始终需要最新的数据,事情就会变得有些复杂。 复制需要一些负载平衡以在节点之间分配负载。这可以像对应用程序代码进行某些修改一样简单,也可以使用专用的软件和硬件解决方案。 分片和分割 分片是扩展数据库解决方案的常用方法。您将数据拆分为较小的碎片,并将其散布在不同的服务器节点上。这需要应用程序知道对数据存储的修改才能有效地工作,因为它需要知道在哪里可以找到所需的信息。 有可用的抽象框架来帮助处理数据分片,例如Hibernate Shards,它是Hibernate ORM的扩展(不幸的是,它是Java的。我正在使用PHP)。HiveDB是另一个这样的解决方案,它也支持分片重新平衡。 其他 狮身人面像 Sphinx是全文搜索引擎,其功能远不止测试搜索。对于许多查询,它比MySQL快得多(尤其是对于分组和排序),并且可以并行查询远程系统并汇总结果-这使其在分片中非常有用。 通常,狮身人面像应与其他扩展解决方案一起使用,以获取更多可用的硬件和基础架构。不利的一面是,您再次需要应用程序代码来了解sphinx,以便明智地使用它。 摘要 伸缩解决方案因需要它的应用程序的需求而异。对于我们和大多数Web应用程序,我相信复制(可能是多主服务器)是负载平衡器分配负载的一种方式。为了能够水平扩展,还必须对特定问题区域(巨大的表)进行分片。 我还将对Continentant Sequoia进行一下测试,看看它是否能够真正实现它所承诺的目标,因为它将对应用程序代码进行的更改最少。来源:stack overflow

保持可爱mmm 2020-05-17 13:02:45 0 浏览量 回答数 0

问题

【Java学习全家桶】1460道Java热门问题,阿里百位技术专家答疑解惑

管理贝贝 2019-12-01 20:07:15 27612 浏览量 回答数 19

回答

你这个问题可以抽象一下。令每个用户和每个IP存在一个以时间轴为基础的登陆数组(一维,下标是历史时间到现在的时间差,值是对应时间片比如分钟内的总登陆次数)。需要有以下基准动作。 每个时间,比如分钟,对整个数组进行移动。 当有新登陆上来,检测整个时间窗内的登陆总次数,比如你的时间窗是30分钟。如果总次数超过你设定的K(30),则对其禁止T(30)。如果没有超过K(30),你对时间窗最后的数据,进行较窄窗口(例如10分钟)再判断。如果总次数超过 K(10) 则对其禁止T(10)。如果小于 K(10),则对最小窗口进行判断,例如10分钟,如果总次数超过K(1),则对其禁止 T(10)。 禁止过程中,该IP,该用户被直接否定,但是上述对应数组的内容,仍然根据时间进行移动修正。将较老的数据刷掉。 当然这个是原理算法。如果这个算法思路符合你的目标。则后续会需要有优化的简化算法。基本思路是压缩上述所谓“数组”的存储空间,以及压缩上述刷新和移动,判断的计算步骤。 上述具备IP和用户对应的数组是动态的。每分钟,刷新时,需要将即便下一分钟产生一次登陆但不存在禁止的数组给删除掉。 而所谓数组,是通过bit来描述,比如每4个bit表示当前的分钟内的登录次数,如果是15次以上,假设你一定会禁止他,则仍然等于15次。类似这样。 而在刷新左移时,对每个分钟的登陆次数,修正加权值,并反馈到最新存储空间内,此时所有的判断都集中在最新存储空间判断,而不用任意判断都要累加操作。这种近似的优化算法,只要能达到目的就可以了。没有必要考虑因为精度问题导致结果的不完全一致性。######回复 @waney : 其实很简单。但是我难得搞公式编辑器了。######好复杂 听不懂,谢谢你。###### 登陆验证码, 登陆验证问题, 同用户名访问失败多次直接封用户一段时间, 如果还是继续尝试失败,直接封IP。 以上为个人意见。######回复 @JustForFly : 因为discuz有这些,根本起不到作用。######那我就不知道你还想要什么了######discuz 这些都有的###### 增加验证码,可避免一些简单的模拟登录; 增加登录失败次数检查,超过N次后禁用用户或IP若干时间; ######discuz 都有的######直接把用户隐射到MAP,不用查数据库,直接查询MAP ######先把数据库的用户查出来,引射到一个map对象,然后用户登录就直接去map对象里面匹配,比如5分钟或者10分钟把在把map里面的用户和数据库同步一次,呵呵,这个办法有点傻。######这个怎讲?听不懂。######这个事情很麻烦,一楼的方法是有效的。但是是针对用户存在IP绑定信息的情况下。当然大多数时刻也是如此。如果抽象来看,楼主也说了,模拟提交,或者从不同IP上大量测试用户名的方式,回避一楼的方案。这个问题但抽象的来看,几乎无解,因为问题和设计目标是矛盾的。还要看楼主其他方面的需求。最终想防止什么。 ######回复 @waney : 延迟,如果发现不匹配,SERVER等待2到3秒后在告知客户端。但客户端会采用无论是否回复,仍然发送新用户方式。######回复 @中山野鬼 : ip是变化的,验证那些都没有用,如果拒绝这类特定请求的频率过高的。######回复 @waney : 两个方案。延迟,绑定IP的锁定。前者方法很多,那些图片内部字符识别本身就是个延迟目的。不是考智商用的。######有人模拟大量提交,匹配然后获得匹配正确的用户名和密码。###### 既然是字典匹配 那肯定会出现大量 同一账号使用不同的错误密码登陆的记录了.. 可以从这方面下手...我的方案是:当检测到某一账号在一段时间内连续输错密码达到一定次数 则帐号进入内部锁定状态.当该帐号成功登陆之后,将无法进行任何操作.而是会进入一个锁定页面. 系统会要求该帐号进行解锁操作.解锁成功后,才能继续操作. 至于解锁操作的话最简单就是发一封邮件给用户注册邮箱,用户根据邮件提示解锁. 这样即使别人凭字典匹配到了密码也没用.而且一旦用户登陆之后发现自己的帐号被锁定就知道肯定有人尝试破解自己帐号的密码.那么此时也可以提示用户修改密码.这样最大限度的可以保证帐号安全了。######而且我没说要禁止...只是帐号置为 内部锁定状态. 你只需要检测用户是否登陆的时候检测是否处于锁定状态就可以了. 基本上只需要加一个字段和一小段代码的######呵呵 如果别人第一次就匹配到了密码 你怎么能知道这个人是不是帐号的拥有者呢. 不可能有100% 完美解决的方案的.######你不能保证别人不会第一次就匹配到正确的啊。而且全都加入禁止,那量不是一般的大啊,所以 我想寻求一个彻底的办法就是如何设置条件抛弃这个请求。###### 当然 上述方法也有缺陷.如果有人恶意用错误的密码尝试登陆某一账号将导致该帐号的用户每次登陆都要进行解锁操作. 那么就还需要一些其他的补充措施来进行完善了.例如:可设置一段时间内 帐号禁止进入锁定状态。###### 楼主,你这个是个博弈的过程。主要策略是延缓对方或者将对方行为区别于正常用户。如果是绑定IP比如3,4次登陆就锁定1分钟,对方可以替换IP,只要IP数量N足够多。上限仍然由他的IP数量决定。 如果你认为1分钟内如果登陆4次以上,就锁定这个IP30分钟。他完全可以每个IP每分钟就登陆4次,则没分钟也达到了4万次的用户访问检测。 但攻击者的IP数量如果不是非常多时,你可以尝试累计对IP进行长时间累计滤波观测。如果一个IP在1分钟内登录4次,在5分钟内登陆 10次,在30分钟内登陆 20次,则均对其锁定。 这样的目的是降低攻击者独立IP的使用价值。以和传统用户行为区别开来。 我先吃饭。回头给你个算法描述,解决这种问题。动态时间窗内的信号检测。######谢谢。

kun坤 2020-06-08 11:25:44 0 浏览量 回答数 0

回答

回 24楼(無名塵客) 的帖子 目前MySQL 5.1首页的数据已经基本支持了,有部分性能数据在5.1这个版本拿不到,在实时性能里面的部分信息中会显示0,其余的功能基本正常。 ------------------------- 回 43楼(不羁的行者) 的帖子 目前你在命令行下输入rz命令是支持文件夹的,单独的文件上传功能,还没支持文件夹,可以多选,后续我们考虑支持下。 ------------------------- 回 52楼(fightgod) 的帖子 您好,目前DMS后端默认是6分钟,只要一直有操作DMS应该就不会断开,另外,关于断开在您的Linux服务器端也是有时间限制的,并非由DMS单方面控制。目前如果断开的话,焦点在该窗口,按任意键就会重新登录,不过会丢失您刚才操作的会话。 关于时间可能会带来体验上的问题,我们结合您的安全再考虑下怎么做会更好一些。 PS:隆重推荐刚上线的新功能:批量终端,相信大家的服务器都是多台集群来达到24*7的服务,当你要给多台机器同时配置信息、传文件、发命令,这将是你的利器。 ------------------------- 回 57楼(周枫枫) 的帖子 您应该是使用的VPC的网络吧,其实对于VPC这块,安全和方便使用一直是矛盾的,我们内部的产品有不少也遇到了很多的麻烦,也一直在探讨这两者的平衡点,近期关于VPC网络的数据库、ECS的访问解决方案,相关的团队有一些初步的结论,会尽快统一来解决这类问题,如果解决掉,理论上不需要EIP。 关于服务器分组的问题,我们也在考虑当中,其实去年就想做这一块,但是一直没太想清楚大家用分组的业务目的到底有那些类型,所以我们也期望于收集一些大家对于服务器管理的分组诉求是什么,然后进行抽象,关于这一点期待您的反馈。 ------------------------- 回 54楼(fightgod) 的帖子 请问一下,您在超过10台机器的情况下遇到了什么问题,或遇到了什么不方便的地方,或者说您期待10台以上是什么样子的管理方式,这样子我们可以给你进一步改进。 ------------------------- 回 66楼(fightgod) 的帖子 现在如果是对机器超过10台的情况,执行命令,可以有其它的方式了,界面上可以将屏幕缩小,最大可以一个界面看到16和主机屏幕,当然这个小界面肯定看到的内容会变少。切换窗口大小,在界面的右上角,如下图所示: ------------------------- 回 89楼(taoguba) 的帖子 命令窗口右下角,有一个小图标,点击下,可以调整很多内容的哦。 ------------------------- 回 97楼(zjdns) 的帖子 你好,关于收费方面来讲,其实这个产品发展有接近3年时间还没涉及到收费。 即便发生,对于绝大部分使用上的功能是肯定不会收费的,这一点是毋庸置疑的,例如MySQL:结构变更、SQL操作、数据管理、存储过程、函数等等这样的功能是 一定一定不会任何收费用的,因为这个产品最基本且不变的原则是希望您和您的团队能在云上方便地管理自己的数据库和服务器,且在这个过程中我们可以逐步通过在阿里的积累,为您和您的团队提供更多非云上环境所没有的服务,如果因为商业因素给您和您的团队在常规工作中带来很差的体验,那么这个产品就失去了意义。总体来讲,即使会出现这么一天,也是为了支撑团队长久为这个产品服务和发展提供营养,以更高、更专业的的标准来要求产品的品质。 ------------------------- 回 96楼(himan4) 的帖子 你好,关于DMS开源还暂时没有计划,请谅解! 产品目前处于快速发展阶段,功能上还有很多已经确定的方向在还不断拓展中(例如:结构对比、数据变化趋势、表级别DML日志、BI报表等),也许做得非常完善后经过公司同意是有可能,但目前确实是没有这个计划的,请您谅解! 关于私有网络的数据库能否在线上DMS来管理,DMS团队也在进行一些技术方案的探索(不需要开放公网端口,避免暴露内网的数据库),如果技术方案成熟,私有网络的数据库也是有可能可以通过线上DMS来服务的。 ------------------------- 回 100楼(寒喵) 的帖子 1、可以用的,DMS不限制用户使用什么账号登录,只要有权限即可。 2、另外关于sudo的问题,首先当前用户需要具备sudo的权限,DMS提供的命令终端几乎与客户端接近,所以该有的操作都有;如果是其它功能,例如文件可视化管理里面,在一些权限处理上存在问题,通常会提示然后确认后尝试使用sudo来操作。 ------------------------- Re:Re数据管理DMS-精华帖 引用第121楼pantian88于2017-11-23 10:22发表的 Re数据管理DMS-精华帖 : 我打开了几个控制页面,但多了就不知道那个面对应那个主机了,最好能够显示主机名 [url=https://bbs.aliyun.com/job.php?action=topost&tid=286015&pid=1756605][/url] 你是指在浏览器选项卡上显示主机名是吗?

钟隐 2019-12-02 02:01:31 0 浏览量 回答数 0

回答

关于二十四点游戏的编程思路与基本算法 漫长的假期对于我来说总是枯燥无味的,闲来无聊便和同学玩起童年时经常玩的二十四点牌游戏来。此游戏说来简单,就是利用加减乘除以及括号将给出的四张牌组成一个值为24的表达式。但是其中却不乏一些有趣的题目,这不,我们刚玩了一会儿,便遇到了一个难题——3、6、6、10(其实后来想想,这也不算是个太难的题,只是当时我们的脑筋都没有转弯而已,呵呵)。 问题既然出现了,我们当然要解决。冥思苦想之际,我的脑中掠过一丝念头——何不编个程序来解决这个问题呢。文曲星中不就有这样的程序吗。所以这个想法应该是可行。想到这里我立刻开始思索这个程序的算法,最先想到的自然是穷举法(后来发现我再也想不到更好的方法了,悲哀呀,呵呵),因为在这学期我曾经写过一个小程序——计算有括号的简单表达式。只要我能编程实现四个数加上运算符号所构成的表达式的穷举,不就可以利用这个计算程序来完成这个计算二十四点的程序吗。确定了这个思路之后,我开始想这个问题的细节。 首先穷举的可行性问题。我把表达式如下分成三类—— 1、 无括号的简单表达式。 2、 有一个括号的简单表达式。 3、 有两个括号的较复4、 杂表达式。 穷举的开始我对给出的四个数进行排列,其可能的种数为4*3*2*1=24。我利用一个嵌套函数实现四个数的排列,算法如下: /* ans[] 用来存放各种排列组合的数组 */ /* c[] 存放四张牌的数组 */ /* k[] c[]种四张牌的代号,其中k[I]=I+1。 用它来代替c[]做处理,考虑到c[]中有可能出现相同数的情况 */ /* kans[] 暂存生成的排列组合 */ /* j 嵌套循环的次数 */ int fans(c,k,ans,kans,j) int j,k[],c[];char ans[],kans[]; { int i,p,q,r,h,flag,s[4],t[4][4]; for(p=0,q=0;p<4;p++) { for(r=0,flag=0;r if(k[p]!=kans[r]) flag++; if(flag==j) t[j][q++]=k[p]; } for(s[j]=0;s[j]<4-j;s[j]++) { kans[j]=t[j][s[j>; if(j==3) { for(h=0;h<4;h++) ans[2*h]=c[kans[h]-1]; /* 调整生成的排列组合在最终的表 达式中的位置 */ for(h=0;h<3;h++) symbol(ans,h); /* 在表达式中添加运算符号 */ } else { j++; fans(c,k,ans,kans,j); j--; } } } 正如上面函数中提到的,在完成四张牌的排列之后,在表达式中添加运算符号。由于只有四张牌,所以只要添加三个运算符号就可以了。由于每一个运算符号可重复,所以计算出其可能的种数为4*4*4=64种。仍然利用嵌套函数实现添加运算符号的穷举,算法如下: /* ans[],j同上。sy[]存放四个运算符号。h为表达式形式。*/ int sans(ans,sy,j,h) char ans[],sy[];int j,h; { int i,p,k[3],m,n; char ktans[20]; for(k[j]=0;k[j]<4;k[j]++) { ans[2*j+1]=sy[k[j>; /* 刚才的四个数分别存放在0、2、4、6位 这里的三个运算符号分别存放在1、3、5位*/ if(j==2) { ans[5]=sy[k[j>; /* 此处根据不同的表达式形式再进行相应的处理 */ } else } } 好了,接下来我再考虑不同表达式的处理。刚才我已经将表达式分为三类,是因为添加三个括号对于四张牌来说肯定是重复的。对于第一种,无括号自然不用另行处理;而第二种情况由以下代码可以得出其可能性有六种,其中还有一种是多余的。 for(m=0;m<=4;m+=2) for(n=m+4;n<=8;n+=2) 这个for循环给出了添加一个括号的可能性的种数,其中m、n分别为添加在表达式中的左右括号的位置。我所说的多余的是指m=0,n=8,也就是放在表达式的两端。这真是多此一举,呵呵。最后一种情况是添加两个括号,我分析了一下,发现只可能是这种形式才不会是重复的——(a b)(c d)。为什么不会出现嵌套括号的情况呢。因为如果是嵌套括号,那么外面的括号肯定是包含三个数字的(四个没有必要),也就是说这个括号里面包含了两个运算符号,而这两个运算符号是被另外一个括号隔开的。那么如果这两个运算符号是同一优先级的,则肯定可以通过一些转换去掉括号(你不妨举一些例子来试试),也就是说这一个括号没有必要;如果这两个运算符号不是同一优先级,也必然是这种形式((a+-b)*/c)。而*和/在这几个运算符号中优先级最高,自然就没有必要在它的外面添加括号了。 综上所述,所有可能的表达式的种数为24*64*(1+6+1)=12288种。哈哈,只有一万多种可能性(这其中还有重复),这对于电脑来说可是小case哟。所以,对于穷举的可行性分析和实现也就完成了。 接下来的问题就是如何对有符号的简单表达式进行处理。这是栈的一个著名应用,那么什么是栈呢。栈的概念是从日常生活中货物在货栈种的存取过程抽象出来的,即最后存放入栈的货物(堆在靠出口处)先被提取出去,符合“先进后出,后进先出”的原则。这种结构犹如子弹夹。 在栈中,元素的插入称为压入(push)或入栈,元素的删除称为弹出(pop)或退栈。 栈的基本运算有三种,其中包括入栈运算、退栈运算以及读栈顶元素,这些请参考相关数据结构资料。根据这些基本运算就可以用数组模拟出栈来。 那么作为栈的著名应用,表达式的计算可以有两种方法。 第一种方法—— 首先建立两个栈,操作数栈OVS和运算符栈OPS。其中,操作数栈用来记忆表达式中的操作数,其栈顶指针为topv,初始时为空,即topv=0;运算符栈用来记忆表达式中的运算符,其栈顶指针为topp,初始时,栈中只有一个表达式结束符,即topp=1,且OPS(1)=‘;’。此处的‘;’即表达式结束符。 然后自左至右的扫描待处理的表达式,并假设当前扫描到的符号为W,根据不同的符号W做如下不同的处理: 1、 若W为操作数 2、 则将W压入操作数栈OVS 3、 且继续扫描下一个字符 4、 若W为运算符 5、 则根据运算符的性质做相应的处理: (1)、若运算符为左括号或者运算符的优先级大于运算符栈栈顶的运算符(即OPS(top)),则将运算符W压入运算符栈OPS,并继续扫描下一个字符。 (2)、若运算符W为表达式结束符‘;’且运算符栈栈顶的运算符也为表达式结束符(即OPS(topp)=’;’),则处理过程结束,此时,操作数栈栈顶元素(即OVS(topv))即为表达式的值。 (3)、若运算符W为右括号且运算符栈栈顶的运算符为左括号(即OPS(topp)=’(‘),则将左括号从运算符栈谈出,且继续扫描下一个符号。 (4)、若运算符的右不大于运算符栈栈顶的运算符(即OPS(topp)),则从操作数栈OVS中弹出两个操作数,设先后弹出的操作数为a、b,再从运算符栈OPS中弹出一个运算符,设为+,然后作运算a+b,并将运算结果压入操作数栈OVS。本次的运算符下次将重新考虑。 第二种方法—— 首先对表达式进行线性化,然后将线性表达式转换成机器指令序列以便进行求值。 那么什么是表达式的线性化呢。人们所习惯的表达式的表达方法称为中缀表示。中缀表示的特点是运算符位于运算对象的中间。但这种表示方式,有时必须借助括号才能将运算顺序表达清楚,而且处理也比较复杂。 1929年,波兰逻辑学家Lukasiewicz提出一种不用括号的逻辑符号体系,后来人们称之为波兰表示法(Polish notation)。波兰表达式的特点是运算符位于运算对象的后面,因此称为后缀表示。在对波兰表达式进行运算,严格按照自左至右的顺序进行。下面给出一些表达式及其相应的波兰表达式。 表达式 波兰表达式 A-B AB- (A-B)*C+D AB-C*D+ A*(B+C/D)-E*F ABCD/+*EF*- (B+C)/(A-D) BC+AD-/ OK,所谓表达式的线性化是指将中缀表达的表达式转化为波兰表达式。对于每一个表达式,利用栈可以把表达式变换成波兰表达式,也可以利用栈来计算波兰表达式的值。 至于转换和计算的过程和第一种方法大同小异,这里就不再赘述了。 下面给出转换和计算的具体实现程序—— /* first函数给出各个运算符的优先级,其中=为表达式结束符 */ int first(char c) { int p; switch(c) { case '*': p=2; break; case '/': p=2; break; case '+': p=1; break; case '-': p=1; break; case '(': p=0; break; case '=': p=-1; break; } return(p); } /* 此函数实现中缀到后缀的转换 */ /* M的值宏定义为20 */ /* sp[]为表达式数组 */ int mid_last() { int i=0,j=0; char c,sm[M]; c=s[0]; sm[0]='='; top=0; while(c!='\0') { if(islower(c)) sp[j++]=c; else switch(c) { case '+': case '-': case '*': case '/': while(first(c)<=first(sm[top])) sp[j++]=sm[top--]; sm[++top]=c; break; case '(': sm[++top]=c; break; case ')': while(sm[top]!='(') sp[j++]=sm[top--]; top--; break; default :return(1); } c=s[++i]; } while(top>0) sp[j++]=sm[top--]; sp[j]='\0'; return(0); } /* 由后缀表达式来计算表达式的值 */ int calc() { int i=0,sm[M],tr; char c; c=sp[0]; top=-1; while(c!='\0') { if(islower(c)) sm[++top]=ver[c-'a'];/*在转换过程中用abcd等来代替数, 这样才可以更方便的处理非一位数, ver数组中存放着这些字母所代替的数*/ else switch(c) { case '+': tr=sm[top--]; sm[top]+=tr; break; case '-': tr=sm[top--]; sm[top]-=tr; break; case '*': tr=sm[top--]; sm[top]*=tr; break; case '/': tr=sm[top--];sm[top]/=tr;break; default : return(1); } c=sp[++i]; } if(top>0) return(1); else } 这样这个程序基本上就算解决了,回过头来拿这个程序来算一算文章开始的那个问题。哈哈,算出来了,原来如此简单——(6-3)*10-6=24。 最后我总结了一下这其中容易出错的地方—— 1、 排列的时候由于一个数只能出现一次, 所以必然有一个判断语句。但是用什么来判断,用大小显然不行,因为有可能这四个数中有两个或者以上的数是相同的。我的方法是给每一个数设置一个代号,在排列结束时,通过这个代号找到这个数。 2、在应用嵌套函数时,需仔细分析程序的执行过程,并对个别变量进行适当的调整(如j的值),程序才能正确的执行。 3、在分析括号问题的时候要认真仔细,不要错过任何一个可能的机会,也要尽量使程序变得简单一些。不过我的分析可能也有问题,还请高手指点。 4、在用函数对一个数组进行处理的时候,一定要注意如果这个数组还需要再应用,就必须将它先保存起来,否则会出错,而且是很严重的错误。 5、在处理用户输入的表达式时,由于一个十位数或者更高位数是被分解成各位数存放在数组中,所以需对它们进行处理,将它们转化成实际的整型变量。另外,在转化过程中,用一个字母来代替这个数,并将这个数存在一个数组中,且它在数组中的位置和代替它的这个字母有一定的联系,这样才能取回这个数。 6、由于在穷举过程难免会出现计算过程中有除以0的计算,所以我们必须对calc函数种对于除的运算加以处理,否则程序会因为出错而退出(Divide by 0)。 7、最后一个问题,本程序尚未解决。对于一些比较著名的题目,本程序无法解答。比如说5、5、5、1或者8、8、3、3。这是由于这些题目在计算的过程用到了小数,而本程序并没有考虑到小数。

知与谁同 2019-12-02 01:22:19 0 浏览量 回答数 0

回答

如果能时光倒流,回到过去,作为一个开发人员,你可以告诉自己在职业生涯初期应该读一本, 你会选择哪本书呢。我希望这个书单列表内容丰富,可以涵盖很多东西。” 1、《代码大全》 史蒂夫·迈克康奈尔 推荐数:1684 “优秀的编程实践的百科全书,《代码大全》注重个人技术,其中所有东西加起来, 就是我们本能所说的“编写整洁的代码”。这本书有50页在谈论代码布局。” —— Joel Spolsky 对于新手来说,这本书中的观念有点高阶了。到你准备阅读此书时,你应该已经知道并实践过书中99%的观念。– esac Steve McConnell的原作《代码大全》(第1版)是公认的关于编程的最佳实践指南之一, 在过去的十多年间,本书一直在帮助开发人员编写更好的软件。 现在,作者将这本经典著作全新演绎,融入了最前沿的实践技术,加入了上百个崭新的代码示例, 充分展示了软件构建的艺术性和科学性。 McConnell汇集了来自研究机构、学术界以及业界日常实践的主要知识, 把最高效的技术和最重要的原理交织融会为这本既清晰又实用的指南。 无论您的经验水平如何,也不管您在怎样的开发环境中工作,也无论项目是大是小, 本书都将激发您的思维并帮助您构建高品质的代码。 《代码大全(第2版))》做了全面的更新,增加了很多与时俱进的内容,包括对新语言、新的开发过程与方法论的讨论等等。 2、《程序员修炼之道》 推荐数:1504 对于那些已经学习过编程机制的程序员来说,这是一本卓越的书。 或许他们还是在校生,但对要自己做什么,还感觉不是很安全。 就像草图和架构之间的差别。虽然你在学校课堂上学到的是画图,你也可以画的很漂亮, 但如果你觉得你不太知道从哪儿下手,如果某人要你独自画一个P2P的音乐交换网络图,那这本书就适合你了。—— Joel 《程序员修炼之道:从小工到专家》内容简介:《程序员修炼之道》由一系列独立的部分组成, 涵盖的主题从个人责任、职业发展,知道用于使代码保持灵活、并且易于改编和复用的各种架构技术, 利用许多富有娱乐性的奇闻轶事、有思想性的例子及有趣的类比, 全面阐释了软件开发的许多不同方面的最佳实践和重大陷阱。 无论你是初学者,是有经验的程序员,还是软件项目经理,《程序员修炼之道:从小工到专家》都适合你阅读。 3、《计算机程序的构造和解释》 推荐数:916 就个人而言,这本书目前为止对我影响醉倒的一本编程书。 《代码大全》、《重构》和《设计模式》这些经典书会教给你高效的工作习惯和交易细节。 其他像《人件集》、《计算机编程心理学》和《人月神话》这些书会深入软件开发的心理层面。 其他书籍则处理算法。这些书都有自己所属的位置。 然而《计算机程序的构造和解释》与这些不同。 这是一本会启发你的书,它会燃起你编写出色程序的热情; 它还将教会你认识并欣赏美; 它会让你有种敬畏,让你难以抑制地渴望学习更多的东西。 其他书或许会让你成为一位更出色的程序员,但此书将一定会让你成为一名程序员。 同时,你将会学到其他东西,函数式编程(第三章)、惰性计算、元编程、虚拟机、解释器和编译器。 一些人认为此书不适合新手。 个人认为,虽然我并不完全认同要有一些编程经验才能读此书,但我还是一定推荐给初学者。 毕竟这本书是写给著名的6.001,是麻省理工学院的入门编程课程。 此书或许需要多做努力(尤其你在做练习的时候,你也应当如此),但这个价是对得起这本书的。 4、《C程序设计语言》 推荐数:774 这本书简洁易读,会教给你三件事:C 编程语言;如何像程序员一样思考;底层计算模型。 (这对理解“底层”非常重要)—— Nathan 《C程序设计语言》(第2版新版)讲述深入浅出,配合典型例证,通俗易懂,实用性强, 适合作为大专院校计算机专业或非计算机专业的C语言教材,也可以作为从事计算机相关软硬件开发的技术人员的参考书。 《C程序设计语言》(第2版新版)原著即为C语言的设计者之一Dennis M.Ritchie和著名的计算机科学家Brian W.Kernighan合著的 一本介绍C语言的权威经典著作。 我们现在见到的大量论述C语言程序设计的教材和专著均以此书为蓝本。 原著第1版中介绍的C语言成为后来广泛使用的C语言版本——标准C的基础。 人们熟知的“hello,world”程序就是由本书首次引入的,现在,这一程序已经成为所有程序设计语言入门的第一课。 5、《算法导论》 推荐数:671 《代码大全》教你如何正确编程; 《人月神话》教你如何正确管理; 《设计模式》教你如何正确设计…… 在我看来,代码只是一个工具,并非精髓。 开发软件的主要部分是创建新算法或重新实现现有算法。 其他部分则像重新组装乐高砖块或创建“管理”层。 我依然梦想这样的工作,我的大部分时间(>50%)是在写算法,其他“管理”细节则留给其他人…… —— Ran Biron 经典的算法书,被亚马逊网,《程序员》等评选为2006年最受读者喜爱的十大IT图书之一。 算法领域的标准教材,全球多所知名大学选用 MIT名师联手铸就,被誉为“计算机算法的圣经” 编写上采用了“五个一”,即一章介绍一个算法、一种设计技术、一个应用领域和一个相关话题。 6、《重构:改善既有代码的设计》 推荐数:617 《重构:改善既有代码的设计》清晰地揭示了重构的过程,解释了重构的原理和最佳实践方式, 并给出了何时以及何地应该开始挖掘代码以求改善。 书中给出了70多个可行的重构,每个重构都介绍了一种经过验证的代码变换手法的动机和技术。 《重构:改善既有代码的设计》提出的重构准则将帮助你一次一小步地修改你的代码,从而减少了开发过程中的风险。 《重构:改善既有代码的设计》适合软件开发人员、项目管理人员等阅读, 也可作为高等院校计算机及相关专业师生的参考读物。 我想我不得不推荐《重构》:改进现有代码的设计。—— Martin 我必须承认,我最喜欢的编程语录是出自这本书:任何一个傻瓜都能写出计算机能理解的程序, 而优秀的程序员却能写出别人能读得懂的程序。—— Martin Fowler 7、《设计模式》 推荐数:617 自1995年出版以来,本书一直名列Amazon和各大书店销售榜前列。 近10年后,本书仍是Addison-Wesley公司2003年最畅销的图书之一。 中文版销售逾4万册。 就我而言,我认为四人帮编著的《设计模式》是一本极为有用的书。 虽然此书并不像其他建议一样有关“元”编程,但它强调封装诸如模式一类的优秀编程技术, 因而鼓励其他人提出新模式和反模式(antipatterns),并运用于编程对话中。—— Chris Jester-Young 8、《人月神话》 推荐数:588 在软件领域,很少能有像《人月神话》一样具有深远影响力并且畅销不衰的著作。 Brooks博士为人们管理复杂项目提供了最具洞察力的见解。 既有很多发人深省的观点,又有大量软件工程的实践。 本书内容来自Brooks博士在IBM公司System/360家族和OS/360中的项目管理经验。 该书英文原版一经面世,即引起业内人士的强烈反响,后又译为德、法、日、俄中等多种语言,全球销量数百万册。 确立了其在行业内的经典地位。 9、《计算机程序设计艺术》 推荐数:542 《计算机程序设计艺术》系列著作对计算机领域产生了深远的影响。 这一系列堪称一项浩大的工程,自1962年开始编写,计划出版7卷,目前已经出版了4卷。 《美国科学家》杂志曾将这套书与爱因斯坦的《相对论》等书并列称为20世纪最重要的12本物理学著作。 目前Knuth正将毕生精力投入到这部史诗性著作的撰写中。 这是高德纳倾注心血写的一本书。—— Peter Coulton 10、《编译原理》(龙书) 推荐数:462 我很奇怪,居然没人提到龙书。(或许已有推荐,我没有看到)。 我从没忘过此书的第一版封面。 此书让我知道了编译器是多么地神奇绝妙。- DB 11、《深入浅出设计模式》 推荐数:445 强大的写作阵容。 《Head First设计模式》(中文版) 作者Eric Freeman; ElElisabeth Freeman是作家、讲师和技术顾问。 Eric拥有耶鲁大学的计算机科学博士学位,E1isabath拥有耶鲁大学的计算机科学硕士学位。 Kathy Sierra(javaranch.com的创始人)FHBert Bates是畅销的HeadFirst系列书籍的创立者,也是Sun公司Java开发员认证考试的开发者。 本书的产品设计应用神经生物学、认知科学,以及学习理论,这使得这本书能够将这些知识深深地印在你的脑海里, 不容易被遗忘。 本书的编写方式采用引导式教学,不直接告诉你该怎么做,而是利用故事当作引子,带领读者思考并想办法解决问题。 解决问题的过程中又会产生一些新的问题,再继续思考、继续解决问题,这样可以加深体会。 作者以大量的生活化故事当背景,例如第1章是鸭子,第2章是气象站,第3章是咖啡店, 书中搭配大量的插图(几乎每一页都有图),所以阅读起来生动有趣,不会感觉到昏昏欲睡。 作者还利用歪歪斜斜的手写字体,增加“现场感”。 精心设计许多爆笑的对白,让学习过程不会太枯燥。 还有模式告白节目,将设计模式拟人化成节目来宾,畅谈其内在的一切。 每一章都有数目不等的测验题。 每章最后有一页要点整理,这也是精华所在,我都是利用这一页做复习。 我知道四人帮的《设计模式》是一本标准书,但倒不如先看看这部大部头,此书更为简易。 一旦你了解了解了基本原则,可以去看四人帮的那本圣经了。- Calanus 12、《哥德尔、艾舍尔、巴赫书:集异璧之大成》 推荐数:437 如果下昂真正深入阅读,我推荐道格拉斯·侯世达(Douglas Hofstadter)的《哥德尔、艾舍尔、巴赫书》。 他极为深入研究了程序员每日都要面对的问题:递归、验证、证明和布尔代数。 这是一本很出色的读物,难度不大,偶尔有挑战,一旦你要鏖战到底,将是非常值得的。 – Jonik 13、《代码整洁之道》 推荐数:329 细节之中自有天地,整洁成就卓越代码 尽管糟糕的代码也能运行,但如果代码不整洁,会使整个开发团队泥足深陷, 写得不好的代码每年都要耗费难以计数的时间和资源。 然而这种情况并非无法避免。 著名软件专家RoberfC.Marlin在《代码整洁之道》中为你呈现出了革命性的视野。 Martin携同ObjectMetltor公司的同事,从他们有关整洁代码的最佳敏捷实践中提炼出软件技艺的价值观, 以飨读者,让你成为更优秀的程序员——只要你着手研读《代码整洁之道》。 阅读《代码整洁之道》需要你做些什么呢。你将阅读代码——大量代码。 《代码整洁之道》促使你思考代码中何谓正确,何谓错误。 更重要的是,《代码整洁之道》将促使你重新评估自己的专业价值观,以及对自己技艺的承诺。 从《代码整洁之道》中可以学到: 好代码和糟糕的代码之间的区别; 如何编写好代码,如何将糟糕的代码转化为好代码; 如何创建好名称、好函数、好对象和好类; 如何格式化代码以实现其可读性的最大化; 如何在不妨碍代码逻辑的前提下充分实现错误处理; 如何进行单元测试和测试驱动开发。 虽然《代码整洁之道》和《代码大全》有很多共同之处,但它有更为简洁更为实际的清晰例子。 – Craig P. Motlin 14、《Effective C++》和《More Effective C++》 推荐数:297 在我职业生涯早期,Scott Meyer的《Effective C++》和后续的《More Effective C++》都对我的编程能力有着直接影响。 正如当时的一位朋友所说,这些书缩短你培养编程技能的过程,而其他人可能要花费数年。 去年对我影响最大的一本书是《大教堂与市集》,该书教会我很有关开源开发过程如何运作,和如何处理我代码中的Bug。 – John Channing 15、《编程珠玑》 推荐数:282 多年以来,当程序员们推选出最心爱的计算机图书时,《编程珠玑》总是位列前列。 正如自然界里珍珠出自细沙对牡蛎的磨砺,计算机科学大师Jon Bentley以其独有的洞察力和创造力, 从磨砺程序员的实际问题中凝结出一篇篇不朽的编程“珠玑”, 成为世界计算机界名刊《ACM通讯》历史上最受欢迎的专栏, 最终结集为两部不朽的计算机科学经典名著,影响和激励着一代又一代程序员和计算机科学工作者。 本书为第一卷,主要讨论计算机科学中最本质的问题:如何正确选择和高效地实现算法。 尽管我不得不羞愧地承认,书中一半的东西我都没有理解,但我真的推荐《编程珠玑》,书中有些令人惊奇的东西。 – Matt Warren 16、《修改代码的艺术》by Michael Feathers 本书是继《重构》和《重构与模式》之后探讨修改代码技术的又一里程碑式的著作, 而且从涵盖面和深度上都超过了前两部经典。 书中不仅讲述面向对象语言(Java、C#和C++)代码,也有专章讨论C这样的过程式语言。 作者将理解、测试和修改代码的原理、技术和最新工具(自动化重构工具、单元测试框架、仿对象、集成测试框架等), 与解依赖技术和大量开发和设计优秀代码的原则、最佳实践相结合,许多内容非常深入,而且常常发前人所未发。 书中处处体现出作者独到的洞察力,以及多年开发和指导软件项目所积累的丰富经验和深厚功力。 通过这部集大成之作,你不仅能掌握最顶尖的修改代码技术,还可以大大提高对代码和软件开发的领悟力。 我认为没有任何一本书能向这本书一样影响了我的编程观点。 它明确地告诉你如何处理其他人的代码,含蓄地教会你避免哪些(以及为什么要避免)。- Wolfbyte 同意。很多开发人员讨论用干净的石板来编写软件。 但我想几乎所有开发人员的某些时候是在吃其他开发人员的狗食。– Bernard Dy 17、《编码:隐匿在计算机软硬件背后的语言》 这是一本讲述计算机工作原理的书。 不过,你千万不要因为“工作原理”之类的字眼就武断地认为,它是晦涩而难懂的。 作者用丰富的想象和清晰的笔墨将看似繁杂的理论阐述得通俗易懂,你丝毫不会感到枯燥和生硬。 更重要的是,你会因此而获得对计算机工作原理较深刻的理解。 这种理解不是抽象层面上的,而是具有一定深度的,这种深度甚至不逊于“电气工程师”和“程序员”的理解。 不管你是计算机高手,还是对这个神奇的机器充满敬畏之心的菜鸟, 都不妨翻阅一下《编码:隐匿在计算机软硬件背后的语言》,读一读大师的经典作品,必然会有收获。 我推荐Charles Petzold的《编码》。 在这个充满工具和IDE的年代,很多复杂度已经从程序员那“抽取”走了,这本书一本开眼之作。 – hemil 18、《禅与摩托车维修艺术 / Zen and the Art of Motorcycle Maintenance》 对我影响最大的那本书是 Robert Pirsig 的《禅与摩托车维修艺术》。 不管你做什么事,总是要力求完美,彻底了解你手中的工具和任务,更为重要的是, 要有乐趣(因为如果你做事有乐趣,一切将自发引向更好的结果)。 – akr 19、《Peopleware / 人件集:人性化的软件开发》 Demarco 和 Lister 表明,软件开发中的首要问题是人,并非技术。 他们的答案并不简单,只是令人难以置信的成功。 第二版新增加了八章内容。 – Eduardo Molteni 20、《Coders at Work / 编程人生》 这是一本访谈笔录,记录了当今最具个人魅力的15位软件先驱的编程生涯。 包括DonaldKnuth、Jamie Zawinski、Joshua Bloch、Ken Thompson等在内的业界传奇人物,为我们讲述了 他们是怎么学习编程的,在编程过程中发现了什么以及他们对未来的看法, 并对诸如应该如何设计软件等长久以来一直困扰很多程序员的问题谈了自己的观点。 一本非常有影响力的书,可以从中学到一些业界顶级人士的经验,了解他们如何思考并工作。 – Jahanzeb Farooq 21、《Surely You’re Joking, Mr. Feynman! / 别闹了,费曼先生。》 虽然这本书可能有点偏题,但不管你信不信,这本书曾在计算机科学专业课程的阅读列表之上。 一个优秀的角色模型,一本有关好奇心的优秀书籍。 – mike511 22、《Effective Java 中文版》 此书第二版教你如何编写漂亮并高效的代码,虽然这是一本Java书,但其中有很多跨语言的理念。 – Marcio Aguiar 23、《Patterns of Enterprise Application Architecture / 企业应用架构模式》 很奇怪,还没人推荐 Martin Fowler 的《企业应用架构模式》- levi rosol 24、《The Little Schemer》和《The Seasoned Schemer》 nmiranda 这两本是LISP的英文书,尚无中文版。 美国东北大学网站上也有电子版。 25、《交互设计之路》英文名:《The Inmates Are Running The Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity》该书作者:Alan Cooper,人称Visual Basic之父,交互设计之父。 本书是基于众多商务案例,讲述如何创建更好的、高客户忠诚度的软件产品和基于软件的高科技产品的书。 本书列举了很多真实可信的实际例子,说明目前在软件产品和基于软件的高科技产品中,普遍存在着“难用”的问题。 作者认为,“难用”问题是由这些产品中存在着的高度“认知摩擦”引起的, 而产生这个问题的根源在于现今软件开发过程中欠缺了一个为用户利益着想的前期“交互设计”阶段。 “难用”的产品不仅损害了用户的利益,最终也将导致企业的失败。 本书通过一些生动的实例,让人信服地讲述了由作者倡导的“目标导向”交互设计方法在解决“难用”问题方面的有效性, 证实了只有改变现有观念,才能有效地在开发过程中引入交互设计,将产品的设计引向成功。 本书虽然是一本面向商务人员而编写的书,但也适合于所有参与软件产品和基于软件的高科技产品开发的专业人士, 以及关心软件行业和高科技行业现状与发展的人士阅读。 他还有另一本中文版著作:《About Face 3 交互设计精髓》 26、《Why’s (Poignant) Guide to Ruby 》 如果你不是程序员,阅读此书可能会很有趣,但如果你已经是个程序员,可能会有点乏味。 27、《Unix编程艺术》 It is useful regardless operating system you use. – J.F. Sebastian 不管你使用什么操作系统,这本书都很有用。 – J.F. Sebastian 28、《高效程序员的45个习惯:敏捷开发修炼之道》 45个习惯,分为7个方面:工作态度、学习、软件交付、反馈、编码、调试和协作。 每一个具体的习惯里,一开始提出一个谬论,然后展开分析,之后有正队性地提出正确的做法,并设身处地地讲出了正确做法给你个人的“切身感受”,最后列出几条注意事项,帮助你修正自己的做法(“平衡的艺术”)。 29、《测试驱动开发》 前面已经提到的很多书都启发了我,并影响了我,但这本书每位程序员都应该读。 它向我展示了单元测试和TDD的重要性,并让我很快上手。 – Curro 我不关心你的代码有多好或优雅。 如果你没有测试,你或许就如同没有编写代码。 这本书得到的推荐数应该更高些。 人们讨论编写用户喜欢的软件,或既设计出色并健壮的高效代码,但如果你的软件有一堆bug,谈论那些东西毫无意义。– Adam Gent 30、《点石成金:访客至上的网页设计秘笈》 可用性设计是Web设计中最重要也是难度最大的一项任务。 《点石成金-访客至上的网页设计秘笈(原书第二版)》作者根据多年从业的经验,剖析用户的心理, 在用户使用的模式、为扫描进行设计、导航设计、主页布局、可用性测试等方面提出了许多独特的观点, 并给出了大量简单、易行的可用性设计的建议。 本书短小精炼,语言轻松诙谐,书中穿插大量色彩丰富的屏幕截图、趣味丛生的卡通插图以及包含大量信息的图表, 使枯燥的设计原理变得平易近人。 本书适合从事Web设计和Web开发的技术人员阅读,特别适合为如何留住访问者而苦恼的网站/网页设计人员阅读。 这是一本关于Web设计原则而不是Web设计技术的书。 本书作者是Web设计专家,具有丰富的实践经验。 他用幽默的语言为你揭示Web设计中重要但却容易被忽视的问题,只需几个小时, 你便能对照书中讲授的设计原则找到网站设计的症结所在,令你的网站焕然一新。

青衫无名 2019-12-02 01:20:04 0 浏览量 回答数 0
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 企业信息查询 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 2020阿里巴巴研发效能峰会 企业建站模板 云效成长地图 高端建站