消息队列

MQ有什么用？

消息队列有很多使用场景，比较常见的有3个：解耦、异步、削峰。

解耦：传统的软件开发模式，各个模块之间相互调用，数据共享，每个模块都要时刻关注其他模块的是否更改或者是否挂掉等等，使用消息队列，可以避免模块之间直接调用，将所需共享的数据放在消息队列中，对于新增业务模块，只要对该类消息感兴趣，即可订阅该类消息，对原有系统和业务没有任何影响，降低了系统各个模块的耦合度，提高了系统的可扩展性。
异步：消息队列提供了异步处理机制，在很多时候应用不想也不需要立即处理消息，允许应用把一些消息放入消息中间件中，并不立即处理它，在之后需要的时候再慢慢处理。
削峰：在访问量骤增的场景下，需要保证应用系统的平稳性，但是这样突发流量并不常见，如果以这类峰值的标准而投放资源的话，那无疑是巨大的浪费。使用消息队列能够使关键组件支撑突发访问压力，不会因为突发的超负荷请求而完全崩溃。消息队列的容量可以配置的很大，如果采用磁盘存储消息，则几乎等于“无限”容量，这样一来，高峰期的消息可以被积压起来，在随后的时间内进行平滑的处理完成，而不至于让系统短时间内无法承载而导致崩溃。在电商网站的秒杀抢购这种突发性流量很强的业务场景中，消息队列的强大缓冲能力可以很好的起到削峰作用。

说一说生产者与消费者模式

所谓生产者-消费者问题，实际上主要是包含了两类线程。一种是生产者线程用于生产数据，另一种是消费者线程用于消费数据，为了解耦生产者和消费者的关系，通常会采用共享的数据区域，就像是一个仓库。生产者生产数据之后直接放置在共享数据区中，并不需要关心消费者的行为。而消费者只需要从共享数据区中去获取数据，就不再需要关心生产者的行为。但是，这个共享数据区域中应该具备这样的线程间并发协作的功能：

如果共享数据区已满的话，阻塞生产者继续生产数据放置入内；
如果共享数据区为空的话，阻塞消费者继续消费数据。

在Java语言中，实现生产者消费者问题时，可以采用三种方式：

使用 Object 的 wait/notify 的消息通知机制；
使用 Lock 的 Condition 的 await/signal 的消息通知机制；
使用 BlockingQueue 实现。

消息队列如何保证消息不丢？

Kafka丢失消息分为如下几种情况：

生产者丢消息：

生产者没有设置相应的策略，发送过程中丢失数据。
Kafka自己丢消息：

比较常见的一个场景，就是Kafka的某个broker宕机了，然后重新选举partition的leader时。如果此时follower还没来得及同步数据，leader就挂了，然后某个follower成为了leader，它就少了一部分数据。
消费端丢消息：

消费者消费到了这个数据，然后消费之自动提交了offset，让Kafka知道你已经消费了这个消息，当你准备处理这个消息时，自己挂掉了，那么这条消息就丢了。

针对上述三种情况，Kafka可以采用如下方式避免消息丢失：

生产者丢消息：

关闭自动提交offset，在自己处理完毕之后手动提交offset，这样就不会丢失数据。
Kafka自己丢消息：

一般要求设置4个参数来保证消息不丢失：
- 给topic设置 replication.factor 参数，这个值必须大于1，表示要求每个partition必须至少有2个副本。
- 在kafka服务端设置 min.isync.replicas 参数，这个值必须大于1，表示要求一个leader至少感知到有至少一个follower在跟自己保持联系正常同步数据，这样才能保证leader挂了之后还有一个follower。
- 在生产者端设置 acks=all ，表示要求每条每条数据，必须是写入所有replica副本之后，才能认为是写入成功了。
- 在生产者端设置 retries=MAX (很大的一个值)，表示这个是一旦写入失败，就无限重试。
消费端丢消息：

如果按照上面设置了ack=all，则一定不会丢失数据，要求是，你的leader接收到消息，所有的follower都同步到了消息之后，才认为本次写成功了。如果没满足这个条件，生产者会自动不断的重试，重试无限次。

MQ处理消息失败了怎么办？

一般生产环境中，都会在使用MQ的时候设计两个队列：一个是核心业务队列，一个是死信队列。核心业务队列，就是比如专门用来让订单系统发送订单消息的，然后另外一个死信队列就是用来处理异常情况的。

生产者与消费者的声明调用

@RunWith(SpringRunner.class)
@SpringBootTest
@ContextConfiguration(classes = CommunityApplication.class)
public class KafkaTests {
 
    @Autowired
    private KafkaProducer kafkaProducer;
 
    @Test
    public void testKafka() {
        kafkaProducer.sendMessage("test", "你好");
        kafkaProducer.sendMessage("test", "在吗");
 
        try {
            Thread.sleep(1000 * 10);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
 
}
 
@Component
class KafkaProducer {
 
    @Autowired
    private KafkaTemplate kafkaTemplate;
    public void sendMessage(String topic, String content) {
        kafkaTemplate.send(topic, content);
    }
 
}
 
@Component
class KafkaConsumer {
    @KafkaListener(topics = {"test"})
    public void handleMessage(ConsumerRecord record) {
        System.out.println(record.value());
    }
 
}

搜索引擎

说说ElasticSearch put的全过程

put过程主要分为三个阶段：

协调阶段：

Client 客户端选择一个 node 发送 put 请求，此时当前节点就是协调节点（coordinating node）。协调节点根据 document 的 id 进行路由，将请求转发给对应的 node。这个 node 上的是 primary shard 。
主要阶段：

对应的 primary shard 处理请求，写入数据，然后将数据同步到 replica shard。
- primary shard 会验证传入的数据结构；
- 本地执行相关操作；
- 将操作转发给 replica shard。
当数据写入 primary shard 和 replica shard 成功后，路由节点返回响应给 Client。
副本阶段：

每个 replica shard 在转发后，会进行本地操作。

面试题集合——消息队列&搜索引擎