高阶篇：
一、在面对千万条并发请求的情况下，如果数据库频繁查询导致崩溃，可以采取以下措施来解决问题:
1.缓存数据:可以使用缓存技术来减少对数据库的查询次数。将经常查询的数据存储在缓存中，例如使用Redis等内存数据库，以减少每次查询时对数据库的访问。
2.限流和降级:在高并发场景下，需要对请求进行限流和降级，以防止系统过载。这可以通过使用限流算法(如令牌桶、漏桶等)或者设置接口级别的限流规则来实现。降级则是指当系统负载过高时，自动降低部分服务的可用性，以保护整个系统的稳定性。
扩展答案：自行研究elasticsearch
二、有很多个服务，一个功能出现问题，怎么快速定位是哪个服务出现的问题?
ZIPKIN：分布式链路追踪
Zipkin可以确定对应用程序的请求在哪里花费了更多时间。无论是代码内部的调用，还是对另一服务的内部或外部API调用，您都可以对系统进行检测以共享上下文。
微服务应用的响应时间过长，使用Zipkin的话，就可以轻松了解应用程序是否花费了大部分时间来查询数据库。通过 Zipkin 提供的请求延迟时间可视化，可能会发现导致请求时间过长的原因，是由于高速缓存服务器已关闭，所有调用都直接发送到数据库，从而增加了微服务的延迟。
ZIPKIN：扩展问题（面试官会顺流而下继续问的问题）经常问的，能不能具体说说怎么实现的？
1、搭建zipkin-server
2、Zipkin就会以单个 span的形式将跟踪数据异步发送到 Zipkin 的数据追踪收集器（跟踪是通过带有 context header 的 HTTP 协议发送的）。
3、Zipkin 自带有一个可访问的用户界面，可以通过可视化看出哪里浪费了时间，哪里有问题。
三、Zookeeper是怎么注册的？
1.1、当服务启动时，服务的信息会存储到ZooKeeper临时节点上，这就是Zookeeper的注册。
四、Zookeeper什么是临时节点和什么是持久节点？
临时节点： 服务注册后连接丢失或session超时，注册的节点会自动被移除 。
持久节点： 服务注册后保证节点不会丢失，注册中心重启也会存在 。
五、zookeper的选举机制？
Leader 节点宕机了，Zookeeper中的每一个节点都会向集群里面的其他节点发送一个票据 Vote，每个节点都会选自己当 Leader，所以第一次投票的时候携带的是当前节点的信息。接下来每个节点用收到的票据和自己节点的票据做比较，根据 epoch、zxid、myid的顺序逐一比较，以值最大的一方获胜。比较结束以后这个节点下次再投票的时候，发送的投票请求就是获胜的