分布式知识点

1、CAP 定理

CAP理论是 Eric Brewer提出的一种分布式状况下，面临的三个无法同时兼顾的问题：

• 一致性（Consistence） :所有节点访问同一份最新的数据副本
• 可用性（Availability）:每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据
• 分区容错性（Partition tolerance） : 分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。

2、BASE 理论

• BASE理论是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于CAP定理逐步演化而来的，它大大降低了我们对系统的要求。
• BASE理论的核心思想： 即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。也就是牺牲数据的一致性来满足系统的高可用性，系统中一部分数据不可用或者不一致时，仍需要保持系统整体“主要可用”。

3、TCC

最终一致性方案——TCC分为 Try , Confirm, Cancel ，简称TCC。Try:尝试锁定事务涉及的资源，进行资源预留Confirm:对预留的资源做确认提交Cancel:如果confirm失败，则进行补偿操作，回滚业务处理，解锁预留资源。

4、分布式事务解决方案

• 两阶段提交协议(2PC)：在分布式事务中，一个事务贯穿多个节点，每个节点仅仅知道自己操作的结果，但是并不知道其它节点的操作结果。为了保证事务的一致性，就需要一个统一的协调者，每个节点把操作的结果告知协调者，协调者再根据操作结果再通知各节点是将操作提交还是取消。
• 三阶段提交协议(3PC)：三阶段提交协议是两阶段提交协议的改进，目的是解决两阶段协议的缺点。它加入了超时机制来解决两阶段协议的阻塞问题，并在准备阶段前增加了询问阶段（协调者询问节点是否可以提交，节点只需要返回是或否即可）。如果发生响应超时的问题，则可以回滚，不会使节点进入阻塞状态等待。
• 可靠消息服务：所以系统A在执行前先将消息发送给消息系统，执行成功后再发送确认消息，确保系统A成功执行后，消息系统才会将消息发送到B系统，保证消息的可执行性；投递到B系统的消息执行失败后重复投递，超过一定次数后采用补偿模式，做特殊处理，保证消息的可靠性，参考。
• 最大努力通知：主要由业务活动的主动方，在完成相关业务处理之后，向业务活动的被动方发送消息，消息允许丢失；在通知N次之后就不再通知，需要人工介入；被动方根据定时的策略，向业务活动的主动方进行轮询，进而恢复丢失的业务消息；这里注意被动方还是需要实现业务幂等的。
• TCC模式：Try、Confirm、Cancel三个步骤
• 参考

5、负载均衡算法

负载均衡算法用于确定流量应该被分发到哪一个健康的服务器上，常见的几个算法如下：

• Round Robin — 轮转（Round Robin）意味着服务器会被按顺序地选择，比如负载均衡器会将第一个请求分配给第一个服务器，然后下一个请求分配给第二个服务器，这样分配下去分配完一轮之后回到开头分配给第一个服务器（操作系统调度算法复习一下）。这种方式比较适合各服务器处理能力相同而且每个业务处理量差不多的时候。
• Least Connections — 最少连接（Least Connections）这个算法意味着负载均衡器会选择当前连接最少的服务器。
• IP hash — 在这个算法下，负载均衡器根据请求源的IP来决定分发给哪个服务器。这个方法保证了一个特定的用户会一直访问相同的服务器。
• 其他还有一些不算太常见的算法，比如Url hash、Random等。

6、负载均衡如何处理状态

我们都知道基于session的用户认证会在服务器存有session的一些信息，但当系统引入负载均衡的时候这样会出现一些问题。
为了解决这个问题一个是可以使用之前说的IP hash算法，这个算法根据IP来分配流量对应的服务器，所以可以保证同一个用户的流量会访问到同一个服务器。另一个应用层的方法是sticky session，中文应该叫粘性会话，负载均衡器会设置一个cookie然后带有这个cookie的session都会被分配到同一个服务器上。

7、健康检测（health checks）

在负载均衡算法一节中我们有一个前提，就是流量只会被分配到健康的服务器上，那么负载均衡器怎么去判断服务器现在是否健康呢？
为了监控健康的服务器，健康检查一般会通过配置的协议和端口尝试去连接服务器来保证服务器正在监听。如果一个服务器的健康检查失败了，也就是说服务器无法正常响应请求，那么就会被自动的移除池子中，流量也不会被分配到这个坏掉的服务器直到它能通过健康检查。

8、分布式数据库保持一致性

主要是对Raft算法的理解：

• Raft强调的是易懂，Raft和Paxos一样只要保证n/2+1节点正常就能够提供服务。
• 众所周知当问题较为复杂时可以把问题分解为几个小问题来处理，Raft也使用了分而治之的思想。Raft算法重点解决三个子问题：选举(Leader election)、日志复制(Log replication)、安全性(Safety)。
• Raft算法中，对节点的状态分为3种角色，分别是Leader(领导者)、Follower(追随者)和Candidate(候选者)。
• Leader，负责处理来自客户端的请求，负责将日志同步到Follower中，并且保证与Follower之间的heartBeat联系;
• Follower，当集群刚刚启动时，所有节点均为Follower状态，它的工作主要为响应Leader的日志同步请求，响应Candidate的请求，以及把请求到Follower的事务请求转发给Leader;
• Candidate，选举Leader时负责投票，选举出来Leader后，节点将从Candidate状态变为Leader状态。
  

9、rpc

RPC就是要像调用本地的函数一样去调远程函数。

• Call ID映射。我们怎么告诉远程机器我们要调用Multiply，而不是Add或者FooBar呢？在本地调用中，函数体是直接通过函数指针来指定的，我们调用Multiply，编译器就自动帮我们调用它相应的函数指针。但是在远程调用中，函数指针是不行的，因为两个进程的地址空间是完全不一样的。所以，在RPC中，所有的函数都必须有自己的一个ID。这个ID在所有进程中都是唯一确定的。客户端在做远程过程调用时，必须附上这个ID。然后我们还需要在客户端和服务端分别维护一个 {函数 <–> Call ID} 的对应表。两者的表不一定需要完全相同，但相同的函数对应的Call ID必须相同。当客户端需要进行远程调用时，它就查一下这个表，找出相应的Call ID，然后把它传给服务端，服务端也通过查表，来确定客户端需要调用的函数，然后执行相应函数的代码。
• 序列化和反序列化。客户端怎么把参数值传给远程的函数呢？在本地调用中，我们只需要把参数压到栈里，然后让函数自己去栈里读就行。但是在远程过程调用时，客户端跟服务端是不同的进程，不能通过内存来传递参数。甚至有时候客户端和服务端使用的都不是同一种语言（比如服务端用C++，客户端用Java或者Python）。这时候就需要客户端把参数先转成一个字节流，传给服务端后，再把字节流转成自己能读取的格式。这个过程叫序列化和反序列化。同理，从服务端返回的值也需要序列化反序列化的过程。
• 网络传输。远程调用往往用在网络上，客户端和服务端是通过网络连接的。所有的数据都需要通过网络传输，因此就需要有一个网络传输层。网络传输层需要把Call ID和序列化后的参数字节流传给服务端，然后再把序列化后的调用结果传回客户端。只要能完成这两者的，都可以作为传输层使用。因此，它所使用的协议其实是不限的，能完成传输就行。尽管大部分RPC框架都使用TCP协议，但其实UDP也可以，而gRPC干脆就用了HTTP2。Java的Netty也属于这层的东西。

10、docker

• 容器，为了减少程序在不同机子上的环境配置问题。
• docker相比虚拟机的优势：与虚拟机通过操作系统实现隔离不同，容器技术只隔离应用程序的运行时环境但容器之间可以共享同一个操作系统，这里的运行时环境指的是程序运行依赖的各种库以及配置。
• 一些概念：我们需要在dockerfile中指定需要哪些程序、依赖什么样的配置，之后把dockerfile交给“编译器”docker进行“编译”，也就是docker build命令，生成的可执行程序就是image，之后就可以运行这个image了，这就是docker run命令，image运行起来后就是docker container。
• 底层实现：NameSpace保证linux中的资源互不干扰；Control groups控制容器中进程对系统资源的消耗了，比如你可以限制某个容器使用内存的上限、可以在哪些CPU上运行等等。

11、Paxos算法

参考1、参考2