分布式一致性

转自： https://www.cnblogs.com/butterfly100/p/9034281.html 一. 数据切分 关系型数据库本身比较容易成为系统瓶颈，单机存储容量、连接数、处理能力都有限。当单表的数据量达到1000W或100G以后，由于查询维度较多，即使添加从库、优化索引，做很多操作时性能仍下降严重。此时就要考虑对其进行切分了，切分的目的就在于减少数据库的负担，缩短查询时间。 数据库分布式核心内容无非就是数据切分（Sharding），以及切分后对数据的定位、整合。数据切分就是将数据分散存储到多个数据库中，使得单一数据库中的数据量变小，通过扩充主机的数量缓解单一数据库的性能问题，从而达到提升数据库操作性能的目的。 数据切分根据其切分类型，可以分为两种方式：垂直（纵向）切分和水平（横向）切分 1、垂直（纵向）切分 垂直切分常见有垂直分库和垂直分表两种。 垂直分库就是根据业务耦合性，将关联度低的不同表存储在不同的数据库。做法与大系统拆分为多个小系统类似，按业务分类进行独立划分。与"微服务治理"的做法相似，每个微服务使用单独的一个数据库。如图： 垂直分表是基于数据库中的"列"进行，某个表字段较多，可以新建一张扩展表，将不经常用或字段长度较大的字段拆分出去到扩展表中。在字段很多的情况下（例如一个大表有100多个字段），通过"大表拆小表"，更便于开发与维护，也能避免跨页问题

作者 | 晓土 阿里巴巴高级工程师 姊妹篇阅读推荐 ： 《 云原生时代，分布式系统设计必备知识图谱（内含22个知识点） 》 导读： 本文力求从分布式基础理论、架构设计模式、工程应用、部署运维、业界方案这几大方面，介绍基于 MSA（微服务架构）的分布式知识体系大纲，从而对 SOA 到 MSA 进化有着立体的认识；从概念上和工具应用上更近一步了解微服务分布式的本质，身临其境的感受如何搭建全套微服务架构的过程。 关注“阿里巴巴云原生”公众号，回复“ 分布 ”，即可下载分布式系统及其知识体系清晰大图！ 随着移动互联网的发展和智能终端的普及，计算机系统早就从单机独立工作过渡到多机器协作，集群按照分布式理论构建出庞大复杂的应用服务，在分布式的基础上正进行一场云原生的技术革命，彻底打破传统的开发方式，解放了新一代的生产力。 分布式系统知识体系大图 关注“阿里巴巴云原生”公众号，回复“ 分布 ”，即可下载分布式系统及其知识体系清晰大图！ 基础理论 SOA 到 MSA 的进化 SOA 面向服务架构 由于业务发展到一定程度后，需要对服务进行解耦，进而把一个单一的大系统按逻辑拆分成不同的子系统，通过服务接口来通讯。面向服务的设计模式，最终需要总线集成服务，而且大部分时候还共享数据库，出现单点故障时会导致总线层面的故障，更进一步可能会把数据库拖垮，所以才有了更加独立的设计方案的出现。 MSA 微服务架构

课程介绍: 分布式事务是一个绕不过去的挑战！微服务架构本质上就是分布式服务化架构，微服务架构的流行，让分布式事务问题日益突出！尤其是在订单业务、资金业务等系统核心业务流程中，一定要有可靠的分布式事务解决方案来保证业务数据的可靠性和准确性。 为了解决大家在实施分布式服务化架构过程中关于分布式事务问题的困扰，本教程将基于支付系统真实业务中的经典场景来对“可靠消息的最终一致性方案”、“TCC两阶段型方案”和“最大努力通知型方案”这3种柔性事务解决方案进行具体设计实现和详细讲解。 本教程提供的分布式事务解决方案的设计思路在所有微服务架构项目中都适用，与编程语言无关，教程中会重点讲解方案的设计思路。 教程中的样例项目基于龙果学院开源的微支付系统进行实现，使用Dubbo作为服务化框架，教程中所实现的分布式事务解决方案在Java体系中的微服务架构系统都能通用，与具体的开发框架无关。 教程样例项目中用到的技术及相应的环境： Dubbo、Spring、SpringMVC、MyBatis、Druid、JDK7（或JDK8）、MySQL5.6、Tomcat 课程大纲: 第1节课程介绍 第2节解决方案的效果演示（结合支付系统真实应用场景） 第3节常用的分布式事务解决方案介绍 [免费观看] 47分钟 第4节消息发送一致性（可靠消息的前提保障）20分钟 第5节消息发送一致性的异常流程处理16分钟

在说分布式事务之前，先回顾下事务的相关知识点。 事务 概念 事务指的是一系列数据库操作，它是保证数据库正确性的基本逻辑单元，拥有ACID四个特性：原子性、一致性、隔离性与持久性。 举个例子，下面这两种组成情况都叫做事务： 1.由单个操作序列（一条SQL语句）组成的事务 select * from test; 2.由多个操作序列（SQL语句）组成的事务 select * from test where id = 1; update test(id, name) set name = 'john' where id = 1; 当然，如果我们没有显示声明事务的话，数据库则会给我们自动地划分事务，对于MySQL来说，没有显示声明事务，则一条SQL语句就是一个事务，执行完便会自动提交。 一个事务由开始标识(begin_transaction)、数据库操作和结束标识(commit或rollback)三部分组成。如下图所示： 关于上图的相关说明如下： 事务开始：begin_transaction，说明事务的开始； 数据库上的操作：表现为一条或多条SQL语句； 事务提交：commit_transaction，提交事务操作，操作生效； 事务回滚：rollback_transaction，事务取消，操作废弃。 特性 事务是对数据库的一系列操作，是保证数据库正确性的基本逻辑单元

本质上来说，分布式事务就是为了保证不同数据库的数据一致性。 事务的ACID特性 原子性 一致性 隔离性 持久性 消息事务+最终一致性 CC提供了一个编程框架，将整个业务逻辑分为三块：Try、Confirm和Cancel三个操作。以在线下单为例，Try阶段会去扣库存，Confirm阶段则是去更新订单状态，如果更新订单失败，则进入Cancel阶段，会去恢复库存。总之，TCC就是通过代码人为实现了两阶段提交，不同的业务场景所写的代码都不一样，复杂度也不一样，因此，这种模式并不能很好地被复用。 来源： https://www.cnblogs.com/Yanss/p/11676223.html

作者：陈肃 整理：周奇，Apache Flink 社区志愿者 本文根据陈肃老师在 Apache Kafka x Flink Meetup 深圳站的分享整理而成，文章首先将从数据融合角度，谈一下 DataPipeline 对批流一体架构的看法，以及如何设计和使用一个基础框架。其次，数据的一致性是进行数据融合时最基础的问题。如果数据无法实现一致，即使同步再快，支持的功能再丰富，都没有意义。 另外，DataPipeline 目前使用的基础框架为 Kafka Connect。为实现一致性的语义保证，我们做了一些额外工作，希望对大家有一定的参考意义。 最后，会提一些我们在应用 Kafka Connect 框架时，遇到的一些现实的工程问题，以及应对方法。尽管大家的场景、环境和数据量级不同，但也有可能会遇到这些问题。希望对大家的工作有所帮助。 一、批流一体架构 批和流是数据融合的两种应用形态 下图来自 Flink 官网。传统的数据融合通常基于批模式。在批的模式下，我们会通过一些周期性运行的 ETL JOB，将数据从关系型数据库、文件存储向下游的目标数据库进行同步，中间可能有各种类型的转换。 另一种是 Data Pipeline 模式。与批模式相比相比， 其最核心的区别是将批量变为实时：输入的数据不再是周期性的去获取，而是源源不断的来自于数据库的日志、消息队列的消息。进而通过一个实时计算引擎

说在前面 我曾不止一次听说过这句话： “十个女人无法在一个月内生出孩子” 我明白这句话的意思，用来形容我们的开发工作需要循序渐进，没有办法简单的增加人员就能加快研发速度。 这句话也经常被用于反驳产品经理或者老板，试图让他们明白我们内心所表达的观点，老实说我也说过这样的话，当时还觉得挺有道理，现在想来可能有些一厢情愿了。 没错，在现实世界中，当然不可能在一个月内生出孩子，但我们毕竟是做产品写代码的，而不是真的要去生孩子，所以这种说法未免有点偷换概念。 我并不是较真，如果只是想让产品经理明白我们所要表达的观点，我们完全可以用其他的比喻，如实反馈存在的困难与问题即可。 言归正传，这句话与本文有什么关系呢？本文想要就“并发”所带来的问题进行探讨，相信看完后你会对此有一个感觉。 与我之前写的几篇文章一样，并发一词在本文中所表达的意思是： “在分布式环境下，超过一个线程同时对同一个状态进行访问和变更所导致的一致性问题和可用性问题” 问题的根源：状态 我无法给出一个百分比数据用以说明到底有多少后端应用程序在使用数据库，但我想国内涉及到增删查改之类的各种“管理系统”应该不在少数。 说到底，增删改查是落地，而怎么落地则取决于业务的需要，也就是说，业务规则以及流程表达了我们的逻辑，但终究离不开柴米油盐（增删改查）。 那么什么是状态？ 它可以是文件，也可以是数据库，可以是一个变量，也可以是缓存

目录 一、简介 二、基本模型 BSON 数据类型 分布式ID 三、操作语法 四、索引 索引特性 索引分类 索引评估、调优 五、集群 分片机制 副本集 六、事务与一致性 一致性 小结 一、简介 MongoDB 是一款流行的开源文档型数据库，从它的命名来看，确实是有一定野心的。 MongoDB 的原名一开始 来自于 英文单词"Humongous", 中文含义是指"庞大" ，即命名者的意图是可以处理大规模的数据。 但笔者更喜欢称呼它为 "芒果"数据库，除了译音更加相近之外，原因还来自于这几年使用 MongoDB 的两层感觉： 第一层感受是"爽"，使用这个文档数据库的特点是几乎不受什么限制，一方面Json文档式的结构更容易理解，而无Schema约束也让DDL管理更加简单，一切都可以很快速的进行。 第二层感受是"酸爽"，这点相信干运维或是支撑性工作的兄弟感受会比较深刻，MongoDB 由于入门体验"太过于友好"，导致一些团队认为用好这个数据库是个很简单的事情，所以开发兄弟在存量系统上埋一些坑也是正常的事情。 所谓交付一时爽，维护火葬场.. 当然了，这句话可能有些过。 但这里的潜台词是：与传统的RDBMS数据库一样，MongoDB 在使用上也需要认真的考量和看护，不然的化，会遇到更多的坑。 那么，尽管文档数据库在选型上会让一些团队望而却步，仍然不阻碍该数据库所获得的一些支持，比如 DB

CAP CAP是一个已经经过证实的理论：一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。 一致性 我们知道ACID中事务的一致性是指事务的执行不能破坏数据库数据的完整性和一致性，一个事务在执行前后，数据库都必须处于一致性状态。也就是说，事务的执行结果必须是使数据库从一个一致性状态转变到另一个一致性状态。 和ACID中的一致性不同，分布式环境中的一致性是指数据在多个副本之间是否能够保持一致的特性。 分布式系统中，数据一般会存在不同节点的副本中，如果对第一个节点的数据成功进行了更新操作，而第二个节点上的数据却没有得到相应更新，这时候读取第二个节点的数据依然是更新前的数据，即脏数据，这就是分布式系统数据不一致的情况。 在分布式系统中，如果能够做到针对一个数据项的更新操作执行成功后，所有的用户都能读取到最新的值，那么这样的系统就被认为具有强一致性（或严格的一致性）。 可用性 可用性是指系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果，如果超过了这个时间范围，那么系统就被认为是不可用的。 “有限的时间内”是在系统的运行指标，不同系统会有差别。例如搜索引擎通常在0.5秒内需要给出用户检索结果。 “返回结果”是可用性的另一个重要指标

本文章比较好的说明了一致性Hash算法的概念 Hash算法一般分为除模求余和一致性Hash 1、 除模求余：当新增、删除机器时会导致大量key的移动 2、一致性Hash：当新增、删除机器时只会影响到附近的key，因为是环状结构 转载请说明出处： http://blog.csdn.net/cywosp/article/details/23397179 一致性哈希算法在1997年由麻省理工学院提出的一种分布式哈希（DHT）实现算法，设计目标是为了解决因特网中的热点(Hot spot)问题，初衷和CARP十分类似。一致性哈希修正了CARP使用的简 单哈希算法带来的问题，使得分布式哈希（DHT）可以在P2P环境中真正得到应用。 一致性hash算法提出了在动态变化的Cache环境中，判定哈希算法好坏的四个定义： 1、平衡性(Balance)：平衡性是指哈希的结果能够尽可能分布到所有的缓冲中去，这样可以使得所有的缓冲空间都得到利用。很多哈希算法都能够满足这一条件。 2、单调性(Monotonicity)：单调性是指如果已经有一些内容通过哈希分派到了相应的缓冲中，又有新的缓冲加入到系统中。哈希的结果应能够保证原有已分配的内容可以被映射到原有的或者新的缓冲中去，而不会被映射到旧的缓冲集合中的其他缓冲区。 3、分散性(Spread)：在分布式环境中，终端有可能看不到所有的缓冲