大家好，又见面了，我是你们的朋友全栈君。

CAP 定理介绍

CAP原则又称CAP定理，指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。

• 一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
• 可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）
• 分区容忍性（P）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。

CAP原则的精髓就是要么AP，要么CP，要么AC，但是不存在CAP。如果在某个分布式系统中数据无副本， 那么系统必然满足强一致性条件， 因为只有独一数据，不会出现数据不一致的情况，此时C和P两要素具备，但是如果系统发生了网络分区状况或者宕机，必然导致某些数据不可以访问，此时可用性条件就不能被满足，即在此情况下获得了CP系统，但是CAP不可同时满足。
必然导致某些数据不可以访问，此时可用性条件就不能被满足，即在此情况下获得了CP系统，但是CAP不可同时满足。
Ps：消息中间件在开发中起服务控制与通知的作用；是在主程序与关系数据库、非关系数据库、缓存、搜索引擎等服务之间类似于桥梁的关系。有异步、削峰、解耦的功能。

抉择

CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。而由于网络硬件肯定会出现延迟丢包等问题，所以分区容错性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡，没有NoSQL系统能同时保证这三点。

• 数据库事务一致性需求
  　　很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求并不高。允许实现最终一致性。
• 数据库的写实时性和读实时性需求
  　　对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的，但是对于很多web应用来说，并不要求这么高的实时性，比方说发一条消息之 后，过几秒乃至十几秒之后，我的订阅者才看到这条动态是完全可以接受的。
• 对复杂的SQL查询，特别是多表关联查询的需求
  　　任何大数据量的web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的报表查询，特别是SNS类型的网站，从需求以及产品设计角 度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大的弱化了。

关系

• NoSQL的关系
  传统的关系型数据库在功能支持上通常很宽泛，从简单的键值查询，到复杂的多表联合查询再到事务机制的支持。而与之不同的是，NoSQL系统通常注重性能和扩展性，而非事务机制（事务就是强一致性的体现）。
  　　传统的SQL数据库的事务通常都是支持ACID的强事务机制。A代表原子性，即在事务中执行多个操作是原子性的，要么事务中的操作全部执行，要么一个都不执行；C代表一致性，即保证进行事务的过程中整个数据库的状态是一致的，不会出现数据花掉的情况;I代表隔离性，即两个事务不会相互影响，覆盖彼此数据等；D表示持久化，即事务一旦完成，那么数据应该是被写到安全的，持久化存储的设备上（比如磁盘）。
  　　NoSQL系统仅提供对行级别的原子性保证，也就是说同时对同一个Key下的数据进行的两个操作，在实际执行的时候是会串行的执行，保证了每一个Key-Value对不会被破坏。
• 与BASE的关系
  BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写。
  BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的结论，是基于CAP定理逐步演化而来的，其核心思想是即使无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。接下来我们着重对BASE中的三要素进行详细讲解。
  • 基本可用：指分布式系统在出现不可预知故障的时候，允许损失部分可用性。注意，这绝不等价于系统不可用，以下两个就是“基本可用”的典型例子：
  • 响应时间上的损失：正常情况下，一个在线搜索引擎需要0.5秒内返回给用户相应的查询结果，但由于出现异常（比如系统部分机房发生断电或断网故障），查询结果的响应时间增加到了1~2秒。
  • 功能上的损失：正常情况下，在一个电子商务网站上进行购物，消费者几乎能够顺利地完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。
  • 弱状态：也称为软状态，和硬状态相对，是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
  • 最终一致性：强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

中间件概述

消息队列中间件是分布式系统中重要的组件，主要解决应用耦合，异步消息， 流量削锋等问题。实现高性能，高可用，可伸缩和最终一致性架构。是大型分布式系统不 可缺少的中间件。常用消息队列系统：目前在生产环境，使用较多的消息队列有 ActiveMQ、RabbitMQ、 ZeroMQ、Kafka、MetaMQ、RocketMQ 等

分类

• （1）事务式中间件
  事务式中间件又称事务处理管理程序，是当前用的最广泛的中间件之一，其主要功能是提供联机事务处理所需要的通信、并发访问控制、事务控制、资源管理、安全管理、负载平衡、故障恢复和其他必要的服务。事务式中间件支持大量客户进程的并发访问，具有极强的扩展性。由于事务式中间件具有可靠性高、极强的扩展性等特点，主要应用于电信、金融、飞机订票系统、证券等拥有大量客户的领域。
• （2）过程式中间件
  过程式中间件又称远程过程调用中间件。过程中间件一般从逻辑上分为两部分：客户和服务器。客户和服务器是一个逻辑概念，既可以运行在同一计算机上，也可以运行在不同的计算机上，甚至客户和服务器底层的操作系统也可以不同。客户机和服务器之间的通信可以使用同步通信，也可以采用线程式异步调用。所以过程式中间件有较好的异构支持能力，简单易用，但由于客户和服务器之间采用访问连接，所以在易剪裁性和容错方面有一定的局限性。
• （3）面向消息的中间件
  面向消息的中间件，简称为消息中间件，是一类以消息为载体进行通信的中间件，利用高效可靠的消息机制来实现不同应用间大量的数据交换。按其通信模型的不同，消息中间件的通信模型有两类：消息队列和消息传递。通过这两种消息模型，不同应用之间的通信和网络的复杂性脱离，摆脱对不同通信协议的依赖，可以在复杂的网络环境中高可靠、高效率的实现安全的异步通信。消息中间件的非直接连接，支持多种通信规程，达到多个系统之间的数据的共享和同步。面向消息中间件是一类常用的中间件。
• （4）面向对象中间件
  面向对象中间件又称分布对象中间件，是分布式计算技术和面向对象技术发展的结合，简称对象中间件。分布对象模型是面向对象模型在分布异构环境下的自然拓广。面向对象中间件给应用层提供过重不同形式的通信服务，通过这些服务，上层应用对事务处理、分布式数据访问，对象管理等处理更简单易行。OMG组织是分布对象技术标准化方面的国际组织，它制定出了CORBA等标准。
• （5）Web应用服务器
  Web应用服务器是Web服务器和应用服务器相结合的产物。应用服务器中间件可以说是软件的基础设施，利用构件化技术将应用软件整合到一个确定的协同工作环境中，并提供多种通信机制，事务处理能力，及应用的开发管理功能。由于直接支持三层或多层应用系统的开发，应用服务器受到了广大用户的欢迎，是目前中间件市场上竞争的热点，J2EE架构是目前应用服务器方面的主流标准。
• （6）其他
  新的应用需求、新的技术创新、新的应用领域促成了新的中间件产品的出现。如，ASAAC在研究标准航空电子体系结构时提出的通用系统管理GSM，属于典型的嵌入式航电系统的中间件，互联网云技术的发展云计算中间件、物流网的中间件等随着应用市场的需求应运而生。

功能

• （1）通信支持
  中间件为其所支持的应用软件提供平台化的运行环境，该环境屏蔽底层通信之间的接口差异，实现互操作，
  所以通信支持是中间件一个最基本的功能。早期应用与分布式的中间件交互主要的通信方式为远程调用和消息两种方式。通信模块中，远程调用通过网络进行通信，通过支持数据的转换和通信服务，从而屏蔽不同的操作系统和网络协议。远程调用是提供给予过程的服务访问，为上层系统只提供非常简单的编程接口或过程调用模型。消息提供异步交互的机制。
• （2）应用支持
  中间件的目的就是服务上层应用，提供应用层不同服务之间的互操作机制。它为上层应用开发提供统一的平台和运行环境，并封装不同操作系统提供API接口，向应用提供统一的标准接口，使应用的开发和运行与操作系统无关，实现其独立性。中间件松耦合的结构，标准的封装服务和接口，有效的互操作机制，从而给应用结构化和开发方法提供有力的支持。
• （3）公共服务
  公共服务是对应用软件中共性功能或约束的提取。将这些共性的功能或者约束分类实现，并支持复用，作为公共服务，提供给应用程序使用。通过提供标准、统一的公共服务，可减少上层应用的开发工作量，缩短应用的开发时间，并有助于提供应用软件的质量。

特长

1. 满足大量应用的需要 ；
2. 运行于多种硬件和OS平台 ；
3. 支持分布式计算，提供跨网络、硬件和OS平台的透明性的应用或服务的交互功能 ；
4. 支持标准的协议 ；
5. 支持标准的接口。

弊端：

• 中间件所应遵循的一些原则离实际还有很大距离。
• 多数流行的中间件服务使用专有的API和专有的协议，使得应用建立于单一厂家的产品，来自不同厂家的实现很难互操作。
• 有些中间件服务只提供一些平台的实现，从而限制了应用在异构系统之间的移植。
• 应用开发者在这些中间件服务之上建立自己的应用还要承担相当大的风险，随着技术的发展他们往往还需重写他们的系统。
• 尽管中间件服务提高了分布计算的抽象化程度，但应用开发者还需面临许多艰难的设计选择，例如，开发者还需决定分布应用在client方和server方的功能分配。通常将表示服务放在client以方便使用显示设备，将数据服务放在server以靠近数据库，但也并非总是如此，何况其它应用功能如何分配也是不容易确定的。