1、说一下项目的整体架构
2、RabbitMQ和kafka的特点，各自适用于什么场景
3、kafka为什么是高可用的
4、说一下Es的分片
5、说一下你们redis集群结构，redis的使用场景
6、分片集群中，3个主节点，3个从节点，如果某个主从节点都宕机，会怎样
7、聊下你们项目使用分布式锁的场景
8、reddsion做分布式锁有哪些优化
9、分布式事务说一下二阶段提交存在的问题
10、说一下mysql索引结构 b+树
11、聚簇索引，回表，索引覆盖
12、你们项目用了分库分表吗？ 数据发生倾斜怎么办？

2、看你的项目中使用到了RabbitMQ和kafka，说一下各自特点，适用于什么场景
RabbitMQ 适用于需要可靠性传输、多种消息传输模式、灵活路由和交换机模型的应用场景
Kafka 适用于高吞吐量、低延迟、大规模数据处理的场景

3、kafka为什么是高可用的？
1）分布式架构：kakfa是一个分布式系统，消息被存储在多个broker上
2）分区 + 副本
3）isr机制
4）leader选择
5）故障恢复
6）节点的水平扩展

4、说一下ElasticSerch的分片，说一下倒排索引。
会将文档的某个字段进行分词，倒排数据就是单词到文档ID的映射

5、说一下redis集群结构，redis的使用场景？
集群架构：分片集群，三个主节点，三个从节点
redis使用场景：
● 缓存
● 分布式锁
● 利用redis的递增做点赞的累加

6、分片集群中，3个主节点，3个从节点，如果某个主从节点都宕机，会怎样
其他分片仍然可以对外提供服务。

7、聊下你们项目使用分布式锁的场景
热点数据缓存击穿时，使用分布式锁来解决

8、reddsion做分布式锁有哪些优化？

9、分布式事务说一下二阶段提交存在的问题？
什么是二阶段提交？
二阶段提交（Two-Phase Commit）是一种在分布式系统中用于确保事务的一致性的协议。
在分布式系统中，数据分布在多个节点上，因此需要一种机制来确保在跨多个节点的操作中，事务要么全部提交，要么全部回滚，以维护数据的一致性。

分布式事务中二阶段提交协议存在的问题？
● 阻塞问题：在二阶段提交的第二阶段中，如果协调者（Transaction Coordinator）在等待参与者（Transaction Participants）的提交或者回滚响应时发生故障，会导致参与者长时间阻塞，资源无法释放，可能引发性能问题和系统可用性问题。
● 单点故障：二阶段提交协议中的协调者是一个单点，如果协调者发生故障，整个事务流程可能被瘫痪，无法进行提交或者回滚操作。
● 同步通信开销：在准备和提交阶段，协调者需要和所有参与者进行同步通信，这会引入较大的通信开销，尤其在参与者数量庞大的情况下，可能影响性能。
● 数据不一致：在二阶段提交中，如果在准备阶段某个参与者发生故障，或者提交阶段中协调者发生故障，可能导致部分参与者已经提交事务，而其他参与者尚未提交，从而引发数据不一致性问题。
● 长时间锁定资源：在二阶段提交协议中，参与者在准备阶段会锁定资源，直到收到提交或回滚请求后才会释放。如果有参与者在等待阶段长时间不响应或者发生故障，会导致资源长时间被锁定，影响系统的并发性能。

10、说一下mysql索引结构 b+树
多路平衡树
数据都存在叶子节点，并且节点之前有指针相互关联，组成一个双向链表

这种结构的优点：
范围查询效率高
支持快速的顺序访问
范围删除和插入更高效

11、聚簇索引、回表，唯一索引查询主键ID时会走回表吗
聚簇索引： 叶子节点存储的是完整的数据，主键索引是聚簇索引
回表：非聚簇索引叶子节点存储的都是主键ID，所以想获取完整数据会进行回表
唯一索引查询主键ID时会走回表吗：不会，因为索引覆盖

12、你们项目用了分库分表吗？ 数据发生倾斜怎么办？
用到了
在统计直播间的人员流水信息时，会将观众进入，离开的数据分表入库
分表策略： hash(直播ID) % 10
发生了数据倾斜怎么办：
1）优化分表策略
分表只是为了降低单表的数据量，并且观众流水只是为了做一些统计工作给管理员使用，所以没有注重解决数据倾斜的问题