1. 分布式系统中，如何通过“逻辑时钟+向量时钟”解决事件因果序问题？

思路

先讲分布式无法依赖物理时钟，再讲逻辑时钟解决happens-before，向量时钟解决多节点因果依赖与冲突检测。

回答示例

面试官您好，分布式系统里各个节点的时间不一样，不能用物理时间判断事件先后。

所以先使用逻辑时钟，每个节点自己维护一个自增的时间戳，事件发生就+1，用来表示事件的先后关系。

但逻辑时钟只能表示单节点顺序，多节点的因果依赖判断不准。

于是就有了向量时钟，每个节点维护一个数组，记录所有节点的版本号。

事件发生时自己的版本+1，通信时带着整个向量。

这样就能精准判断两个事件谁先谁后、有没有因果关系，还能检测数据冲突。

简单说：逻辑时钟解决顺序，向量时钟解决多节点因果与冲突。

2. Kafka生产者设置acks=1时，Leader写入成功但Follower未同步，宕机风险如何规避？

思路

acks=1只写Leader就返回，存在丢数据风险；规避从配置、副本、选举、重试多方面入手。

回答示例

面试官您好，acks=1表示Leader写入成功就返回，不等待Follower同步。

如果此时Leader宕机，Follower没同步到数据，被选为新Leader，数据就丢了。

要规避这个风险，首先核心业务建议把acks设为all，等待ISR集合同步完成。

然后配置min.insync.replicas=2，保证至少有一个副本同步成功。

同时关闭unclean.leader.election.enable，不让不同步的副本当选Leader。

最后开启生产者重试、保证消息幂等，就能最大限度避免数据丢失。

3. Redis Cluster槽位迁移期间，客户端收到ASK重定向与MOVED重定向的本质区别？

思路

MOVED是永久变更、更新本地路由；ASK是临时迁移、不更新路由、只临时访问。

回答示例

面试官您好，两者的本质区别非常明确。

MOVED重定向表示槽位已经永久分配给新节点了。

客户端收到后，会更新本地的槽位映射表，以后直接访问新节点。

ASK重定向表示槽位正在迁移中，是临时状态。

客户端不会更新本地路由，只是带上ASKING命令，临时访问一次目标节点。

一句话总结：MOVED是永久搬家，ASK是临时借用。

4. 设计用户积分系统：如何用Redis SortedSet实现积分排行榜+实时更新？

思路

ZSet天然支持分数排序、O(logN)读写；实时更新用ZADD，查榜用ZREVRANGE，查个人排名用