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系统的消息执行失败后重复投递，超过一定次数后采用补偿模式，做特殊处理，保证消息的可靠性。
- 最大努力通知：最大努力通知的解决方案在事务的执行过程中，消息的传递允许发生丢失，所以消息是不可靠的；被动方根据定时策略，采用补偿模式，主动向主动方发起校对查询（主动方提供校对查询接口），恢复丢失的业务消息。
- 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）
在负载均衡算法一节中我们有一个前提，就是流量只会被分配到健康的服务器上，那么负载均衡器怎么去判断服务器现在是否健康呢？
为了监控健康的服务器，健康检查一般会通过配置的协议和端口尝试去连接服务器来保证服务器正在监听。如果一个服务器的健康检查失败了，也就是说服务器无法正常响应请求，那么就会被自动的移除池子中，流量也不会被分配到这个坏掉的服务器直到它能通过健康检查。