java面试题

单点登录：

SSO单点登录系统。单点登录系统是采用redis缓存来模拟session机制，即用户登录成功后，我们将用户信息以json字符串的形式存储在redis缓存中，并生成一个唯一token作为redis存储用户信息的key。然后将该token写入cookie并返回给浏览器客户端。由于各个子系统的域名不一样，所以我们必须在返回cookie之前设置有效域名，使得不同子系统在发送请求时，都可以携带该cookie到后台进行登录拦截。

说一下dubbox的使用方法

dubbo采用rpc协议（远程过程调用协议）
Dubbo提供了三个关键功能：基于接口的远程调用，容错与负载均衡，服务自动注册与发现。Dubbo使得调用远程服务就像调用本地java服务一样简单
调用关系说明：
• 0. 服务容器负责启动，加载，运行服务提供者。
• 1. 服务提供者在启动时，向注册中心注册自己提供的服务。
• 2. 服务消费者在启动时，向注册中心订阅自己所需的服务。
• 3. 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
• 4. 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
• 5. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。
Dubbox是一个分布式服务框架，提供了统一的高性能的远程服务调用平台。所有的业务逻辑都使用dubbox发布供表现层工程调用。发布dubbox服务需要使用spring容器的支持来发布服务，调用服务同样使用spring容器来应用服务。其中服务的发布和服务的发现都是通过注册中心来实现，我们使用zookeeper作为注册中心。

Dubbo中zookeeper做注册中心，如果注册中心集群都挂掉，发布者和订阅者之间还能通信么？

可以的，启动dubbo时，消费者会从zk拉取注册的生产者的地址接口等数据，缓存在本地。每次调用时，按照本地存储的地址进行调用

注册中心对等集群，任意一台宕掉后，会自动切换到另一台
注册中心全部宕掉，服务提供者和消费者仍可以通过本地缓存通讯
服务提供者无状态，任一台 宕机后，不影响使用
服务提供者全部宕机，服务消费者会无法使用，并无限次重连等待服务者恢复

zookeeper宕机后，因为消费者会缓存提供者的信息，所以应用不会有问题。

但是，此时提供者和消费者都无法重连zookeeper，因为dubbo貌似配置的zkclient不会重连zookeeper，所以一旦重启一台服务提供者，那么这台就从服务消费者的缓存中消失了，
此时服务消费者又连不上zookeeper，所以如果同时重启，消费者就没有提供者可用了，所以只能重启一台提供者后，再重启一个消费者，交错重启。

SpringCloud与Dubbo的区别

SpringCloud是采用Http协议做远程调用，接口一般是Rest风格,Dubbo一开始只是做RPC远程调用，接口一般是Java的Service接口，格式固定。但调用时采用Netty的NIO方式，性能较好。

Spring Cloud中的Eureka和Zookeeper的区别在哪

CAP 定理：C (一致性) A (可用性) P (分区容错性)

C（Consistency）：数据一致性。大家都知道，分布式系统中，数据会有副本。由于网络或者机器故障等因素，可能有些副本数据写入正确，有些却写入错误或者失败，这样就导致了数据的不一致了。而满足数据一致性规则，就是保证所有数据都要同步。
A（Availability）：可用性。我们需要获取什么数据时，都能够正常的获取到想要的数据（当然，允许可接受范围内的网络延迟），也就是说，要保证任何时候请求数据都能够正常响应。
P（Partition
Tolerance）：分区容错性。当网络通信发生故障时，集群仍然可用，不会因为某个节点挂了或者存在问题，而影响整个系统的正常运作。

zookeeper 的 CP 原则

zookeeper 是保证数据的一致性的，但是这里还需要注意一点是，zookeeper 它不是强一致的，什么意思呢？打个比方，现在客户端 A 提交一个写操作，zookeeper 在过半数节点操作成功之后就可以返回，但此时，客户端 B 的读操作请求的是 A 写操作尚未同步到的节点，那么读取的就不是 A 最新提交的数据了。

那如何保证强一致性呢？我们可以在读取数据的时候先执行一下 sync 操作，即与 leader 节点先同步一下数据，再去取，这样才能保证数据的强一致性。

但是 zookeeper 也有个缺陷，刚刚提到了 leader 节点，当 master 节点因为网络故障与其他节点失去联系时，剩余节点会重新进行 leader 选举。问题在于，选举 leader 的时间太长，30 ~ 120s, 且选举期间整个 zookeeper 集群都是不可用的，这就导致在选举期间注册服务瘫痪。

在云部署的环境下，因网络问题使得 zookeeper 集群失去 master 节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。比如双十一当天，那就是灾难性的。

eureka 的 AP 原则
大规模网络部署时，失败是在所难免的，因此我们无法回避这个问题。当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接 down 掉不可用。

Eureka 在被设计的时候，就考虑到了这一点，因此在设计时优先保证可用性，这就是 AP 原则。Eureka 各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而 Eureka 的客户端在向某个 Eureka 注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台 Eureka 还在，就能保证注册服务可用（即保证A原则），只不过查到的信息可能不是最新的（不保证B原则）。

正因为应用实例的注册信息在集群的所有节点间并不是强一致的，所以需要客户端能够支持负载均衡以及失败重试。在 Netflix 的生态中，ribbon 可以提供这个功能。

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

作为服务注册中心，最重要的是要保证可用性，可以接收段时间内数据不一致的情况。个人觉得 Eureka 作为单纯的服务注册中心来说要比 zookeeper 更加“专业”一点。

分布式事务解决方案

两阶段提交协议(2PC)
1）第一阶段：准备阶段（prepare）
协调者通知参与者准备提交订单，参与者开始投票。
协调者完成准备工作向协调者回应Yes。
2）第二阶段：提交(commit)/回滚(rollback)阶段
协调者根据参与者的投票结果发起最终的提交指令。
如果有参与者没有准备好则发起回滚指令。
事务补偿（TCC）
1、Try 检查及预留业务资源
完成提交事务前的检查，并预留好资源。
2、Confirm 确定执行业务操作
对try阶段预留的资源正式执行。
3、Cancel 取消执行业务操作
对try阶段预留的资源释放。
消息队列实现最终一致（MQ）最实用
是将分布式事务拆分成多个本地事务来完成，并且由消息队列异步协调完成
第一阶段 Prepared（准备） 消息，会拿到消息的地址。
第二阶段执行本地事务。
第三阶段通过第一阶段拿到的地址去访问消息，并修改状态。消息接受者就能使用这个消息。
如果确认消息失败，在 RocketMQ Broker 中提供了定时扫描没有更新状态的消息。
如果有消息没有得到确认，会向消息发送者发送消息，来判断是否提交，
在 RocketMQ 中是以 Listener 的形式给发送者，用来处理。
数据库有个消息表的，订单支付成功以后，会添加任务在消息表，springtask会定时扫描消息表，添加，执行成功后删除消息表任务。没成功就会一直扫描

什么是索引？介绍一下存储过程。

索引：是针对数据所建立的目录，作用：可以加快查询速度，负面影响：降低了增删改的速度。
普通索引：index仅仅是加快查询速度。
唯一索引：unique index 行上的值不能重复
主键索引：primary key 不能重复
主键必唯一，但是唯一的索引不一定是主键。一张表上，只能有一个主键，但是可以用一个或多个唯一索引
全文索引：fulltext index

存储函数：类似于函数，就是把一段代码封装起来，当要执行这一段代码的时候，可以通过该存储过程来实现，在封装的语句体里面，可以用if/else,case,while等控制结构，可以进行sql编程

谈一谈你对Spring的理解？

①Spring是一个开源的业务层框架，分模块，一站式框架，它能够整合各种其他主流框架；
②Spring的实质就是一个实现了工厂模式的工厂类，在其配置文件中，通过添加标签，来创建实例对象；
③Spring的核心——IoC/DI;
a)IoC(Inverse of Control）控制反转，将对象的创建全交给Spring去管理，
di(依赖注入)创建一个对象，这个对象所需要的属性通过配置注入
然 后Spring容易通过依赖注入的方式，注入给调用者。这样做的好处是，让bean与bean之间以配置文件的形式组织在一起，而不是以硬编码的方式耦合在一起。
b)依赖注入的方式有三种：接口注入、Setter方法注入（使用<property name="" value或者ref="">）、构造注入；

④Spring的核心——AOP;
a)AOP(面向切面编程)，当我们需要为多个不具有继承关系的对象引入一个公共行为，例如日志、权限验证、事务等功能时，只能在在每个对象里引用公共行为。这样做不便于维护，而且有大量重复代码。AOP的出现弥补了OOP的这点不足。
可以在