分布式-总结列表

• 单一职责
• 适中的服务粒度
• 考虑团队结构
• 切入商业模式
• 演进式拆分
• 避免环形依赖和双向依赖

1 人员的角度

维护代名工程Denali数百万代码怪物（虽然物理部署是分开的），从发布到在线，从人员的角度来看，数百人同时在一个项目中开发，一旦在线问题，所有代码都需要回滚，从人员的角度来看，也基本上忍受了极端。

2 业务的角度

淘宝业务太多：用户、商品、交易、支付…等等，所有代码都在早期denali在一个项目中，代码严重影响了业务效率。每个业务都有自己的需求，需要部署自己的应用程序和开发需求。

3 从架构的角度

从数据库端oracle数据库集中架构的瓶颈，连接池的数量有限(oracle数据库提供约5000个连接)，数据库CPU已达90%的极限。垂直拆分也需要考虑数据库端。

4.迫切需要走向大型分布式时代，率先应用拆分

三类集群：

• 负载均衡集群（Load balancing clusters）简称LBC
• 高可用性集群（High-availability clusters）简称HAC
• 高性能计算集群（High-perfomance clusters）简称HPC

单点登录SSO（Single Sign On）简单来说，在多系统共存的环境下，用户在一个地方登录后，不需要在其他系统中登录，即用户的一次登录可以得到所有其他系统的信任。

单点登录的本质是在多个应用程序系统中共享登录状态。如果用户的登录状态被记录在中 Session 要实现共享登录状态，必须先共享 Session。

原理相对简单，采用共享cookie实现SSO，sso-server使用redis存储用户ticket，app-a和app-b使用Spring拦截器过滤用户请求，每个请求都需要sso-server验证ticket,如果验证失败，重定向登录(附带源)url).

sso先看客户端/服务端架构。sso-client与sso-server要实现的功能(以下:sso认证中心=sso-server）

CAS与OAuth2的区别

一、

CAS确保客户端用户资源的安全 。

OAuth二是保证服务端用户资源的安全 。

二、

CAS客户端需要获得的最终信息是用户是否有权访问我（CAS客户端)资源。

OAuth我得到的最终信息是，我（oauth2服务提供商)用户资源能让你吗？（oauth2客户端)访问。

三、

CAS单点登录，资源在客户端，而不是CAS的服务器那一方。 用户在给CAS服务器提供用户名密码后，作为CAS客户不知道。 随便给客户端个ST，那么客户端就不确定了ST是用户伪造还是真的有效，所以拿这个ST再问一遍，这个用户给我的是有效的ST还是无效的ST，这个用户访问是有效的。

OAuth认证，资源都在OAuth在服务提供商方面，客户端希望获取用户资源。 因此，在最安全的模式下，服务端不能在用户授权后直接返回token，因为这个，通过重定向交付给客户端token如果黑客截获了这个，它可能会被黑客截获token，那么用户的资源也暴露在黑客之下。 所以聪明的服务器发送了认证code给客户端(通过重定向)，客户端在后台，通过https用这个code，以及另一系列客户端和服务端提前讨论的密码，以获得token和刷新token，这个过程非常安全。 若黑客截获code，他没有提前讨论的密码，他也得不到token的。这样oauth2就能保证请求资源这件事，是用户同意的，客户端也是被认可的，可以放心的把资源发给这个客户端了。

总结：所以cas登录和OAuth过程中最大的区别是通过ST或者code去认证的时候，需不需要预先商量好的密码。

分布式事务的解决方案如下：

• 全局消息
• 基于可靠信息服务的分布式事务
• TCC
• 尽量通知

XA 一个或多个资源管理器的事务（RM）、事务管理器（TM）应用程序（ApplicationProgram）组成。

Saga是这篇数据库论文saga提到的计划。其核心思想是将长事务分为多个本地短事务，由Saga如果事务协调器协调正常，则正常完成。如果某一步骤失败，则按相反顺序调用补偿操作。

SAGA事务特点：

• 并发度高，不需要像XA事务长期锁定资源
• 正常操作和补偿操作需要定义，开发量比XA大
• 一致性弱，对于转账，A用户可能已经扣除，最终转账失败

关于 TCC（Try-Confirm-Cancel）概念，最早是由 Pat Helland 于 2007 年发表的一篇文章叫《Life beyond Distributed Transactions:an Apostate’s Opinion》论文提出。

TCC分为3个阶段

• Try 阶段：尝试实施，完成所有业务检查（一致性）， 必须预留业务资源(准隔离)
• Confirm 阶段：确认业务实施，不进行任何业务检查，只使用 Try 阶段预留的业务资源，Confirm 操作要求有幂等设计，Confirm 失败后需要重试。
• Cancel 阶段:取消执行，释放 Try 阶段预留的业务资源。Cancel 阶段异常和 Confirm 阶段异常处理方案基本一致，要求满足功率等设计。

TCC特点如下：

• 并发度高，无长期资源锁定。
• 开发量大，需要提供Try/Confirm/Cancel接口。
• 一致性好，不会发生SAGA已扣款最后又转账失败的情况
• TCC适用于订单业务，对中间状态有约束力

设计核心是通过消息异步确保需要分布式处理的任务的执行。

本地消息表的特点：

• 长事务只需分为多个任务，使用简单
• 生产者需要创建额外的信息表
• 每个本地消息表都需要轮询
• 如果消费者的逻辑不能通过重试成功，需要更多的机制来回滚动

发起人通过一定的机制，尽最大努力将业务处理结果通知接收人：

• 提供接口，通过接口查询业务处理结果
• 消息队列ACK机制，消息队列按间隔1min、5min、10min、30min、1h、2h、5h、10h通知间隔的方式逐渐扩大 ，直到达到通知要求的时间窗口上限。之后不再通知

这是阿里开源项目seata蚂蚁金服的事务模式也被称为FMT。优点是该事务模式的使用方式相似XA模式，业务不需要编写各种补偿操作，回滚由框架自动完成，缺点类似AT，锁时间长，不符合高并发场景。感兴趣的学生可以参考seata-AT

Seata 为用户提供 AT、TCC、SAGA 和 XA 为用户创建一站式分布式解决方案。

数据库有四个隔离级别：

1. 1. Read uncommitted 读未提交 在这个级别下，在一行数据修改过程中，不允许另一行数据修改，但允许另一行数据读取。 因此，在这个级别下，不会有更新丢失，但会有脏读，不能重复读。
   2. Read committed 读提交 在这个级别下，未提交的写作事务不允许其他事务访问银行，因此不会有肮脏的阅读；但读取数据的事务允许其他事务访问银行数据，因此不能重复。
   3. Repeatable read 重复读 在这个级别下，禁止阅读事务，但允许阅读事务，因此不会有同一事务两次阅读不同的数据情况（不可重复读），且写事务禁止其他一切事务。
   4. Serializable 序列化 该级别要求所有事务都必须串行执行，因此能避免一切因并发引起的问题，但效率很低。

CAP理论说的是：在一个分布式系统中，最多只能满足C、A、P中的两个需求。

CAP的含义：

• • C：Consistency 一致性 同一数据的多个副本是否实时相同。
  • A：Availability 可用性 可用性：一定时间内 & 系统返回一个明确的结果 则称为该系统可用。
  • P：Partition tolerance 分区容错性 将同一服务分布在多个系统中，从而保证某一个系统宕机，仍然有其他系统提供相同的服务。

CAP理论告诉我们一个悲惨但不得不接受的事实——我们只能在C、A、P中选择两个条件。而对于业务系统而言，我们往往选择牺牲一致性来换取系统的可用性和分区容错性。不过这里要指出的是，所谓的“牺牲一致性”并不是完全放弃数据一致性，而是牺牲强一致性换取弱一致性。下面来介绍下BASE理论。

• • • BA：Basic Available 基本可用
      • 整个系统在某些不可抗力的情况下，仍然能够保证“可用性”，即一定时间内仍然能够返回一个明确的结果。只不过“基本可用”和“高可用”的区别是：
        • “一定时间”可以适当延长 当举行大促时，响应时间可以适当延长
        • 给部分用户返回一个降级页面 给部分用户直接返回一个降级页面，从而缓解服务器压力。但要注意，返回降级页面仍然是返回明确结果。
    • S：Soft State：柔性状态 同一数据的不同副本的状态，可以不需要实时一致。
    • E：Eventual Consisstency：最终一致性 同一数据的不同副本的状态，可以不需要实时一致，但一定要保证经过一定时间后仍然是一致的。

update stock set num=num-1 where id = #{id};

select * from stock where id=#{id} for update;

select num,version from stock where id=#{id};

update stock set num=new_num, version=version+1 where id=#{id} and version=#{version};

Redis天然提供了setnx命令，可以保证原子操作，命令在指定的key不存在时，为key设置指定的值。

如果是Java代码，可以使用Redission包来实现分布式锁。

数据库锁：

优点：直接使用数据库，使用简单。

缺点：分布式系统大多数瓶颈都在数据库，使用数据库锁会增加数据库负担。

缓存锁：

优点：性能高，实现起来较为方便，在允许偶发的锁失效情况，不影响系统正常使用，建议采用缓存锁。

缺点：通过锁超时机制不是十分可靠，当线程获得锁后，处理时间过长导致锁超时，就失效了锁的作用。

zookeeper锁：

优点：不依靠超时时间释放锁；可靠性高；系统要求高可靠性时，建议采用zookeeper锁。

缺点：性能比不上缓存锁，因为要频繁的创建节点删除节点。

• 动态数据源
• 读写分离
• 分布式唯一主键生成器
• 分库分表
• 连接池及SQL监控
• 动态化配置等

1.TDDL

淘宝根据自己的业务特点开发了TDDL框架，主要解决了分库分表对应用的透明化以及异构数据库之间的数据复制，它是一个基于集中式配置的JDBC datasource实现。

特点

实现动态数据源、读写分离、分库分表。

缺点

分库分表功能还未开源，当前公布文档较少，并且需要依赖diamond（淘宝内部使用的一个管理持久配置的系统）

2.DRDS

阿里分布式关系型数据库服务（Distribute Relational Database Service，简称DRDS）是一种水平拆分、可平滑扩缩容、读写分离的在线分布式数据库服务。

前身为淘宝 TDDL，下一代是 DRDS，整合云服务，收费、Cobar、TDDL整合，商用，首选。

3.Atlas

Atlas是由 Qihoo 360公司Web平台部基础架构团队开发维护的一个基于MySQL协议的数据中间层项目。

它在MySQL官方推出的MySQL-Proxy 0.8.2版本的基础上，修改了大量bug，添加了很多功能特性。目前该项目在360公司内部得到了广泛应用，很多MySQL业务已经接入了Atlas平台，每天承载的读写请求数达几十亿条。

主要功能：

1.读写分离

2.从库负载均衡

3.IP过滤

4.自动分表

5.DBA可平滑上下线DB

6.自动摘除宕机的DB

4.MTDDL（Meituan Distributed Data Layer）

美团点评分布式数据访问层中间件

特点

实现动态数据源、读写分离、分库分表，与tddl类似。

下面我以MTDDL为例，也可以参考淘宝tddl，完整详解分布式数据层中间件的架构设计。

Zookeeper 分布式服务框架是Apache Hadoop 的一个子项目，它主要是用来解决分布式应用中经常遇到的一些数据管理问题，如：

1. 统一命名服务
2. 状态同步服务
3. 集群管理
4. 分布式应用配置项的管理等

1、Zookeeper的角色

» 领导者（leader）：负责进行投票的发起和决议，更新系统状态。

» 学习者（learner）：包括跟随者（follower）和观察者（observer），follower用于接受客户端请求并想客户端返回结果，在选主过程中参与投票。

» Observer：可以接受客户端连接，将写请求转发给leader，但observer不参加投票过程，只同步leader的状态，observer的目的是为了扩展系统，提高读取速度

» 客户端（client）：请求发起方

Zookeeper的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。

Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。

每个Server在工作过程中有三种状态：

LOOKING：当前Server不知道leader是谁，正在搜寻

LEADING：当前Server即为选举出来的leader

FOLLOWING：leader已经选举出来，当前Server与之同步

ZooKeeper命名空间中的Znode，兼具文件和目录两种特点。既像文件一样维护着数据、元信息、ACL、时间戳等数据结构，又像目录一样可以作为路径标识的一部分。图中的每个节点称为一个Znode。 每个Znode由3部分组成:

① stat：此为状态信息, 描述该Znode的版本, 权限等信息

② data：与该Znode关联的数据

③ children：该Znode下的子节点

(4) 节点类型

**① 临时节点：**该节点的生命周期依赖于创建它们的会话。一旦会话(Session)结束，临时节点将被自动删除，当然可以也可以手动删除。虽然每个临时的Znode都会绑定到一个客户端会话，但他们对所有的客户端还是可见的。另外，ZooKeeper的临时节点不允许拥有子节点。

**② 永久节点：**该节点的生命周期不依赖于会话，并且只有在客户端显示执行删除操作的时候，他们才能被删除。

顺序节点

ID是数据的唯一标识，传统的做法是利用UUID和数据库的自增ID，在互联网企业中，大部分公司使用的都是Mysql，并且因为需要事务支持，所以通常会使用Innodb存储引擎，UUID太长以及无序，所以并不适合在Innodb中来作为主键，自增ID比较合适，但是随着公司的业务发展，数据量将越来越大，需要对数据进行分表，而分表后，每个表中的数据都会按自己的节奏进行自增，很有可能出现ID冲突。

1、Disconf

2014年7月百度开源的配置管理中心，同样具备配置的管理能力，不过目前已经不维护了，最近的一次提交是两年前了。

2、Spring Cloud Config

2014年9月开源，Spring Cloud 生态组件，可以和Spring Cloud体系无缝整合。

3、Apollo

2016年5月，携程开源的配置管理中心，具备规范的权限、流程治理等特性。

4、Nacos

2018年6月，阿里开源的配置中心，也可以做DNS和RPC的服务发现。

应用、集群、灰度发布、权限管理、版本管理&回滚、多环境、配置实时推送的对比

6部署结构 & 高可用的对比

Spring Cloud Config

Spring Cloud Config包含config-server、Git和Spring Cloud Bus三大组件：

• config-server提供给客户端获取配置;
• Git用于存储和修改配置;
• Spring Cloud Bus通知客户端配置变更;

Apollo

Apollo分为MySQL，Config Service，Admin Service，Portal四个模块：

• MySQL存储Apollo元数据和用户配置数据;
• Config Service提供配置的读取、推送等功能，客户端请求都是落到Config Service上;
• Admin Service提供配置的修改、发布等功能，Portal操作的服务就是Admin Service;
• Portal提供给用户配置管理界面;

Apollo支持四个维度Key-Value格式的配置

• Application(应用) 实际使用配置的应用，Apollo客户端在运行时需要知道当前应用是谁，从而可以去获取对应的配置。每个应用都有对应的身份标识–appId，需要在代码中配置
• Environment(环境) 配置对应的环境，Apollo客户端需要知道当前应用出于哪个环境，，从而可以去获取应用的配置；环境和代码无关，同一份代码部署在不同的环境就应该获取不同环境的配置；环境默认是通过读取机器上的配置(server.properties的env属性)指定的
• Cluster(集群) 一个应用下不同实例的分组，例如按照不同数据中心划分，把上海机房的实例分为一个集群、把深圳机房的实例分为一个集群；对于不同的Cluster，同一个配置可以有不一样的值；集群默认是通过读取机器上的配置指定的(server.properties的idc属性)
• Namespace(命名空间) 一个应用下不同配置的分组，是配置项的集合，可以简单地把Namespace类别为(配置)文件，不同类型的配置存放在不同的文件中，例如数据库配置文件、RPC配置文件、应用自身的配置文件等；应用可以直接读取到公共组件的配置namespace，例如DAL、RPC等；应用也可以通过继承公共组件的配置namespace来对公共组件的配置做调整，如DAL的初始数据库连接数

• 统一管理不同环境、不同集群的配置
• 配置修改实时生效（热发布）
• 版本发布管理
• 灰度发布
• 权限管理、发布审核、操作审计
• 客户端配置信息监控
• 提供Java和.Net原生客户端
• 提供开放平台API
• 部署简单，依赖少

Nacos

Nacos部署需要Nacos Service和MySQL：

• Nacos对外提供服务，支持配置管理和服务发现;
• MySQL提供Nacos的数据持久化存储;

目前市面上有很多的配置中心，本篇主要挑选应用较广的几个针对关键项进行对比，如下表所示

分布式事物常见解决方案:

1. 2PC两段提交协议
2. 3PC三段提交协议(弥补两端提交协议缺点)
3. TCC或者GTS(阿里)
4. 消息中间件最终一致性
5. 使用LCN解决分布式事物，理念“LCN并不生产事务,LCN只是本地事务的搬运工”。

垂直切分常见有垂直分库和垂直分表两种。

垂直切分的优点：

• 解决业务系统层面的耦合，业务清晰
• 与微服务的治理类似，也能对不同业务的数据进行分级管理、维护、监控、扩展等
• 高并发场景下，垂直切分一定程度的提升IO、数据库连接数、单机硬件资源的瓶颈

缺点：

• 部分表无法join，只能通过接口聚合方式解决，提升了开发的复杂度
• 分布式事务处理复杂
• 依然存在单表数据量过大的问题（需要水平切分）

当一个应用难以再细粒度的垂直切分，或切分后数据量行数巨大，存在单库读写、存储性能瓶颈，这时候就需要进行水平切分了。

水平切分的优点：

• 不存在单库数据量过大、高并发的性能瓶颈，提升系统稳定性和负载能力
• 应用端改造较小，不需要拆分业务模块

缺点：

• 跨分片的事务一致性难以保证
• 跨库的join关联查询性能较差
• 数据多次扩展难度和维护量极大

1、事务一致性问题

2、跨节点关联查询 join 问题

3、跨节点分页、排序、函数问题

4、全局主键避重问题

5、数据迁移、扩容问题

站在巨人的肩膀上能省力很多，目前分库分表已经有一些较为成熟的开源解决方案：

• sharding-jdbc（当当）
• TSharding（蘑菇街）
• Atlas（奇虎360）
• Cobar（阿里巴巴）
• MyCAT（基于Cobar）
• Oceanus（58同城）
• Vitess（谷歌）

client模式，proxy模式

无论是client模式，还是proxy模式，几个核心的步骤是一样的：SQL解析，重写，路由，执行，结果归并。

反向代理位于应用服务器机房，处理所有对 Web 服务器的请求。

如果用户请求的页面在代理服务器上有缓冲的话，代理服务器直接将缓冲内容发送给用户。

如果没有缓冲则先向 Web 服务器发出请求，取回数据，本地缓存后再发送给用户。通过降低向 Web 服务器的请求数，从而降低了 Web 服务器的负载。

常见的问题主要包括如下几点：

• 数据一致性
• 缓存穿透
• 缓存雪崩
• 缓存高可用
• 缓存热点

TRDB数据库技术特点：

（1） 使用强存储模式技术。这里特别值数据库表、行、字段的建立，都需要预先严格定义，并进行相关属性约束。

（2） 采用SQL技术标准来定义和操作数据库。

（3） 采用强事务保证可用性及安全性

（4） 主要采用单机集中式处理（CP，Centralized Processing）方式。

NoSQL数据库技术特点：

（1） 使用弱存储模式技术

（2） 没有采用SQL技术标准来定义和操作数据库

（3） 采用弱事务保证数据可用性及安全性或根本没有事务处理机制。

（4） 主要采用多机分布式处理（DP，Distributed Processing）方式。

常见的分布式文件系统

GFS、HDFS、Lustre 、Ceph 、GridFS 、mogileFS、TFS、FastDFS等。各自适用于不同的领域。它们都不是系统级的分布式文件系统，而是应用级的分布式文件存 储服务。

分布式关系型数据库的关键主要有以下几点：

• 分库
• 分表
• M-S
• 集群
• 负载均衡
• 编程接口

• 支持读写分离，支持 Mysql 双主多从，以及一主多从的模式
• 支持全局表，数据自动分片到多个节点，用于高效表关联查询
• 支持独有的基于 E-R 关系的分片策略，实现了高效的表关联查询
• 自动故障切换，高可用性
• 提供高可用性数据分片集群
• 支持 JDBC 连接 ORACLE、DB2、SQL Server，将其模拟为 MySQL Server 使用
• 支持 Mysql 集群，可以作为 Proxy 使用
• 基于阿里开源的 Cobar 产品而研发，Cobar 的稳定性、可靠性、优秀的架构和性能

Atlas 是由 Qihoo360,Web 平台部基础架构团队开发维护的一个基于 MySQL 协议的数据中间层项目。它在 MySQL 官方推出的 MySQL-Proxy0.8.2 版本的基础上，修改了大量 bug，添加了很多功能特性。目前该项目在 360 公司内部得到了广泛应用，很多 MySQL 业务已经接入了 Atlas 平台，每天承载的读写请求数达几十亿条。

• 读写分离
• 从库负载均衡
• IP 过滤
• SQL 语句黑白名单
• 自动分表

Cobar 是提供关系型数据库（MySQL）分布式服务的中间件，它可以让传统的数据库得到良好的线性扩展，并看上去还是一个数据库,对应用保持透明。

• 产品在阿里巴巴稳定运行 3 年以上。
• 接管了 3000+ 个 MySQL 数据库的 schema。
• 集群日处理在线 SQL 请求 50 亿次以上。
• 集群日处理在线数据流量 TB 级别以上。

MySQL Proxy 是一个处于你的 client 端和 MySQLserver 端之间的简单程序，它可以监测、分析或改变它们的通信。它使用灵活，没有限制，常见的用途包括：负载平衡，故障、查询分析，查询过滤和修改等等。MySQLProxy 就是这么一个中间层代理，简单的说，MySQLProxy 就是一个连接池，负责将前台应用的连接请求转发给后台的数据库，并且通过使用 lua 脚本，可以实现复杂的连接控制和过滤，从而实现读写分离和负载平衡。对于应用来说，MySQLProxy 是完全透明的，应用则只需要连接到 MySQLProxy 的监听端口即可。当然，这样 proxy 机器可能成为单点失效，但完全可以使用多个 proxy 机器做为冗余，在应用服务器的连接池配置中配置到多个 proxy 的连接参数即可。MySQLProxy 更强大的一项功能是实现 “读写分离”，基本原理是让主数据库处理事务性查询，让从库处理 SELECT 查询。数据库复制被用来把事务性查询导致的变更同步到集群中的从库。

• • 负载均衡
  • 读写分离
  • 不支持表的拆分
  • 代理层监控

• 事务：事务是由一组操作构成的可靠的独立的工作单元，事务具备ACID的特性，即原子性、一致性、隔离性和持久性。
• 本地事务：当事务由资源管理器本地管理时被称作本地事务。本地事务的优点就是支持严格的ACID特性，高效，可靠，状态可以只在资源管理器中维护，而且应用编程模型简单。但是本地事务不具备分布式事务的处理能力，隔离的最小单位受限于资源管理器。
• 全局事务：当事务由全局事务管理器进行全局管理时成为全局事务，事务管理器负责管理全局的事务状态和参与的资源，协同资源的一致提交回滚。
• TX协议：应用或者应用服务器与事务管理器的接口。
• XA协议：全局事务管理器与资源管理器的接口。XA是由X/Open组织提出的分布式事务规范。该规范主要定义了全局事务管理器和局部资源管理器之间的接口。主流的数据库产品都实现了XA接口。XA接口是一个双向的系统接口，在事务管理器以及多个资源管理器之间作为通信桥梁。之所以需要XA是因为在分布式系统中从理论上讲两台机器是无法达到一致性状态的，因此引入一个单点进行协调。由全局事务管理器管理和协调的事务可以跨越多个资源和进程。全局事务管理器一般使用XA二阶段协议与数据库进行交互。
• AP：应用程序，可以理解为使用DTP（Data Tools Platform）的程序。
• RM：资源管理器，这里可以是一个DBMS或者消息服务器管理系统，应用程序通过资源管理器对资源进行控制，资源必须实现XA定义的接口。资源管理器负责控制和管理实际的资源。
• TM：事务管理器，负责协调和管理事务，提供给AP编程接口以及管理资源管理器。事务管理器控制着全局事务，管理事务的生命周期，并且协调资源。
• 两阶段提交协议：XA用于在全局事务中协调多个资源的机制。TM和RM之间采取两阶段提交的方案来解决一致性问题。两节点提交需要一个协调者（TM）来掌控所有参与者（RM）节点的操作结果并且指引这些节点是否需要最终提交。两阶段提交的局限在于协议成本，准备阶段的持久成本，全局事务状态的持久成本，潜在故障点多带来的脆弱性，准备后，提交前的故障引发一系列隔离与恢复难题。
• BASE理论：BA指的是基本业务可用性，支持分区失败，S表示柔性状态，也就是允许短时间内不同步，E表示最终一致性，数据最终是一致的，但是实时是不一致的。原子性和持久性必须从根本上保障，为了可用性、性能和服务降级的需要，只有降低一致性和隔离性的要求。
• CAP定理：对于共享数据系统，最多只能同时拥有CAP其中的两个，任意两个都有其适应的场景，真是的业务系统中通常是ACID与CAP的混合体。分布式系统中最重要的是满足业务需求，而不是追求高度抽象，绝对的系统特性。C表示一致性，也就是所有用户看到的数据是一样的。A表示可用性，是指总能找到一个可用的数据副本。P表示分区容错性，能够容忍网络中断等故障。
• 柔性事务中的服务模式：
  1. 可查询操作：服务操作具有全局唯一的标识，操作唯一的确定的时间。
  2. 幂等操作：重复调用多次产生的业务结果与调用一次产生的结果相同。一是通过业务操作实现幂等性，二是系统缓存所有请求与处理的结果，最后是检测到重复请求之后，自动返回之前的处理结果。
  3. TCC操作：Try阶段，尝试执行业务，完成所有业务的检查，实现一致性；预留必须的业务资源，实现准隔离性。Confirm阶段：真正的去执行业务，不做任何检查，仅适用Try阶段预留的业务资源，Confirm操作还要满足幂等性。Cancel阶段：取消执行业务，释放Try阶段预留的业务资源，Cancel操作要满足幂等性。TCC与2PC(两阶段提交)协议的区别：TCC位于业务服务层而不是资源层，TCC没有单独准备阶段，Try操作兼备资源操作与准备的能力，TCC中Try操作可以灵活的选择业务资源，锁定粒度。TCC的开发成本比2PC高。实际上TCC也属于两阶段操作，但是TCC不等同于2PC操作。
  4. 可补偿操作：Do阶段：真正的执行业务处理，业务处理结果外部可见。Compensate阶段：抵消或者部分撤销正向业务操作的业务结果，补偿操作满足幂等性。约束：补偿操作在业务上可行，由于业务执行结果未隔离或者补偿不完整带来的风险与成本可控。实际上，TCC的Confirm和Cancel操作可以看做是补偿操作。

直接将信息存储在cookie中 cookie是存储在客户端上的一小段数据，客户端通过http协议和服务器进行cookie交互，通常用来存储一些不敏感信息

缺点：

• • 数据存储在客户端，存在安全隐患
  • cookie存储大小、类型存在限制
  • 数据存储在cookie中，如果一次请求cookie过大，会给网络增加更大的开销

session复制是小型企业应用使用较多的一种服务器集群session管理机制，在真正的开发使用的并不是很多，通过对web服务器(例如Tomcat)进行搭建集群。

存在的问题：

• session同步的原理是在同一个局域网里面通过发送广播来异步同步session的，一旦服务器多了，并发上来了，session需要同步的数据量就大了，需要将其他服务器上的session全部同步到本服务器上，会带来一定的网路开销，在用户量特别大的时候，会出现内存不足的情况

Nginx是一款自由的、开源的、高性能的http服务器和反向代理服务器

Nginx能做什么： 反向代理、负载均衡、http服务器（动静代理）、正向代理

如何使用nginx进行session绑定 我们利用nginx的反向代理和负载均衡，之前是客户端会被分配到其中一台服务器进行处理，具体分配到哪台服务器进行处理还得看服务器的负载均衡算法(轮询、随机、ip-hash、权重等)，

优点：

• 这是企业中使用的最多的一种方式
• spring为我们封装好了spring-session，直接引入依赖即可
• 数据保存在redis中，无缝接入，不存在任何安全隐患
• redis自身可做集群，搭建主从，同时方便管理

缺点：

• 多了一次网络调用，web容器需要向redis访问

负载均衡（Load Balance），意思是将负载（如前端的访问请求）进行平衡、（通过负载均衡算法）分摊到多个操作单元（服务器，中间件）上进行执行。是解决高性能，单点故障（高可用），扩展性（水平伸缩）的终极解决方案。可以理解为，负载均衡是高可用和高并发共同使用的一种技术。

负载均衡的作用：

1、增加吞吐量，解决并发压力（高性能）；

2、提供故障转移（高可用）；

3、通过添加或减少服务器数量，提供网站伸缩性（扩展性）；

4、安全防护（负载均衡设备上做一些过滤，黑白名单等处理）。

硬件负载均衡

通过F5、A10、Citrix Netscaler等硬件实现负载均衡。

软件负载均衡

通过LVS、Nginx、HAProxy等软件实现负载均衡。

• 强一致性

• • 说明：保证系统改变提交以后立即改变集群的状态。

  • 模型：

  • • Paxos
    • Raft（muti-paxos）
    • ZAB（muti-paxos）

• 弱一致性

• • 说明：也叫最终一致性，系统不保证改变提交以后立即改变集群的状态，但是随着时间的推移最终状态是一致的。

  • 模型：

  • • DNS系统
    • Gossip协议

Cluster中的每个节点都维护一份在自己看来当前整个集群的状态，主要包括：

1. 当前集群状态
2. 集群中各节点所负责的slots信息，及其migrate状态
3. 集群中各节点的master-slave状态
4. 集群中各节点的存活状态及不可达投票

Redis 集群是去中心化的，彼此之间状态同步靠 gossip 协议通信，集群的消息有以下几种类型：

• Meet 通过「cluster meet ip port」命令，已有集群的节点会向新的节点发送邀请，加入现有集群。
• Ping 节点每秒会向集群中其他节点发送 ping 消息，消息中带有自己已知的两个节点的地址、槽、状态信息、最后一次通信时间等。
• Pong 节点收到 ping 消息后会回复 pong 消息，消息中同样带有自己已知的两个节点信息。
• Fail 节点 ping 不通某节点后，会向集群所有节点广播该节点挂掉的消息。其他节点收到消息后标记已下线。

• nginx(24)

• RPC(8)

• 分布式(18)

• 互联网-MYSQL(19)

• 互联网-redis(31)

• 互联网-并发编程(40)

• 互联网-分布式(17)

• 互联网-高并发(17)

• 互联网-微服务(45)

• 互联网-性能调优(20)

• HTTP协议—HTTP协议详解(1)

• 分布式数据库NoSQL简介(1)​