注册中心
什么是注册中心
注册中心主要有三种角色：
- 服务提供者:在启动时，向注册中心注册自身实例并定期发送心跳。
- 服务消费者:在启动时，向注册中心订阅服务，把注册中心返回的服务节点缓存在内存。
- 服务注册中心:保存注册信息。
CAP理论
CAP 也就是 Consistency（一致性） 、Availability（可用性） 、Partition Tolerance（分区容错性） 这三个单词首字母组合。
- 一致性:所有节点在统一时间具有相同的数据
- 可用性:保证每个请求不管成功还是失败都有响应
- 分区容错性:分布式系统中出现网络分区仍然提供对外访问
CAP是只能3选2的：
首先CAP中P是必须保证的，当发生网络分区后我们要继续提供对外服务就只能在强一直性(C)和高可用(A)上进行2选1。
为什么CA不能同时存在
在发生分区情况下,我们要保证强一直性(C)服务之间会有同步过程，我们就必须要禁掉别的服务，这时候这个服务是不可请求状态那么就和高可用(A)冲突了。如果保证了高可用(A)，就会和强一致性(C)进行了冲突。
BASE理论
BASE理论 是 Basically Available(基本可用)、Soft State（软状态） 和 Eventually Consistent（最终一致性） 三个短语的缩写。
基本可用
什么是基本可用呢？假设系统，出现了不可预知的故障，但还是能用，相比较正常的系统而言：
- 响应时间上的损失：正常情况下的搜索引擎0.5秒即返回给用户结果，而基本可用的搜索引擎可以在2秒作用返回结果。
- 功能上的损失：在一个电商网站上，正常情况下，用户可以顺利完成每一笔订单。但是到了大促期间，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。
软状态
软状态指允许系统中的数据存在中间状态（CAP 理论中的数据不一致），并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
最终一致性
最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。
分布式一致性的 3 种级别：
- 强一致性 ：系统写入了什么，读出来的就是什么。
- 弱一致性 ：不一定可以读取到最新写入的值，也不保证多少时间之后读取到的数据是最新的，只是会尽量保证某个时刻达到数据一致的状态。
- 最终一致性 ：弱一致性的升级版。，系统会保证在一定时间内达到数据一致的状态，
注册中心对比
什么是nacos
Nacos 是 Dynamic Naming and Configuration Service 的首字母简称；一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。
优势
- 易用：简单的数据模型，标准的restfulAPI，易用的控制台，丰富的使用文档。
- 稳定：99.9% 高可用，脱胎于历经阿里巴巴10年生产验证的内部产品，支持具有数百万服务的大规模场景，具备企业级SLA的开源产品。
- 实时：数据变更毫秒级推送生效；1w 级，SLA 承诺 1w 实例上下线 1s，99.9%推送完成；10w 级，SLA 承诺 1w 实例上下线 3s，99.9% 推送完成；100w 级别，SLA 承诺 1w 实例上下线 9s 99.9% 推送完成。
- 规模：十万级服务/配置，百万级连接，具备强大扩展性。
核心功能
- 服务注册：Nacos Client会通过发送REST请求的方式向Nacos Server注册自己的服务，提供自身的元数据，比如ip地址、端口等信息。Nacos Server接收到注册请求后，就会把这些元数据信息存储在一个双层的内存Map中。
- 服务心跳：在服务注册后，Nacos Client会维护一个定时心跳来持续通知Nacos Server，说明服务一直处于可用状态，防止被剔除。默认5s发送一次心跳。
- 服务同步：Nacos Server集群之间会互相同步服务实例，用来保证服务信息的一致性。
- 服务发现：服务消费者（Nacos Client）在调用服务提供者的服务时，会发送一个REST请求给Nacos Server，获取上面注册的服务清单，并且缓存在Nacos Client本地，同时会在Nacos Client本地开启一个定时任务定时拉取服务端最新的注册表信息更新到本地缓存
- 服务健康检查：Nacos Server会开启一个定时任务用来检查注册服务实例的健康情况，对于超过15s没有收到客户端心跳的实例会将它的healthy属性置为false(客户端服务发现时不会发现)，如果某个实例超过30秒没有收到心跳，直接剔除该实例(被剔除的实例如果恢复发送心跳则会重新注册)
