Spring的核心特性就是IOC和AOP，IOC（Inversion of Control），即“控制反转”；AOP（Aspect-OrientedProgramming），即“面向切面编程”。

IOC：IOC，另外一种说法叫DI（Dependency Injection），即依赖注入。它并不是一种技术实现，而是一种设计思想。在任何一个有实际开发意义的程序项目中，我们会使用很多类来描述它们特有的功能，并且通过类与类之间的相互协作来完成特定的业务逻辑。这个时候，每个类都需要负责管理与自己有交互的类的引用和依赖，代码将会变的异常难以维护和极度的高耦合。而IOC的出现正是用来解决这个问题，我们通过IOC将这些相互依赖对象的创建、协调工作交给Spring容器去处理，每个对象只需要关注其自身的业务逻辑关系就可以了。在这样的角度上来看，获得依赖的对象的方式，进行了反转，变成了由spring容器控制对象如何获取外部资源（包括其他对象和文件资料等等）。

AOP：面向切面编程，往往被定义为促使软件系统实现关注点的分离的技术。系统是由许多不同的组件所组成的，每一个组件各负责一块特定功能。除了实现自身核心功能之外，这些组件还经常承担着额外的职责。例如日志、事务管理和安全这样的核心服务经常融入到自身具有核心业务逻辑的组件中去。这些系统服务经常被称为横切关注点，因为它们会跨越系统的多个组件。

JDBC的理解

JDBC（Java DataBase Connectivity,java数据库连接）是一种用于执行SQL语句的Java API，可以为多种关系数据库提供统一访问，它由一组用Java语言编写的类和接口组成。JDBC提供了一种基准，据此可以构建更高级的工具和接口，使数据库开发人员能够编写数据库应用程序

有了JDBC，向各种关系数据发送SQL语句就是一件很容易的事。换言之，有了JDBC API，就不必为访问Sybase数据库专门写一个程序，为访问Oracle数据库又专门写一个程序，或为访问Informix数据库又编写另一个程序等等，程序员只需用JDBC API写一个程序就够了，它可向相应数据库发送SQL调用。

Ajax异步和同步

同步是指：发送方发出数据后，等接收方发回响应以后才发下一个数据包的通讯方式。 

异步是指：发送方发出数据后，不等接收方发回响应，接着发送下个数据包的通讯方式。

同步通信方式要求通信双方以相同的时钟频率进行，而且准确协调，通过共享一个单个时钟或定时脉冲源保证发送方和接收方的准确同步，效率较高； 

异步通信方式不要求双方同步，收发方可采用各自的时钟源，双方遵循异步的通信协议，以字符为数据传输单位，发送方传送字符的时间间隔不确定，发送效率比同步传送效率低。

使用者可以同步或异步实现服务调用。从使用者的观点来看，这两种方式的不同之处在于： 

同步——使用者通过单个线程调用服务；该线程发送请求，在服务运行时阻塞，并且等待响应。 

异步——使用者通过两个线程调用服务；一个线程发送请求，而另一个单独的线程接收响应。

秒杀活动

秒杀架构设计理念

限流： 鉴于只有少部分用户能够秒杀成功，所以要限制大部分流量，只允许少部分流量进入服务后端。

削峰：对于秒杀系统瞬时会有大量用户涌入，所以在抢购一开始会有很高的瞬间峰值。高峰值流量是压垮系统很重要的原因，所以如何把瞬间的高流量变成一段时间平稳的流量也是设计秒杀系统很重要的思路。实现削峰的常用的方法有利用缓存和消息中间件等技术。

异步处理：秒杀系统是一个高并发系统，采用异步处理模式可以极大地提高系统并发量，其实异步处理就是削峰的一种实现方式。

内存缓存：秒杀系统最大的瓶颈一般都是数据库读写，由于数据库读写属于磁盘IO，性能很低，如果能够把部分数据或业务逻辑转移到内存缓存，效率会有极大地提升。

可拓展：当然如果我们想支持更多用户，更大的并发，最好就将系统设计成弹性可拓展的，如果流量来了，拓展机器就好了。像淘宝、京东等双十一活动时会增加大量机器应对交易高峰。

前端方案

浏览器端(js)：

页面静态化：将活动页面上的所有可以静态的元素全部静态化，并尽量减少动态元素。通过CDN来抗峰值。

禁止重复提交：用户提交之后按钮置灰，禁止重复提交 

用户限流：在某一时间段内只允许用户提交一次请求，比如可以采取IP限流

后端方案

服务端控制器层(网关层)

限制uid（UserID）访问频率：我们上面拦截了浏览器访问的请求，但针对某些恶意攻击或其它插件，在服务端控制层需要针对同一个访问uid，限制访问频率。

服务层

上面只拦截了一部分访问请求，当秒杀的用户量很大时，即使每个用户只有一个请求，到服务层的请求数量还是很大。比如我们有100W用户同时抢100台手机，服务层并发请求压力至少为100W。

采用消息队列缓存请求：既然服务层知道库存只有100台手机，那完全没有必要把100W个请求都传递到数据库啊，那么可以先把这些请求都写到消息队列缓存一下，数据库层订阅消息减库存，减库存成功的请求返回秒杀成功，失败的返回秒杀结束。

利用缓存应对读请求：对类似于12306等购票业务，是典型的读多写少业务，大部分请求是查询请求，所以可以利用缓存分担数据库压力。

利用缓存应对写请求：缓存也是可以应对写请求的，比如我们就可以把数据库中的库存数据转移到Redis缓存中，所有减库存操作都在Redis中进行，然后再通过后台进程把Redis中的用户秒杀请求同步到数据库中。

数据库层

数据库层是最脆弱的一层，一般在应用设计时在上游就需要把请求拦截掉，数据库层只承担“能力范围内”的访问请求。所以，上面通过在服务层引入队列和缓存，让最底层的数据库高枕无忧。

案例：利用消息中间件和缓存实现简单的秒杀系统

Redis是一个分布式缓存系统，支持多种数据结构，我们可以利用Redis轻松实现一个强大的秒杀系统。

我们可以采用Redis 最简单的key-value数据结构，用一个原子类型的变量值(AtomicInteger)作为key，把用户id作为value，库存数量便是原子变量的最大值。对于每个用户的秒杀，我们使用 RPUSH key value插入秒杀请求， 当插入的秒杀请求数达到上限时，停止所有后续插入。

然后我们可以在台启动多个工作线程，使用 LPOP key 读取秒杀成功者的用户id，然后再操作数据库做最终的下订单减库存操作。

当然，上面Redis也可以替换成消息中间件如ActiveMQ、RabbitMQ等，也可以将缓存和消息中间件 组合起来，缓存系统负责接收记录用户请求，消息中间件负责将缓存中的请求同步到数据库。

单点登陆如果在另一台电脑上登陆并修改了密码怎么办？

（Single Sign On），简称为 SSO，是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。

当用户第一次访问应用系统的时候，因为还没有登录，会被引导到认证系统中进行登录；根据用户提供的登录信息，认证系统进行身份校验，如果通过校验，应该返回给用户一个认证的凭据－－ticket；用户再访问别的应用的时候，就会将这个ticket带上，作为自己认证的凭据，应用系统接受到请求之后会把ticket送到认证系统进行校验，检查ticket的合法性。如果通过校验，用户就可以在不用再次登录的情况下访问应用系统2和应用系统3了。

要实现SSO，需要以下主要的功能：

所有应用系统共享一个身份认证系统。
　　统一的认证系统是SSO的前提之一。认证系统的主要功能是将用户的登录信息和用户信息库相比较，对用户进行登录认证；认证成功后，认证系统应该生成统一的认证标志（ticket），返还给用户。另外，认证系统还应该对ticket进行效验，判断其有效性。

所有应用系统能够识别和提取ticket信息
　　要实现SSO的功能，让用户只登录一次，就必须让应用系统能够识别已经登录过的用户。应用系统应该能对ticket进行识别和提取，通过与认证系统的通讯，能自动判断当前用户是否登录过，从而完成单点登录的功能。

当用户在另一终端登陆并修改密码，则对应的ticket附带的信息会发生改变，导致原有ticket因无法通过校验而失效。因此要求用户使用新的密码重新登陆。

在我们的电商项目中，单点登陆使用的验证字符串叫token。这里的ticket是门票的意思，与我们学的token对应相同。

Redis宕机之后，购物车中的数据如何处理？如何缓解mysql压力？

用redis保存的*.rdb文件恢复即可。

另外redis还有AOF功能，启动时可以自动恢复到前一条查询。

这样做在一定程度上减少数据丢失。但重启redis会需要从关系型数据库中读取数据，增大mysql的压力。

依据实际情况，如果redis之前有主从复制，则可在其他节点redis上拿到数据。如果公司没钱，则只能暂时限制客户端访问量，优先恢复redis数据。

Zookeeper待机的情况下，dubbo如何工作？

1.   Zookeeper的作用：

        zookeeper用来注册服务和进行负载均衡，哪一个服务由哪一个机器来提供必需让调用者知道，简单来说就是ip地址和服务名称的对应关系。当然也可以 通过硬编码的方式把这种对应关系在调用方业务代码中实现，但是如果提供服务的机器挂掉调用者无法知晓，如果不更改代码会继续请求挂掉的机器提供服务。 zookeeper通过心跳机制可以检测挂掉的机器并将挂掉机器的ip和服务对应关系从列表中删除。至于支持高并发，简单来说就是横向扩展，在不更改代码 的情况通过添加机器来提高运算能力。通过添加新的机器向zookeeper注册服务，服务的提供者多了能服务的客户就多了。

2.  dubbo：

      是管理中间层的工具，在业务层到数据仓库间有非常多服务的接入和服务提供者需要调度，dubbo提供一个框架解决这个问题。

      注意这里的dubbo只是一个框架，至于你架子上放什么是完全取决于你的，就像一个汽车骨架，你需要配你的*引擎。这个框架中要完成调度必须要有一个分布式的注册中心，储存所有服务的元数据，你可以用zk，也可以用别的，只是大家都用zk。

3. zookeeper和dubbo的关系：

      Dubbo的将注册中心进行抽象，是得它可以外接不同的存储媒介给注册中心提供服务，有ZooKeeper，Memcached，Redis等。

      引入了ZooKeeper作为存储媒介，也就把ZooKeeper的特性引进来。首先是负载均衡，单注册中心的承载能力是有限的，在流量达到一定程度的时 候就需要分流，负载均衡就是为了分流而存在的，一个ZooKeeper群配合相应的Web应用就可以很容易达到负载均衡；资源同步，单单有负载均衡还不 够，节点之间的数据和资源需要同步，ZooKeeper集群就天然具备有这样的功能；命名服务，将树状结构用于维护全局的服务地址列表，服务提供者在启动 的时候，向ZK上的指定节点/dubbo/${serviceName}/providers目录下写入自己的URL地址，这个操作就完成了服务的发布。 其他特性还有Mast选举，分布式锁等。

从MQ在完成订单之后，发送消息锁定库存。消息始终失败。

网关是如何实现？

就是定义一个Servlet接收请求。然后经过preFilter(封装请求参数),routeFilter(转发请求)，postFilter(输出内容)。三个过滤器之间，共享request、response以及其他的一些全局变量。

(1)将request,response放入threadlocal中

(2)执行三组过滤器

(3)清除threadlocal中的的环境变量

Redis和mysql数据同步是先删除redis还是先删除mysql？

不管是先写库，再删除缓存；还是先删缓存，再写库，都有可能出现数据不一致的情况

因为写和读是并发的，没法保证顺序，如果删了缓存，还没有来得及写库，另一个线程就来读取，发现缓存为空，则去数据库中读取数据写入缓存，此时缓存中为脏数据。如果先写了库，再删除缓存前，写库的线程宕机了，没有删除掉缓存，则也会出现数据不一致情况。 如果是redis集群，或者主从模式，写主读从，由于redis复制存在一定的时间延迟，也有可能导致数据不一致。

这时候，考虑先删除数据库内容，再删redis。因为在库存等实时数据都是直接在数据库中读取，从业务逻辑上来说，我们允许查询时的数据缓存误差，但是不允许结算时的数据存在误差。

Hashmap为什么线程不安全，如何让它线程安全

HashMap在put的时候，插入的元素超过了容量（由负载因子决定）的范围就会触发扩容操作，就是rehash，这个会重新将原数组的内容重新hash到新的扩容数组中，在多线程的环境下，存在同时其他的元素也在进行put操作，如果hash值相同，可能出现同时在同一数组下用链表表示，造成闭环，导致在get时会出现死循环，所以HashMap是线程不安全的。

使用 java.util.Hashtable 类，此类是线程安全的。

使用 java.util.concurrent.ConcurrentHashMap，此类是线程安全的。

使用 java.util.Collections.synchronizedMap() 方法包装 HashMap object，得到线程安全的Map，并在此Map上进行操作。

Spring cloud原理 网关

Eureka是微服务架构中的注册中心，专门负责服务的注册与发现。Eureka Client组件，这个组件专门负责将这个服务的信息注册到Eureka Server中。Eureka Server是一个注册中心，里面有一个注册表，保存了各服务所在的机器和端口号。

Zuul，也就是微服务网关。这个组件是负责网络路由的。而且有一个网关之后，还有很多好处，比如可以做统一的降级、限流、认证授权、安全，等等。

Dubbo+zookeeper如何集群

Dubbo 是Alibaba开源的分布式服务框架，它最大的特点是按照分层的方式来架构，使用这种方式可以使各个层之间解耦合（或者最大限度地松耦合）。从服务模型的角度来看，Dubbo采用的是一种非常简单的模型，要么是提供方提供服务，要么是消费方消费服务，所以基于这一点可以抽象出服务提供方（Provider）和服务消费方（Consumer）两个角色。

ZooKeeper 是 Apache 的一个*项目，为分布式应用提供高效、高可用的分布式协调服务，提供了诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知和分布式锁等分布式基础服务。由于 ZooKeeper 便捷的使用方式、卓越的性能和良好的稳定性，被广泛地应用于诸如 Hadoop、HBase、Kafka 和 Dubbo 等大型分布式系统中。

Nginx 是一款*的、开源的、高性能的HTTP服务器和反向代理服务器；同时也是一个IMAP、POP3、SMTP代理服务器；Nginx可以作为一个HTTP服务器进行网站的发布处理，另外Nginx可以作为反向代理进行负载均衡的实现。

设计模式在项目中如何体现

1、模板方法模式 
定义一个操作中的算法的骨架，而将一些步骤延迟到子类中，如JdbcTemplate 
2、代理 
spring的Proxy模式在aop中有体现 
3、观察者 
定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。 
spring中Observer模式常用的地方是listener的实现。如ApplicationListener。 
4、适配器（Adapter ） 
MethodBeforeAdviceAdapter类 
5、策略模式 
使用了java的继承和多态 
案例1：加减法计算器，定义一个计算类接口，加法和减法类都实现它，加的时候传入加法对象。 
案例2：导出excel,pdf,word时，分别创建不同的对象 
简单理解：执行多个事情时，创建多个对象 
6、单例模式 
解决一个全局使用的类频繁的创建与销毁 
7、工厂模式 
分为三种：简单工厂，工厂方法，抽象工厂 
根据“需求”生产“产品”，解耦“需求”“工厂”和“产品”。

简单工厂：通过构造时传入的标识来生产产品，不同产品都在同一个工厂中生产，每新增加一种产品，需要改工厂类，来判断，这种判断会随着产品的增加而增加，给扩展和维护带来麻烦 
简单工厂项目案例：根据传入的 不同（比如1对应支付流水，2 对应订单流水），生成不同类型的流水号

工厂方法：（使一个类的使用延迟到子类） 
其中的工厂类根据传入的A.class类型，反射出实例。 
产品接口，产品类A，产品类B，工厂类可以生成不同的产品类对象，如果要随着产品的增加而增加，工厂类不变，只需新增一个产品类C即可。 
项目案例：邮件服务器，有三种协议，POP3，IMAP,HTTP,把这三种做完产品类，在定义个工厂方法

抽象工厂：一个工厂生产多个产品，它们是一个产品族，不同的产品族的产品派生于不同的抽象产品

MQ丢包如何解决

transaction机制就是说，发送消息前，开启事物(channel.txSelect())，然后发送消息，如果发送过程中出现什么异常，事物就会回滚(channel.txRollback())，如果发送成功则提交事物(channel.txCommit())。然而缺点就是吞吐量下降了。

所有在该信道上面发布的消息都将会被指派一个唯一的ID(从1开始)，一旦消息被投递到所有匹配的队列之后，rabbitMQ就会发送一个Ack给生产者(包含消息的唯一ID)，这就使得生产者知道消息已经正确到达目的队列了.如果rabiitMQ没能处理该消息，则会发送一个Nack消息给你，你可以进行重试操作。

分布式事务在项目中如何体现

一、两阶段提交（2PC）

两阶段提交这种解决方案属于牺牲了一部分可用性来换取的一致性。在实现方面，在 .NET 中，可以借助 TransactionScop 提供的 API 来编程实现分布式系统中的两阶段提交，比如WCF中就有实现这部分功能。不过在多服务器之间，需要依赖于DTC来完成事务一致性

优点： 尽量保证了数据的强一致，适合对数据强一致要求很高的关键领域。（其实也不能100%保证强一致）

缺点： 实现复杂，牺牲了可用性，对性能影响较大，不适合高并发高性能场景，如果分布式系统跨接口调用，目前 .NET 界还没有实现方案

二、补偿事务（TCC）

TCC 其实就是采用的补偿机制，其核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作。它分为三个阶段：

Try 阶段主要是对业务系统做检测及资源预留

Confirm 阶段主要是对业务系统做确认提交，Try阶段执行成功并开始执行 Confirm阶段时，默认 Confirm阶段是不会出错的。即：只要Try成功，Confirm一定成功。

Cancel 阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放。

优点： 跟2PC比起来，实现以及流程相对简单了一些，但数据的一致性比2PC也要差一些

缺点： 缺点还是比较明显的，在2,3步中都有可能失败。TCC属于应用层的一种补偿方式，所以需要程序员在实现的时候多写很多补偿的代码，在一些场景中，一些业务流程可能用TCC不太好定义及处理

三、本地消息表（异步确保）（使用最多的技术方案）

消息生产方，需要额外建一个消息表，并记录消息发送状态。消息表和业务数据要在一个事务里提交，也就是说他们要在一个数据库里面。然后消息会经过MQ发送到消息的消费方。如果消息发送失败，会进行重试发送。

消息消费方，需要处理这个消息，并完成自己的业务逻辑。此时如果本地事务处理成功，表明已经处理成功了，如果处理失败，那么就会重试执行。如果是业务上面的失败，可以给生产方发送一个业务补偿消息，通知生产方进行回滚等操作。

生产方和消费方定时扫描本地消息表，把还没处理完成的消息或者失败的消息再发送一遍。

四、MQ 事务消息

有一些第三方的MQ是支持事务消息的，比如RocketMQ，他们支持事务消息的方式也是类似于采用的二阶段提交，但是市面上一些主流的MQ都是不支持事务消息的，比如 RabbitMQ 和 Kafka 都不支持。

以阿里的 RocketMQ 中间件为例，其思路大致为：

第一阶段Prepared消息，会拿到消息的地址。
第二阶段执行本地事务，第三阶段通过第一阶段拿到的地址去访问消息，并修改状态。

也就是说在业务方法内要想消息队列提交两次请求，一次发送消息和一次确认消息。如果确认消息发送失败了RocketMQ会定期扫描消息集群中的事务消息，这时候发现了Prepared消息，它会向消息发送者确认，所以生产方需要实现一个check接口，RocketMQ会根据发送端设置的策略来决定是回滚还是继续发送确认消息。这样就保证了消息发送与本地事务同时成功或同时失败。

Spring管理bean的作用域，为什么不会被GC处理？

当通过spring容器创建一个Bean实例时，不仅可以完成Bean实例的实例化，还可以为Bean指定特定的作用域。Spring支持如下5种作用域：

singleton：单例模式，在整个Spring IoC容器中，使用singleton定义的Bean将只有一个实例

prototype：原型模式，每次通过容器的getBean方法获取prototype定义的Bean时，都将产生一个新的Bean实例

request：对于每次HTTP请求，使用request定义的Bean都将产生一个新实例，即每次HTTP请求将会产生不同的Bean实例。只有在Web应用中使用Spring时，该作用域才有效

session：对于每次HTTP Session，使用session定义的Bean豆浆产生一个新实例。同样只有在Web应用中使用Spring时，该作用域才有效

globalsession：每个全局的HTTP Session，使用session定义的Bean都将产生一个新实例。典型情况下，仅在使用portlet context的时候有效。同样只有在Web应用中使用Spring时，该作用域才有效

　　其中比较常用的是singleton和prototype两种作用域。对于singleton作用域的Bean，每次请求该Bean都将获得相同的实例。容器负责跟踪Bean实例的状态，负责维护Bean实例的生命周期行为；如果一个Bean被设置成prototype作用域，程序每次请求该id的Bean，Spring都会新建一个Bean实例，然后返回给程序。在这种情况下，Spring容器仅仅使用new 关键字创建Bean实例，一旦创建成功，容器不在跟踪实例，也不会维护Bean实例的状态。

如果不指定Bean的作用域，Spring默认使用singleton作用域。Java在创建Java实例时，需要进行内存申请；销毁实例时，需要完成垃圾回收，这些工作都会导致系统开销的增加。因此，prototype作用域Bean的创建、销毁代价比较大。而singleton作用域的Bean实例一旦创建成功，可以重复使用。因此，除非必要，否则尽量避免将Bean被设置成prototype作用域。

spring底层使用map来存放bean实体，而map的键值是强引用，所以不会被GC，可以重复使用

上传图片的过程中图片是在前端压缩还是后端压缩

前端，减少服务器压力，从最开始就降低了传输的数据量。

分布式事务的具体实现？有哪些模块运用了？

实现：前面有

运用：

Redis和MySQL如何对接

应用Redis实现数据的读写，同时利用队列处理器定时将数据写入mysql，此种情况存在的问题主要是如何保证mysql与redis的数据同步，二者数据同步的关键在于mysql数据库中主键，方案是在redis启动时去mysql读取所有表键值存入redis中，往redis写数据时，对redis主键自增并进行读取，若mysql更新失败，则需要及时清除缓存及同步redis主键。

Spring aop注解

设置事务隔离级别

多线程问题（原理）如何查看Stop之后的线程

Spring对bean是如何解析

所谓bean的解析就是将我们的xml文件中的bean解析出来，上面的入口看到使用的是ClassPathXmlApplicationContext来获取ApplicationContext，所以，分析的入口也就从ClassPathXmlApplicationContext类中相应的构造函数开始。

getBean() 方法开始创建过程，getBean()有一系列的重载方法，最终都是调用doGetBean() 方法

getSingleton 方法尝试从缓存中获取单例 bean

当前 bean 是单例且缓存不存在则通过 getSingleton(String beanName, ObjectFactory<?> singletonFactory) 方法创建单例对象

主要包含下下面三个主要方法：

createBeanInstance

populateBean

initializeBean

createBeanInstance 方法用于创建 Bean 实例

populateBean 方法主要给 Bean 进行属性注入

initializeBean 方法主要处理各种回调

为什么InnoDB支持事务而myisam不支持

MyISAM:这个是默认类型,它是基于传统的ISAM类型,ISAM是Indexed Sequential Access Method (有索引的顺序访问方法) 的缩写,它是存储记录和文件的标准方法.与其他存储引擎比较,MyISAM具有检查和修复表格的大多数工具. MyISAM表格可以被压缩,而且它们支持全文搜索.它们不是事务安全的,而且也不支持外键。如果事物回滚将造成不完全回滚，不具有原子性。如果执行大量的SELECT，MyISAM是更好的选择。

InnoDB:这种类型是事务安全的.它与BDB类型具有相同的特性,它们还支持外键.InnoDB表格速度很快.具有比BDB还丰富的特性,因此如果需要一个事务安全的存储引擎,建议使用它.如果你的数据执行大量的INSERT或UPDATE,出于性能方面的考虑，应该使用InnoDB表

幂等性防止订单重复提交

1、token机制，防止页面重复提交 

2、唯一索引，防止新增脏数据 

3、悲观锁乐观锁机制

4、 分布式锁

Mysql除了可以做读写分离集群外还可以做什么集群

Mysql有主从复制集群和读写分离集群

项目中哪些体现了动态代理

Aop面向切面使用动态代理，有jdk和cglig

CurrentHashmap的并发度 Synchronized和writeeverywhere

乐观锁和悲观锁在代码层面和sql层面如何实现

Sql层面：

一、悲观锁

    1、排它锁，当事务在操作数据时把这部分数据进行锁定，直到操作完毕后再解锁，其他事务操作才可操作该部分数据。这将防止其他进程读取或修改表中的数据。

    2、实现：大多数情况下依靠数据库的锁机制实现

     一般使用 select ...for update 对所选择的数据进行加锁处理，例如select * from account where name=”Max” for update， 这条sql 语句锁定了account 表中所有符合检索条件（name=”Max”）的记录。本次事务提交之前（事务提交时会释放事务过程中的锁），外界无法修改这些记录。

二、乐观锁

    1、如果有人在你之前更新了，你的更新应当是被拒绝的，可以让用户重新操作。

    2、实现：大多数基于数据版本（Version）记录机制实现

     具体可通过给表加一个版本号或时间戳字段实现，当读取数据时，将version字段的值一同读出，数据每更新一次，对此version值加一。当我们提交更新的时候，判断当前版本信息与第一次取出来的版本值大小，如果数据库表当前版本号与第一次取出来的version值相等，则予以更新，否则认为是过期数据，拒绝更新，让用户重新操作。

代码层面：

悲观锁:一段执行逻辑加上悲观锁,不同线程同时执行时,只能有一个线程执行,其他的线程在入口处等待,直到锁被释放.

乐观锁:一段执行逻辑加上乐观锁,不同线程同时执行时,可以同时进入执行,在最后更新数据的时候要检查这些数据是否被其他线程修改了(版本和执行初是否相同),没有修改则进行更新,否则放弃本次操作。

Jdk1.7和1.8之后的锁有什么不同

MySQL存储过程

SQL语句需要先编译然后执行，而存储过程（Stored Procedure）是一组为了完成特定功能的SQL语句集，经编译后存储在数据库中，用户通过指定存储过程的名字并给定参数（如果该存储过程带有参数）来调用执行它。

存储过程是可编程的函数，在数据库中创建并保存，可以由SQL语句和控制结构组成。当想要在不同的应用程序或平台上执行相同的函数，或者封装特定功能时，存储过程是非常有用的。数据库中的存储过程可以看做是对编程中面向对象方法的模拟，它允许控制数据的访问方式。

存储过程的优点：

(1).增强SQL语言的功能和灵活性：存储过程可以用控制语句编写，有很强的灵活性，可以完成复杂的判断和较复杂的运算。

(2).标准组件式编程：存储过程被创建后，可以在程序中被多次调用，而不必重新编写该存储过程的SQL语句。而且数据库专业人员可以随时对存储过程进行修改，对应用程序源代码毫无影响。

(3).较快的执行速度：如果某一操作包含大量的Transaction-SQL代码或分别被多次执行，那么存储过程要比批处理的执行速度快很多。因为存储过程是预编译的。在首次运行一个存储过程时查询，优化器对其进行分析优化，并且给出最终被存储在系统表中的执行计划。而批处理的Transaction-SQL语句在每次运行时都要进行编译和优化，速度相对要慢一些。

(4).减少网络流量：针对同一个数据库对象的操作（如查询、修改），如果这一操作所涉及的Transaction-SQL语句被组织进存储过程，那么当在客户计算机上调用该存储过程时，网络中传送的只是该调用语句，从而大大减少网络流量并降低了网络负载。

(5).作为一种安全机制来充分利用：通过对执行某一存储过程的权限进行限制，能够实现对相应的数据的访问权限的限制，避免了非授权用户对数据的访问，保证了数据的安全。

MySQL存储过程的创建

语法

CREATE PROCEDURE  过程名([[IN|OUT|INOUT] 参数名 数据类型[,[IN|OUT|INOUT] 参数名 数据类型…]]) [特性 ...] 过程体

DELIMITER //
  CREATE PROCEDURE myproc(OUT s int)
    BEGIN
      SELECT COUNT(*) INTO s FROM students;
    END
    //
DELIMITER ;

分隔符

MySQL默认以";"为分隔符，如果没有声明分割符，则编译器会把存储过程当成SQL语句进行处理，因此编译过程会报错，所以要事先用“DELIMITER //”声明当前段分隔符，让编译器把两个"//"之间的内容当做存储过程的代码，不会执行这些代码；“DELIMITER ;”的意为把分隔符还原。

参数

存储过程根据需要可能会有输入、输出、输入输出参数，如果有多个参数用","分割开。MySQL存储过程的参数用在存储过程的定义，共有三种参数类型,IN,OUT,INOUT:

·  IN参数的值必须在调用存储过程时指定，在存储过程中修改该参数的值不能被返回，为默认值

·  OUT:该值可在存储过程内部被改变，并可返回

·  INOUT:调用时指定，并且可被改变和返回

过程体

过程体的开始与结束使用BEGIN与END进行标识。

Spring boot和spring cloud的区别与联系

Spring boot 是 Spring 的一套快速配置脚手架，可以基于spring boot 快速开发单个微服务，Spring Boot，看名字就知道是Spring的引导，就是用于启动Spring的，使得Spring的学习和使用变得快速无痛。不仅适合替换原有的工程结构，更适合微服务开发。

Spring Cloud基于Spring Boot，为微服务体系开发中的架构问题，提供了一整套的解决方案——服务注册与发现，服务消费，服务保护与熔断，网关，分布式调用追踪，分布式配置管理等。

Spring Cloud是一个基于Spring Boot实现的云应用开发工具；Spring boot专注于快速、方便集成的单个个体，Spring Cloud是关注全局的服务治理框架；spring boot使用了默认大于配置的理念，很多集成方案已经帮你选择好了，能不配置就不配置，Spring Cloud很大的一部分是基于Spring boot来实现。

分布式锁（zookeeper，redis，数据库）如何实现

一、基于数据库实现的分布式锁

基于表实现的分布式锁

CREATE TABLE `methodLock` (

`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键',  

`method_name` varchar(64) NOT NULL DEFAULT '' COMMENT '锁定的方法名',

`desc` varchar(1024) NOT NULL DEFAULT '备注信息',  

`update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '保存数据时间，自动生成',  

PRIMARY KEY (`id`),  

UNIQUE KEY `uidx_method_name` (`method_name `) USING BTREE ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='锁定中的方法';

当我们想要锁住某个方法时，执行以下SQL： 
insert into methodLock(method_name,desc) values (‘method_name’,‘desc’) 
因为我们对method_name做了唯一性约束，这里如果有多个请求同时提交到数据库的话，数据库会保证只有一个操作可以成功，那么我们就可以认为操作成功的那个线程获得了该方法的锁，可以执行方法体内容。

当方法执行完毕之后，想要释放锁的话，需要执行以下Sql: 
delete from methodLock where method_name ='method_name'

上面这种简单的实现有以下几个问题：

这把锁强依赖数据库的可用性，数据库是一个单点，一旦数据库挂掉，会导致业务系统不可用。

这把锁没有失效时间，一旦解锁操作失败，就会导致锁记录一直在数据库中，其他线程无法再获得到锁。

这把锁只能是非阻塞的，因为数据的insert操作，一旦插入失败就会直接报错。没有获得锁的线程并不会进入排队队列，要想再次获得锁就要再次触发获得锁操作。

这把锁是非重入的，同一个线程在没有释放锁之前无法再次获得该锁。因为数据中数据已经存在了。

这把锁是非公平锁，所有等待锁的线程凭运气去争夺锁。

当然，我们也可以有其他方式解决上面的问题。

数据库是单点？搞两个数据库，数据之前双向同步。一旦挂掉快速切换到备库上。

没有失效时间？只要做一个定时任务，每隔一定时间把数据库中的超时数据清理一遍。

非阻塞的？搞一个while循环，直到insert成功再返回成功。

非重入的？在数据库表中加个字段，记录当前获得锁的机器的主机信息和线程信息，那么下次再获取锁的时候先查询数据库，如果当前机器的主机信息和线程信息在数据库可以查到的话，直接把锁分配给他就可以了。

非公平的？再建一张中间表，将等待锁的线程全记录下来，并根据创建时间排序，只有最先创建的允许获取锁

基于排他锁实现的分布式锁

除了可以通过增删操作数据表中的记录以外，其实还可以借助数据中自带的锁来实现分布式的锁。

我们还用刚刚创建的那张数据库表。可以通过数据库的排他锁来实现分布式锁。 基于MySql的InnoDB引擎，可以使用以下方法来实现加锁操作：

public boolean lock(){    

    connection.setAutoCommit(false);

    while(true){        

        try{            

            result = select * from methodLock where method_name=xxx for update;            

            if(result==null){                

                return true;           

            }        

        }catch(Exception e){

 

        }

        sleep(1000);

    }

    return false;

}

在查询语句后面增加for update，数据库会在查询过程中给数据库表增加排他锁。当某条记录被加上排他锁之后，其他线程无法再在该行记录上增加排他锁。

我们可以认为获得排它锁的线程即可获得分布式锁，当获取到锁之后，可以执行方法的业务逻辑，执行完方法之后，再通过以下方法解锁：

public void unlock(){ connection.commit(); }

通过connection.commit();操作来释放锁。

这种方法可以有效的解决上面提到的无法释放锁和阻塞锁的问题。

阻塞锁？ for update语句会在执行成功后立即返回，在执行失败时一直处于阻塞状态，直到成功。

锁定之后服务宕机，无法释放？使用这种方式，服务宕机之后数据库会自己把锁释放掉。

但是还是无法直接解决数据库单点、可重入和公平锁的问题。

总结一下使用数据库来实现分布式锁的方式，这两种方式都是依赖数据库的一张表，一种是通过表中的记录的存在情况确定当前是否有锁存在，另外一种是通过数据库的排他锁来实现分布式锁。

数据库实现分布式锁的优点

直接借助数据库，容易理解。

数据库实现分布式锁的缺点

会有各种各样的问题，在解决问题的过程中会使整个方案变得越来越复杂。

操作数据库需要一定的开销，性能问题需要考虑。

二、基于缓存的分布式锁

相比较于基于数据库实现分布式锁的方案来说，基于缓存来实现在性能方面会表现的更好一点。

目前有很多成熟的缓存产品，包括Redis，memcached等。这里以Redis为例来分析下使用缓存实现分布式锁的方案。

基于Redis实现分布式锁在网上有很多相关文章，其中主要的实现方式是使用Jedis.setNX方法来实现。

public boolean trylock(String key) {    

    ResultCode code = jedis.setNX(key, "This is a Lock.");    

    if (ResultCode.SUCCESS.equals(code))        

        return true;    

    else        

        return false;

}

public boolean unlock(String key){

    ldbTairManager.invalid(NAMESPACE, key);

}

以上实现方式同样存在几个问题：

1、单点问题。

2、这把锁没有失效时间，一旦解锁操作失败，就会导致锁记录一直在redis中，其他线程无法再获得到锁。

3、这把锁只能是非阻塞的，无论成功还是失败都直接返回。

4、这把锁是非重入的，一个线程获得锁之后，在释放锁之前，无法再次获得该锁，因为使用到的key在redis中已经存在。无法再执行setNX操作。

5、这把锁是非公平的，所有等待的线程同时去发起setNX操作，运气好的线程能获取锁。

当然，同样有方式可以解决。

现在主流的缓存服务都支持集群部署，通过集群来解决单点问题。

没有失效时间？redis的setExpire方法支持传入失效时间，到达时间之后数据会自动删除。

非阻塞？while重复执行。

非可重入？在一个线程获取到锁之后，把当前主机信息和线程信息保存起来，下次再获取之前先检查自己是不是当前锁的拥有者。

非公平？在线程获取锁之前先把所有等待的线程放入一个队列中，然后按先进先出原则获取锁。

redis集群的同步策略是需要时间的，有可能A线程setNX成功后拿到锁，但是这个值还没有更新到B线程执行setNX的这台服务器，那就会产生并发问题。

redis的作者Salvatore Sanfilippo，提出了Redlock算法，该算法实现了比单一节点更安全、可靠的分布式锁管理（DLM）。

Redlock算法假设有N个redis节点，这些节点互相独立，一般设置为N=5，这N个节点运行在不同的机器上以保持物理层面的独立。

算法的步骤如下：

1、客户端获取当前时间，以毫秒为单位。

2、客户端尝试获取N个节点的锁，（每个节点获取锁的方式和前面说的缓存锁一样），N个节点以相同的key和value获取锁。客户端需要设置接口访问超时，接口超时时间需要远远小于锁超时时间，比如锁自动释放的时间是10s，那么接口超时大概设置5-50ms。这样可以在有redis节点宕机后，访问该节点时能尽快超时，而减小锁的正常使用。

3、客户端计算在获得锁的时候花费了多少时间，方法是用当前时间减去在步骤一获取的时间，只有客户端获得了超过3个节点的锁，而且获取锁的时间小于锁的超时时间，客户端才获得了分布式锁。

4、客户端获取的锁的时间为设置的锁超时时间减去步骤三计算出的获取锁花费时间。

5、如果客户端获取锁失败了，客户端会依次删除所有的锁。 
使用Redlock算法，可以保证在挂掉最多2个节点的时候，分布式锁服务仍然能工作，这相比之前的数据库锁和缓存锁大大提高了可用性，由于redis的高效性能，分布式缓存锁性能并不比数据库锁差。

但是，有一位分布式的专家写了一篇文章《How to do distributed locking》，质疑Redlock的正确性。

该专家提到，考虑分布式锁的时候需要考虑两个方面：性能和正确性。

如果使用高性能的分布式锁，对正确性要求不高的场景下，那么使用缓存锁就足够了。

如果使用可靠性高的分布式锁，那么就需要考虑严格的可靠性问题。而Redlock则不符合正确性。为什么不符合呢？专家列举了几个方面。

现在很多编程语言使用的虚拟机都有GC功能，在Full GC的时候，程序会停下来处理GC，有些时候Full GC耗时很长，甚至程序有几分钟的卡顿，文章列举了HBase的例子，HBase有时候GC几分钟，会导致租约超时。而且Full GC什么时候到来，程序无法掌控，程序的任何时候都可能停下来处理GC，比如下图，客户端1获得了锁，正准备处理共享资源的时候，发生了Full GC直到锁过期。这样，客户端2又获得了锁，开始处理共享资源。在客户端2处理的时候，客户端1 Full GC完成，也开始处理共享资源，这样就出现了2个客户端都在处理共享资源的情况。

给锁带上token，token就是version的概念，每次操作锁完成，token都会加1，在处理共享资源的时候带上token，只有指定版本的token能够处理共享资源。

使用缓存实现分布式锁的优点

性能好。

使用缓存实现分布式锁的缺点

实现过于负责，需要考虑的因素太多。

基于Zookeeper实现的分布式锁

基于zookeeper临时有序节点可以实现的分布式锁。

大致思想即为：每个客户端对某个方法加锁时，在zookeeper上的与该方法对应的指定节点的目录下，生成一个唯一的瞬时有序节点。 判断是否获取锁的方式很简单，只需要判断有序节点中序号最小的一个。 当释放锁的时候，只需将这个瞬时节点删除即可。同时，其可以避免服务宕机导致的锁无法释放，而产生的死锁问题。

来看下Zookeeper能不能解决前面提到的问题。

锁无法释放？使用Zookeeper可以有效的解决锁无法释放的问题，因为在创建锁的时候，客户端会在ZK中创建一个临时节点，一旦客户端获取到锁之后突然挂掉（Session连接断开），那么这个临时节点就会自动删除掉。其他客户端就可以再次获得锁。

非阻塞锁？使用Zookeeper可以实现阻塞的锁，客户端可以通过在ZK中创建顺序节点，并且在节点上绑定监听器，一旦节点有变化，Zookeeper会通知客户端，客户端可以检查自己创建的节点是不是当前所有节点中序号最小的，如果是，那么自己就获取到锁，便可以执行业务逻辑了。

不可重入？使用Zookeeper也可以有效的解决不可重入的问题，客户端在创建节点的时候，把当前客户端的主机信息和线程信息直接写入到节点中，下次想要获取锁的时候和当前最小的节点中的数据比对一下就可以了。如果和自己的信息一样，那么自己直接获取到锁，如果不一样就再创建一个临时的顺序节点，参与排队。

单点问题？使用Zookeeper可以有效的解决单点问题，ZK是集群部署的，只要集群中有半数以上的机器存活，就可以对外提供服务。

公平问题？使用Zookeeper可以解决公平锁问题，客户端在ZK中创建的临时节点是有序的，每次锁被释放时，ZK可以通知最小节点来获取锁，保证了公平。

问题又来了，我们知道Zookeeper需要集群部署，会不会出现Redis集群那样的数据同步问题呢？

Zookeeper是一个保证了弱一致性即最终一致性的分布式组件。

Zookeeper采用称为Quorum Based Protocol的数据同步协议。假如Zookeeper集群有N台Zookeeper服务器(N通常取奇数，3台能够满足数据可靠性同时有很高读写性能，5台在数据可靠性和读写性能方面平衡最好)，那么用户的一个写操作，首先同步到N/2 + 1台服务器上，然后返回给用户，提示用户写成功。基于Quorum Based Protocol的数据同步协议决定了Zookeeper能够支持什么强度的一致性。

在分布式环境下，满足强一致性的数据储存基本不存在，它要求在更新一个节点的数据，需要同步更新所有的节点。这种同步策略出现在主从同步复制的数据库中。但是这种同步策略，对写性能的影响太大而很少见于实践。因为Zookeeper是同步写N/2+1个节点，还有N/2个节点没有同步更新，所以Zookeeper不是强一致性的。

用户的数据更新操作，不保证后续的读操作能够读到更新后的值，但是最终会呈现一致性。牺牲一致性，并不是完全不管数据的一致性，否则数据是混乱的，那么系统可用性再高分布式再好也没有了价值。牺牲一致性，只是不再要求关系型数据库中的强一致性，而是只要系统能达到最终一致性即可。

Zookeeper是否满足因果一致性，需要看客户端的编程方式。

不满足因果一致性的做法

A进程向Zookeeper的/z写入一个数据，成功返回

A进程通知B进程，A已经修改了/z的数据

B读取Zookeeper的/z的数据

由于B连接的Zookeeper的服务器有可能还没有得到A写入数据的更新，那么B将读不到A写入的数据

满足因果一致性的做法

B进程监听Zookeeper上/z的数据变化

A进程向Zookeeper的/z写入一个数据，成功返回前，Zookeeper需要调用注册在/z上的监听器，Leader将数据变化的通知告诉B

B进程的事件响应方法得到响应后，去取变化的数据，那么B一定能够得到变化的值

这里的因果一致性提现在Leader和B之间的因果一致性，也就是是Leader通知了数据有变化

第二种事件监听机制也是对Zookeeper进行正确编程应该使用的方法，所以，Zookeeper应该是满足因果一致性的

所以我们在基于Zookeeper实现分布式锁的时候，应该使用满足因果一致性的做法，即等待锁的线程都监听Zookeeper上锁的变化，在锁被释放的时候，Zookeeper会将锁变化的通知告诉满足公平锁条件的等待线程。

可以直接使用zookeeper第三方库客户端，这个客户端中封装了一个可重入的锁服务。

Dubbo原理，ES权重如何实现

Spring boot和dubbo的区别

Ik分词器分出中英文的原因是什么

后台订单倒计时如何对接（同步）前端页面

Spring代理是什么

项目上线后，日志如何处理

输出成文本文档保存记录

如何使用集合分组

ThreadLocal作用和使用场景，数据传递是否同步

ThreadLocal提供一个方便的方式，可以根据不同的线程存放一些不同的特征属性，可以方便的在线程中进行存取。

　在Hibernate中是通过使用ThreadLocal来实现的。在getSession方法中，如果ThreadLocal存在session，则返回session，否则创建一个session放入ThreadLocal中

　　总结一下就是在ThreadLocal中存放了一个session。

实际上ThreadLocal中并没有存放任何的对象或引用，在上面的的代码中ThreadLocal的实例threadSession只相当于一个标记的作用。而存放对象的真正位置是正在运行的Thread线程对象，每个Thread对象中都存放着一个ThreadLocalMap类型threadLocals对象，这是一个映射表map，这个map的键是一个ThreadLocal对象，值就是我们想存的局部对象。

在线程中存放一些就像session的这种特征变量，会针对不同的线程，有不同的值。

因此，不同步。

线程池满了怎么办

Dubbo失败策略

Failover Cluster 模式

1.失败自动切换，当出现失败，重试其它服务器。(缺省)

2. 通常用于读操作，但重试会带来更长延迟。

3. 可通过retries=”2”来设置重试次数(不含第一次)。

 

Failfast Cluster

快速失败，只发起一次调用，失败立即报错。

通常用于非幂等性的写操作，比如新增记录。

Failsafe Cluster

失败安全，出现异常时，直接忽略。

通常用于写入审计日志等操作。

.Failback Cluster

失败自动恢复，后台记录失败请求，定时重发。

通常用于消息通知操作。

Forking Cluster

并行调用多个服务器，只要一个成功即返回。

通常用于实时性要求较高的读操作，但需要浪费更多服务资源。 

可通过forks=”2”来设置最大并行数。

Broadcast Cluster

广播调用所有提供者，逐个调用，任意一台报错则报错。(2.1.0开始支持)

通常用于通知所有提供者更新缓存或日志等本地资源信息。

Redis中watch机制和原理

我们常用redis的watch和multi来处理一些涉及并发的操作，redis的watch+multi实际是一种乐观锁

watch命令描述

WATCH命令可以监控一个或多个键，一旦其中有一个键被修改（或删除），之后的事务就不会执行。监控一直持续到EXEC命令（事务中的命令是在EXEC之后才执行的，所以在MULTI命令后可以修改WATCH监控的键值）