一、kafka相关
1.kafka如何保证消息不丢失和重复消息？
2.kafka任务积压怎么排查，怎么解决？
二、Redis相关
1.Redis的热点key虽然在多个节点有，都访问到一个节点怎么解决？
2.大key问题怎么解决？
三、Mysql相关
1.主从复制的流程是什么？
2.主从复制延迟高怎么解决？
3.为什么有索引SQL还是突然变慢？
1.kafka保证消息不丢失的方法，在生产者这边要通过ack，确定服务端收到才表示推送成功，在服务端可能宕机的考虑，要通过ack=all，保证多个broker，备份的也都存下来才推送成功，在消费端，对于重复消费的问题，在消费端通过手动提交offset位置，在事务中用唯一性索引作为约束保证只有一个业务只处理一次且唯一性索引的插入和处理是原子性的。
总结：
这里的生产者做的是防止服务器宕机，消费者做的是防止反复处理。
2.kafka消息积压
不能简单的通过增加消费者处理积压问题，因为一个partition只能被一个消费者处理，要考虑是不是因为慢查询或者业务处理复杂，其次是考虑partition和线程数目，还有就是检查broker的网络io的问题，线程问题。
3.Redis热点key，可以使用不同的key记录信息，存在不同的slot不同的节点，在访问的时候不要访问一个key，通过不同的key获得相同的数据，负载均衡。
4.Redis大key问题，不存储完整的数据记录，存储数据地址信息，指针，把数据拆分成更小粒度去存储。
5.主从复制的流程就是主库写redolog、写binlog、从库获取binlog，写到relaylog，按照relaylog重放SQL，判断进度到哪里了
6.主从延迟是因为SQL重放有一个延迟，对于硬性要求可以去主库读，对于延迟允许的，可以确定从库追上主库再读，对于过高延迟的情况，要考虑是不是慢查询、通过并行复制解决
7.为什么有索引SQL变慢？
连接过多，排队、没有按照执行计划查询、索引失效、cpuio瓶颈、事务的当前读锁住行，不能读、数据分布变动，查询内容变多
回答消息不丢失类问题，主要是通过确认机制，比如TCP里会有序号和确认，对于不重复，幂等性，主要是业务方去记录，唯一索引是一种方式。
对于任务积压，不能简单的增加线程，还要考虑能不能处理，线程会不会有竟态问题。
对于Redis问题的回答，是比较特别属于Redis的，比如大key。
对于mysql类型的问题，主要从索引、从SQL语句本身、连接、资源，比如IO/CPU、锁这些角度去回答；主从过程的延迟是必然存在的，不过要确定知道自己的进度，要确定不同的业务场景对于延迟的接受程度。
我个人感觉前面的时候经常被问到mysql和redis 的问题，等自己把八股背熟悉之后，包括事务特性、隔离级别，mvcc概念和解决的问题这些没被问到了，可能是我的注意力偏差吧，因为总是会关注不是很熟悉的部分。