可用性

一、基础组件总结 1、文章阅读目录 1)、基础组件 Eureka组件，服务注册与发现 Ribbon和Feign组件，实现负载均衡 Hystrix组件，实现服务熔断 Turbine组件，实现微服务集群监控 Zuul组件，实现路由网关控制 Config组件，实现配置统一管理 Zipkin组件，实现请求链路追踪 2)、应用案例 基于Shard-Jdbc分库分表，数据库扩容方案 基于SpringCloud实现Shard-Jdbc的分库分表扩容 3)、后续更新 该案例主要基于SpringCloud2版本，演示微服务在实际开发中的应用。 <modules> <!-- 客户端接口层 --> <module>storey-client-web</module> <!-- 公共代码块层 --> <module>storey-block-code</module> <!-- 中间件管理层 --> <module>storey-middle-soft</module> <!-- 数据 中 心层 --> <module>storey-data-center</module> <!-- 微服务组件层 --> <module>storey-cloud-ware</module> </modules> 采用版本 Spring： 5.0+ SpringBoot： 2.0+ SpringCloud: 2.0+ 2

一、关系型数据库与欸关系型数据库的主要区别： 二、关系型数据库 关系型数据库：指采用了关系模型来组织数据的数据库。 关系模型指的就是二维表格模型，而一个关系型数据库就是由二维表及其之间的联系所组成的一个数据组织。 关系模型中常用的概念： 关系：一张二维表，每个关系都具有一个关系名，也就是表名 元组：二维表中的一行，在数据库中被称为记录 属性：二维表中的一列，在数据库中被称为字段 域：属性的取值范围，也就是数据库中某一列的取值限制 关键字：一组可以唯一标识元组的属性，数据库中常称为主键，由一个或多个列组成 关系模式：指对关系的描述。其格式为：关系名(属性1，属性2， ... ... ，属性N)，在数据库中成为表结构 关系型数据库的优点： 1.容易理解：二维表结构是非常贴近逻辑世界的一个概念，关系模型相对网状、层次等其他模型来说更容易理解 2.使用方便：通用的SQL语言使得操作关系型数据库非常方便 3.易于维护：丰富的完整性(实体完整性、参照完整性和用户定义的完整性)大大减低了数据冗余和数据不一致的概率 关系型数据库存在的问题 1.网站的用户并发性非常高，往往达到每秒上万次读写请求，对于传统关系型数据库来说，硬盘 I/O 是一个很大的瓶颈 2.网站每天产生的数据量是巨大的，对于关系型数据库来说，在一张包含海量数据的表中查询，效率是非常低的 3.在基于web的结构当中

CAP定理： 一个分布式系统 不可能 同时满足 一致性 （C:Consistency）、 可用性 （A:Availability）和 分区容错性 （P:Partition tolerance）这三个基本要求，最多只能满足 其中的两项 。 一致性 在分布式环境中，一致性是指数据在 多个副本之间 是否能够 保持强一致 的特性。 对于一个将数据副本分布在不同节点上的分布式系统来说，如果对第一个节点的数据进行了更新操作并且更新成功后，却没有使得第二个节点上的数据得到相应的更新，于是在对第二个节点的数据进行读取操作时，获取的依然是更新前的数据（称为 脏数据 ），这就是典型的分布式数据不一致情况。在分布式系统中，如果能够做到针对一个数据项的更新操作执行成功后，所有的用户都能读取到最新的值，那么这样的系统就被认为具有 强一致性 （或严格的一致性）。 可用性 可用性是指系统提供的服务必须 一直处于可用 的状态，对于用户的每一个操作请求总是能够在 有限的时间 内 返回结果 ，如果超过了这个时间范围，那么系统就被认为是不可用的。 『有限的时间内』是一个在系统设计之初就设定好的运行指标， 不同的系统会有很大的差别 。比如对于一个在线搜索引擎来说，通常在0.5秒内需要给出用户搜索关键词对应的检索结果。而对应Hive来说，一次正常的查询时间可能在20秒到30秒之间。 『返回结果

什么是系统集成？ 系统集成是指将计算机 软件 、 硬件 、 网络通信 等技术和产品集成为能够满足用户特定需求的信息系统，包括 总体策划 、 设计开发 、 实施 、 服务与保障 。 常用信息 系统集成技术 有什么？ 一、网络标准与网络协议 网络协议三要素 （ 语义 ，表示要做什么。 语法 ，表示要怎么做。 时序 ，表示做的顺序）。 OSI （Open System Interconnect开放系统互联参考模型）： 数据 是通过 网络 来传输的，双方用 会话 来表示 应用 OSI参考模型 TCP/IP五层模型 各层的解释 协议 应用层 Application Layer 应用层 为应用程序提供服务 HTTP Telnet FTP DNS SMTP 表示层 。。。同上 数据格式转化、数据加密 。。。同上 会话层 。。。同上 建立、管理、维护会话 。。。同上 传输层 Transport Layer 传输层 建立、管理、维护端到端链接 TCP UDP 网络层 Internet Layer 网络层 IP地址、路由选择 IP ICMP RIP IGMP ARP 数据链路层 Network Access Layer 物理层/网络接口/网络访问层 介质访问、链路管理 IEEE802.3 PPP CSMA/CD 物理层 。。。同上 硬件设备 FE自协商 Manchester MLT-3 4A PAM5

1、什么是消息？ 说白了就是传输的数据. 2、什么是消息队列？ 说白了就是存放消息的容器，当我们需要消息的时候就去消息队列里取。 3、作用？ 消息队列是分布式系统中重要的组件，使用消息队列主要是为了通过异步处理提高系统性能和削峰、降低系统耦合性、消息通讯。 4、常用的消息队列？ 目前使用较多的消息队列有ActiveMQ，RabbitMQ，Kafka，RocketMQ 5、消息队列带来的问题？ 系统可用性降低： 系统可用性在某种程度上降低，为什么这样说呢？在加入MQ之前，你不用考虑消息丢失或者说MQ挂掉等等的情况，但是，引入MQ之后你就需要去考虑了！ 系统复杂性提高： 加入MQ之后，你需要保证消息没有被重复消费、处理消息丢失的情况、保证消息传递的顺序性等等问题！ 一致性问题： 我上面讲了消息队列可以实现异步，消息队列带来的异步确实可以提高系统响应速度。但是，万一消息的真正消费者并没有正确消费消息怎么办？这样就会导致数据不一致的情况了! 6、常见消息队列对比 对比方向 概要 吞吐量 万级的 ActiveMQ 和 RabbitMQ 的吞吐量（ActiveMQ 的性能最差）要比 十万级甚至是百万级的 RocketMQ 和 Kafka 低一个数量级。 可用性 都可以实现高可用。ActiveMQ 和 RabbitMQ 都是基于主从架构实现高可用性。RocketMQ 基于分布式架构。 kafka

分布式理论（一） CAP 理论 一． CAP 理论前言 CAP 原则又称为 CAP 理论，主要思想是在任何一个分布式系统中都无法同时满足 CAP 。 C （ Consistency ）：表示一致性，所有的节点同一时间看到的是相同的数据。 A （ Avaliablity ）：表示可用性，不管是否成功，确保一个请求都能接收到响应。 P （ Partion Tolerance ）：分区容错性，系统任意分区后，在网络故障时，仍能操作。 如上所述，正如 Gilbert 认为， 一致性 其实就是关系型数据库所讲的 ACID ，一个用户请求要么是成功，要么是失败的，不能有处于一个中间状态；一旦一个事务完成，将来所有事务都必须基于这个完成后的状态；未完成的事务不会互相影响；一旦一个事务完成，就是持戒的。 可用性 其实就是对于一个系统而言，所有的请求都应该 “成功”并且收到“响应”。 分区容错性 其实就是指分布式系统的容错性，一个节点出现了故障，不影响整个集群的正常使用。 二． CAP 理论介绍 如图，在一个网络中， N1 和 N2 即分布式系统中的两个节点，他们都共享数据块 V ，其中有一个值是为 V0 。 l 在满足一致性的时候， A 中的 V0 应该和 B 中的 V0 保持一致的，即 V0=V0 l 在满足可用性的时候，无论请求访问 A 或者是 B 都应该得到响应。 l 在满足分区可用性的时候

1.1 模型 节点 在具体的工程项目中，一个节点往往是一个操作系统上的进程。在本文的模型中，认为节点是一个完整的、不可分的整体，如果某个程序进程实际上由若干相对独立部分构成，则在模型中可以将一个进程划分为多个节点。 异常 机器宕机 ：机器宕机是最常见的异常之一。在大型集群中每日宕机发生的概率为千分之一左右，在实践中，一台宕机的机器恢复的时间通常认为是24 小时，一般需要人工介入重启机器。 网络异常 ：消息丢失，两片节点之间彼此完全无法通信，即出现了“网络分化”；消息乱序，有一定的概率不是按照发送时的顺序依次到达目的节点，考虑使用序列号等机制处理网络消息的乱序问题，使得无效的、过期的网络消息不影响系统的正确性；数据错误；不可靠的TCP，TCP 协议为应用层提供了可靠的、面向连接的传输服务，但在分布式系统的协议设计中不能认为所有网络通信都基于TCP 协议则通信就是可靠的。TCP协议只能保证同一个TCP 链接内的网络消息不乱序，TCP 链接之间的网络消息顺序则无法保证。 分布式三态 ：如果某个节点向另一个节点发起RPC(Remote procedure call)调用，即某个节点A 向另一个节点B 发送一个消息，节点B 根据收到的消息内容完成某些操作，并将操作的结果通过另一个消息返回给节点A，那么这个RPC 执行的结果有三种状态：“成功”、“失败”、“超时（未知）”

1、zookeeper宕机与dubbo直连 现象：zookeeper注册中心宕机，还可以消费dubbo暴露的服务。 原因： 健壮性 l 监控中心宕掉不影响使用，只是丢失部分采样数据 l 数据库宕掉后，注册中心仍能通过缓存提供服务列表查询，但不能注册新服务 l 注册中心对等集群，任意一台宕掉后，将自动切换到另一台 l 注册中心全部宕掉后，服务提供者和服务消费者仍能通过本地缓存通讯 l 服务提供者无状态，任意一台宕掉后，不影响使用 l 服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复 高可用：通过设计，减少系统不能提供服务的时间； Dubbo直连： 直接连接到服务器ip地址，绕过zookeeper 2、集群下dubbo负载均衡配置 在集群负载均衡时，Dubbo 提供了多种均衡策略，缺省为 random 随机调用。 负载均衡策略 Random LoadBalance 随机，按权重设置随机概率。 在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。 RoundRobin LoadBalance 轮循，按公约后的权重设置轮循比率。 存在慢的提供者累积请求的问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。 LeastActive LoadBalance

ookeeper与Eureka区别 CPA理论:一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。由于分区容错性在是分布式系统中必须要保证的，因此我们只能在A和C之间进行权衡。在此Zookeeper保证的是CP, 而Eureka则是AP。 Consistency(一致性), 数据一致更新，所有数据变动都是同步的 Availability(可用性), 好的响应性能 Partition tolerance(分区容忍性) 可靠性 1、“C”是指一致性，即当一个Process（过程）修改了某个数据后，其他Process读取这是数据是，得到的是更新后的数据，但并不是所有系统都 可以做到这一点。例如，在一些并非严格要求一致性的系统中，后来的Process得到的数据可能还是修改之前的数据，或者需要等待一定时间后才能得到修改 之后的数据，这被成为“弱一致性”，最经典的应用就是DNS系统。当用户修改了DNS配置后，往往不会马上在全网更新，必定会有一个延迟，这个延迟被称为 “不一致窗口”，它的长度取决于系统的负载、冗余的个数等因素。但对于某些系统而言，一旦写入，后面读取的一定是修改后的数据，如银行账户信息，这被称为 “强一致性”。 2、“A”是指可用性。即系统总是能够为用户提供连续的服务能力。当用户发出请求是，系统能给出响应（成功或者失败），而且是立即给出响应

Zookeeper是什么 ZooKeeper是一个开放源码的分布式协调服务，它是集群的管理者，监视着集群中各个节点的状态根据节点提交的反馈进行下一步合理操作。最终，将简单易用的接口和性能高效、功能稳定的系统提供给用户。 分布式应用程序可以基于Zookeeper实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Leader选举、分布式锁和分布式队列等功能。 Zookeeper保证了如下分布式一致性特性： 顺序一致性 原子性 单一视图 可靠性 实时性（最终一致性） 客户端的读请求可以被集群中的任意一台机器处理，如果读请求在节点上注册了监听器，这个监听器也是由所连接的zookeeper机器来处理。对于写请求，会统一由Leader接收并处理，广播给其他zookeeper机器并且达成一致后，请求才会返回成功。因此，随着zookeeper的集群机器增多，读请求的吞吐会提高但是写请求的吞吐会下降。 有序性是zookeeper中非常重要的一个特性，所有的更新都是全局有序的，每个更新都有一个唯一的时间戳，这个时间戳称为zxid（Zookeeper Transaction Id）。而读请求只会相对于更新有序，也就是读请求的返回结果中会带有这个zookeeper最新的zxid。 分布式系统的CAP原则是什么？ZK实现的是AP还是CP？ CAP原则又称CAP定理