分布式一致性

什么场景下会产生分布式事务？ 在支付异步回调的情况下，支付宝发送http请求给第三方平台，第三方平台需要更改支付状态以及订单状态，在此场景下，第三方平台更改本地支付数据库的支付状态后，通知订单服务更改订单的状态，在此程序后，如果代码出现异常，由于有声明式事务的存在，本地支付服务的数据库会进行回滚，变成未支付状态，但是订单服务的状态却无法回滚，订单服务的订单的状态变成已支付状态，这就出现了订单数据库和支付数据库数据不一致的情况，这便是分布式事务产生的场景之一。 什么是分布式事务？ 分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。以上是百度百科的解释，简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。 分布式事务的理论 1、cap理论 1）数据一致性（consistency） 如果系统对一个写操作返回成功，那么之后的读请求都必须读到这个新数据；如果返回失败，那么所有读操作都不能读到这个数据，对调用者而言数据具有强一致性(strong consistency) (又叫原子性 atomic、线性一致性 linearizable consistency) 一致性指

1.zap协议 ZAB 协议是为分布式协调服务 ZooKeeper 专门设计的一种支持崩溃恢复的原子广播协议。在 ZooKeeper 中，主要依赖 ZAB 协议来实现分布式数据一致性，基于该协议，ZooKeeper 实现了一种主备模式的系统架构来保持集群中各个副本之间的数据一致性。 来源： CSDN 作者： qq_25705173 链接： https://blog.csdn.net/qq_25705173/article/details/103654765

前言 随着大型网站的各种高斌发访问、海量数据处理等场景越来越多，如何实现网站的高可用、易伸缩、可扩展、安全等目标就显得越来越重要。为了解决这样一系列问题。大型网站的架构也在不断发展。提高大型网站的高可用架构，就不得不提 分布式系统（Distributed Systems） 。下面说一下分布式系统及其相关的概念 在学习分布式系统之前，先了解一下与之相对应的集中式系统是什么样的。 集中式系统 集中式系统，主要指IBM、HP一个主机带多个终端。终端没有数据处理能力，仅负责数据的录入和输出。而运算、存储等全部在主机上进行，也就是我们平常说的单机服务器。 集中式系统的最大特点就是不熟结构非常简单，底层一般采用IBM、HP等厂商购买的昂贵的大型主机。因此无需要考虑如何对服务进行多节点的部署，也就不用考虑各节点的分布式协作问题。但是，由于采用单机部署、和可能带来系统大而复杂、难于维护、发生单点故障（单个点发生故障的时候会波及到整个系统或者网络，从而导致整个系统或者网络的瘫痪）、扩展性差等问题。 说完集中式系统，再来说一个与分布式很相似的概念-集群 集群 集群是一组独立的计算机系统构成一个松耦合的多处理器系统，它们之间通过网络实现进程间的通信。用来提供比集中式系统更具扩展性与可用性的服务平台。集群有两个关键的特性： 可扩展性，集群的性能不限于单一的服务实体，新的服务实体可以动态地添加到集群

一、前言 　　 在大数据系统中，分布式系统已经成为一个无法避免的组件，如zookeeper已经成为了工业届的标准。所以对于大数据的研究，也必须要研究分布式系统的特点。 二、集中式系统 　　由一台或多台计算机组成的中心节点，数据集中存储在这个中心节点中，并且整个系统的所有业务单元都集中部署在这个中心节点上，系统的所有功能均由其集中处理。其部署简单，不用考虑多个节点间的分布式协作问题。 三、分布式系统 　　分布式系统是一个由硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统。其拥有如下特点 　　 3.1 分布性 　　分布式系统中的多台计算机都会在空间中随意分布，同时，机器的分布情况也会随时变动。 　 　3.2 对等性 　　分布式系统中的计算机没有主/从之分，既没有控制整个系统的主机，也没有被控制的从机，组成分布式系统的所有计算机节点都是对等的， 副本 指的是分布式系统对数据和服务提供的一种冗余方式，为了对外提供高可用的服务，我们往往会对数据和服务进行副本处理。 数据副本 是指在不同的节点上持久化同一份数据，当某一个节点上存储的数据丢失时，可以从副本上读取到该数据，这是解决分布式系统数据丢失问题最为有效的手段。 服务副本 是只多个节点提供同样的服务，每个节点都有能力接受来自外部的请求并进行相应的处理。 　 　3.3 并发性 　　同一分布式系统中的多个节点

　　　 我的探索历程 　　 这一部分，与分布式不大相关，记录的是我是如何在分布式学习这条道路上摸索的，不感兴趣的读者请直接跳到下一章 。 　 　 过去的一年，我在分布式 学习 这条道路上苦苦徘徊，始终没有找到一个好的学习方法，一个能激励我持续学习的方法。 　　当然，我也在不停的反思，最先发现的问题是学习不系统，东看看，西看看，看过就忘。于是写了一篇文章《 带着问题学习分布式系统 》提出了一些问题，然后写了两篇文章来回带自己提出的问题。回过头看，其实这两篇文章都是基于分布式存储的。 　　然后接下来，又是一段时间的迷茫，不知道要学习啥（也是在学习Paxos的时候遇到了阻碍），偶然看到了关于SMART的一些文章，发现原来自己的学习一点都不SAMRT，所以坚持不下去。于是又写了一篇文章《 带着SMART原则重新出发 》，希望给自己设定SMART的目标，结果被博友打脸“一点都不smart”，而且也被结果打脸了，确实没有让我“重新出发”。 　　我也曾经在网上搜索，“如何学习分布式系统“，但并没有找到理想的、或者说适合我的学习方法。网上的答案，都是说，看这些论文，看这些系统的实现。。。或者很多大学的课程，都是罗列出一堆术语：概念、协议、组件。而我觉得，逐个去了解这些术语似乎很无聊，因为不知道为什么要这个协议，或者说这些协议、组件是如何组合起来的。 　　在没有得到适合自己的方案之后，我自己思考

Paxos协议/算法是分布式系统中比较重要的协议，它有多重要呢？ <分布式系统的事务处理> ： Google Chubby的作者Mike Burrows说过这个世界上只有一种一致性算法，那就是Paxos，其它的算法都是残次品。 <大规模分布式存储系统> ： 理解了这两个分布式协议之后(Paxos/2PC)，学习其他分布式协议会变得相当容易。 学习Paxos算法有两部分：a) 算法的原理/证明；b) 算法的理解/运作。 理解这个算法的运作过程其实基本就可以用于工程实践。而且理解这个过程相对来说也容易得多。 网上我觉得讲Paxos讲的好的属于这篇： paxos图解 及 Paxos算法详解 ，我这里就结合 wiki上的实例 进一步阐述。一些paxos基础通过这里提到的两篇文章，以及wiki上的内容基本可以理解。 算法内容 Paxos在原作者的《Paxos Made Simple》中内容是比较精简的： Phase 1 (a) A proposer selects a proposal number n and sends a prepare request with number n to a majority of acceptors. (b) If an acceptor receives a prepare request with number n greater than

数据库分表） 数据切分 垂直（纵向）切分 水平（横向）切分 分库分表带来的问题 1. 事务一致性问题 2. 跨节点关联查询 join 问题 3. 跨节点分页、排序、函数问题 4. 全局主键避重问题 1. UUID 2. 结合数据库维护主键ID表 3. Snowflake分布式自增ID算法 5. 数据迁移、扩容问题 什么时候考虑切分 1. 能不切分尽量不要切分 2. 数据量过大，正常运维影响业务访问 3. 随着业务发展，需要对某些字段垂直拆分 4. 数据量快速增长 5. 安全性和可用性 案例分析 1. 用户中心业务场景 2. 水平切分方法 "根据数值范围"：以主键uid为划分依据，按uid的范围将数据水平切分到多个数据库上。 "根据数值取模"：也是以主键uid为划分依据，按uid取模的值将数据水平切分到多个数据库上。 3. 非uid的查询方法 1. 建立非uid属性到uid的映射关系 1. 映射关系 2. 基因法 2. 前台与后台分离 支持分库分表中间件 数据切分 关系型数据库本身比较容易成为系统瓶颈，单机存储容量、连接数、处理能力都有限。当单表的数据量达到1000W或100G以后，由于查询维度较多，即使添加从库、优化索引，做很多操作时性能仍下降严重。此时就要考虑对其进行切分了，切分的目的就在于减少数据库的负担，缩短查询时间。 数据库分布式核心内容无非就是数据切分（Sharding）

问题场景 什么是事务? 事务是数据库从一个稳定状态变迁到另一个稳定状态的保证，具备 ACID 这 4 个特性： 原子性（Atomicity）：一个事务中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚到事务开始前的状态。 一致性（Consistency）：在事务开始之前和事务结束以后，数据库的完整性限制没有被破坏。 隔离性（Isolation）：两个事务的执行是互不干扰的，两个事务时间不会互相影响。 持久性（Durability）：在事务完成以后，该事务对数据库所作的更改便持久地保存在数据库之中，并且是完全的。 例如应用程序需要更新多条相关数据时就需要进行事务处理。 什么是分布式事务? 当遇到复杂业务调用时，可能会出现跨库多资源调用(一个事务管理器，多个资源)/多服务调用（多个事务管理器，多个资源），期望全部成功或失败回滚，这就是分布式事务，用以保证“操作多个隔离资源的数据一致性”。 分布式事务与 XA 规范 分布式事务是指会涉及到操作多个数据库的事务，同样必须保证 ACID。其就是将对同一库事务的概念扩大到了对多个库的事务：对同一库的 SQL 操作对应了分布式事务中对一个库的事务。 X/Open XA 定义了分布式事务处理的规范，并由数据库厂商在驱动层面进行实现。XA 规范的基础是两阶段提交协议

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 一致性哈希算法在1997年由麻省理工学院提出的一种分布式哈希（DHT）实现算法，设计目标是为了解决因特网中的热点(Hot spot)问题，初衷和CARP十分类似。一致性哈希修正了CARP使用的简 单哈希算法带来的问题，使得分布式哈希（DHT）可以在P2P环境中真正得到应用。 一致性hash算法提出了在动态变化的Cache环境中，判定哈希算法好坏的四个定义： 1、 平衡性(Balance) ：平衡性是指哈希的结果能够尽可能分布到所有的缓冲中去，这样可以使得所有的缓冲空间都得到利用。很多哈希算法都能够满足这一条件。 2、 单调性(Monotonicity) ：单调性是指如果已经有一些内容通过哈希分派到了相应的缓冲中，又有新的缓冲加入到系统中。哈希的结果应能够保证原有已分配的内容可以被映射到原有的或者新的缓冲中去，而不会被映射到旧的缓冲集合中的其他缓冲区。 3、 分散性(Spread) ： 在分布式环境中，终端有可能看不到所有的缓冲，而是只能看到其中的一部分。当终端希望通过哈希过程将内容映射到缓冲上时，由于不同终端所见的缓冲范围有可 能不同，从而导致哈希的结果不一致，最终的结果是相同的内容被不同的终端映射到不同的缓冲区中。这种情况显然是应该避免的，因为它导致相同内容被存储到不 同缓冲中去，降低了系统存储的效率

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 简介： 一致性哈希算法在1997年由麻省理工学院提出的一种分布式哈希（DHT）实现算法，设计目标是为了解决因特网中的热点(Hot spot)问题，初衷和CARP十分类似。一致性哈希修正了CARP使用的简 单哈希算法带来的问题，使得分布式哈希（DHT）可以在P2P环境中真正得到应用。 一致性hash算法提出了在动态变化的Cache环境中，判定哈希算法好坏的四个定义： 平衡性(Balance)： 平衡性是指 哈希的结果能够尽可能分布到所有的缓冲中去 ，这样可以使得所有的缓冲空间都得到利用。很多哈希算法都能够满足这一条件。 单调性(Monotonicity)： 单调性是指如果已经有一些内容通过哈希分派到了相应的缓冲中，又有新的缓冲加入到系统中。哈希的结果应能够 保证原有已分配的内容可以被映射到原有的或者新的缓冲中去 ，而不会被映射到旧的缓冲集合中的其他缓冲区。 分散性(Spread)： 在分布式环境中，终端有可能看不到所有的缓冲，而是只能看到其中的一部分。当终端希望通过哈希过程将内容映射到缓冲上时，由于不同终端所见的缓冲范围有可能不同，从而导致哈希的结果不一致，最终的结果是相同的内容被不同的终端映射到不同的缓冲区中。这种情况显然是应该避免的，因为它导致相同内容被存储到不同缓冲中去， 降低了系统存储的效率