分布式一致性

一致哈希是一种特殊的哈希算法。在使用一致哈希算法后，哈希表槽位数（大小）的改变平均只需要对 K/n个关键字重新映射，其中K是关键字的数量， n是槽位数量。然而在传统的哈希表中，添加或删除一个槽位的几乎需要对所有关键字进行重新映射。 原理 一致性Hash算法通过一个叫做一致性Hash环的数据结构实现Key到缓存服务器的Hash映射。 先构造一个长度为2的32次方的整数环（这个环被称为一致性Hash环），根据节点名称的Hash值（其分布为[0, 232-1]）将服务器节点放置在这个Hash环上，然后根据数据的Key值计算得到其Hash值（其分布也为[0, 232-1]），接着在Hash环上顺时针查找距离这个Key值的Hash值最近的服务器节点，完成Key到服务器的映射查找。 环形Hash空间 环形Hash空间 把数据通过一定的hash算法处理后映射到环上 现在我们将object1、object2、object3、object4四个对象通过特定的Hash函数计算出对应的key值，然后散列到Hash环上。如下： Hash(object1) = key1； Hash(object2) = key2； Hash(object3) = key3； Hash(object4) = key4； 数据Hash 将节点通过hash算法映射到环上 在采用一致性哈希算法的分布式集群中将新的节点加入

在服务化之前，业务通常都是本地API调用，本地方法调用性能损耗较小。服务化之后，服务提供者和消费者之间采用远程网络通信，增加了额外的性能损耗，业务调用的时延将增大，同时由于网络闪断等原因，分布式调用失败的风险也增大。如果服务框架没有足够的容错能力，业务失败率将会大幅提升。 除了性能、可靠性等问题，跨节点的事务一致性问题、分布式调用带来的故障定界困难、海量微服务运维成本增加等也是分布式服务框架必须要解决的难题。本章节我们将对服务化之后面临的挑战进行分析，并给出解决方案和业务最佳实践。 1. 性能和时延问题 在服务化之前，业务通常都是本地API调用，本地方法调用性能损耗较小。服务化之后，服务提供者和消费者之间采用远程网络通信，增加了额外的性能损耗： 1） 客户端需要对消息进行序列化，主要占用CPU计算资源。 2） 序列化时需要创建二进制数组，耗费JVM堆内存或者堆外内存。 3） 客户端需要将序列化之后的二进制数组发送给服务端，占用网络带宽资源。 4） 服务端读取到码流之后，需要将请求数据报反序列化成请求对象，占用CPU计算资源。 5） 服务端通过反射的方式调用服务提供者实现类，反射本身对性能影响就比较大。 6） 服务端将响应结果序列化，占用CPU计算资源。 7） 服务端将应答码流发送给客户端，占用网络带宽资源。 8） 客户端读取应答码流，反序列化成响应消息，占用CPU资源。

1、一致性 1.1、简述 　　一致性，是指对每个节点一个数据的更新，整个集群都知道更新，并且是一致的，假设一个具有N个节点的分布式系统，当其满足以下条件时，我们说这个系统满足一致性： 全认同 ：所有N个节点都认同一个结果 值合法 ：该结果必须由N个节点中的过半节点提出 可结束 ：决议过程在一定时间内结束，不会无休止地进行下去 1.2、面临着的问题　 消息传递异步无序： 现实网络不是一个可靠的信道，存在消息延时、丢失，节点间消息传递做不到同步有序 节点宕机： 节点持续宕机，不会恢复 节点宕机恢复： 节点宕机一段时间后恢复，在分布式系统中最常见 网络分化： 网络链路出现问题，将N个节点隔离成多个部分 拜占庭将军问题： 节点或宕机或逻辑失败，甚至不按套路出牌抛出干扰决议的信息 2、2PC 2.1、简述 　　2PC(tow phase commit)两阶段提交 　　 　　所谓的两个阶段是指：第一阶段：准备阶段(投票阶段)和第二阶段：提交阶段（执行阶段）。我们将提议的节点称为协调者(coordinator)，其他参与决议节点称为参与者(participants, 或cohorts)。 2.2、阶段1 　　 在阶段1中，协调者发起一个提议，分别问询各参与者是否接受，如下图： 　　 2.3、阶段2 　　 在阶段2中，协调者根据参与者的反馈，提交或中止事务，如果参与者全部同意则提交

BASE 模型是CAP定理牺牲强一致性、保证可用性的折中方案： 1、 B asically A vailable-基本可用 　　分布式系统发生不可预知的故障时，允许损失部分可用性，如服务降级等。 2、 S oft state-弱状态 　　分布式系统不同节点间某个时刻数据允许存在中间状态，不同节点的数据副本之间进行同步时可能存在时延，如主从同步。 3、 E ventually consistent-最终一致 　　分布式系统不同节点的所有数据副本，在经过一段时间数据同步后，最终达到一致状态，即保证最终一致性，不保证实时一致性。 我们通常接触的常见中间件，如mysql、zookeeper、redis、elasticsearch等都是基于BASE理论建立的 来源： https://www.cnblogs.com/jackcto/p/11904616.html

课程介绍 微服务架构的技术体系、社区目前已经越来越成熟。在最初系统架构的搭建，或者当现有架构已到达瓶颈需要进行架构演进时，很多架构师、运维工程师会考虑是否需要搭建微服务架构体系。虽然很多文章都说微服务架构是复杂的、会带来很多分布式的问题，但只要我们了解这些问题，并找到解法，就会有种拨开云雾的感觉。 微服务架构也不是完美的，世上没有完美的架构，微服务架构也是随着业务、团队成长而不断演进的。最开始可能就几个、十几个微服务，每个服务是分库的，通过 API Gateway 并行进行服务数据合并、转发。随着业务扩大、不断地加入搜索引擎、缓存技术、分布式消息队列、数据存储层的数据复制、分区、分表等。 本课程会一一解开微服务架构下分布式场景的问题，以及通过对于一些分布式技术的原理、模型和算法的介绍，来帮助想要实施微服务架构的工程师们知其然并知其所以然。并且，本课程通过对分布式问题的体系化梳理，结合一些方案的对比选型，可以让工程师们一览微服务的知识图谱。 注：为了方便初学者理解微服务实践，以及掌握怎样在微服务中使用 DDD（Domain-Driven Design）思想，在本课程第 05 课中讲解了 Demo 示例，该示例是基于 Spring Boot、Spring Cloud Eureka 技术写的，Microservice 代码详见这里，Gateway 代码详见这里。 专家推荐

微服务架构：最终一致性 + 事务补偿 分布式事务产生的原因 数据库分库分表 微服务化 在微服务架构中，每个服务在用 本地事务 的时候，知道自己执行的事务是成功还是失败，但是无法知道其他服务节点的事务执行情况，因此需要引入 协调者TM ，负责协调 参与者RM 的行为，并最终决定这些参与者是否把事务进行提交。 随着微服务架构的流行，让分布式事务问题日益突出， 那么常见的分布式事务解决方案有哪些呢？ 如何理解最终一致性和它的事务补偿机制呢？ 刚性事务 - 强一致性 如上图，这是个标准的全局事务， 事务管理器 控制着全局事务，管理事务的生命周期，并通过XA协议与 资源管理器 协调资源；资源管理器负责控制和管理实际的资源 （这里的资源管理器，可以是一个DBMS，或者消息服务管理系统） 两阶段提交 它是XA用于在全局事务中协调多个资源的机制，常用于 事务管理器 和 资源管理器 之间，解决一致性问题，分两阶段： 提交事务请求 执行事务请求 2PC的问题 效率低，与本地事务相比，XA协议的系统开销比较大（数据被锁定的时间跨度整个事务，直到全局事务的结束），只有支持XA协议的资源才能参与分布式事务。 2PC是反可伸缩模式的，在事务处理过程中，参与者需要一直持有资源直到整个事务的结束，这样当业务规模越来越大的情况下，它的局限性就越明显。 数据不一致，在2pc中的第二阶段时，当TM向RM发送提交请求之后

1. 为啥在项目里要用缓存呢 用缓存，主要是俩用途，高性能和高并发 高性能 image.png 高并发 image.png 2.介绍 Redis 是一个开源的使用 ANSI C 语言编写、遵守 BSD 协议、支持网络、可基于内存亦可持久化的日志型、Key-Value 数据库，并提供多种语言的 API的非关系型数据库。 传统数据库（关系型数据库）遵循 ACID 规则。而 Nosql（非关系型数据库）（Not Only SQL 的缩写，是对不同于传统的关系型数据库的数据库管理系统的统称） 一般为分布式，而分布式一般遵循 CAP 定理。 CAP理论 C:consistency(一致性) A:avalibility(可用性) P:Partition(分区)-tolerence to partition(分区容忍度) 分区：一个分布式系统，网络不通讯，导致连接不通，系统被分割成几个数据区域 原因：数据不连通了，产生数据分区 影响： 查还好一点 数据修改时，必须要求数据一致--加锁，实现数据一致性【需求要求数据一致性】 数据修改时，可以数据不一致--不用加锁【需求不要求数据一致性】 分区容忍度 数据的一致性要求高，容忍度高，加锁 数据的一致性要求低，容忍度低，可以不加锁 预期结果，保持数据的一致 可用性 请求在一定时间段内都应该有响应 为了解决锁一直加着 CP理论：【一致性+分区

Eureka、Consul、Zookeeper的基本原理与比较。 前言 在云计算和容器化技术发展火热的当下，对于微服务架构，服务注册与发现组件是必不可少的。在传统的服务架构中，服务的规模处于运维人员的可控范围内。当部署服务的多个节点时，一般使用静态配置的方式实现服务信息的设定。在微服务应用中，服务实例的数量和网络地址都是动态变化的，这对系统运维提出了巨大的挑战。因此，动态的服务注册与发现就显得尤为重要。 解决的问题 在一个分布式系统中，服务注册与发现组件主要解决两个问题：服务注册和服务发现。 服务注册：服务实例将自身服务信息注册到注册中心。这部分服务信息包括服务所在主机IP和提供服务的Port，以及暴露服务自身状态以及访问协议等信息。 服务发现：服务实例请求注册中心获取所依赖服务信息。服务实例通过注册中心，获取到注册到其中的服务实例的信息，通过这些信息去请求它们提供的服务。 除此之外，服务注册与发现需要关注监控服务实例运行状态、负载均衡等问题。 监控：微服务应用中，服务处于动态变化的情况，需要一定机制处理无效的服务实例。一般来讲，服务实例与注册中心在注册后通过心跳的方式维系联系，一旦心跳缺少，对应的服务实例会被注册中心剔除。 负载均衡：同一服务可能同时存在多个实例，需要正确处理对该服务的负载均衡。 CAP CAP原则，指的是在一个分布式系统中，Consistency(一致性)

https://www.cnblogs.com/wupeixuan/p/9302496.html 第一章主要讲的是分布式架构，主要包含以下内容： 集中式的特点 分布式的特点 分布式环境的各种问题 ACID 分布式事务 CAP和BASE理论 1 | 1 集中式与分布式的特点 集中式的特点：部署结构简单（因为基于底层性能卓越的大型主机，不需考虑对服务多个节点的部署，也就不用考虑多个节点之间分布式协调问题） 分布式的特点： 分布性 对等性 并发性 缺乏全局时钟 故障总是会发生 1 | 2 分布式环境的各种问题 分布式环境的各种问题： 通信异常：主要是因为网络本身的不可靠性 网络分区：当网络发生异常时，导致部分节点之间的网络延时不断增大，最终导致部分节点可以通信，而另一部分节点不能。 三态（成功、失败与超时） 节点故障：组成分布式系统的服务器节点出现宕机或“僵死”现象 1 | 3 ACID与分布式事务 事务是由一系列对系统中数据进行访问与更新的操作所组成的一个程序执行逻辑单元，狭义上的事务特指数据库事务。 事务有四个特性，分别是原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability），简称为事务的ACID特性。 原子性（Atomicity）：必须是一个原子的操作序列单元，只允许出现两种状态之一（全部成功执行，全部不执行）。

CAP 定理 CAP定理：CAP定理又称CAP原则，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。 一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本） 可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性） 分区容忍性（P），就是高可用性，一个节点崩了，并不影响其它的节点（100个节点，挂了几个，不影响服务，越多机器越好） 一般来讲，基于网络的不稳定性，分布容错是不可避免的，所以我们默认CAP中的P总是成立的。 我们接下来介绍的服务注册和发现组件中，Eureka满足了其中的AP，Consul和Zookeeper满足了其中的CP Eureka Eureka是在Java语言上，基于Restful Api开发的服务注册与发现组件，由Netflix开源。遗憾的是，目前Eureka仅开源到1.X版本，2.X版本已经宣布闭源。 Eureka 采用的是Server/Client的模式进行设计的。Server是服务注册中心的角色，为Client提供服务的注册与发现功能，维护着注册到自身的Client的相关信息