1、Dubbo的底层实现原理和机制node
–高性能和透明化的RPC远程服务调用方案redis
–SOA服务治理方案算法
Dubbo缺省协议采用单一长链接和NIO异步通信，数据库
适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的状况apache
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。
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