CAP理论和Base理论等概念

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实现最终一致性， 从而达到分布式事务的特点，柔性事务   补偿重发 

集群、分布式、SOA、微服务的概念及区别     

集群:不同服务器部署同一套应用服务对外提供访问，实现服务的负载均衡或者互备(热备，主从等), 指同-种组件的多个实例，形成的逻辑上的整体。单个节点可以提供完整服务。集群是物理形态     

分布式:服务的不同模块部黑在不同的服务器上,单个节点不能提供完整服务,需要多节点协调提供服务(也可以是相同组件部署在不同节点、但节点问通过交换信息协作提供服务),分布式强调的是工作方式     

SOA:面向服务的架构，- 种设计方法，其中包含多个服务，服务 之间通过相互依赖最终提供一系列的功能。一 个服务通常以独立的形式存在于操作系统进程中。各个服务之间通过网络调用。    

• 中心化实现: ESB(企业服务总线),各服务通过ESB进行交互，解决异构系统之间的连通性,通过协议转换、消息解析、消息路由把服务提供者的数据传送到服务消费者。很重，有一定的逻辑, 可以解决一些公用逮辑的问题。   
• 去中心化实现:微服务     

微服务:在SOA.上做的升华，微服务架构强调的一个重点是业务需要彻底的组件化和服务化,原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成     

服务单一职责     轻量级通信:去掉ESB总线，采用restapi通信 

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接收客户端的请求之后调用远程方法来响应客户端的请求。 

数据一致性模型有哪些     

强一致性:当更新操作完成之后,任何多个后续进程的访问都会返回最新的更新过的值，这种是对用户最友好的，就是用户上一-次写什么，下一次就保证能读到什么。根据CAP理论,这种实现需要牺牲可用性。

弱一致性: 系统在数据写入成功之后，不承诺立即可以读到最新写入的值，也不会具体的承诺多久之后可以读到。用户读到某一操作对系统数据的更新需要一段时间， 我们称这段时间为“不一致性窗口"。

最終一致性:最終- -致性是弱- -致性的特例,强调的是所有的数据副本,在经过一段时间的同步之后，最终都能够 达到一个一致的状态。 因此,最终-致性的本质 是需要系统保证最终数据能够达到一致，而不需要实时保证系统数     据的强一致性。 到达最终一致性的时间 ,就是不一致窗口时间， 在没有故障发生的前提下，不致窗口的时间主要受通信延迟，系统负较和复制副本的个数影响。     

最終一致性模型根据其提供的不同保证可以划分为更多的模型,包括因果一致性和会话一 致性等。     

因果一致性: 要求有因果关系的操作顺序得到保证，非因果关系的操作顺序则无所谓。进程A在更新完某个数据项后通知了进程B,那么进程B之后对该数据项的访问都应该能够获取到进程A更新后的最新值，并且如果进程B要对该数据项进行更新操作的话，务必基于进程A更新后的最新值。

在微博或者微信进行评论的时候，比如你在朋友圈发了一张照片, 朋友给你评论了,而你对朋友的评论进行了回 复，这条朋友圈的显示中，你的回复必须在朋友之后，这是一个因果关系， 而其他没有因果关系的数据，可以允许不一致。 

会话一致性:将对系统数据的访问过程框定在了一个会话当中,约定了系统能保证在同一个有效的会话中实现"读己之所写”的一致性，就是在你的一次访问中,执行更新操作之后，客户端能够在同一个会话中始终读取到该数据 项的最新值。实际开发中有分布式的Session一致性问题，可以认为是会话一致性的一 个应用。