分布式一致性

springboot1.5.9 + mybatis + layui + shir搭建后台权限管理系统 作者：wyait 简介：业务场景 spring boot + mybatis后台管理系统框架； layUI前端界面； shiro权限控制，ehCache缓存； 老司机带你在MySQL领域“大吉大利，晚上吃鸡” 作者：superZS 简介：本章介绍MySQL官方推荐的一款高可用集群方案MySQL Group Replication。简称：MGR(组复制)。它是官方推出的一种基于Paxos协议的状态机复制，彻底解决了基于传统的异步复制和半同步复制中数据一致性问题无法保证的情况。也让MySQL数据库涉及的领域更广，彻底拥有了打开互联网金融行业的大门。2016年12月 MySQL Group Replication推出了第一个GA版本发布在MySQL5.7.17中。但目前直接投入到生产环境中使用，风险还是比较大。建议等其越来越成熟之后，我们再真正投入使用。 对HashMap的思考及手写实现 作者：zfz_linux_boy 简介：HashMap是Java中常用的集合，而且HashMap的一些思想，对于我们平时解决业务上的一些问题，在思路上有帮助，基于此，本篇博客将分析HashMap底层设计思想，并手写一个迷你版的HashMap！ 分布式服务化系统一致性的“最佳实干” 作者

文章纲要 此次分享的缘由 目前分布式事务问题是怎么解决的 行业中有什么解决方案 这些解决方案分别有什么优缺点 别人是怎么做的 我们可以怎么来做 此次分享的缘由 支付重构 考虑支付重构的时候，自然想到原本属于一个本地事务中的处理，现在要跨应用了要怎么处理。拿充值订单举个栗子吧，假设：原本订单模块和账户模块是放在一起的，现在需要做服务拆分，拆分成订单服务，账户服务。原本收到充值回调后，可以将修改订单状态和增加金币放在一个mysql事务中完成的，但是呢，因为服务拆分了，就面临着需要协调2个服务才能完成这个事务 所以就带出来，我们今天要分享和讨论的话题是： 怎么解决分布式场景下数据一致性问题，暂且用分布式事务来定义吧。 同样的问题还存在于其他的场景： 送礼： 调用支付服务：先扣送礼用户的金币，然后给主播加相应的荔枝，确认第一步成功后，播放特效，发聊天室送礼评论等复制代码 充值成功消息： 完成充值订单，发送订单完成的kafka消息，在涉及支付交易等付费接口的时候，数据一致性的问题就显得尤为重要，因为都是钱啊 目前分布式事务是怎么解决的呢？ 问题肯定不是新问题，也就是目前已经有相应的解决方案了，那就看一下现在是怎么来解决这类问题的吧。 以购买基础商品成功后发送支付订单完成消息为例：假设支付下单购买基础商品，此刻已经收到支付回调，订单已经处理成功了，这个时候kafka服务故障，消息发送失败

目录 一、分布式事务前奏 二、柔性事务解决方案架构 （一）、基于可靠消息的最终一致性方案概述 （二）、TCC事务补偿型方案 （三）、最大努力通知型 三、基于可靠消息的最终一致性方案详解 （一）、消息发送一致性 （二）、保证消息一致的变通做法 （三）、常规MQ消息处理流程和特点 （四）、消息重复发送问题和业务接口幂等性设计 （五）、本地消息服务方案 （六）、独立消息服务方案 （七）、消息服务子系统的设计实现 一、分布式事务前奏 事务：事务是由一组操作构成的可靠的独立的工作单元，事务具备ACID的特性，即原子性、一致性、隔离性和持久性。 本地事务：当事务由资源管理器本地管理时被称作本地事务。本地事务的优点就是支持严格的ACID特性，高效，可靠，状态可以只在资源管理器中维护，而且应用编程模型简单。但是本地事务不具备分布式事务的处理能力，隔离的最小单位受限于资源管理器。 全局事务：当事务由全局事务管理器进行全局管理时成为全局事务，事务管理器负责管理全局的事务状态和参与的资源，协同资源的一致提交回滚。 TX协议：应用或者应用服务器与事务管理器的接口。 XA协议：全局事务管理器与资源管理器的接口。XA是由X/Open组织提出的分布式事务规范。该规范主要定义了全局事务管理器和局部资源管理器之间的接口。主流的数据库产品都实现了XA接口。XA接口是一个双向的系统接口

深入了解分布式 分布式事务 分布式事务概念 分布式事务产生的原因 事务的ACID特性 分布式理论 CAP理论 BASE理论 分布式事务的应用场景 常见的分布式事务解决方案 两阶段提交 TCC编程模式 TCC开源框架-tcc-transaction TCC使用关键技术分析 分布式项目使用tcc-transaction框架 发布服务 调用服务 LCN解决方案 参考链接 分布式事务 分布式事务概念 分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。 分布式事务是为了保证不同数据库的数据一致性 分布式事务产生的原因 数据库分库分表 当数据库单表一年产生的数据超过1000W，那么就要考虑分库分表 应用SOA化 所谓的SOA化，就是业务的服务化。现在对整个网站进行拆解，分离除了订单中心、用户中心、库存中心。 事务的ACID特性 原子性(Atomicity) 所谓的原子性就是说，在整个事务中的所有操作，要么全部完成，要么全部不做，没有中间状态。对于事务在执行中发生错误，所有的操作都会被回滚，整个事务就像从没被执行过一样。 一致性(Consistency) 事务的执行必须保证系统的一致性，就拿转账为例，A有500元，B有300元，如果在一个事务里A成功转给B50元，那么不管并发多少，不管发生什么，只要事务执行成功了

出处： https://github.com/clsaa/Distributed-Transaction-Notes 。 作者总结得很全面，做个笔记搬运。 一、 两阶段提交(2PC) 一个基于两阶段提交协议的分布式事务框架(LCN) 二阶段提交(Two-phaseCommit)是指，在计算机网络以及数据库领域内，为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种算法(Algorithm)。通常，二阶段提交也被称为是一种协议(Protocol))。在分布式系统中，每个节点虽然可以知晓自己的操作时成功或者失败，却无法知道其他节点的操作的成功或失败。当一个事务跨越多个节点时，为了保持事务的ACID特性，需要引入一个作为协调者的组件来统一掌控所有节点(称作参与者)的操作结果并最终指示这些节点是否要把操作结果进行真正的提交(比如将更新后的数据写入磁盘等等)。因此，二阶段提交的算法思路可以概括为：参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。 所谓的两个阶段是指：第一阶段：准备阶段(投票阶段)和第二阶段：提交阶段（执行阶段）。 1. 准备阶段 事务协调者(事务管理器)给每个参与者(资源管理器)发送Prepare消息，每个参与者要么直接返回失败(如权限验证失败)，要么在本地执行事务，写本地的redo和undo日志

首先,我们需要搞清楚为什么会出现事务. Transactions are not a law of nature; they were created with a purpose, namely to simplify the programming model for applications accessing a database. By using transactions, the application is free to ignore certain potential error scenarios and concurrency issues, because the database takes care of them instead (we call these safety guarantees). 这句话的大体含义就是,事务的产生,其实是为了当应用程序访问数据库的时候,事务能够简化我们的编程模型,不需要我们去考虑各种各样的潜在错误和并发问题.可以想一下当我们使用事务时,要么提交,要么回滚,我们不会去考虑网络异常了,服务器宕机了,同时更改一个数据怎么办对吧? 题外话: 因此事务本质上是为了应用层服务的.而不是伴随着数据库系统天生就有的.其次,说道一致性,很遗憾,这个词在不同的环境下有着不同的含义,被极大的滥用了,导致很难理解:1. 多副本的一致性2.

分布式系统与高并发高可用 浅析分布式系统中的一致性哈希算法 通过本文将了解到以下内容： 分布式系统的简单概念和基本作用 分布式系统常用负载均衡策略 普通哈希取模策略优缺点 一致性哈希算法的定义和思想 一致性哈希的基本过程 Redis集群中一致性哈希的实现 1.分布式系统的基本概念 分布式系统与高并发高可用 当今高并发和海量数据处理等场景越来越多，实现服务应用的高可用、易扩展、短延时等成为必然。 在此情况下分布式系统应运而生，互联网的场景无外乎存储和计算，因此分布式系统可以简单地分为： 分布式存储 分布式计算 所谓分布式系统就是一批计算机组合起来共同对外提供服务，对于用户来说具体有多少规模的计算机完成了这次请求，完全是无感知的。分布式系统中的计算机越多，意味着计算和存储资源等也就越多，能够处理的并发访问量也就越大，响应速度也越快。 如图为简单整体架构图： 大前端 主要实现了服务应用对应的所有流量的接入，比如xyz域名下可能有N个子服务，这一层涉及很多网络流量的处理，也很有挑战，像百度的BFE(百度统一前端)接入了百度的大部分流量，每日转发1万亿次，峰值QPS1000w。 中间层 完成了各个服务的调度和分发，粒度相比大前端接入层更细致一些，这一层实现了用户的无感知体验，可以简单理解为反向代理层。 业务层 完成了数据存储、数据计算、数据缓存等，各个业务环节高度解耦，并且基于集群化来实现。

文章目录 Hash取余法与Hash一致性算法 一、Hash取余法 1.1 Hash取余法是什么？ 二、Hash一致性算法 2.1 什么是Hash一致性算法 三、Hash一致性算法的平衡性问题 四、如果看完这篇文章还不太懂。推荐一下这篇文章 Hash取余法与Hash一致性算法 一、Hash取余法 Hash取余法其实非常简单，只要学过数据结构哈希表的大概都会知道（常用算法） Hash取余法在分布式系统中的使用 1.1 Hash取余法是什么？ 为了简单说明问题，就不说微服务、redis之类的东西了（下面这个例子并不符合当前开发的模式，但足以说明Hash取余能解决的问题以及带来的问题） 以下图为例。 下面每个tomcat都是一个单体应用，通过nginx负载均衡搭建后端应用集群。为了session能够的正确获取，通过nginx的取余算法来达到负载均衡的目的 负载均衡算法：Hash(ip地址)%tomcat总数即（“ip地址”.hashCode&Integer.MAX_VALUE）%tomcat总数 通过Hash算法，得到ip地址的hash值（得出一个整数），再通过取余计算，因为这里的tomcat为三台，所以这里的余数为3，那么这个ip地址每次访问都总是可以分配到同一台tomcat上去 优点： 1）、这种算法及其简单，并且效率较高（CPU最擅长的就是计算） 2）、IP地址的hash值总是一样的

简述 ：用于解决分布式系统中数据一致性问题 推导过程 ：在Paxos算法中，有三种角色，分别是Proposer（负责提案），Acceptor（负责决策）和Learner（学习最终提案），Paxos的推导是建立在这两个基础之上的： 消息在传输过程中可能会丢失，但不会被篡改。因为分布式系统一般在内网集群中，不容易被篡改，并且通过校验就可以简单判断是否被篡改 每个参与者可能会发生异常，包括数据丢失，关机等 　　在Paxos原始论文（Paxos Made Simple）中，作者是通过不断添加约束条件来推导该算法的 。首先，最简单的方式是选定一个Acceptor，但这种方式容易存在单点故障，因此需要有多个Acceptor，并且规定足够多Acceptor同意的提案才能被选定，后面再讨论足够多是多少。 　　首先，即使只有一个提案被提出，也应该有提案被选定，因此有了第一个约束条件： 　　　 　P1： Acceptor必须同意它收到的第一个提案 　　在P1的基础之上，可能会有这种情况，有n个Proposer，分别向一个Acceptor（总共也n个）提交提案，每个Acceptor都会同意它接受到的第一个提案，此时并不会有一个提案被多数Acceptor批准，如图： 　　 　　或者是只有两个提案被同时提出，但分别被一般Acceptor批准，最终也无法得到最终提案，如图（红色问号代表不可达）： 　　因此

1、什么是分布式事务 分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。以上是百度百科的解释，简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。 2、分布式事务的产生的原因 2.1、数据库分库分表 当数据库单表一年产生的数据超过1000W，那么就要考虑分库分表，具体分库分表的原理在此不做解释，以后有空详细说，简单的说就是原来的一个数据库变成了多个数据库。这时候，如果一个操作既访问01库，又访问02库，而且要保证数据的一致性，那么就要用到分布式事务。 2.2、应用SOA化 所谓的SOA化，就是业务的服务化。比如原来单机支撑了整个电商网站，现在对整个网站进行拆解，分离出了订单中心、用户中心、库存中心。对于订单中心，有专门的数据库存储订单信息，用户中心也有专门的数据库存储用户信息，库存中心也会有专门的数据库存储库存信息。这时候如果要同时对订单和库存进行操作，那么就会涉及到订单数据库和库存数据库，为了保证数据一致性，就需要用到分布式事务。 以上两种情况表象不同，但是本质相同，都是因为要操作的数据库变多了！ 3、事务的ACID特性 3.1、原子性（A） 所谓的原子性就是说