分布式-总结列表

个人总结

一、拆分原则

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

1 人员的角度

维护一个代名工程Denali的百万级代码怪兽(虽然物理部署是分离的)，从发布到上线，从人员的角度，百号人同时在一个工程上开发，一旦线上出问题，所有代码都需要回滚，从人员的角度，也基本忍受到了极致。

2 业务的角度

淘宝包含太多业务：用户、商品、交易、支付…等等，所有的代码早期都在denali一个工程里，代码已经严重影响到业务的效率，每个业务有各自的需求，需要给自己应用部署，各自开发需求。

3 从架构的角度

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

4.急需走向一个大型的分布式时代，率先需要应用拆分

集群的三类：

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

二、单点登录SSO的实现原理

单点登录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的单点登录时保障客户端的用户资源的安全 。

　　OAuth2则是保障服务端的用户资源的安全 。

二、

　　CAS客户端要获取的最终信息是，这个用户到底有没有权限访问我（CAS客户端）的资源。

　　OAuth2获取的最终信息是，我（oauth2服务提供方）的用户的资源到底能不能让你（oauth2的客户端）访问。

三、

　　CAS的单点登录，资源都在客户端这边，不在CAS的服务器那一方。 用户在给CAS服务端提供了用户名密码后，作为CAS客户端并不知道这件事。 随便给客户端个ST，那么客户端是不能确定这个ST是用户伪造还是真的有效，所以要拿着这个ST去服务端再问一下，这个用户给我的是有效的ST还是无效的ST，是有效的我才能让这个用户访问。

　　OAuth2认证，资源都在OAuth2服务提供者那一方，客户端是想索取用户的资源。 所以在最安全的模式下，用户授权之后，服务端并不能直接返回token，通过重定向送给客户端，因为这个token有可能被黑客截获，如果黑客截获了这个token，那用户的资源也就暴露在这个黑客之下了。 于是聪明的服务端发送了一个认证code给客户端（通过重定向），客户端在后台，通过https的方式，用这个code，以及另一串客户端和服务端预先商量好的密码，才能获取到token和刷新token，这个过程是非常安全的。 如果黑客截获了code，他没有那串预先商量好的密码，他也是无法获取token的。这样oauth2就能保证请求资源这件事，是用户同意的，客户端也是被认可的，可以放心的把资源发给这个客户端了。

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

三、分布式事务-解决方案

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

  • 全局消息
  • 基于可靠消息服务的分布式事务
  • TCC
  • 最大努力通知

1、两阶段提交/XA

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

第一阶段（prepare）：即所有的参与者RM准备执行事务并锁住需要的资源。参与者ready时，向TM报告已准备就绪。
第二阶段 (commit/rollback)：当事务管理者(TM)确认所有参与者(RM)都ready后，向所有参与者发送commit命令。

2、SAGA

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

SAGA事务的特点：

  • 并发度高，不用像XA事务那样长期锁定资源

  • 需要定义正常操作以及补偿操作，开发量比XA大

  • 一致性较弱，对于转账，可能发生A用户已扣款，最后转账又失败的情况

3、TCC

关于 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适用于订单类业务，对中间状态有约束的业务

4、本地消息表|事务消息

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

本地消息表的特点：

  • 长事务仅需要分拆成多个任务，使用简单

  • 生产者需要额外的创建消息表

  • 每个本地消息表都需要进行轮询

  • 消费者的逻辑如果无法通过重试成功，那么还需要更多的机制，来回滚操作

5、最大努力通知

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

  • 提供接口，让接受通知放能够通过接口查询业务处理结果

  • 消息队列ACK机制，消息队列按照间隔1min、5min、10min、30min、1h、2h、5h、10h的方式，逐步拉大通知间隔 ，直到达到通知要求的时间窗口上限。之后不再通知

6、AT事务模式（开源的分布式事务解决方案-Seata）

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

Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案。

四、数据库的四种隔离级别

数据库一共有如下四种隔离级别：

    1. Read uncommitted 读未提交
      在该级别下，一个事务对一行数据修改的过程中，不允许另一个事务对该行数据进行修改，但允许另一个事务对该行数据读。
      因此本级别下，不会出现更新丢失，但会出现脏读、不可重复读。

    2. Read committed 读提交
      在该级别下，未提交的写事务不允许其他事务访问该行，因此不会出现脏读；但是读取数据的事务允许其他事务的访问该行数据，因此会出现不可重复读的情况。

    3. Repeatable read 重复读
      在该级别下，读事务禁止写事务，但允许读事务，因此不会出现同一事务两次读到不同的数据的情况（不可重复读），且写事务禁止其他一切事务。

    4. Serializable 序列化
      该级别要求所有事务都必须串行执行，因此能避免一切因并发引起的问题，但效率很低。

五、CAP理论

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

CAP的含义：

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

BASE理论

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

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

六、分布式锁的实现

1：SQL优化

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

基于MySQL的悲观锁

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

基于MySQL的乐观锁

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

2：基于Redis分布式锁

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

3：java中的Redission

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

4：基于zookeeper的分布式锁

数据库锁：

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

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

缓存锁：

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

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

zookeeper锁：

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

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

七、分布式数据库数据一致性技术实现方案|数据层中间件

基于 ZooKeeper 的服务发现（CP）

基于 Eureka 的服务发现（AP）

分布式数据层中间件

  • 动态数据源
  • 读写分离
  • 分布式唯一主键生成器
  • 分库分表
  • 连接池及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的原理和架构设计

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

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

Zookeeper的基本原理和架构

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与之同步

1、分布式协调技术

2、分布式锁的实现

ZooKeeper数据模型Znode

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

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

② data：与该Znode关联的数据

③ children：该Znode下的子节点

(4) 节点类型

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

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

 顺序节点

ZooKeeper服务中操作

九、分布式全局唯一ID解决方案详解

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的数据持久化存储;

配置中心对比

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

功能点spring-cloud-configctrip-apollodisconf
灰度发布 不支持 支持 不支持部分更新
告警通知 不支持 支持 支持
实例配置监控 需结合springadmin 支持 支持
配置生效时间 通过refresh生效 实时 实时
配置更新推送 手工触发 支持 支持
配置定时拉取 无 支持 依赖事件驱动
本地缓存配置 无 支持 支持
Spring Boot支持 原生支持 支持 不支持
Spring Cloud支持 原生支持 支持 不支持
业务侵入性 弱 弱 弱，支持注解及xml方式
统一管理 无，通过git操作 统一界面 统一界面

十一、分布式事务---2PC和3PC原理TCC事务

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

  1. 2PC两段提交协议

  2. 3PC三段提交协议(弥补两端提交协议缺点)

  3. TCC或者GTS(阿里)

  4. 消息中间件最终一致性

  5. 使用LCN解决分布式事物，理念“LCN并不生产事务,LCN只是本地事务的搬运工”。

十二、分布式搞清楚分库分表

1、垂直（纵向）切分

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

垂直切分的优点：

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

缺点：

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

2、水平（横向）切分

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

水平切分的优点：

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

缺点：

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

3、几种典型的数据分片规则为：

根据数值范围

根据数值取模

分库分表带来的问题

1、事务一致性问题

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

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

4、全局主键避重问题

5、数据迁移、扩容问题

支持分库分表中间件

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

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

client模式，proxy模式

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

十三、大型分布式系统中的缓存架构

1、CDN 缓存优点如下图：

2、反向代理缓存

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

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

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

应用场景：一般只缓存体积较小静态文件资源，如 css、js、图片。 

3、本地应用缓存

Ehcache 的主要特征如下图：

Guava Cache

基本介绍：Guava Cache 是 Google 开源的 Java 重用工具集库 Guava 里的一款缓存工具。

4、分布式缓存

Memcached

Redis

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

  • 数据一致性

  • 缓存穿透

  • 缓存雪崩

  • 缓存高可用

  • 缓存热点

十四、分布式NoSQL简介

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
  • 集群
  • 负载均衡
  • 编程接口

1、MyCat

特点

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

2、Atlas

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

特点

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

3、Cobar

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

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

4、Mysql proxy

概述

　　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操作可以看做是补偿操作。

十七、全分布式Session解决方案详解

方案一：客户端存储

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

缺点：

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

方案二：session复制

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

存在的问题：

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

方案三：session绑定：

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

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

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

方案四：基于redis存储session方案

优点：

  • 这是企业中使用的最多的一种方式
  • 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 不通某节点后，会向集群所有节点广播该节点挂掉的消息。其他节点收到消息后标记已下线。

 

posted @ 2022-05-20 19:38  hanease  阅读(67)  评论(0)  编辑  收藏  举报