1.Elasticsearch 和 MongoDB 的概念
这两个我都没有接触过，而且因为自己没有接触过也不会写在简历上，所以被问到的主要和数据库，缓存相关的就是 MySQL 和 Redis，最多是被问到是否了解消息队列。
它们都是 NoSQL 的数据库，Elasticsearch 的直译是弹性的搜索，它支持动态的扩容缩容，使用倒排索引，支持由关键词到文档的快速搜索，MongoDB 是文档型数据库，它的结构和 MySQL 的区别是 MySQL 每个数据记录格式固定，MongoDB 没有这个要求。
2.关于高性能高并发和高可用
在这里面对于高性能和高可用的支持是更多的，因为高并发可能相对更困难，成本更高，高性能的支持比如不要使用跨页查询，由业务维护之前搜索的位置，使用索引的方式比如 MongoDB 查询的没有索引使用索引，高可用比如分区存储多份且同一个的不同副本在不同的机器。
高可用的一种方法是使用 singleflight，这个在减少锁竞争，减少数据库的压力的时候都可以用。
3.关于 kafka 要解决的问题以及方法
kafka 是非常经典的消息队列，它的作用包括异步处理，削峰填谷和解耦。在具体使用场景比如秒杀场景就可以把判断是否有库存和扣减和创建订单分开异步处理。
第一个解决的问题消息可靠性？
可靠性包括三部分第一个生产者发送的没有正常被接收，可以通过 ack 和回表查询解决，第二个是 bRokeR 宕机还没持久化消息丢失，解决方法可以设置持久化频率，第三个是消费者异步处理的时候没有处理完成就标记已经消费，解决方法可以是处理完再移动偏移量。
第二个解决的问题是消息重复的问题？
这个主要是避免业务做多次操作，比如多次扣减钱，多次扣减库存，可以通过数据库的唯一键唯一索引实现，问题是插入索引和业务是两个操作可能出现部分成功的问题，所以要保证同时完成或者同时失败才可以。
如果消费者支持本地事务，就使用本地事务，先插入唯一索引再进行业务操作，如果不支持就使用分布式事务，可以使用两阶段提交的思路，如果第二个措施失败就补偿。
第三个解决的问题是消息积压的问题？
这里要考虑比如是短期还是长期，短期可能就不用处理自然就慢慢处理完，如果是长期，首先考虑我们的并发量需要的分区数目，这取决于消费者消费能力，broker 能放入的速度，其次是看能不能对消费者做业务优化加快速度、能不能使用批量操作、能不能异步处理，异步处理要避免上面说的标记成功但是没有真的处理业务成功的问题。
第四个是延迟消息的实现？
kafka 不原生支持延迟消息，可以使用一个定时任务中间件由它在时间到达后推送消息实现或者可以使用一个 topic 它的不同 partition 表示不同延迟的消息，然后由消费者在达到对应 partition 的时间段之后去把消息移动到真正的队列中去处理。
使用每个消息启动一个定时器的方法也可以但是成本不可以接受。
总结 感觉 Elasticsearch 和 MongoDB 确实没有被问到过也没有了解过 所以更多是知识层面的学习，kafka 的话从最开始知道是进程间通信的方式也渐渐掌握了一些相关知识。