carp

设计模式有两种分类方法，即根据模式的目的来分和根据模式的作用的范围来分。 根据目的来分 根据模式是用来完成什么工作来划分，这种方式可分为创建型模式、结构型模式和行为型模式 3 种。 创建型模式： 用于描述“怎样创建对象”，它的主要特点是“将对象的创建与使用分离”。 GoF 中提供了单例、原型、工厂方法、抽象工厂、建造者等 5 种创建型模式。 结构型模式： 用于描述如何将类或对象按某种布局组成更大的结构，GoF 中提供了代理、适配器、桥接、装饰、外观、享元、组合等 7 种结构型模式。 行为型模式： 用于描述类或对象之间怎样相互协作共同完成单个对象都无法单独完成的任务，以及怎样分配职责。 GoF 中提供了模板方法、策略、命令、职责链、状态、观察者、中介者、迭代器、访问者、备忘录、解释器等 11 种行为型模式。 根据作用范围来分 根据模式是主要用于类上还是主要用于对象上来分，这种方式可分为类模式和对象模式两种。 类模式： 用于处理类与子类之间的关系，这些关系通过继承来建立，是静态的，在编译时刻便确定下来了。 GoF中的工厂方法、（类）适配器、模板方法、解释器属于该模式。 对象模式： 用于处理对象之间的关系，这些关系可以通过组合或聚合来实现，在运行时刻是可以变化的，更具动态性。 GoF 中除了以上 4 种，其他的都是对象模式。 GoF的23种设计模式的功能 前面说明了 GoF 的 23

设计模式不应该停留于理论，跟具体业务结合，它才会变得更香～ 1.前言 设计模式我们多少都有些了解，但是往往也只是知道是什么。 在真实的业务场景中，你有用过什么设计模式来编写更优雅的代码吗？ 我们更多的是每天从产品经理那里接受到新需求后，就开始MVC一把梭，面向sql编程了。 我们习惯采用MVC架构，实时上是非常容易创建很多贫血对象模型，然后写出过程式代码。我们使用的对象，往往只是数据的载体，没有任何逻辑行为。我们的设计过程，也是从ER图开始，以数据为中心进行驱动设计。一个需求一个接口，从controller到service到dao，这样日复一日的CRUD。 什么设计模式？根本不存在的！ 今天，我们尝试从常用设计模式（工厂模式、代理模式、模版模式）在CRUD中的可落地场景，希望能给大家带来一些启发。 2.理解设计模式 设计模式（Design pattern），不是前人凭空想象的，而是在长期的软件设计实践过程中，经过总结得到的。 使用设计模式是为了让代码具有可扩展性，实现高聚合、低耦合的特性。 世上本来没有设计模式，写代码的人多了，便有了设计模式。 面向对象的设计模式有七大基本原则： 开闭原则（Open Closed Principle，OCP） 单一职责原则（Single Responsibility Principle, SRP） 里氏代换原则（Liskov

设计模式不应该停留于理论，跟具体业务结合，它才会变得更香～ 1.前言 设计模式我们多少都有些了解，但是往往也只是知道是什么。 在真实的业务场景中，你有用过什么设计模式来编写更优雅的代码吗？ 我们更多的是每天从产品经理那里接受到新需求后，就开始MVC一把梭，面向sql编程了。 我们习惯采用MVC架构，实时上是非常容易创建很多贫血对象模型，然后写出过程式代码。我们使用的对象，往往只是数据的载体，没有任何逻辑行为。我们的设计过程，也是从ER图开始，以数据为中心进行驱动设计。一个需求一个接口，从controller到service到dao，这样日复一日的CRUD。 什么设计模式？根本不存在的！ 今天，我们尝试从常用设计模式（工厂模式、代理模式、模版模式）在CRUD中的可落地场景，希望能给大家带来一些启发。 2.理解设计模式 设计模式（Design pattern），不是前人凭空想象的，而是在长期的软件设计实践过程中，经过总结得到的。 使用设计模式是为了让代码具有可扩展性，实现高聚合、低耦合的特性。 世上本来没有设计模式，写代码的人多了，便有了设计模式。 面向对象的设计模式有七大基本原则： 开闭原则（Open Closed Principle，OCP） 单一职责原则（Single Responsibility Principle, SRP） 里氏代换原则（Liskov

又是一个没有开工红包的公司！！！ 问题分析 通过以上对话，各位是否能够猜到所有缓存穿透的原因呢？回答之前我们先来看一下缓存策略的具体代码 缓存服务器IP=hash(key)%服务器数量 这里还要多说一句，key的取值可以根据具体业务具体设计。比如，我想要做负载均衡，key可以为调用方的服务器IP；获取用户信息，key可以为用户ID；等等。 在服务器数量不变的情况下，以上设计没有问题。但是要知道，程序员的现实世界是悲惨的，唯一不变的就是业务一直在变。我本无奈，只能靠技术来改变这种状况。 假如我们现在服务器的数量为10，当我们请求key为6的时候，结果是4，现在我们增加一台服务器，服务器数量变为11，当再次请求key为6的服务器的时候，结果为5.不难发现，不光是key为6的请求，几乎大部分的请求结果都发生了变化，这就是我们要解决的问题， 这也是我们设计分布式缓存等类似场景时候主要需要注意的问题。 我们终极的设计目标是：在服务器数量变动的情况下 尽量提高缓存的命中率（转移的数据最少） 缓存数据尽量平均分配 解决方案 通过以上的分析我们明白了，造成大量缓存失效的根本原因是公式分母的变化，如果我们把分母保持不变，基本上可以减少大量数据被移动 分母不变方案 如果基于公式：缓存服务器IP=hash(key)%服务器数量 我们保持分母不变，基本上可以改善现有情况。我们选择缓存服务器的策略会变为：

桥接模式 目录 桥接模式 模式定义 模式动机 UML类图 源码实现 优点 缺点 总结 模式定义 桥接模式(Bridge), 将抽象部分与它的实现部分分离，使他们都可以独立的变化。 什么叫抽象与他的实现分离，这并不是说让抽象类与其派生类分离，因为这没有任何意义。实现指的是抽象类和它的派生类用来实现自己的对象。 模式动机 解决继承带来的问题 对象的继承关系是在编译时就定义好的，所以无法再运行时改变从父类继承的实现。子类的实现与他的父类有非常紧密的依赖关系，以至于父类实现中的任何变化必然会导致子类发生变化。当你需要复用子类时，如果继承下来的实现不适合解决新的问题，则父类必须重写或被其他更适合的类替换。这种依赖关系限制了灵活性并最终限制了复用性。 合成/聚合复用原则（CARP） 合成（组合）和聚合都是关联的特殊种类。 聚合表示一种弱的‘拥有’关系，体现的是A对象可以包含B对象，但B对象不是A对象的一部分；合成则是一种强的‘拥有’关系，体现了严格的部分和整体的关系，部分和整体的生命周期一样。 聚合关系在继承关系不适用的情况下可以做替代。其实 只要真正深入的理解了设计原则，很多设计模式其实就是原则的应用而已，或许在不知不觉中就在使用设计模式了。 设想如果要绘制矩形、圆形、椭圆、正方形，我们至少需要4个形状类，但是如果绘制的图形需要具有不同的颜色，如红色、绿色、蓝色等，此时至少有如下两种设计方案

1.简介 if判断语句是很多编程语言的重要组成部分。但是，若我们最终编写了大量嵌套的if语句，这将使得我们的代码更加复杂和难以维护。 让我们看看能否使用别的方式来做呢。 设计模式是为了更好的代码重用性，可读性，可靠性，可维护性，它有六大原则 　　　　　　1)单一职责原则（Single Responsibility Principle，简称SRP）:该原则是针对类来说的，即一个类应该只负责一项职责. 　　　　　　2)开放--封闭原则（The Open-Closed Principle简称OCP）:是说软件实体（类、模块、函数等等）应该可以扩展，但是不可以修改。 　　　　　　3)依赖倒转原则（Dependence Inversion Principle :针对接口编程，不要对实现编程 　　　　　　4)里氏代换原则（Liskov Substitution Principle，简称LSP）:里氏代换原则，子类型必须能够替换掉他们的父类型 　　　　　　5)迪米特法则（Law of Demeter）:如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用 　　　　　　6)合成/聚合复用原则（Composition/Aggregation Principle]，简称CARP）:尽量使用合成/聚合，尽量不使用类继承。合成聚合是“has a”的关系，而继承是“is a”的关系。 2.示例

假如 需要设计这样一个业务场景：某公司管理系统登录账户有 销售员工、研发员工 用户，现系统规划 考勤系统、薪资系统 需要针对三种员工做不业务逻辑 。该系统有两个维度方面的变化，一个是员工的变化，即可以是销售员工，可以是研发员工；另一个是业务维度的变化，即考勤系统和薪资系统的变化，针对这一系统设计，我尝试从单继承结构到使用桥接模式来尝试感受桥接模式带来的好处。 1.单继承结构设计 对于 以员工为抽象父类进行设计，类图如下： 简单 的单继承结构，虽然可以满足初期的业务需求，但是假如这时候，需要再添加一类员工：财务员工，这时候就需要在与销售和研发员工同层类中增加一个新的员工类继承抽象员工类，并且在此基础上，还需要再增加两个子类：财务员工考勤、财务员工绩效，增加一类员工，我一共增加了三个新的类。由此可见，单继承结构，会随着业务需求的增长，类的数量剧烈增长，容易引起类爆炸。此外，如果业务类增加，比如增加一个薪资管理系统，那么就需要再每类型员工下再增加一个子类：xx员工薪资管理。再有，如果考勤系统方法发生了变化，那么，就需要去修改每个xx员工考勤系统下的相关方法，这样显然违背了 开放-封闭原则 ，使得维护难度大大提升。 造成单继承结构的该管理系统维护困难的原因，在于业务逻辑和员工之间的 紧耦合 ，单一的分支结构中，既处理业务逻辑，也体现员工分类，显然，这也违背了 单一职能原则

一.架构师内功心法之设计原则 1.为什么要学习软件架构设计原则 1.1.课程目标 通过对节课内容的学习，了解设计原则的重要性。 掌握七大设计原则的具体内容。 1.2.内容定位 学习设计原则，学习设计模式的基础。在实际开发过程中，并不是一定要求所有代码都遵循设计原则，我们要考虑人力、时间、成本、质量，不是刻意追求完美，要在 适当的场景 遵循设计原则，体现的是一种 平衡取舍 ，帮助我们设计出更加优雅的代码结构。 1.3.七大设计原则 [x] 第1章 Open-Closed Principle 开闭原则 [x] 第2章 Dependence Inversion Principle 依赖倒置原则 [x] 第3章 Simple Responsibility Principle 单一职责原则 [x] 第4章 Interface Segregation Principle 接口隔离原则 [x] 第5章 Law of Demeter 迪米特法则 [x] 第6章 Liskov Substitution Principle 里氏替换原则 [x] 第7章 Composite&Aggregate Reuse Principle 合成复用原则 1.3.1.开闭原则 定义 开闭原则（Open-Closed Principle, OCP）是指一个软件实体如类、模块和函数应该对扩展开放， 对修改关闭。所谓的开闭

HTTP权威指南笔记 第一部分、基本组成 一、HTTP报文 1.报文格式 报文的起始行和首部是以行分隔的，以回车换行CRLF进行结束。回车符ASCII码13，换行符ASCII码10. 请求报文格式 <method><request-URL><version> <headers> <entity-body> 响应报文格式 <version><status><reason-phrase> <headers> <entity-body> 2.HTTP方法 1)GET和HEAD被认为是安全方法 2)HEAD与GET方法的行为类似，但服务器在响应中只返回首部，不返回实体的主体部分。 HEAD可以用于判断资源类型，查看响应状态码(404是否存在等)，资源是否被修改等。 3)PUT方法与GET相反，用于向服务器写入文档。让服务器用请求的主体部分创建一个由所请求的 URL命名的新文档。 4)POST用于向服务器输入数据，如表单数据。 5)TRACE请求，主要用于诊断网络，可以查看代理和其他应用程序对用户请求所产生的修改。 6)OPTIONS方法用于请求服务器支持哪些方法 7)DELETE方法，请求服务器删除所请求的资源。 3.HTTP首部 包括通用首部(客户端和服务器端都可以使用)、请求首部、响应首部、实体首部、扩展首部 1)通用信息首部 Connection 允许客户端和服务器指定与请求

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 一致性哈希算法在1997年由麻省理工学院的Karger等人在解决分布式Cache中提出的，设计目标是为了解决因特网中的热点(Hot spot)问题，初衷和CARP十分类似。一致性哈希修正了CARP使用的简单哈希算法带来的问题，使得DHT可以在P2P环境中真正得到应用。 　　但现在一致性hash算法在分布式系统中也得到了广泛应用，研究过memcached缓存数据库的人都知道，memcached服务器端本身不提供分布式cache的一致性，而是由客户端来提供，具体在计算一致性hash时采用如下步骤： 首先求出memcached服务器（节点）的哈希值，并将其配置到0～232的圆（continuum）上。 然后采用同样的方法求出存储数据的键的哈希值，并映射到相同的圆上。 然后从数据映射到的位置开始顺时针查找，将数据保存到找到的第一个服务器上。如果超过232仍然找不到服务器，就会保存到第一台memcached服务器上。 　　从上图的状态中添加一台memcached服务器。余数分布式算法由于保存键的服务器会发生巨大变化而影响缓存的命中率，但Consistent Hashing中，只有在园（continuum）上增加服务器的地点逆时针方向的第一台服务器上的键会受到影响，如下图所示： 一致性Hash性质