架构师训练营作业 -20200712

1、请简述CAP原理



CAP是三个单词的首字母的合并，分别是：一致性（Consistency）、可用性（Availability）和分区容错性（Partiton tolerence）。在分布式场景下，这三个特性对应用程序的要求之间存在着矛盾，甚至是不可调和的矛盾。



举例来说：一致性要求应用程序在各节点中的数据是“无论何时都保持一致”，但是当应用程序进行分区部署的时候（例如跨IDC部署），数据写入后同步到其它分区中客观上是存在时延的，而且各分区之间物理距离越远时延越明显。一致性要求用户无论访问那个分区的数据都应该是一致的，然而由于有时延问题的存在，就会导致访问不同节点的用户在某时刻读取到的内容可能存在差异，因为新增的数据尚未同步到所有节点。再举例来说：可用性要求应用程序能够灵活的对节点进行增/减，实现快速扩容的目标；而新增加的节点在增加之初，数据上通常处在落后于其它节点，或需要重新同步/转移数据的情况，这就与一致性的要求相违背。



从目前的实践经验来看，软件在进行部署的时候，通常时尽量满足CAP中的两个要求，并通过其它手段，例如柔性事务、最终一致性等方式进行补足。以目前个人所了解到的中间件产品来看，比较常见的场景是满足CP或AP。例如ZooKeeper通过抢夺主节点的方式，实现群集内的仲裁统一通过主节点，且其余节点进行投票表决的方案实现CP，因为任何决策都要通过主节点发起所有节点的投票的方式进行，可以保证群集内的所有节点的数据在提交的时候都遵从主节点的决策，可以保证各节点的数据是一致的，及时各节点的部署不在一个分区内；然而当主节点宕机的时候，其它服务器需要重新抢夺主节点，因此在新的主节点确定下来之前，由于群集内缺少主节点，此时群集将不可用，就无法满足可用性的要求；此外，当群集内超过一半的节点网络中断无法向主节点反馈投票结果的时候，由于赞成票数未超过半数，因此无法达成一致，此时整个群集也将不可用。



再比如常见的通过数据库复制实现的分布式数据库，由于其实现原理是将主节点的binlog传输至各个子节点进行重做，因此虽然可以很方便的增减从节点实现高可用和分区容错，但是由于日志传输和子节点重做操作所需要的时间，不能保证所有节点在所有时刻的数据都是统一的，最典型的情况就是在子节点还未接收到主节点发送过来的日志的时候，主子节点之间的数据就是不一致的；或者由于传输时延的问题，不同子节点之间的数据也可能出现不一致，因为有一些子节点已经接收到并完成了重做，而有一些子节点还未接收到日志。



在实际工作过程中，应该根据实际需求选择实现方案。对数据一致性要求较高的应用，如银行系统、财务系统等，一般选择满足CP的方式进行开发，保证数据的准确性；对于数据一致性要求不十分严格的应用，如社交类应用，可以选择AP的方式，保证自己的服务一致可以访问，再通过最终一致性的方案解决数据一致的问题。



2、针对Doris案例，请用UML时序图描述Doris临时失效的处理过程（包括判断系统进入临时失效状态，临时失效的读写过程，失效恢复过程）



判断节点进入临时失效的时序图如下：



客户端程序向Doris发送请求时，如果遇到发送失败（例如超时）时首先会进行重试，以判断是否为网络抖动；重试超过指定次数（如3次）仍失败则向仲裁节点申请仲裁，以确认目标节点是否确实不可用。仲裁节点接收到仲裁请求后尝试向问题节点发送请求，如同样失败，则认为该节点确实已失效，从可用节点列表里去除目标节点，并向群集内各客户端程序发送节点失效的广播。此时视为节点1临时失效。



节点在临时失效期间读写操作的时序图如下：

在节点1临时失效期间，客户端与群集内其它节点进行交互。其它节点在收到群集内有节点失效的信息时，在进行数据处理的同时，向备用的日志节点写入操作日志，记录每一次数据变更，以备节点从临时失效恢复时进行数据同步。



节点失效恢复的时序图如下：

当节点1从临时失效中恢复的时候，向仲裁节点发送消息声明已恢复，此时节点1处于只写不读的状态。仲裁节点会告知日志节点向临时失效的节点1补录数据，同时也会通知群集内其它节点。日志节点收到节点1处于恢复状态的通知后，将节点内保存的操作日志向节点1同步，节点1在收到日志节点同步过来的操作日志时在节点内进行重做；其它节点在收到客户端的消息时也会向节点1进行同步。数据同步完毕后节点1向仲裁节点发送数据补录完毕的消息，仲裁节点重新将节点1加回可用节点列表，并向客户端重新广播新的可用节点列表。之后节点1恢复正常工作。