java面试总结

JVM结构原理

JVM分为：类加载器（ClassLoader）、运行时数据区（虚拟机栈、本地方法栈、堆、方法区、程序计数器）、执行引擎、本地方法接口
类加载器（ClassLoader）:在JVM启动时或者在类运行时将需要的class加载到JVM中。
内存区（也叫运行时数据区）：是在JVM运行的时候操作所分配的内存区。
本地方法栈用于支持native方法的执行，存储了每个native方法的执行状态。
虚拟机栈占用的是操作系统内存，每个线程对应一个虚拟机栈，它是线程私有的，生命周期和线程一样，每个方法被执行时产生一个栈帧（Statck Frame），栈帧用于存储局部变量表、动态链接、操作数和方法出口等信息，当方法被调用时，方法的调用到结束对应着栈帧的入栈到出栈。
堆区是GC最频繁的，也是理解GC机制最重要的区域。堆区由所有线程共享，在虚拟机启动时创建。堆区主要用于存放对象实例及数组，所有new出来的对象都存储在该区域。
方法区存放了要加载的类的信息（如类名、修饰符等）、静态变量、构造函数、final定义的常量、类中的字段和方法等信息。方法区是全局共享的，在一定条件下也会被GC。当方法区超过它允许的大小时，就会抛出OutOfMemory：PermGen Space异常。
程序计数器是线程私有的，记录正在执行的虚拟机字节码指令地址。
执行引擎：负责执行class文件中包含的字节码指令
本地方法接口：主要是调用C或C++实现的本地方法及返回结果。

GC工作机制详解

垃圾收集器一般必须完成两件事：检测出垃圾；回收垃圾。怎么检测出垃圾？一般有以下几种方法：
**引用计数法：**给一个对象添加引用计数器，每当有个地方引用它，计数器就加1；引用失效就减1。
好了，问题来了，如果我有两个对象A和B，互相引用，除此之外，没有其他任何对象引用它们，实际上这两个对象已经无法访问，即是我们说的垃圾对象。但是互相引用，计数不为0，导致无法回收，所以还有另一种方法：
**可达性分析算法：**以根集对象为起始点进行搜索，如果有对象不可达的话，即是垃圾对象。这里的根集一般包括java栈中引用的对象、方法区常良池中引用的对象、本地方法中引用的对象等。
总之，JVM在做垃圾回收的时候，会检查堆中的所有对象是否会被这些根集对象引用，不能够被引用的对象就会被垃圾收集器回收。一般回收算法也有如下几种：
1.标记-清除（Mark-sweep）
算法和名字一样，分为两个阶段：标记和清除。标记所有需要回收的对象，然后统一回收。这是最基础的算法，后续的收集算法都是基于这个算法扩展的。
**2.复制（Copying）**此算法把内存空间划为两个相等的区域，每次只使用其中一个区域。垃圾回收时，遍历当前使用区域，把正在使用中的对象复制到另外一个区域中。此算法每次只处理正在使用中的对象，因此复制成本比较小，同时复制过去以后还能进行相应的内存整理，不会出现“碎片”问题。当然，此算法的缺点也是很明显的，就是需要两倍内存空间
3.标记-整理（Mark-Compact）
此算法结合了“标记-清除”和“复制”两个算法的优点。也是分两阶段，第一阶段从根节点开始标记所有被引用对象，第二阶段遍历整个堆，把 清除未标记对象并且把存活对象“压缩”到堆的其中一块，按顺序排放。此算法避免了“标记-清除”的碎片问题，同时也避免了“复制”算法的空间问题
4.分代收集算法
这是当前商业虚拟机常用的垃圾收集算法。分代的垃圾回收策略，是基于这样一个事实：不同的对象的生命周期是不一样的。因此，不同生命周期的对象可以采取不同的收集方式，以便提高回收效率。年轻代：是所有新对象产生的地方。
年轻代被分为3个部分——Enden区和两个Survivor区（From和to）当Eden区被对象填满时，就会执行Minor GC。并把所有存活下来的对象转移到其中一个survivor区（假设为from区）。Minor GC同样会检查存活下来的对象，并把它们转移到另一个survivor区（假设为to区）。这样在一段时间内，总会有一个空的survivor区。经过多次GC周期后，仍然存活下来的对象会被转移到年老代内存空间。通常这是在年轻代有资格提升到年老代前通过设定年龄阈值来完成的。需要注意，Survivor的两个区是对称的，没先后关系，from和to是相对的。
**年老代：**在年轻代中经历了N次回收后仍然没有被清除的对象，就会被放到年老代中，可以说他们都是久经沙场而不亡的一代，都是生命周期较长的对象。对于年老代和永久代，就不能再采用像年轻代中那样搬移腾挪的回收算法，因为那些对于这些回收战场上的老兵来说是小儿科。通常会在老年代内存被占满时将会触发Full GC,回收整个堆内存。
**持久代：**用于存放静态文件，比如java类、方法等。持久代对垃圾回收没有显著的影响。
1， 分代GC在新生代的算法：采用了GC的复制算法，速度快，因为新生代一般是新对象，都是瞬态的用了可能很快被释放的对象。
2， 分代GC在年老代的算法 标记／整理算法，GC后会执行压缩，整理到一个连续的空间，这样就维护着下一次分配对象的指针，下一次对象分配就可以采用碰撞指针技术，将新对象分配在第一个空闲的区域。

对RabbitMQ的个人理解

1、什么是RabbitMQ？为什么使用RabbitMQ？
答：RabbitMQ是一款开源的，Erlang编写的，基于AMQP协议的，消息中间件；
可以用它来：解耦、异步、削峰。
为什么要使用rabbitmq
1.在分布式系统下具备异步,削峰,负载均衡等一系列高级功能;
2.拥有持久化的机制，进程消息，队列中的信息也可以保存下来。
3.实现消费者和生产者之间的解耦。
4.对于高并发场景下，利用消息队列可以使得同步访问变为串行访问达到一定量的限流，利于数据库的操作。
5.可以使用消息队列达到异步下单的效果，排队中，后台进行逻辑下单。
2、RabbitMQ有什么优缺点？
答：优点：解耦、异步、削峰；
缺点：降低了系统的稳定性：本来系统运行好好的，现在你非要加入个消息队列进去，那消息队列挂了，你的系统不是呵呵了。因此，系统可用性会降低；
增加了系统的复杂性：加入了消息队列，要多考虑很多方面的问题，比如：一致性问题、如何保证消息不被重复消费、如何保证消息可靠性传输等。因此，需要考虑的东西更多，复杂性增大。
3、如何保证RabbitMQ的高可用？
答：没有哪个项目会只用一搭建一台RabbitMQ服务器提供服务，风险太大；
4、如何保证RabbitMQ不被重复消费？
答：先说为什么会重复消费：正常情况下，消费者在消费消息的时候，消费完毕后，会发送一个确认消息给消息队列，消息队列就知道该消息被消费了，就会将该消息从消息队列中删除；
但是因为网络传输等等故障，确认信息没有传送到消息队列，导致消息队列不知道自己已经消费过该消息了，再次将消息分发给其他的消费者。
针对以上问题，一个解决思路是：保证消息的唯一性，就算是多次传输，不要让消息的多次消费带来影响；保证消息等幂性；
比如：在写入消息队列的数据做唯一标示，消费消息时，根据唯一标识判断是否消费过；
5、如何保证RabbitMQ消息的可靠传输？
答：消息不可靠的情况可能是消息丢失，劫持等原因；
**丢失又分为：**生产者丢失消息、消息列表丢失消息、消费者丢失消息；
**生产者丢失消息：**从生产者弄丢数据这个角度来看，RabbitMQ提供transaction和confirm模式来确保生产者不丢消息；
transaction机制就是说：发送消息前，开启事务（channel.txSelect()）,然后发送消息，如果发送过程中出现什么异常，事务就会回滚（channel.txRollback()）,如果发送成功则提交事务（channel.txCommit()）。然而，这种方式有个缺点：吞吐量下降；
confirm模式用的居多：一旦channel进入confirm模式，所有在该信道上发布的消息都将会被指派一个唯一的ID（从1开始），一旦消息被投递到所有匹配的队列之后；
rabbitMQ就会发送一个ACK给生产者（包含消息的唯一ID），这就使得生产者知道消息已经正确到达目的队列了；
如果rabbitMQ没能处理该消息，则会发送一个Nack消息给你，你可以进行重试操作。
消息队列丢数据：消息持久化。
处理消息队列丢数据的情况，一般是开启持久化磁盘的配置。
这个持久化配置可以和confirm机制配合使用，你可以在消息持久化磁盘后，再给生产者发送一个Ack信号。
这样，如果消息持久化磁盘之前，rabbitMQ阵亡了，那么生产者收不到Ack信号，生产者会自动重发。
那么如何持久化呢？
这里顺便说一下吧，其实也很容易，就下面两步
将queue的持久化标识durable设置为true,则代表是一个持久的队列
发送消息的时候将deliveryMode=2
这样设置以后，即使rabbitMQ挂了，重启后也能恢复数据
消费者丢失消息：消费者丢数据一般是因为采用了自动确认消息模式，改为手动确认消息即可！
消费者在收到消息之后，处理消息之前，会自动回复RabbitMQ已收到消息；
如果这时处理消息失败，就会丢失该消息；
解决方案：处理消息成功后，手动回复确认消息。
6、如何保证RabbitMQ消息的顺序性？
答：单线程消费保证消息的顺序性；对消息进行编号，消费者处理消息是根据编号处理消息；
7.如何确保消息正确地发送至RabbitMQ？ 如何确保消息接收方消费了消息？
发送方确认模式：
将信道设置成confirm模式（发送方确认模式），则所有在信道上发布的消息都会被指派一个唯一的ID。
一旦消息被投递到目的队列后，或者消息被写入磁盘后（可持久化的消息），信道会发送一个确认给生产者（包含消息唯一ID）。
如果RabbitMQ发生内部错误从而导致消息丢失，会发送一条nack（not acknowledged，未确认）消息。
发送方确认模式是异步的，生产者应用程序在等待确认的同时，可以继续发送消息。当确认消息到达生产者应用程序，生产者应用程序的回调方法就会被触发来处理确认消息。

接收方确认机制
接收方消息确认机制：消费者接收每一条消息后都必须进行确认（消息接收和消息确认是两个不同操作）。只有消费者确认了消息，RabbitMQ才能安全地把消息从队列中删除。
这里并没有用到超时机制，RabbitMQ仅通过Consumer的连接中断来确认是否需要重新发送消息。也就是说，只要连接不中断，RabbitMQ给了Consumer足够长的时间来处理消息。保证数据的最终一致性；
下面罗列几种特殊情况：
如果消费者接收到消息，在确认之前断开了连接或取消订阅，RabbitMQ会认为消息没有被分发，然后重新分发给下一个订阅的消费者。（可能存在消息重复消费的隐患，需要去重）
如果消费者接收到消息却没有确认消息，连接也未断开，则RabbitMQ认为该消费者繁忙，将不会给该消费者分发更多的消息。
8.如何避免消息重复投递或重复消费？
在消息生产时，MQ内部针对每条生产者发送的消息生成一个inner-msg-id，作为去重的依据（消息投递失败并重传），避免重复的消息进入队列；
在消息消费时，要求消息体中必须要有一个bizId（对于同一业务全局唯一，如支付ID、订单ID、帖子ID等）作为去重的依据，避免同一条消息被重复消费。
9.消息基于什么传输？
由于TCP连接的创建和销毁开销较大，且并发数受系统资源限制，会造成性能瓶颈。RabbitMQ使用信道的方式来传输数据。信道是建立在真实的TCP连接内的虚拟连接，且每条TCP连接上的信道数量没有限制。

10.消息如何分发？
若该队列至少有一个消费者订阅，消息将以循环（round-robin）的方式发送给消费者。每条消息只会分发给一个订阅的消费者（前提是消费者能够正常处理消息并进行确认）。
通过路由可实现多消费的功能

11.消息怎么路由？
消息提供方->路由->一至多个队列
消息发布到交换器时，消息将拥有一个路由键（routing key），在消息创建时设定。
通过队列路由键，可以把队列绑定到交换器上。
消息到达交换器后，RabbitMQ会将消息的路由键与队列的路由键进行匹配（针对不同的交换器有不同的路由规则）；
常用的交换器主要分为一下三种：
fanout：如果交换器收到消息，将会广播到所有绑定的队列上
direct：如果路由键完全匹配，消息就被投递到相应的队列
topic：可以使来自不同源头的消息能够到达同一个队列。 使用topic交换器时，可以使用通配符

12.如何确保消息不丢失？
消息持久化，当然前提是队列必须持久化
RabbitMQ确保持久性消息能从服务器重启中恢复的方式是，将它们写入磁盘上的一个持久化日志文件，当发布一条持久性消息到持久交换器上时，Rabbit会在消息提交到日志文件后才发送响应。
一旦消费者从持久队列中消费了一条持久化消息，RabbitMQ会在持久化日志中把这条消息标记为等待垃圾收集。如果持久化消息在被消费之前RabbitMQ重启，那么Rabbit会自动重建交换器和队列（以及绑定），并重新发布持久化日志文件中的消息到合适的队列。

事物传播行为介绍

@Transactional(propagation=Propagation.REQUIRED)
如果有事务, 那么加入事务, 没有的话新建一个(默认情况下)
@Transactional(propagation=Propagation.NOT_SUPPORTED)
容器不为这个方法开启事务
@Transactional(propagation=Propagation.REQUIRES_NEW)
不管是否存在事务,都创建一个新的事务,原来的挂起,新的执行完毕,继续执行老的事务
@Transactional(propagation=Propagation.MANDATORY)
必须在一个已有的事务中执行,否则抛出异常
@Transactional(propagation=Propagation.NEVER)
必须在一个没有的事务中执行,否则抛出异常(与Propagation.MANDATORY相反)
@Transactional(propagation=Propagation.SUPPORTS)
如果其他bean调用这个方法,在其他bean中声明事务,那就用事务.如果其他bean没有声明事务,那就不用事务.
事物超时设置:
@Transactional(timeout=30) //默认是30秒

事务特性

1）原子性：诸多操作要么全做，要么全不做
2）一致性：事务执行结果使数据库从一个一致性状态变到另一个一致性状态
3）隔离性：事务执行不被其他事务影响
4）持久性：一旦提交，对数据库的改变是永久性的

事务隔离级别

@Transactional(isolation = Isolation.READ_UNCOMMITTED)
读取未提交数据(会出现脏读, 不可重复读) 基本不使用
@Transactional(isolation = Isolation.READ_COMMITTED)
读取已提交数据(会出现不可重复读和幻读)
@Transactional(isolation = Isolation.REPEATABLE_READ)
可重复读(会出现幻读)
@Transactional(isolation = Isolation.SERIALIZABLE)
串行化

MYSQL: 默认为REPEATABLE_READ级别 可重复读(会出现幻读)
SQLSERVER: 默认为READ_COMMITTED 读取已提交数据(会出现不可重复读和幻读)

脏读 : 一个事务读取到另一事务未提交的更新数据
不可重复读 : 在同一事务中, 多次读取同一数据返回的结果有所不同, 换句话说,
后续读取可以读到另一事务已提交的更新数据. 相反, "可重复读"在同一事务中多次
读取数据时, 能够保证所读数据一样, 也就是后续读取不能读到另一事务已提交的更新数据
幻读 : 一个事务读到另一个事务已提交的insert数据

Hibernate与Mybatis对比总结

两者相同点
Hibernate与MyBatis都可以是通过SessionFactoryBuider由XML配置文件生成SessionFactory，然后由SessionFactory 生成Session，最后由Session来开启执行事务和SQL语句。其中SessionFactoryBuider，SessionFactory，Session的生命周期都是差不多的。
Hibernate和MyBatis都支持JDBC和JTA事务处理。
Mybatis优势
MyBatis可以进行更为细致的SQL优化，可以减少查询字段。
MyBatis容易掌握，而Hibernate门槛较高。
Hibernate优势
Hibernate的DAO层开发比MyBatis简单，Mybatis需要维护SQL和结果映射。
Hibernate对对象的维护和缓存要比MyBatis好，对增删改查的对象的维护要方便。
Hibernate数据库移植性很好，MyBatis的数据库移植性不好，不同的数据库需要写不同SQL。Hibernate有更好的二级缓存机制，可以使用第三方缓存。MyBatis本身提供的缓存机制不佳。

Java多线程sleep和wait的区别

使用上
从使用角度看，sleep是Thread线程类的方法，而wait是Object顶级类的方法。
sleep可以在任何地方使用，而wait只能在同步方法或者同步块中使用。
CPU及资源锁释放
sleep,wait调用后都会暂停当前线程并让出cpu的执行时间，但不同的是sleep不会释放当前持有的对象的锁资源，到时间后会继续执行，而wait会放弃所有锁并需要notify/notifyAll后重新获取到对象锁资源后才能继续执行。
异常捕获
sleep需要捕获或者抛出异常，而wait/notify/notifyAll不需要。

java中volatile和synchronized有什么区别

1.volatile本质是在告诉jvm当前变量在寄存器（工作内存）中的值是不确定的，需要从主存中读取；synchronized则是锁定当前变量，只有当前线程可以访问该变量，其他线程被阻塞住。
2.volatile仅能使用在变量级别；synchronized则可以使用在变量、方法、和类级别的。
3.volatile仅能实现变量的修改可见性，并不能保证原子性；而synchronized则可以保证变量的修改可见性和原子性。
4.volatile不会造成线程的阻塞；synchronized可能会造成线程的阻塞。
5.volatile标记的变量不会被编译器优化；synchronized标记的变量可以被编译器优化。

有了解java的原子类？实现原理是什么?

采用硬件提供原子操作指令实现的，即CAS。每次调用都会先判断预期的值是否符合，才进行写操作，保证数据安全。

说说数据库性能优化有哪些方法？

使用explain进行优化，查看sql是否充分使用索引。避免使用in,用exist替代，字段值尽可能使用更小的值，任何对列的操作都将导致表扫描，它包括数据库函数、计算表达式等等，查询时要尽可能将操作移至等号右边。使用连接查询(join)代替子查询。
在表的多列字段上建立一个索引，但只有在查询这些字段的第一个字段时，索引才会被使用。

HTTP请求方法get和post有什么区别？

1：Post传输数据时，不需要在URL中显示出来，而Get方法要在URL中显示。
2：Post传输的数据量大，可以达到2M，而Get方法由于受到URL长度限制,只能传递大约1024字节.
3：Post就是为了将数据传送到服务器段,Get就是为了从服务器段取得数据.而Get 之所以也能传送数据,只是用来设计告诉服务器,你到底需要什么样的数据.Post的信息作为http请求的内容，而Get是在Http头部传输的。

linux命令熟悉？查看某个线程命令是什么？查看整个机器负载命令？文件内容快速查找命令是什么？

查看线程：ps -ef|greptomcat
查看负载：top
文件内容查找：vi /aa test.txt 或者先打开文件，再查找: vi test.txt /aa

java抽象类和接口有什么区别？项目中怎么去使用它们？

相同点：
1.两者都是抽象类，都不能实例化。
2.interface实现类及abstractclass的子类都必须要实现已经声明的抽象方法。
不同点：
1.interface需要实现，要用implements，而abstractclass需要继承，要用extends。
2.一个类可以实现多个interface，但一个类只能继承一个abstractclass。
3.interface强调特定功能的实现，而abstractclass强调所属关系。
.4.尽管interface实现类及abstrctclass的子类都必须要实现相应的抽象方法，但实现的形式不同。interface中的每一个方法都是抽象方法，都只是声明的 (declaration, 没有方法体)，实现类必须要实现。而abstractclass的子类可以有选择地实现。
使用：
abstract：在既需要统一的接口，又需要实例变量或缺省的方法的情况下，使用abstract;
interface：使用: 类与类之前需要特定的接口进行协调，而不在乎其如何实现。 作为能够实现特定功能的标识存在，也可以是什么接口方法都没有的纯粹标识。需要将一组类视为单一的类，而调用者只通过接口来与这组类发生联系。需要实现特定的多项功能，而这些功能之间可能完全没有任何联系。

了解java反射机制？获取Class对象几种方式?反射生成类，能访问私有变量？

在 Java API 中，提供了获取 Class 类对象的三种方法：
第一种，使用 Class.forName 静态方法。
前提：已明确类的全路径名。
第二种，使用 .class 方法。
说明：仅适合在编译前就已经明确要操作的 Class
第三种，使用类对象的 getClass() 方法。
适合有对象示例的情况下
动态生成java的实例，可以

四种权限修饰符private、默认、protected、public作用范围

1）private，同类
2）默认，同类、同包
3）protected，同类，同包，子类
4）public，所有

List、Set、Collections区别

1）List，有序可重复
2）Set， 无序不可重复
3）Collections，集合工具类

spring mvc 和 struts2区别

一、框架机制
spring mvc 和 struts2的加载机制不同：spring mvc的入口是servlet，而struts2是filter(servlet和filter区别见本文最后)
1、Struts2采用Filter（StrutsPrepareAndExecuteFilter）实现，SpringMVC（DispatcherServlet）则采用Servlet实现。
2、Filter在容器启动之后即初始化；服务停止以后坠毁，晚于Servlet。Servlet在是在调用时初始化，先于Filter调用，服务停止后销毁。
二、拦截机制
1、Struts2
a、Struts2框架是类级别的拦截，每次请求就会创建一个Action，和Spring整合时Struts2的ActionBean注入作用域是原型模式prototype（否则会出现线程并发问题），然后通过setter，getter吧request数据注入到属性。
b、Struts2中，一个Action对应一个request，response上下文，在接收参数时，可以通过属性接收，这说明属性参数是让多个方法共享的。
c、Struts2中Action的一个方法可以对应一个url，而其类属性却被所有方法共享，这也就无法用注解或其他方式标识其所属方法了
2、SpringMVC
a、SpringMVC是方法级别的拦截，一个方法对应一个Request上下文，所以方法直接基本上是独立的，独享request，response数据。而每个方法同时又何一个url对应，参数的传递是直接注入到方法中的，是方法所独有的。处理结果通过ModeMap返回给框架。
b、在Spring整合时，SpringMVC的Controller Bean默认单例模式Singleton，所以默认对所有的请求，只会创建一个Controller，有应为没有共享的属性，所以是线程安全的，如果要改变默认的作用域，需要添加@Scope注解修改。
三、性能方面
SpringMVC实现了零配置，由于SpringMVC基于方法的拦截，有加载一次单例模式bean注入。而Struts2是类级别的拦截，每次请求对应实例一个新的Action，需要加载所有的属性值注入，所以，SpringMVC开发效率和性能高于Struts2。
四、拦截机制
Struts2有自己的拦截Interceptor机制，SpringMVC这是用的是独立的Aop方式，这样导致Struts2的配置文件量还是比SpringMVC大。
五、配置方面
spring MVC和Spring是无缝的。从这个项目的管理和安全上也比Struts2高（当然Struts2也可以通过不同的目录结构和相关配置做到SpringMVC一样的效果，但是需要xml配置的地方不少）。
SpringMVC可以认为已经100%零配置。
六、设计思想
Struts2更加符合OOP的编程思想， SpringMVC就比较谨慎，在servlet上扩展。
七、集成方面
SpringMVC集成了Ajax，使用非常方便，只需一个注解@ResponseBody就可以实现，然后直接返回响应文本即可，而Struts2拦截器集成了Ajax，在Action中处理时一般必须安装插件或者自己写代码集成进去，使用起来也相对不方便。

$和#的区别

#将传入的数据都当成一个字符串，会对自动传入的数据加一个双引号。
KaTeX parse error: Expected 'EOF', got '#' at position 20: …数据直接显示生成在sql中。 #̲方式能够很大程度防止sql注入…方式无法防止Sql注入。
$方式一般用于传入数据库对象，例如传入表名。
从安全性上考虑，能使用#尽量使用#来传参，因为这样可以有效防止SQL注入的问题。

inner join、left join、 right join区别

1）inner join，两表字段值相同
2）left join，两表字段值相同，以及左表字段有值，右表字段值为null
3）right join，与上相反

Dubbo 和 Spring Cloud 有什么区别？

一.两者的模块组成：
1、Dubbo主要分为服务注册中心，服务提供者，服务消费者，还有管控中心；
2、相比起Dubbo简单的四个模块，SpringCloud则是一个完整的分布式一站式框架，他有着一样的服务注册中心，服务提供者，服务消费者，管控台，断路器，分布式配置服务，消息总线，以及服务追踪等；
二.在性能上来说
由于Dubbo底层是使用Netty这样的NIO框架，是基于TCP协议传输的，配合以Hession序列化完成RPC。而SpringCloud是基于Http协议+rest接口调用远程过程的，相对来说，Http请求会有更大的报文，占的带宽也会更多。如图所示：（图片借用某博客，如有侵权请告知，我删了）

Nginx负载均衡算法

1、轮询（默认）
每个请求按时间顺序逐一分配到不同的后端服务，如果后端某台服务器死机，自动剔除故障系统，使用户访问不受影响。
2、weight（轮询权值）
weight的值越大分配到的访问概率越高，主要用于后端每台服务器性能不均衡的情况下。或者仅仅为在主从的情况下设置不同的权值，达到合理有效的地利用主机资源。
3、ip_hash
每个请求按访问IP的哈希结果分配，使来自同一个IP的访客固定访问一台后端服务器，并且可以有效解决动态网页存在的session共享问题。
4、fair
比 weight、ip_hash更加智能的负载均衡算法，fair算法可以根据页面大小和加载时间长短智能地进行负载均衡，也就是根据后端服务器的响应时间 来分配请求，响应时间短的优先分配。Nginx本身不支持fair，如果需要这种调度算法，则必须安装upstream_fair模块。
5、url_hash
按访问的URL的哈希结果来分配请求，使每个URL定向到一台后端服务器，可以进一步提高后端缓存服务器的效率。Nginx本身不支持url_hash，如果需要这种调度算法，则必须安装Nginx的hash软件包。
1.轮询（默认）
每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。
2.weight
指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。
例如：

upstream bakend {  

    server 192.168.0.14 weight=10;  
    
    server 192.168.0.15 weight=10;  

}

3.ip_hash

每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。
例如：
upstream bakend {

    ip_hash;  
    
    server 192.168.0.14:88;  
    
    server 192.168.0.15:80;  

}

4.fair（第三方）

按后端服务器的响应时间来分配请求，响应时间短的优先分配。

upstream backend { 
   server server1;  
   server server2;  
	fair;  
}

5.url_hash（第三方）
按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存时比较有效。
例：在upstream中加入hash语句，server语句中不能写入weight等其他的参数，hash_method是使用的hash算法

upstream backend {  

	    server squid1:3128;  
	    
	    server squid2:3128;  
	    
	    hash $request_uri;  
	    
	    hash_method crc32;
}

redis的主从复制原理

1、从库向主库发送sync命令，也就是从库向主库发送同步请求；
2、当主库接受到sync命令后，会执行bgsave命令(保存此刻主库的一个快照)，创建一个RDB文件，创建RDB文件期间主库上的执行过的命令都会被保存到缓冲区中；
3、当主库执行完bgsave时，会向从库发送RDB文件，从库接受该文件并加载该文件，将自己的数据库状态更新至主服务器执行BGSAVE命令时的数据库状态；
4、主库将缓冲区的所有写命令发给从库执行；
5、至此可以认为redis主从建立成功，之后主库的每一个写命令都会传到从库上执行。
复制原理说明：
master创建RDB文件是通过一个子进程进行的，所以master依然可以处理客户端发来的请求。但这也导致了在保存RDB文件期间，“键空间”可能发生变化（譬如接收到一个客户端请求，执行”set name diaocow”命令），因此为了保证数据同步的一致性，master会在保存RDB文件期间，把接受到的这些可能变更数据库“键空间”的命令保存到缓冲区中。