怎么解决缓存雪崩？
事前（redis挂前）：除了redis高可用，主从+哨兵或者redis cluster避免全盘崩溃
事中（最重要保证数据库不能挂）：系统本地也需要启用缓存，数据库ehcache缓存，少量的map结构数据可以用ConcurrentHashMap，
然后加上hystrix限流和降级，避免mysql挂了
事后（redis挂后）：redis持久化，恢复缓存数据
怎么解决缓存穿透？
比如说查询的数据是数据库没有的，但是这种查询请求非常多，
这种条件及返回结果，可以设置一个unkown之类的，只要这种条件不在查询数据库就算解决了
dubbo的工作原理是什么？
服务注册，注册中心，消费者，代理通信，负载均衡
ps. 详细来说dubbo分为10层：
1.service层，接口层，留给我们实现的接口
2.config层，配置层，任何一个框架都需要提供配置文件
3.proxy层，服务代理层，无论是消费者还是生产者，dubbo都会生成代理，代理之间进行网络通信
4.registry层，注册层，provider注册自己作为一个服务，consumer就可以找注册中心去寻找自己要调用的服务
5.cluster层，集群层，provider可以部署在多台机器上，组成集群
6.monitor层，监控层，consumer调用provider，统计信息监控
7.protocol层，远程调用层，负责具体的provider和consumer之间调用接口的网络通信
8.exchange层，信息交换层，封装请求响应模式，同步转异步
9.transport层，网络传输层，抽象mina和netty为统一接口
10.serialize层，数据序列化层
注册中心挂了可以继续通信吗？
可以，因为初始化的时候，消费者将提供者的信息拉取到了本地缓存。
dubbo都支持什么通信协议和序列化协议？
协议+序列化：
1.默认dubbo协议，单一长连接，NIO异步通信，基于hessian作为序列化协议，适用场景：传输数据量小（100k以内，数据量大长连接会导致并发降低），并发高
2.rmi协议，java二进制序列化，多个短连接，适用于文件传输
3.hessian协议（支持跨语言，序列化速度较慢），多个短连接，适用文件传输
4.http协议，走json序列化
5.webservice协议，走SOAP文本序列化
dubbo支持哪些负载均衡，高可用，动态代理策略？
负载均衡策略：
1.默认 随机调用，可以对生产者配置权重
2.均衡模式
3.自动感知，给不活跃（性能查，接收较少请求的机器）的机器更少请求
4.一致性hash，相同参数的请求分发到一个机器过去
集群容错策略：
1.失败自动切换（默认）
2.一次调用失败就立即失败
3.出现异常时忽略
4.失败了后台记录日志，定送重发，适合写消息队列
5.冰箱调用多个provider，一个成功就返回
6.逐个调用所有provider
动态代理策略：
默认使用javassist动态字节码生成，创建代理类，可以通过spi扩展机制配置自己的动态代理策略
SPI是什么，dubbo是怎么用SPI的？
中文是 服务提供接口 ；
意思就是对于很多组件，dubbo保留一个接口和多个实现，然后在系统运行的时候动态根据配置去找到对应的实现类，如果不配置就用默认实现
基于dubbo怎么做服务治理，服务降级和重试？
1.服务治理（怎么管理好那么多的服务？）：
a调用链路自动生成：基于dubbo，对各个服务间的调用自动记录下来，自动生成各个服务之间的依赖和调用链路
b服务访问压力和时长统计：按照服务倍访问多少次，以及完整链路的时长，这样可以知道系统的访问压力
c服务分层避免循环依赖，调用链路监控和报警，服务可用性监控（成功率）
2.服务降级
就是降级后调用对应的接口mock
3.服务重试
失败重试+超时重试
分布式服务接口的幂等性如何设计？（例如怎么保证不重复扣款）
从本质上说，保证幂等性主要就3点：
1.对于每个请求必须有一个唯一的标识；
2.处理完请求，必须有一个记录来标识这个请求处理过了，例如数据库插入流水；
3.每次接收请求需要判断之前是否处理过。
所以说可以通过数据库做，可以通过分布式锁；
分布式系统中接口调用如何保证顺序性？
1.和MQ章节说的那样，将请求都放在一个队列
2.可以用分布式锁保证100%的顺序性，但是会使系统吞吐量和并发降低；
如何设计一个类似dubbo的rpc框架？
可以参考dubbo的分层来讲：
1.首先服务需要注册，那得有注册中心，可以用zookeeper做
2.消费者得去注册中心拿服务，服务存在多个机器上，得基于动态代理，就是接口在本地的一个代理，通过它获取服务地址
3.给哪个机器发送，需要负载均衡算法
4.怎么发送？用netty，nio；发送什么格式数据？hessian序列化协议数据
5.服务这边也一样，需要动态代理监听网络端口，接收请求后调用对应接口；
上面就是最简单的rpc框架的思路；还可以加上降级 限流之类的；
zookeeper都有哪些使用场景？
最常使用场景：
1.分布式的协调
a系统通过mq给b系统发送请求，a在zk上注册监听器，b系统消费后，a可以收到通知
2.分布式锁
3.配置信息管理：作为dubbo注册中心
zk和redis的分布式锁比较？
1.性能比较：
redis分布式锁，需要自己不断尝试获取锁，比较消耗性能
zk分布式锁，获取不到锁，注册个监听器，性能开销小，别人释放了能感知到
2.客户端挂了释放锁的处理比较：
redis获取锁的客户端挂了，只能等待超时时间后释放
zk的话因为是创建临时节点（创建一个节点就是上一个锁），客户端挂机了节点没了自动释放锁
所以个人认为zk分布式锁比redis分布式锁牢靠，模型简单易用
我实际项目中使用的都是redis分布式锁。
redis分布式锁，官方叫RedLock算法，有3个重要的考量点：互斥，不能死锁，容错（大部分节点或者这个锁就可以加可以释放）
redis分布式锁最基本的实现方式：
在redis创建一个key加锁
SET key value（随机值） NX PX 30000 //NX意思是key不存在才能设置成功，PX 30000 是说30秒后自动释放
释放就是删除key，用lua脚本删除，判断value一样才删除
setnx的时候为什么要用随机值？
因为加上自己操作时间太长，超过30秒，自己操作完准备删锁了，实际上锁超时释放了，如果不加随机值，可能就把后面别人加的锁干掉了
RedLock算法
假设redis cluster中有5个master实例
1.获取当前时间戳，单位毫秒
2.和基本实现一样，轮流尝试在每个master节点创建锁，过期时间较短，一般几十毫秒
3.尝试在大多数节点上建立一个锁，比如5个节点要求是3个（为什么是大多数？是为了规避宕机的风险，5个宕机2个依然可以成功）
4.客户端计算好建立好锁的时间，小于超时时间就算成功
5.锁创建失败就依次删除这个锁
6.别人建立了，你就不断轮询去尝试获取锁
分布式session如何实现？
常见方案：
1.tomcat + redis（也可以连哨兵）
基于tomcat原生的session支持，用TomcatRedisSessionManager，让部署的tomcat都将session存到redis；
缺点是和web容器耦合，如果要迁移到jetty怎么办？全部再配置一边吗，所以很麻烦；
2.spring session + redis
通过spring session直接写到redis不需要和容器打交道。
文源网络，仅供学习之用，如有侵权请联系删除。
我将面试题和答案都整理成了PDF文档，还有一套学习资料，涵盖Java虚拟机、spring框架、Java线程、数据结构、设计模式等等，但不仅限于此。
关注公众号【java圈子】获取资料，还有优质文章每日送达。
