java面试之plus

1.观察者模式和发布订阅模式

1.区别

• 前者：观察者订阅主题，主题也维护观察者的记录，而后者：发布者和订阅者不需要彼此了解，而是在消息队列或代理的帮助下通信，实现松耦合。
• 前者主要以同步方式实现，即某个事件发生时，由Subject调用所有Observers的对应方法，后者则主要使用消息队列异步实现。
  

2.延迟消费

2.1 redis zset实现

1. 将延迟的消息任务通过 hash 算法路由至不同的 Redis Key 上，这样做有两大好处：
   a. 避免了当一个 KEY 在存储了较多的延时消息后，入队操作以及查询操作速度变慢的问题（两个操作的时间复杂度均为O(logN)）。
   b. 系统具有了更好的横向可扩展性，当数据量激增时，我们可以通过增加 Redis Key 的数量来快速的扩展整个系统，来抗住数据量的增长。
2. 每个 Redis Key 都对应建立一个处理进程，称为 Event 进程，通过上述步骤 2 中所述的 ZRANGEBYSCORE 方法轮询 Key，查询是否有待处理的延迟消息。
3. 所有的 Event 进程只负责分发消息，具体的业务逻辑通过一个额外的消息队列异步处理，这么做的好处也是显而易见的：
   a. 一方面，Event 进程只负责分发消息，那么其处理消息的速度就会非常快，就不太会出现因为业务逻辑复杂而导致消息堆积的情况。
   b. 另一方面，采用一个额外的消息队列后，消息处理的可扩展性也会更好，我们可以通过增加消费者进程数量来扩展整个系统的消息处理能力。
4. Event 进程采用 Zookeeper 选主单进程部署的方式，避免 Event 进程宕机后，Redis Key 中消息堆积的情况。一旦 Zookeeper 的 leader 主机宕机，Zookeeper 会自动选择新的 leader 主机来处理 Redis Key 中的消息。

2.2 RabbitMQ

	死信队列
	消息被拒绝basic.reject/ basic.nack 并且不再重新投递 requeue=false
	消息超时未消费，也就是 TTL 过期了
	消息队列到达最大长度

2.3 时间轮

延迟队列在我们日常开发中应用非常广泛，介绍了三种不同的实现延迟队列的方案，三种方案各自有各自的特点，例如 Redis 的实现方案理解起来最为简单，能够快速落地，但 Redis 毕竟是基于内存的，虽然有数据持久化方案，但还是有数据丢失的可能性。而 RabbitMQ 的实现方案，由于 RabbitMQ 本身的消息可靠发送、消息可靠投递、死信队列等特性，可以保障消息至少被消费一次以及未被正确处理的消息不会被丢弃，让消息的可靠性有了保障。最后 Kafka 的时间轮算法，个人觉得是三种实现方案中最难理解但也不失为一种非常巧妙实现方案。