CAP
C: 一致性(consistency)： 每一次的请求得到的数据是一样的，每个节点保存的数据是- -致的
如果系统对一个写操作返回成功，那么之后的读请求都必须读到这个新数据;如果 返回失败，那么所有读操作都不能读到这个数据，对调用者而言数据具有强一致性(strong consistency)
A:可用性(availbilty) ： 每一次的请求都可以在一定时间内得到正确的响应，但是数据不一定是最新的 ，可终止，不会一直等待。
P:分区容错性(partition -tolerance)： 分区+容错
分区:是一种现象，由于网络的不稳定性,造成部分节点之间的通信出现了问题（不互通了），于是就产生了分区 容错:是一种目标，就是在发生分区之后,服务的节点是否还可以对外提供服务
所以这里面就造就了-个矛盾：如果节点多,那么可以提高可用性,但是由于节点多,数据之间同步速度会变慢，就影响了-致性 所以，我们选择的时候，就是在AP或CP做选择。
如果选择了CA而放弃了P,那么当发生分区现象时,为了保证C，系统需要禁止写入，当有弓入请求时，系统返回error (例如，当前系统不允许写入) , 这又和A冲突了，因为A要求返回no error和no timeout。因此，分布式系统理论上不可能选择CA架构，只能选择CP或者AP架构。
反证: 如果CAP三者可同时满足，由于允许P的存在,则一定存在节点之间的丢包，如此则不能保证C 因为允许分区容错，写操作可能在节点1上成功，在节点2上失败，这时候对于Client 1 (读取节点1)和Client 2(读取节点2)，就会读取到不一致的值,出现不一致的情况。如果要保持一致性， 写操作必须同时失败，也就是降低系统的可用性。
base理论
cap理论的一种妥协，由于cap只能二取其一， base理论降低了发生分区容错时对可用性和一致性的要求
base里面包括三个方面:基本可用(Basilly Available) ,柔性状态(soft state), 最终一致性(Eventual Consistency)
base理论通过牺牲强一致性, 保证最终一致性, 来获得高可用性。
- 基本可用(BA) :允许可用性降低(可能响应延长、可能服务降级)。分布式系统出现故障时，允许损失-部分功能的可用性。 比如大促的时候,对一些非核心链路的功能进行降级处理，比如商品的评论信息(举例)，Eureka的设计理念也是一个例子。
- 柔性状态(S):在柔性事务中，允许系统存在中间状态，且这个中间状态不会影响系统整体可用性。 比如读写分离，写库同步到读库会有一定的延迟如：支付中····的提示， 其实就是一种柔性状态。电商系统，评论的信息(性能，允许有延迟) , 订单的信息(-致性)
- 最终一致性(E) : 在最终状态中，数据都是一致的。节点数据同步可以存在时延，但在一定的期限后必须达成数据的一 致， 状态变为最终状态 MQ实现最终一致性， 从而达到分布式事务的特点，柔性事务 补偿重发
QPS, TPS,响应时间，吞吐量，并发量, PV, UV,日活名词解释 .
QPS: query 每秒可以处理的查询请求数量
TPS: transaction 事务每秒可以处理的事务请求数量
响应时间:处理一次请求消耗的时间 10ms
吞吐量:单位时间可以处理的请求数量100（单核）
以上是服务器性能
并发量:同一个时刻有多少请求访问我们的服务器
PV: page view当前页面被访问的次数，页面刷新次数参考量不大
UV: user view当前被多少用户访问，以用户为单位
日活:一天活跃用户 （如粉丝量和活跃数比值）
以上是抗压性
简述对RPC、RMI的理解RPC:在本地调用远程的函数，远程过程调用，可以跨语言实现httpClient
RMI:远程方法调用，java中用于实现RPC的一种机制，RPC的java版本， 是2EE的网络调用机制，跨JVM调用对象的方法，面向对象的思维方式直接或间接实现接口java.rmi.Remote 成为存在于服务器端的远程对象，供客户端访问并提供一定的服务远程对象必须实现java.rmi.server.UniCastRemoteObject类,这样才能保证客户端访问获得远程对象时,该远程对象将会把自身的一个拷则以Socket的形式传输给客户端，此时客户端所获得的这个拷贝称为"存根”，而服务器端本身已存在的远程对象则称之为“骨架"”。其实此时的存根是客户端的一个代理, 用于与服务器端的通信，而骨架也可认为是服务器端的一个代理，用f接收客户端的请求之后调用远程方法来响应客户端的请求。
