微众银行java面经 1、nginx负载均衡策略有哪几种？ 轮询 默认方式 weight  权重方式 ip_hash  依据ip分配方式 least_conn 最少连接方式 fair（第三方） 响应时间方式 url_hash（第三方） 依据URL分配方式 2、nginx怎么保证高可用？ 可以用nginx+keepalived保证高可用。 3、Kafka中是怎么体现消息顺序性的？ kafka每个partition中的消息在写入时都是有序的，消费时，每个partition只能被每一个group中的一个消费者消费，保证了消费时也是有序的。 整个topic不保证有序。如果为了保证topic整个有序，那么将partition调整为1. 4、讲一讲springcloud的eureka组件？ Eureka Client组件，这个组件专门负责将这个服务的信息注册到Eureka Server中。说白了，就是告诉Eureka Server，自己在哪台机器上，监听着哪个端口。 而Eureka Server是一个注册中心，里面有一个注册表，保存了各服务所在的机器和端口号。 5、gateway和zuul做网关的区别？ Zuul 1.x，是一个基于阻塞io的API Gateway。Zuul已经发布了Zuul 2.x，基于Netty，也是非阻塞的，支持长连接，但Spring Cloud暂时还没有整合计划。 gateway异步的、非堵塞的、事件驱动的服务。所以目前来看，gateway性能更好。 6、分布式事务的解决方案？ 一、两阶段提交（2PC） 两阶段提交（Two-pha***mit，2PC），通过引入协调者（Coordinator）来协调参与者的行为，并最终决定这些参与者是否要真正执行事务。 准备阶段：协调者询问参与者事务是否执行成功，参与者发回事务执行结果。 提交阶段：如果事务在每个参与者上都执行成功，事务协调者发送通知让参与者提交事务；否则，协调者发送通知让参与者回滚事务。 二、补偿事务（TCC） TCC 其实就是采用的补偿机制，其核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作。它分为三个阶段： Try 阶段主要是对业务系统做检测及资源预留 Confirm 阶段主要是对业务系统做确认提交，Try阶段执行成功并开始执行 Confirm阶段时，默认 Confirm阶段是不会出错的。即：只要Try成功，Confirm一定成功。 Cancel 阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放。 三、本地消息表（异步确保） 本地消息表与业务数据表处于同一个数据库中，这样就能利用本地事务来保证在对这两个表的操作满足事务特性，并且使用了消息队列来保证最终一致性。 在分布式事务操作的一方完成写业务数据的操作之后向本地消息表发送一个消息，本地事务能保证这个消息一定会被写入本地消息表中。 之后将本地消息表中的消息转发到 Kafka 等消息队列中，如果转发成功则将消息从本地消息表中删除，否则继续重新转发。 在分布式事务操作的另一方从消息队列中读取一个消息，并执行消息中的操作。 四、MQ 事务消息 第一阶段Prepared消息，会拿到消息的地址。 第二阶段执行本地事务，第三阶段通过第一阶段拿到的地址去访问消息，并修改状态。 答案只是个人的一些观点，有不对的欢迎指出来。