java面试中经常会被问到分布式面试题
1、Dubbo的底层实现原理和机制
–高性能和透明化的RPC远程服务调用方案
–SOA服务治理方案
Dubbo缺省协议采用单一长连接和NIO异步通讯，
适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况
2、描述一个服务从发布到被消费的详细过程
务。首先先获取zk的配置信息，然后获取需要暴露的url，然后调用registry.register方法将url注册到zookeeper上去。
3、分布式系统怎么做服务治理
针对互联网业务的特点，eg 突发的流量高峰、网络延时、机房故障等，重点针对大规模跨机房的海量服务进行运行态治理，保障线上服务的高SLA，满足用户的体验，常用的策略包括限流降级、服务嵌入迁出、服务动态路由和灰度发布等
4、接口的幂等性的概念
幂等的意思是同一个操作，重复执行多次，跟执行一次结果一致。消息幂等，即消息发送操作对于消息消费来说是幂等。也就是相同的消息发送多次，跟发送一次是一样的，这个消息只会被消费一次。
5、消息中间件如何解决消息丢失问题
为了解决消息丢失问题，我们引入了一些重发机制，但也带来的另外一个问题：消息重复，我们来看下都有哪些情况会导致消息重复：
消息发送超时，处于不确定状态，导致重试发送消息，有可能之前的消息已经发送成功，会出现消息重复的情况。解决的思路是，每个消息生成一个消息id，如果发送的消息Broker已经存在了，则丢弃。这种解决办法需要维护一个已经接收的消息的message id list。
消息在Broker中只有一份，但是consumer重启前，未及时更新offset，导致consumer重启之后重复消费消息。
上游业务给每个message 分配一个message ID，下游业务在接收到message之后，执行业务并且保存message ID，而且要讲两部分放到同一个事务中，保证业务执行成功，message ID肯定保存，业务执行失败，message ID肯定不会保存下来，利用db中存储的message id来做幂等。我们可以重新封装producer client和consumer client，将这部分message ID分配和判重的逻辑封装到client lib里面。
6、Dubbo的服务请求失败怎么处理
dubbo启动时默认有重试机制和超时机制。
超时机制的规则是如果在一定的时间内，provider没有返回，则认为本次调用失败，
重试机制在出现调用失败时，会再次调用。如果在配置的调用次数内都失败，则认为此次请求异常，抛出异常。
7、重连机制会不会造成错误
dubbo在调用服务不成功时，默认会重试2次。
Dubbo的路由机制，会把超时的请求路由到其他机器上，而不是本机尝试，所以 dubbo的重试机器也能一定程度的保证服务的质量。
但是如果不合理的配置重试次数，当失败时会进行重试多次，这样在某个时间点出现性能问题，调用方再连续重复调用，
系统请求变为正常值的retries倍，系统压力会大增，容易引起服务雪崩，需要根据业务情况规划好如何进行异常处理，何时进行重试。
8、对分布式事务的理解
本质上来说，分布式事务就是为了保证不同数据库的数据一致性。
事务的ACID特性 原子性 一致性 隔离性 持久性
消息事务+最终一致性
CC提供了一个编程框架，将整个业务逻辑分为三块：Try、Confirm和Cancel三个操作。以在线下单为例，Try阶段会去扣库存，Confirm阶段则是去更新订单状态，如果更新订单失败，则进入Cancel阶段，会去恢复库存。总之，TCC就是通过代码人为实现了两阶段提交，不同的业务场景所写的代码都不一样，复杂度也不一样，因此，这种模式并不能很好地被复用。
9、如何实现负载均衡，有哪些算法可以实现？
经常会用到以下四种算法：随机（random）、轮训（round-robin）、一致哈希（consistent-hash）和主备（master-slave）。
10、Zookeeper的用途，选举的原理是什么？
11、数据的垂直拆分水平拆分。
12、zookeeper原理和适用场景
13、zookeeper watch机制
Znode发生变化（Znode本身的增加，删除，修改，以及子Znode的变化）可以通过Watch机制通知到客户端。那么要实现Watch，就必须实现org.apache.zookeeper.Watcher接口，并且将实现类的对象传入到可以Watch的方法中。Zookeeper中所有读操作（getData()，getChildren()，exists()）都可以设置Watch选项。
14、redis/zk节点宕机如何处理
15、分布式集群下如何做到唯一序列号
Redis生成ID 这主要依赖于Redis是单线程的，所以也可以用生成全局唯一的ID。可以用Redis的原子操作 INCR和INCRBY来实现。
16、如何做一个分布式锁
17、用过哪些MQ，怎么用的，和其他mq比较有什么优缺点，MQ的连接是线程安全的吗
RabbitMQ 支持 AMQP（二进制），STOMP（文本），MQTT（二进制），HTTP（里面包装其他协议）等协议。Kafka 使用自己的协议。
Kafka 自身服务和消费者都需要依赖 Zookeeper。在此我向大家推荐一个架构学习交流圈。交流学习指导伪鑫：1253431195（里面有大量的面试题及答案）里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化、分布式架构等这些成为架构师必备的知识体系。还能领取免费的学习资源，目前受益良多
RabbitMQ 在有大量消息堆积的情况下性能会下降，Kafka不会。毕竟AMQP设计的初衷不是用来持久化海量消息的，而Kafka一开始是用来处理海量日志的。
总的来说，RabbitMQ 和 Kafka 都是十分优秀的分布式的消息代理服务，只要合理部署，不作，基本上可以满足生产条件下的任何需求。
18、MQ系统的数据如何保证不丢失
在数据生产时避免数据丢失的方法：
只要能避免上述两种情况，那么就可以保证消息不会被丢失。
1）就是说在同步模式的时候，确认机制设置为-1，也就是让消息写入leader和所有的副本。
2）还有，在异步模式下，如果消息发出去了，但还没有收到确认的时候，缓冲池满了，在配置文件中设置成不限制阻塞超时的时间，也就说让生产端一直阻塞，这样也能保证数据不会丢失。
在数据消费时，避免数据丢失的方法：如果使用了storm，要开启storm的ackfail机制；如果没有使用storm，确认数据被完成处理之后，再更新offset值。低级API中需要手动控制offset值。
数据重复消费的情况，如果处理
（1）去重：将消息的唯一标识保存到外部介质中，每次消费处理时判断是否处理过；
（2）不管：大数据场景中，报表系统或者日志信息丢失几条都无所谓，不会影响最终的统计分析结
19、列举出你能想到的数据库分库分表策略；分库分表后，如何解决全表查询的问题
业务拆分、主从复制，数据库分库与分表
使用用户ID是最常用的分库的路由策略。用户的ID可以作为贯穿整个系统用的重要字段。因此，使用用户的ID我们不仅可以方便我们的查询
垂直分表
水平分表
20、zookeeper的选举策略
在zookeeper集群中也是一样，每个节点都会投票，如果某个节点获得超过半数以上的节点的投票，则该节点就是leader节点了。
zookeeper中有三种选举算法，分别是LeaderElection,FastLeaderElection,AuthLeaderElection，
FastLeaderElection此算法和LeaderElection不同的是它不会像后者那样在每轮投票中要搜集到所有结果后才统计投票结果，而是不断的统计结果，一旦没有新的影响leader结果的notification出现就返回投票结果。这样的效率更高。
21、全局ID
Snowflake
redis
