分布式面试
fastDFS分布式文件系统
作用 ： 存储图片
1.访问效率高。
2.自动容错。
3.线性扩容。
监控设计
监控是可靠性的前提, 没有监控, 无法在第一时间发现问题, 更别说预防问题的发生了. 监控也是分层的:
- 基础层: CPU, 内存, 网络吞吐, 磁盘 等
- 中间层: nginx, redis, 消息队列, 数据库 等
- 应用层: HTTP 响应时间, 返回码, API 调用链路, 客户端访问信息 等
一致性设计
强一致性(ACID)和最终一致性(BASE)
ACID: 原子性(Atomcity), 一致性(Consistency), 隔离性(Isolation,又称独立性), 持久性(Durability)
BASE: 基本可用(Basic Availability), 软状态(Soft-state), 最终一致性(Eventual Consistency)
重试设计（消息队列 rabbitMq/数据库记录）
失败重试机制
死信队列
熔断设计
重试是请求端的机制, 熔断是响应端的机制，熔断类似保险丝
限流设计
限流的目的是通过对并发访问进行限速, 让服务端能够响应更多的请求
降级设计
- 降低一致性: 从强一致性变为最终一致性
- 停止次要功能: 停止访问不重要的功能, 从而释放出更多的资源
- 简化功能: 把一些功能简化掉. 比如, 简化业务流程, 或是不再返回全量数据, 只返回部分数据
分布式锁
Redis实现的分布式锁
主要是利用了redis的set NX的原理，以及对redis的script脚本原子性利用。（个人看法，其实后面一步就看各自的程序逻辑如何去判定到底要不要这一步了）
简单的说一下主要流程：
- 首先设置一个全局唯一的key和一个唯一性的value（value是一个解锁的保障，删除之前判断一下值是否一致）
- 使用Redis的set 方法 以多参数形式配置key,value,nx,px,过期时间 （参数 NX：只有键不存在时，才能对其进行设置操作）
- 利用Redis的script脚本来对key的删除操作，只能自己删除自己的value（删除之前先判断一下value是否是我之前的value，是否被改过，没有就删了）
这是脚本的主要 内容 if redis.call("get",KEYS[1]) == ARGV[1] then return redis.call("del",KEYS[1]) else return 0 end
对其解释： 根据 get 获取到 key 的值 ，判断key的值是否跟你传的值相等，相等则 执行del key 否则返回0 结束
对此推荐去看一下redis的Lua脚本，给个简单的：http://redisdoc.com/script/eval.html
在实际场景中可以利用AOP的切点切面形式，实现具体是什么地方需要分布式锁，搭配分布式锁，再搭配注解方式，来实现想要的自定义设置那里需要就点哪里
AOP的主要实现是
注解类 DistributedLock
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
@Documented
public @interface DistributedLock {
/**
* 自定义形式添加你对分布式锁的对外配置属性
* 例如：key的规则，锁的超时时间，获取锁的等待时间，等一系列的属性配置
*
*/
}
切面类 DistributedLockAspect
@Aspect
@Component
public class DistributedLockAspect {
/**
* 层切点
*/
@Pointcut("@annotation(com.creditease.hardess.common.annotation.DistributedLock)")
public void distributedLockAspect() {}
/**
* @param joinPoint 切点
* @return Object 添加分布式锁后，实际调用业务逻辑部分代码的返回值
* @throws Throwable 产生的所有异常，为了避免对异常处理流程产生干扰，所有异常都应该继续抛出
*/
@Around("distributedLockAspect()")
public Object doAround(ProceedingJoinPoint joinPoint) throws Throwable {
/**
*主要写一些锁的获取，和业务逻辑执行，锁的删除等
*
*/
return returnObject;
}
/**
* 获取 DistributedLock 注解
*
* @param joinPoint
* @return 代码中定义的注解
* @throws NoSuchMethodException
*/
private static DistributedLock getDistributedLock(ProceedingJoinPoint joinPoint)
throws NoSuchMethodException {
String methodName = joinPoint.getSignature().getName();
Class<?> classTarget = joinPoint.getTarget().getClass();
Class<?>[] par = ((MethodSignature) joinPoint.getSignature()).getParameterTypes();
Method objMethod = classTarget.getMethod(methodName, par);
return objMethod.getAnnotation(DistributedLock.class);
}
}
}
-
NX表示只有当resource_name对应的key值不存在的时候才能SET成功。这保证了只有第一个请求的客户端才能获得锁，而其它客户端在锁被释放之前都无法获得锁。
-
PX 30000表示这个锁有一个30秒的自动过期时间。当然，这里30秒只是一个例子，客户端可以选择合适的过期时间。
Dubbo并发通信原理解析
从Dubbo开源文档中看到：Dubbo缺省协议采用单一长连接和NIO异步通讯，适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的
情况。
Dubbo通信默认采用的是Netty框架。Netty实质就是通过Socket进行通信，Socket(TCP)通信是全双工的方式。
因为采用单一长连接，所以如果消费者多线程请求，服务端处理完消息后返回，就会造成消息错乱的问题。解决这个问题的思路跟解决socket中的粘包问题类似。
socket粘包问题解决方法：用的最多的其实是定义一个定长的数据包头，其中包含了完整数据包的长度，以此来完成服务器端拆包工作。
类似的，那么dubbo解决上述问题的方法：就是给包头中添加一个全局唯一标识id，服务器端响应请求时也要携带这个id，供客户端多线程领取对应的响应数据提供
线索。
分布式服务框架：
–高性能和透明化的RPC远程服务调用方案
-Apache MINA 框架基于Reactor模型通信框架，基于tcp长连接
Dubbo缺省协议采用单一长连接和NIO异步通讯，
适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况
分析源代码，基本原理如下：
client一个线程调用远程接口，生成一个唯一的ID（比如一段随机字符串，UUID等），Dubbo是使用AtomicLong从0开始累计数字的
将打包的方法调用信息（如调用的接口名称，方法名称，参数值列表等），和处理结果的回调对象callback，全部封装在一起，组成一个对象object
向专门存放调用信息的全局ConcurrentHashMap里面put(ID, object)
将ID和打包的方法调用信息封装成一对象connRequest，使用IoSession.write(connRequest)异步发送出去
当前线程再使用callback的get()方法试图获取远程返回的结果，在get()内部，则使用synchronized获取回调对象callback的锁， 再先检测是否已经获取到结果，
如果没有，然后调用callback的wait()方法，释放callback上的锁，让当前线程处于等待状态。
服务端接收到请求并处理后，将结果（此结果中包含了前面的ID，即回传）发送给客户端，客户端socket连接上专门监听消息的线程收到消息，分析结果，取到ID，
再从前面的ConcurrentHashMap里面get(ID)，从而找到callback，将方法调用结果设置到callback对象里。
监听线程接着使用synchronized获取回调对象callback的锁（因为前面调用过wait()，那个线程已释放callback的锁了），再notifyAll()，唤醒前面处于等待状态
的线程继续执行（callback的get()方法继续执行就能拿到调用结果了），至此，整个过程结束。
当前线程怎么让它“暂停”，等结果回来后，再向后执行？
答：先生成一个对象obj，在一个全局map里put(ID,obj)存放起来，再用synchronized获取obj锁，再调用obj.wait()让当前线程处于等待状态，然后另一消息
监听线程等到服 务端结果来了后，再map.get(ID)找到obj，再用synchronized获取obj锁，再调用obj.notifyAll()唤醒前面处于等待状态的线程。
正如前面所说，Socket通信是一个全双工的方式，如果有多个线程同时进行远程方法调用，这时建立在client server之间的socket连接上会有很多双方发送的消息
传递，前后顺序也可能是乱七八糟的，server处理完结果后，将结果消息发送给client，client收到很多消息，怎么知道哪个消息结果是原先哪个线程调用的？
答：使用一个ID，让其唯一，然后传递给服务端，再服务端又回传回来，这样就知道结果是原先哪个线程的了。
Dubbo是一种分布式服务框架。 Webservice也是一种服务框架，但是webservice并不是分布式的服务框架，他需要结合F5实现负载均衡。因此，dubbo除了可以提供服务之外，还可以实现软负载均衡。它还提供了两个功能Monitor 监控中心和调用中心。这两个是可选的，需要单独配置。
虚拟机中类的加载 ；类的数据从ｃｌａｓｓ文件加载到内存，并对数据进行效验，类型的加载，连接和初始化，最终形成可以被虚拟机直接使用的Ｊａｖａ类型，这就是
虚拟机的类加载机制。
类的加载时间 ： 类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括 ： 加载（Ｌｏａｄｉｎｇ），严重，准备，解析，初始化，使用和卸载
七个阶段。其中验证，准备，解析三个部分统称为连接。
加载 ： 在加载阶段，虚拟机需要完成三件事情 ：
１.通过一个类的全限定名来获取定义类的二进制字节流。
２.将这个字节流所代表的静态存储结构转换为方法区的运行时数据结构。
３.在内存中生成一个代表这个类的ｊａｖａ．ｌａｎｇ．Ｃｌａｓｓ对象，作为方法区这个类的各种数据的访问入口。
为什么会产生内存泄漏？
当一个对象已经不需要再使用本该被回收时，另外一个正在使用的对象持有它的引用从而导致它不能被回收，这导致本该被回收的对象不能被回收而停留在堆内存中，这就产生了内存泄漏。
内存泄漏对程序的影响？
内存泄漏是造成应用程序OOM的主要原因之一。我们知道Android系统为每个应用程序分配的内存是有限的，而当一个应用中产生的内存泄漏比较多时，这就难免会导致应用所需要的内存超过系统分配的内存限额，这就造成了内存溢出从而导致应用Crash。
如何检查和分析内存泄漏？
因为内存泄漏是在堆内存中，所以对我们来说并不是可见的。通常我们可以借助MAT、LeakCanary等工具来检测应用程序是否存在内存泄漏。
1、MAT是一款强大的内存分析工具，功能繁多而复杂。
2、LeakCanary则是由Square开源的一款轻量级的第三方内存泄漏检测工具，当检测到程序中产生内存泄漏时，它将以最直观的方式告诉我们哪里产生了内存泄漏和导致谁泄漏了而不能被回收。
Dubbo缺省协议采用单一长连接和NIO异步通讯，适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况。
- 共享锁：
sql select * from table where ... lock in share mode - 排他锁：
sql select * from table where ... for update
分布式锁可以把整个集群就当作是一个应用一样去处理，那么也就需要这个锁，要独立于每一个服务之外，而不是在服务里面。
有数据库方式的，有redis分布式锁，有zookeeper分布式锁
1.为什么redis可以实现分布式锁？
首先redis是单线程的，这里的单线程指的是网络请求模块使用了一个线程（所以不需考虑并发安全性），即一个线程处理所有网络请求，其他模块仍用了多个线程。
通过上面的方式，我们好像是解决了分布式锁的问题，但是想想还有没有什么问题呢？？
对，问题还是有的，可能会有死锁的问题发生，比如服务器1设置完之后，获取了锁之后，忽然发生了宕机。
那后续的删除key操作就没法执行，这个key会一直在redis中存在，其他服务器每次去检查，都会返回0，他们都会认为有人在使用锁，我需要等。
为了解决这个死锁的问题，我们就就需要给key 设置有效期了。
2.为什么zookeeper可以实现分布式锁？
百度百科是这么介绍的：ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。
那对于我们初次认识的人，可以理解成ZooKeeper就像是我们的电脑文件系统，我们可以在d盘中创建文件夹a，并且可以继续在文件夹a中创建 文件夹a1，a2。
那我们的文件系统有什么特点？？那就是同一个目录下文件名称不能重复，同样ZooKeeper也是这样的。
在ZooKeeper所有的节点，也就是文件夹称作 Znode，而且这个Znode节点是可以存储数据的。
我们可以通过“ create /zkjjj nice” 来创建一个节点，这个命令就表示，在跟目录下创建一个zkjjj的节点，值是nice。同样这里的值，和我在前面说的redis中的一样，没什么意义，你随便给。
另外ZooKeeper可以创建4种类型的节点，分别是：
1，持久性节点
2，持久性顺序节点
3，临时性节点
4，临时性顺序节点
首先说下持久性节点和临时性节点的区别，
持久性节点表示只要你创建了这个节点，那不管你ZooKeeper的客户端是否断开连接，ZooKeeper的服务端都会记录这个节点。
临时性节点刚好相反，一旦你ZooKeeper客户端断开了连接，那ZooKeeper服务端就不再保存这个节点。
再说下顺序性节点，顺序性节点是指，在创建节点的时候，ZooKeeper会自动给节点编号比如0000001 ，0000002 这种的。
最后说下，zookeeper有一个监听机制，客户端注册监听它关心的目录节点，当目录节点发生变化（数据改变、被删除、子目录节点增加删除）等，zookeeper会通知客户端。
RPC
RPC的目的是让你在本地调用远程的方法，而对你来说这个调用是透明的，你并不知道这个调用的方法是部署哪里。通过RPC能解耦服务，这才是使用RPC的真正目的。
