一：什么是CAP理论，为什么不能同时满足？
CAP理论：一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability)和分区容错性（Partition tolerance）这三项中的两项。一致性是指每次读取都会收到最新的写入数据或错误信息。
二：什么是Nacos？
三：注册中心如何选型?
选择服务注册中心和配置中心需要考虑应用场景、功能需求、易用性和维护成本等因素，有以下几个原则供参考：
- 如果对一致性要求高，建议考虑支持CP模型的Consul、Nacos以及ZK
- 如果应用已经在使用Spring Cloud框架，则建议使用Eureka；
- 如果应用在用Dubbo/Spring Cloud Alibaba，或者需要一套更全面的云原生服务治理平台，则建议使用Nacos；
- 如果需要更强大的健康检查和路由功能，则建议使用Consul。虽然Nacos和Eureka都支持服务健康检查和路由功能，但是Consul在这方面的功能更为强大，比如Consul支持多种健康检查方式（TCP、HTTP、gRPC等）、支持自定义健康检查脚本，可以更精细地控制服务的健康状况。
- 当然，Zookeeper也是一款成熟的分布式协调服务框架，如果已经熟悉使用Zookeeper，也可以考虑使用Zookeeper作为服务注册中心和配置中心。
四：Nacos是AP的还是CP的？
Nacos支持AP和CP两种模式，可以根据具体的使用场景进行选择。默认情況下是AP模式，可以通过修改nacos的配置文件来切换AP/CP。在AP模式下，Nacos保证高可用性和可伸缩性，但不保证强一致性。在CP模式下，Nacos保证强一致性，但可能会降低可用性和可伸缩性。
在实际应用中，具体采用哪种模式，需要根据业务的特点和需求来判断。
如果在分布式系统中，某些数据的一致性对业务有非常高的要求，例如金融、支付等场景，那么可以选择使用CP模式。
如果对于某些服务来说，可用性比一致性更加重要，例如网站、在线游戏等场景，那么可以选择使用AP模式。
五：Nacos能同时实现AP和CP的原理是什么？
Nacos在单个集群中同时支持AP和CP两种模式，之所以这么设计是因为Nacos目前主要用于注册中心和配置中心。对于注册中心来说，一旦可用性不能满足了，那么就会影响所有服务的互相调用。对于配置中心来说，他的主要职责就是提供统一的配置，一致性是他的一个重点考量
Nacos为了同时支持注册中心和配置中心，他通过JRaft协议实现了一个CP的模式，又通过Distro协议实现了一个AP的模式，可以在这两者模式之间进行切换。
六：服务心跳与服务注册原理？
在spring容器启动的时候，nacos客户端会进行两步操作，向nacos服务端发送心跳，向nacos服务端注册当前服务
服务心跳
客户端在启动的时候，会开启一个心跳线程，每隔5s调用一次服务端的心跳接口（Http调用），服务端将心跳请求封装成一个task，放到线程池中。由服务端的线程池执行task，更新对应服务的最后心跳时间。
服务注册
客户端启动的时候，向服务端发起Http接口调用，调用服务注册的接口。服务端收到注册请求，将新的注册信息和老的服务列表封装为一个Pair对象，并放入阻塞队列。服务端在启动的时候会创建一个线程池，并提交一个任务，这个任务就是循环从阻塞队列里拿Pair对象，对其解析，更新服务所在的service内部的clusterMap中的服务列表。
七：服务发现？
客户端定时从服务端拉取最新的服务列表数据，将服务列表加载到本地缓存。同样服务端也会定时向客户端推送服务列表数据。
客户端拉取服务列表
客户端发起服务获取的请求。服务端获取客户端服务所在的service下的所有cluster下的服务列表，并剔除其中不健康的，将所有健康状态的服务列表返回给客户端。
服务端推送服务列表
客户端向服务端拉取数据的同时，会将客户端信息注册到clientMap中。等到下一次发生心跳、服务列表数据变更、健康状态发生变化等，都会触发推送事件。在推送事件方法中，服务端将此客户端对应的service下的所有服务列表基于UDP推送给客户端，并开启一个定时任务，每隔10s定时推送数据到客户端。
八：Nacos配置变化客户端如何感知到?
在Nacos1.x版本中采用的是长轮询，不是长连接，也不是轮询，长轮询其实就是把长连接和轮询综合了一下，就是说客户端发起轮询，但是不立即返回，而是hold一段时间，这段时间保持着一个有效连接，超时或者变化再返回，然后再发起一次轮询。
在Nacos2.0中，采用gRPC长连接。
