知识总结：面试重要知识点

0：Java基础

1.自动装箱与拆箱

https://www.cnblogs.com/dolphin0520/p/3780005.html

2.面向对象五大原则：

单一职责原则SRP(Single Responsibility Principle)

是指一个类的功能要单一，不能包罗万象。如同一个人一样，分配的工作不能太多，否则一天到晚虽然忙忙碌碌的，但效率却高不起来。

开放封闭原则OCP(Open－Close Principle)

一个模块在扩展性方面应该是开放的而在更改性方面应该是封闭的。比如：一个网络模块，原来只服务端功能，而现在要加入客户端功能，那么应当在不用修改服务端功能代码的前提下，就能够增加客户端功能的实现代码，这要求在设计之初，就应当将服务端和客户端分开，公共部分抽象出来。

里式替换原则LSP(the Liskov Substitution Principle LSP)

子类应当可以替换父类并出现在父类能够出现的任何地方。比如：公司搞年度晚会，所有员工可以参加抽奖，那么不管是老员工还是新员工，也不管是总部员工还是外派员工，都应当可以参加抽奖，否则这公司就不和谐了。

依赖倒置原则DIP(the Dependency Inversion Principle DIP)

具体依赖抽象，上层依赖下层。假设B是较A低的模块，但B需要使用到A的功能，这个时候，B不应当直接使用A中的具体类： 而应当由B定义一抽象接口，并由A来实现这个抽象接口，B只使用这个抽象接口：这样就达到了依赖倒置的目的，B也解除了对A的依赖，反过来是A依赖于B定义的抽象接口。通过上层模块难以避免依赖下层模块，假如B也直接依赖A的实现，那么就可能 造成循环依赖。一个常见的问题就是编译A模块时需要直接包含到B模块的cpp文件，而编译B时同样要直接包含到A的cpp文件。

接口分离原则ISP(the Interface Segregation Principle ISP)

模块间要通过抽象接口隔离开，而不是通过具体的类强耦合起来

一：javaWeb部分

1.Servlet何时创建：默认第一次访问servlet时创建该对象

2.Servlet何时销毁：服务器关闭servlet就销毁了 

3.每次访问必然执行的方法：service(ServletRequest req, ServletResponse res)方法

4.获得web应用中任何资源的绝对路径：String path = context.getRealPath(相对于该web应用的相对地址);

5.转发与重定向的区别？

    1）重定向两次请求，转发一次请求

    2）重定向地址栏的地址变化，转发地址不变

    3）重新定向可以访问外部网站 转发只能访问内部资源

    4）转发的性能要优于重定向

6.Session对象的生命周期（面试题/笔试题）

    1）创建：第一次执行request.getSession()时创建

    2）销毁：服务器（非正常）关闭时，session过期/失效（默认30分钟），手动销毁session--session.invalidate();

7.事务的特性ACID

    1）原子性（Atomicity）原子性是指事务是一个不可分割的工作单位，事务中的操作 要么都发生，要么都不发生。

    2）一致性（Consistency）一个事务中，事务前后数据的完整性必须保持一致。

    3）隔离性（Isolation）多个事务，事务的隔离性是指多个用户并发访问数据库时， 一个用户的 事务不能被其它用户的事务所干扰，多个并发事务之间数据要相互隔离。

    4）持久性（Durability）持久性是指一个事务一旦被提交，它对数据库中数据的改变 就是永久性的，接下来即使数据库发生故障也不应该对其有任何影响。

8.并发访问问题----由隔离性引起

    1）脏读：B事务读取到了A事务尚未提交的数据   ------  要求B事务要读取A事 务提交的数据

    2）不可重复读：一个事务中 两次读取的数据的内容不一致  ----- 要求的是一个事 务中多次读取时数据是一致的  --- unpdate

    3）幻读/虚读：一个事务中 两次读取的数据的数量不一致  ----- 要求在一个事务多 次读取的数据的数量是一致的 --insert  delete

9.事务的隔离级别

    1）read uncommitted : 读取尚未提交的数据 ：哪个问题都不能解决

    2）read committed：读取已经提交的数据 ：可以解决脏读 ---- oracle默认的

    3）repeatable read：重读读取：可以解决脏读 和 不可重复读 ---mysql默认的

    4）serializable：串行化：可以解决 脏读 不可重复读 和 虚读---相当于锁表

    mysql数据库默认的隔离级别：repeatable read

二：Linux部分

略（详细见博客）

三：Hibernate

一级缓存 

二级缓存（二级缓存是基于SessionFactory的缓存）

略

四：status2

五：spring

spring中使用的设计模式：

• 简单工厂：spring中的BeanFactory就是简单工厂模式的体现，根据传入一个唯一的标识来获得bean对象
• 工厂方法：采用工厂模式,即应用程序将对象的创建及初始化职责交给工厂对象。一般情况下,应用程序有自己的工厂对象来创建bean.如果将应用程序自己的工厂对象交给Spring管理,那么Spring管理的就不是普通的bean,而是工厂Bean。
• 单例模式：保证一个类仅有一个实例，并提供一个访问它的全局访问点。spring中的单例模式完成了后半句话，即提供了全局的访问点BeanFactory。但没有从构造器级别去控制单例，这是因为spring管理的是任意的java对象。
• 代理模式：在Spring的Aop中，使用的Advice（通知）来增强被代理类的功能。Spring实现这一AOP功能的原理就使用代理模式（1、JDK动态代理。2、CGLib字节码生成技术代理。）对类进行方法级别的切面增强，即，生成被代理类的代理类， 并在代理类的方法前，设置拦截器，通过执行拦截器重的内容增强了代理方法的功能，实现的面向切面编程。
• 适配器模式：比如：DispatcherServlet根据HandlerMapping返回的handler，向HandlerAdatper发起请求，处理Handler。HandlerAdapter根据规则找到对应的Handler并让其执行，执行完毕后Handler会向HandlerAdapter返回一个ModelAndView，最后由HandlerAdapter向DispatchServelet返回一个ModelAndView。HandlerAdatper使得Handler的扩展变得容易，只需要增加一个新的Handler和一个对应的HandlerAdapter即可。因此Spring定义了一个适配接口，使得每一种Controller有一种对应的适配器实现类，让适配器代替controller执行相应的方法。这样在扩展Controller时，只需要增加一个适配器类就完成了SpringMVC的扩展了。
• 装饰器模式：Spring中用到的包装器模式在类名上有两种表现：一种是类名中含有Wrapper，另一种是类名中含有Decorator。
• 观察者模式：spring的事件驱动模型使用的是观察者模式 ，Spring中Observer模式常用的地方是listener的实现。
• 策略模式：Spring框架的资源访问Resource接口 。该接口提供了更强的资源访问能力，Spring 框架本身大量使用了 Resource 接口来访问底层资源。
• 模版方法模式：JDBC的抽象和对Hibernate的集成，都采用了一种理念或者处理方式，那就是模板方法模式与相应的Callback接口相结合。

spring中bena的注入方式：

• 属性注入

    
      Kevin
    
  

• 构造方法注入（可以通过参数索引，参数类型，参数反射ref注入）

    
      Kevin
    
    
      20
    

• 工厂方法注入（静态工厂，非静态工厂）

spring事务隔离级别及传播机制

spring中的事务隔离级别：

 spring事务的传播机制：

• PROPAGATION_REQUIRED：有事务就用已有的，没有就重新开启一个
• PROPAGATION_SUPPORTS：有事务就用已有的，没有也不会重新开启
• PROPAGATION_REQUIRES_NEW：有事务，挂起当前事务，开启新事务
• PROPAGATION_MANDATORY：必须要有事务，没事务抛异常
• PROPAGATION_NOT_SUPPORTED：不需要事务，若当前已有事务，挂起当前事务
• PROPAGATION_NEVER：不需要事务，若当前已有事务，抛出异常
• PROPAGATION_NESTED：嵌套事务，如果外部事务回滚，则嵌套事务也会回滚，外部事务提交的时候，嵌套它才会被提交。嵌套事务回滚不会影响外部事务。

Spring的@Transactional默认是PROPAGATION_REQUIRED。

Spring Bean的生命周期：

1. 初始化bean，调用构造方法
2. 如果实现了BeanNameAware接口，调用其setBeanName方法
3. 如果实现了BeanFactoryAware接口，调用其setBeanFactory方法
4. 如果实现了ApplicationContextAware，调用其setApplicationContext方法
5. 如果配置了后置处理器，调用其postProcessBeforeInitialization方法
6. 如果实现了InitializingBean调用其afterPropertiesSet方法
7. 如果xml中配置了init方法，调用init方法
8. 如果配置了后置处理器，调用其postProcessAfterInitialization方法
9. 调用bean的自己的方法
10. 销毁的时候如果实现了DisDisposableBean，则调用其destroy方法
11. 如果xml中配置了的destroy方法，调用其destroy方法

六：oracle部分

 

 

七：MyBatis部分

一级缓存的四种失效情况

1. sqlSession不同
2. sqlSession相同，查询条件不同
3. sqlSession相同，两次查询之间，执行了增删改操作，本次增删改可能就是改变的缓存中的某个对象
4. sqlSession相同，手动清除一级缓存   sqlSession.clearCache();

八：SpringMVC部分

九：Lucene部分

十：redis部分

十一：品优购项目

搜索整体架构

                              

首页关键字搜索

根据关键字搜索solr中的复制域的内容即可

商品搜索页复杂搜索实现

首先页面需要通过品牌，规格进行搜索，所以先将品牌和规格数据放入redis中

通过solr的分组查询，对根据关键字查询出来的数据通过分类分组，得出分类集合数据，显示在页面上，通过第一个分类到redis中查询出分类下的品牌及规格数据，显示在页面上，这个时候页面就有了分类，品牌，规格的选择条目。

查询页的复杂条件查询，构建查询传入参数为    $scope.searchMap={'keywords':'','category':'','brand':'','spec':{'屏幕尺寸':'6.3寸','内存大小':'8G',....},'price':'500-2000','pageNo':1,'pageSize':40,'sort':'','sortField':''}，返回map={"categoryList":[],"totalPages":1000,"total":50000,"rows":[{....}],"brandList":[],"specList":[],.......}，后台通过品牌，规格，价格等进行过滤查询。

单点登录CAS解决方案

SSO单点登录访问流程主要有以下步骤：

1. 访问服务：SSO客户端发送请求访问应用系统提供的服务资源。

2. 定向认证：SSO客户端会重定向用户请求到SSO服务器。

3. 用户认证：用户身份认证。

4. 发放票据：SSO服务器会产生一个随机的Service Ticket。

5. 验证票据：SSO服务器验证票据Service Ticket的合法性，验证通过后，允许客户端访问服务。

6. 传输用户信息：SSO服务器验证票据通过后，传输用户认证结果信息给客户端。

购物车解决方案

跨域解决方案

CORS请求默认不发送Cookie和HTTP认证信息。如果要把Cookie发到服务器，一方面要服务器同意，指定Access-Control-Allow-Credentials字段。另一方面，开发者必须在AJAX请求中打开withCredentials属性。否则，即使服务器同意发送Cookie，浏览器也不会发送。或者，服务器要求设置Cookie，浏览器也不会处理。

秒杀解决方案

秒杀方案：Redis+MQ实现

基本思路是通过Redis高速缓存来代替缓慢的数据库操作，借此提高系统在高并发情况下的数据处理能力。
原系统：

• 秒杀请求进入后台后被发送到消息队列，并返回入队成功；
• 消息队列的消费者依次处理执行SQL处理消息队列中的秒杀请求；
• 根据测试，SQL函数的执行时间约为30ms，属于慢SQL，在1000次/s,总计50次请求下，系统能够很快的对50万次请求进行入队操作，但是后续消息队列中请求大约需要执行6小时。

修改后：

• 秒杀请求进入后台后，判断Redis中对应秒杀商品的库存，若有库存则发送到消息队列1，返回入队成功，否则，返回秒杀结束；
• 消息队列1使用Redis对请求进行去重处理，去掉重复的请求后发送给消息队列2；
• 消息队列2使用Redis对对应秒杀商品进行减库存操作，之后发送给消息队列3；
• 消息队列3执行原秒杀系统中SQL,对MySql中对应数据表进行操作；
• 修改后的系统由于消息队列1、2中都是对Redis的操作，所以执行速度非常快，响应非常迅速，等到了消息队列3时，请求数基本上已经等于秒杀的商品数，需要执行的SQL数量少了，速度自然也就快了，不会发生消息队列的拥堵。 

十二：SpringBoot部分

十三：SpringCloud部分

1.什么是微服务：微服务化的核心就是将传统的一站式应用,根据业务拆分成一个一个的服务,彻底地去耦合,每一个微服务提供单个业务功能的服务,一个服务做一件事,从技术角度看就是一种小而独立的处理过程,类似进程概念,能够自行单独启动或销毁,拥有自己独立的数据库

2.微服务与微服务架构：微服务强调的是服务的大小,它关注的是某一个点,是具体解决某一个问题/提供落地对应服务的一个服务应用,狭义的看,可以看做Eclipse里面的一个个微服务工程/或者Module。微服务架构是一种架构模式,它提倡将单一应用程序划分成一组小的服务,服务之间互相协调、互相配合,为用户提供最终价值.每个服务运行在其独立的进程中,服务与服务间采用轻量级的通信机制互相协作(通常是基于HTTP协议的RESTful API).每个服务都围绕着具体业务进行构建,并且能够被独立的部署到生产环境、类生产环境等.另外,应当尽量避免统一的、集中式的服务管理机制,对具体的一个服务而言,应根据业务上下文,选择合适的语言、工具对其进行构建.

3.微服务优缺点

优点
每个服务足够内聚,足够小,代码容易理解这样能聚焦一个指定的业务功能或业务需求
开发简单、开发效率提高,一个服务可能就是专一的只干一件事.
微服务能够被小团队单独开服,这个小团队是2到5人的开发人员组成
微服务是松耦合的,是有功能意义的服务,无论是在开发阶段或部署阶段都是独立的.
微服务能使用不同的语言开发
易于和第三方集成,微服务允许容易且灵活的方式集成自动部署,通过持续集成工具,如Jenkins,Hudson,bamboo.
微服务易于被一个开发人员理解,修改和维护,这样小团队能够更关注自己的工作成果.无需通过合作才能体现价值
微服务允许你利用融合最新技术.
微服务只是业务逻辑的代码,不会和HTML,CSS或其他界面组件混合.
每个微服务都有自己的存储能力,可以有自己的数据库.也可以有统一的数据库
 
缺点
开发人员要处理分布式系统的复杂性
多服务运维难度,随着服务的增加,运维的压力也在增大
系统部署依赖
服务间通信成本
数据一致性
系统集成测试
性能监控

4.微服务技术栈

5.为什么使用SpringCloud作为服务架构

1）Spring Cloud来源于Spring，质量、稳定性、持续性都可以得到保证

2）Spirng Cloud天然支持Spring Boot，更加便于业务落地。

3）Spring Cloud发展非常的快，从16年开始接触的时候相关组件版本为1.x，到现在将要发布2.x系列

4）Spring Cloud是Java领域最适合做微服务的框架。

5）相比于其它框架,Spring Cloud对微服务周边环境的支持力度最大。

6）对于中小企业来讲，使用门槛较低。

6.SpringCloud是什么

Spring Cloud是一个微服务架构下的一站式解决方案，提供了一整套的技术实现，俗称微服务全家桶

7.SpringCloud与SpringBoot的关系

Springboot专注于快速方便的开发单个个体微服务.
SpringCloud是关注全局的微服务协调整理治理框架,它将Springboot开发的一个个单体微服务整合并管理起来,为各个微服务质检提供,配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等集成服务
Springboot可以离开SpringCloud独立使用开发项目,但是SpringCloud离不开Springboot,属于依赖的关系.
Springboot专注于快速、方便的开发单个微服务个体,SpringCloud关注全局的服务治理框架.

8.SpringCloud与Dubbo的区别

最大区别:SpringCloud抛弃了Dubbo的RPC通信,采用的是基于HTTP的REST方式.
严格来说,这种方式各有优劣,虽然从一定程度上来说,后者牺牲了服务调用性能,但也避免了上面提到的原生RPC带来的问题.而且REST相比RPC更为灵活,服务提供方和调用方的依赖只依靠一纸契约,不存在代码级别的强依赖,这在强调快速演化的微服务环境下,显得更加合适.

品牌机与组装机的区别
很明显,SpringCloud的功能比Dubbo更加强大,涵盖面更广,而且作为Spring的拳头项目,它也能够与Spring Framework、Springboot、SpringData、SpringBatch等其他Spring项目完美融合,这些对于微服务而言是至关重要的.使用Dubbo构建的微服务架构就像组装电脑,各环节我们的选择自由度很高,但是最终结果很有可能因为一条内存质量不行就点不亮了,总是让人不怎么放心,但是如果你是一名高手,那这些都不是问题;二SpringCloud就像品牌机,在Spring Source的整合下,做了大量兼容性测试,保证了机器拥有更高的稳定性,但是如果要在使用非原装组件外的东西,就需要对其基础有足够的了解.
社区支持与更新力度
最为重要的是,Dubbo停止了5年左右的更新,虽然2017年7月重启了,对于技术发展的新需求,需要由开发者自行拓展升级(比如当当网弄出了DubboX),这对于很多想要采用微服务架构的中小软件组织,显然是不太合适的,中小公司没有这么强大的技术能力去修改Dubbo源码+周边的一整套解决方案,并不是每一个公司都有阿里的大牛+真实的线上生产环境测试过.
9.Eureka是什么

Eureka是Netflix的一个子模块,也是核心模块.Eureka是一个基于REST的服务,用于定位服务,以实现云端中间层服务发现和故障转移.服务注册与发现对于微服务架构来说是非常重要的,有了服务发现与注册,只需要使用服务的标识符,就可以访问到服务,而不需要修改服务调用的配置文件了.功能类似于dubbo的注册中心,比如Zookeeper.
10.eureka自我保护模式

默认情况下,如果EurekaServer在一定时间内没有接收到某个微服务实例心跳,EurekaServer将会注销该实例(默认90秒).但是当网络分区故障发生时,微服务与EurekaServer之间无法正常通信,以上行为可能变得非常危险了----因为微服务本身其实是健康的,此时本不应该注销这个微服务,Eureka通过"自我保护模式"来解决这个问题------当EurekaServer节点在短时间内丢失过多客户端时(可能发生网络分区故障),那么这个节点就会进入自我保护模式.一但进入该模式,EurekaServer就会保护服务注册表中的信息,不再删除服务注册表中的数据(也就是不会注销任何微服务).当网络故障恢复后,该EurekaServer节点会自动退出自我保护模式.
 在自我保护模式中,EurekaServer会保护服务注册表中的信息,不再注销任何服务实例,当它收到的心跳数重新恢复到阈值以上时,该EurekaServer节点就会自动退出自我保护模式,它的设计哲学就是宁可保留错误的服务注册信息,也不盲目注销任何可能健康的服务实例.一句话讲解:好死不如赖活着
 综上,自我保护模式是一种应对网络异常的安全保护措施.它的架构哲学是宁可同时保留所有微服务(健康的微服务和不健康的微服务都会保留),也不盲目注销任何健康的微服务.使用自我保护模式,可以让Eureka集群更加的健壮,稳定.
 在SpringCloud中,可以使用eureka.server.enable-self-preservation = false 禁用自我保护模式
11.eureka与zookeeper比较

CAP:C(consictency)强一致性    A(Availability)可用性   P(Partition tolerance)f分区容错性，分布式系统没有办法同时满足三点，所以eureka遵守AP原则，Zookeeper遵守CP原则。CAP理论：https://blog.csdn.net/yeyazhishang/article/details/80758354

最多只能同时较好的满足两个
CAP理论的核心是:分布式系统不可能同时很好的满足一致性,可用性和分区容错性这三个需求,因此根据CAP原理将NoSQL数据库分成了满足CA原则,满足CP原则和满足AP原则的三大类:
CA-单点集群,满足一致性,可用性的系统,通常在可扩展性上不太强大
CP-满足一致性,分区容忍性的系统,通常不是特别高可用
AP-满足可用性,分区容忍性的系统,通常可能对一致性要求低一些

CAP理论就是说在分布式存储系统中,最多只能实现上面的两点
而由于当前的网络硬件肯定会出现延迟丢包等问题,所以分区容忍性
使我们必须要实现的
所以我们只能在一致性和可用性之间进行权衡,没有nosql系统能同时保证这三点
=======================================================
C:强一致性  A:高可用性  P:分布式容忍性
 
CA  传统Oracle数据库
AP 大多数网站架构的选择
CP Redis,Mongodb
 
注意:分布式架构的时候必须做出取舍.

Zookeeper保证的是CP
当向注册中心查询服务列表时,我们可以容忍注册中心返回的是几分钟以前的注册信息,但不能接受服务直接down掉不可用.也就是说,服务注册功能对可用性的要求高于一致性,但是zk会出现这样一种情况,当master节点因为网络故障与其他节点失去联系时,剩余节点会重新进行leader选举.问题在与,选举leader时间太长,20~120s,且选举期间整个zk集群都是不可用的,这就导致在选举期间注册服务瘫痪,在云部署的环境下,因为网络问题使得zk集群失去master节点是较大概率会发生的事,虽然服务能够最终恢复,但是漫长的选举时间导致的注册长期不可用是不能容忍的.

Eureka保证AP
Eureka看明白了这一点,因此在设计时就优先保证可用性.Eureka各个节点都是平等的,几个节点挂掉不会影响正常节点的工作,剩余的节点依然可以提供注册和查询服务.而Eureka的客户端在向某个Eureka注册时如果发现连接失败,则会自动切换至其他节点,只要有一台Eureka还在,就能保证注册服务可用(保证可用性),只不过查到的信息可能不是最新的(不保证强一致性).除此之外,Eureka还有一种自我保护机制,如果在15分钟内超过85%的节点都没有正常的心跳,那么Eureka就认为客户端与注册中心出现了网络故障,此时会出现以下几种情况:
1.Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
2.Eureka仍然能够接受新服务的注册和查询请求,但是不会被同步到其节点上(即保证当前节点依然可用)
3.当网络稳定时,当前实例新的注册信息会被同步到其他节点中

因此,Eureka可以很好的应对因网络故障导致部分节点失去联系的情况,而不会像Zookeeper那样使整个注册服务瘫痪.

12.ribbon

Spring Cloud Ribbon是基于Netflix Ribbon实现的一套客户端  负载均衡工具
 简单的说,Ribbon是Netflix发布的开源项目,主要功能是提供客户端的软件负载均衡算法,将NetFlix的中间层服务连接在一起.Ribbon客户端组件提供一系列完善的配置项如连接超时,重试等.简单的说,就是在配置文件中列出Load Balancer(简称LB)后面所有的机器,Ribbon会自动的帮助你基于某种规则(如简单轮询,随机连接等)去连接这些机器.我们也很容易使用Ribbon实现自定义的负载均衡算法.

13.feign（本地服务调用）

Feign是一个声明式WebService客户端.使用Feign能让编写WebService客户端更加简单,它的使用方法是定义一个接口,然后再上面添加注解,用时也支持JAX-RS标准的注解.Feign也支持可拔插式的编码器和解码器,Spring CLoud对Feign进行了封装,使其支持了Spring MVC标准注解和HttpMessageConverters.Feign可以与Eureka和RIbbon组合使用以支持负载均衡.Feign是一个声明式的Web服务客户端,使得编写Web服务客户端变得非常容易,只需要创建一个接口,然后再上面添加注解即可

Feign能干什么
Feign旨在使编写Java HTTP客户端变得更容易.
前面在使用Ribbon+RestTemplate时,利用RestTemplate对http请求的封装处理,形成了一套模板化的调用方法,但在实际开发中,由于对服务以来的调用可能不止一处,往往一个接口会被多处调用,所以通常都会针对每个微服务自行封装一些客户端类来包装这些以来服务的调用.所以,Feign在此基础上做了进一步的封装,由他来帮助我们定义和实现依赖服务接口的定义.在Feign的实现下,我们只需要创建一个接口并使用注解的方式来配置它(以前是Dao接口上面标注Mapper注解,现在是一个微服务接口上面标注一个Feign注解即可),即可完成对服务提供方的接口绑定,简化了使用Spring Cloud Ribbon 时,自动封装服务调用客户端的开发量.

Feign通过接口的方法调用Rest服务(之前是Ribbon+RestTemplate),
该请求发送给Eureka服务器(http://MICROSERVICECLOUD-DEPT/dept/list),
通过Feign直接找到服务接口,由于在进行服务调用的时候融合了Ribbon技术,所以也支持负载均衡作用.

14.hystrix

服务雪崩
多个微服务之间调用的时候,假设微服务A调用微服务B和微服务C,微服务B和微服务C又调用其它的微服务,这就是所谓的"扇出".如果扇出的链路上某个微服务的调用响应时间过长或者不可用,对微服务A的调用会占用越来越多的系统资源,进而引起系统崩溃,所谓的"雪崩效应".对于高流量的应用来说,单一的后端依赖可能会导致所有服务器上的所有资源都在几秒钟内饱和.比失败更糟糕的是,这些应用程序还可能导致服务之间的延迟增加,备份队列,线程和其他系统资源紧张,导致整个系统发生更多的级联故障.这些都表示需要对故障和延迟进行隔离和管理,以便单个依赖关系的失败,不能取消整个应用程序或系统.

Hystrix是一个用于处理分布式系统的延迟和容错的开源库,在分布式系统里,许多依赖不可避免的会调用失败,比如超时、异常等,Hystrix能够保证在一个依赖出问题的情况下,不会导致整体服务失败,避免级联故障,以提高分布式系统的弹性.
 "断路器"本身是一种开关装置,当某个服务单元发生故障之后,通过断路器的故障监控(类似熔断保险丝),向调用方返回一个符合预期的,可处理的备选响应(FallBack),而不是长时间的等待或者抛出调用方法处理的异常,这样就保证了服务调用方的线程不会被长时间、不必要地占用,从而避免了故障在分布式系统中的蔓延,乃至雪崩.

服务熔断
熔断机制时应对雪崩效应的一种微服务链路保护机制
当扇出链路的某个微服务不可用或者响应时间太长,会进行服务的降级,进而熔断该节点微服务的调用,快速返回"错误"的响应信息.当检测到该节点微服务调用响应正常后恢复调用链路.在SpringCloud框架里熔断机制通过Hystrix实现.Hystrix会监控微服务调用的状况,当失败的调用到一定阈值,缺省是5秒内20次调用失败就会启动熔断机制.熔断机制的注解是@HystrixCommand.

服务降级：整体资源快不够了,忍痛将某些服务先关掉,待渡过难关,再开启回来，客户端自己带一个本地的fallback回调，返回一个缺省值。

15.Hystrix Dashboard

除了隔离依赖服务的调用以外,Hystrix还提供了准实时的调用监控(Hystrix Dashboard),Hystrix 会持续地记录所有通过Hystrix发起的请求的执行信息,并以统计报表和图形的形式展示给用户,包括每秒执行多少请求多少成功,多少失败等.Netflix通过hystrix-metrics-event-stream项目实现了对以上指标的监控.Spring Cloud也提供了Hystrix Dashboard的整合.对监控内容转化成可视化界面.

16.zuul

Zuul包含了对请求的路由和过滤两个最主要的功能:
其中路由功能负责将外部请求转发到具体的微服务实例上,是实现外部访问统一入口的基础,而过滤器功能则负责对请求的处理过程进行干预,是实现请求校验,服务聚合等功能的基础.Zuul和Eureka进行整合,将Zuul自身注册为Eureka服务治理下的应用,同时从Eureka中获得其他微服务的消息,也即以后的访问微服务都是通过Zuul跳转后获得.
注意:Zuul服务最终还是会注册进Eureka
提供=代理+路由+过滤三大功能

17:springCloud Config

微服务意味着要将单体应用中的业务拆分成一个个子服务,每个服务的粒度相对较小,因此系统中会出现大量的服务.由于每个服务都需要必要的配置信息才能运行,所以一套集中式的、动态的配置管理设施是必不可少的.SpringCloud提供了ConfigServer来解决这个问题.我们每一个微服务自己带着一个application.yml,上百个配置文件的管理.....

是什么
SpringCloud Config 为微服务架构中的微服务提供集中化的外部配置支持,配置服务器为各个不同微服务应用的所有环境提供了一个中心化的外部配置.
 怎么玩
SpringCloud Config分为服务端和客户端两部分.
 服务端也称为分布式配置中心,它是一个独立的微服务应用,用来连接配置服务器并为客户端提供获取配置信息,加密/解密信息等访问接口
 客户端则是通过制定的配置中心来管理应用资源,以及业务相关的配置内容,并在启动的时候从配置中心获取和加载配置信息配置服务器默认采用git来存储配置信息,这样就有助于对环境配置进行版本管理,并且可以通过git客户端工具来方便的管理和访问配置内容.

十四：乐优商城部分

1.单点登录

十五：电商项目服务器及人员配置

1.人员配置：

产品经理：3人，确定需求以及给出产品原型图。
项目经理：1人，项目管理。
前端团队：5人，根据产品经理给出的原型制作静态页面。
后端团队：20人，实现产品功能。
测试团队：5人，测试所有的功能。
运维团队：3人，项目的发布以及维护

2.服务器配置（17台）：

十六：TCP与UDP区别

• TCP面向连接（如打电话要先拨号建立连接）;UDP是无连接的，即发送数据之前不需要建立连接
• TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保证可靠交付
• TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流;UDP是面向报文的
• UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等）
• 每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信
• TCP首部开销20字节;UDP的首部开销小，只有8个字节
• TCP的逻辑通信信道是全双工的可靠信道，UDP则是不可靠信道

十七：开发中遇到的问题，如何解决

1.栈内存溢出（StackOverflow）

宽带加速递归方法时，由于跳出方法的条件没有限制好，导致栈内存溢出，用户进入首页空白，解决办法就是报这个用户的相关户据拉取下来，导入到测试数据库，通过调试查看为啥会出现栈内存溢出，修改跳出方法的条件。

2.堆内存溢出（OutOfMemory）

某次活动中，客户经理每个月出都会导出自己上个月的发展量为Excel，导致一瞬间，查出大量的数据在内存中，导致堆内存溢出。排错：通过堆快照、GC日志的分析，我们得到了最终的结论：问题确实出在excel导出方法，这个方法在内存中一次性加载的数据量太过庞大，虽然不是立即发生GC，但是新对象的不断堆积最终还是压垮JVM发生了内存溢出，这是一种典型的内存溢出问题。解决方法：

• 分配更大的JVM内存空间，但不推荐，目前系统流量不大，扩大空间只是缓兵之计
• 优化业务流程，每月初一凌晨定时生成excel数据，保存在硬盘中，用户若有需求，直接下载，下载完毕后，在删除对应文件。

十八：Tomcat执行流程

• 用户点击网页内容，请求被发送到本机端口8080，被在那里监听的Coyote HTTP/1.1 Connector获得。
• Connector把该请求交给它所在的Service的Engine来处理，并等待Engine的回应。
• Engine获得请求localhost/test/index.jsp，匹配所有的虚拟主机Host。
• Engine匹配到名为localhost的Host（即使匹配不到也把请求交给该Host处理，因为该Host被定义为该Engine的默认主机），名为localhost的Host获得请求/test/index.jsp，匹配它所拥有的所有的Context。Host匹配到路径为/test的Context（如果匹配不到就把该请求交给路径名为" "的Context去处理）。
• path=“/test”的Context获得请求/index.jsp，在它的mapping table中寻找出对应的Servlet。Context匹配到URL PATTERN为*.jsp的Servlet,对应于JspServlet类。
• 构造HttpServletRequest对象和HttpServletResponse对象，作为参数调用JspServlet的doGet（）或doPost（）.执行业务逻辑、数据存储等程序。
• Context把执行完之后的HttpServletResponse对象返回给Host。
• Host把HttpServletResponse对象返回给Engine。
• Engine把HttpServletResponse对象返回Connector。
• Connector把HttpServletResponse对象返回给客户Browser。

Connector->Service->Engine->Host->Context->Servlet->Context->Host->Engine->Connector->Browser

浏览器发起请求到8080端口，被监听protocol="HTTP/1.1"的Connector 捕获到，Connector将请求交给所在Service的Engine，并等待Engine返回，Engine匹配名为localhost的Host主机，默认也是这个主机，Host通过请求地址找到对应的Context，默认为路径配置为空的Context，Context找到对应的Servlet，构造HttpServletRequest及HttpServletResponse传入Servlet中，处理后，在将数据返回给Context，最后返回给浏览器。