分布式面试资料

Redis 如何解决集群情况下分布式锁的可靠性？
       为了避免 Redis 实例故障导致锁无法工作的问题，Redis 的开发者 Antirez 设计了分布式锁算法 Redlock。
Redlock 算法的基本思路，是让客户端和多个独立的 Redis 实例依次请求申请加锁，
如果客户端能够和半数以上的实例成功地完成加锁操作，那么我们就认为，客户端成功地获得分布式锁，否则加锁失败。

那 Redlock 算法是如何做到的呢？
       我们假设目前有 N 个独立的 Redis 实例， 客户端先按顺序依次向 N 个 Redis 实例执行加锁操作。
这里的加锁操作和在单实例上执行的加锁操作一样，但是需要注意的是，
Redlock 算法设置了加锁的超时时间，为了避免因为某个 Redis 实例发生故障而一直等待的情况。
当客户端完成了和所有 Redis 实例的加锁操作之后，如果有超过半数的 Redis 实例成功的获取到了锁，
并且总耗时没有超过锁的有效时间，那么就是加锁成功。

锁的四种设计原则：

1. 互斥性：即在分布式系统环境下，对于某一共享资源，需要保证在同一时间只能一个线程或进程对该资源进行操作。
2. 高可用：也就是可靠性，锁服务不能有单点风险，要保证分布式锁系统是集群的，并且某一台机器锁不能提供服务了，其他机器仍然可以提供锁服务。
3. 锁释放：具备锁失效机制，防止死锁。即使出现进程在持有锁的期间崩溃或者解锁失败的情况，也能被动解锁，保证后续其他进程可以获得锁。
4. 可重入：一个节点获取了锁之后，还可以再次获取整个锁资源。

基于 Zookeeper 是如何设计和解决的呢？它的优缺点是什么
      zookeeper分布式锁是通过临时顺序节点来实现的，由zab协议保证锁的互斥性和高可用，
客户端异常退出后临时顺序节点会失删除，相当于释放锁，并会通知下一个临时节点对应的客户端可以加锁。
基于zookeeper的分布式锁需要通过共识算法保证一致性，所以锁的效率不高。

分布式事务一致性问题？
      基于MQ的可靠消息队列投递方案是目前互联网最为常见的方式，在对应高并发场景下的分布式事务问题时，
这种方案通过放弃强一致性，而选择最终一致性，来提高系统的可用性

在使用MQ的时候，怎么确保消息100%不丢失？
       最直接的目的是：做系统解耦合流量控制，追其根源
       消息生产阶段： 从消息被生产出来，然后提交给 MQ 的过程中，只要能正常收到 MQ Broker 的 ack 确认响应，
就表示发送成功，所以只要处理好返回值和异常，这个阶段是不会出现消息丢失的。
       消息存储阶段： 这个阶段一般会直接交给 MQ 消息中间件来保证，但是你要了解它的原理，比如 Broker 会做副本，
保证一条消息至少同步两个节点再返回 ack（这里涉及数据一致性原理，我在 04 讲中已经讲过，在面试中，你可以灵活延伸）。
       消息消费阶段： 消费端从 Broker 上拉取消息，只要消费端在收到消息后，不立即发送消费确认给 Broker，
而是等到执行完业务逻辑后，再发送消费确认，也能保证消息的不丢失。

如何确保消息不会丢失？ 
    你要知道一条消息从发送到消费的每个阶段，是否存在丢消息，以及如何监控消息是否丢失，
最后才是如何解决问题，方案可以基于“ MQ 的可靠消息投递 ”的方式。

如何保证消息不被重复消费？
    在进行消息补偿的时候，一定会存在重复消息的情况，那么如何实现消费端的幂等性就这道题的考点。

如何处理消息积压问题？
    这道题的考点就是如何通过 MQ 实现真正的高性能，回答的思路是，
本着解决线上异常为最高优先级，然后通过监控和日志进行排查并优化业务逻辑，最后是扩容消费端和分片的数量。

Kafka 高性能有以下原因，
写： 1.内存池设计。
        2.默认200ms批量发送一次数据，同一个 broker 的请求会合并成一个。
        3. Reactor 网络设计模式（selector ，网络线程池，IO线程池）。
        4. 顺序写磁盘。
        5.零拷贝。读：1.跳表设计，定位到文件。 2.日志存储是稀疏索引，定位到数据。