分布式一致性

前后端处理分离解耦，前批处理+有向图编译，后端为有向图优化+自动资源分配+自动监控/错误跟踪 首先我们忘掉所有的框架，我们想做的业务设计其实是就是一个count() 一个topK() 衡量指标很简单是sla 工程一致性模型，强一致性，弱一致性，最终一致性 Cloud Spanner 就是强一致性，业务级的数据引擎 ''' 复制 过滤 分离 合并 ''' 可以使用发布订阅，进行解耦 削峰 cap c 线性一致性 分布式系统操作就像单机一样 a 可用性 只要不是所有节点都挂了，数据一定要返回响应 p 分区容错 ，就是数据不能仅仅存在一个节点上 存储架构使用的cp 系统 Google BigTable, Hbase, MongoDB Ap 系统 amazon dynamo 数据系统 kafka 属于ca 系统 批处理层 速度处理层 服务层  spark spark 不只能依赖于hadoop 才能使用，还可以运行在apache mesos ,kubernetes ，standalone ![](https://img2018.cnblogs.com/blog/1337375/201909/1337375

1、什么是分布式事务 分布式事务就是指事务的资源分别位于不同的分布式系统的不同节点之上的事务； 2、分布式事务产生的原因 2.1、数据库分库分表 在单库单表场景下，当业务数据量达到单库单表的极限时，就需要考虑分库分表，将之前的单库单表拆分成多库多表； 分库分表之后，原来在单个数据库上的事务操作，可能就变成跨多个数据库的操作，此时就需要使用分布式事务； 2.2、业务服务化 业务服务化即业务按照面向服务（SOA）的架构拆分整个网站系统； 比如互联网金融网站SOA拆分，分离出交易系统、账务系统、清算系统等，交易系统负责交易管理和记录交易明细，账务系统负责维护用户余额，所有的业务操作都以服务的方式对外发布； 一笔金融交易操作需要同时记录交易明细和完成用户余额的转账，此时需要分别调用交易系统的交易明细服务和账务系统的用户余额服务，这种跨应用、跨服务的操作需要使用分布式事务才能保证金融数据的一致性； 3、分布式事务原理简介 数据库本地事务（ACID） 说到数据库事务就不得不说，数据库事务中的四大特性 ACID： A：原子性(Atomicity)，一个事务(transaction)中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。 事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。 就像你买东西要么交钱收货一起都执行

Chain Replication for Supporting High Throughput and Availability 作者提出一种方法， 在保证高可用和高吞吐的情况下，不以牺牲强一致性为代价 提供分布式存储服务 要理解这篇文章解决的问题，可以看下另外两篇文章： Brewer's CAP Theorem Dynamo: Amazon’s Highly Available Key-value Store CAP:对于分布式存储服务，不可能同时满足可用性、一致性和分区容错性（数据分布性的大小对系统的正确性、性能的影响）。由于分区容错性是分布式系统的基本需求，所以，分布式系统一般在可用性和一致性中做权衡。 Dynamo是非常经典的满足AP模型的系统，有非常多好的应用，包括： 一致性Hash 、vector clocks、 Gossip 等 链式复制期望从Replication的角度，保证系统的高可用和强一致性，其设计思路如下： 1.数据relication采用Chain Replication a. 更新：只能发生在数据头节点,然后更新逐步后移，直到更新到达尾节点，并由尾节点向客户确认更新成功。写操作的向后传播是顺序的，即：每个节点上已完成的更新操作是其predecessor节点的子集 b. 查询：为保证强一致性，客户查询只能在尾节点进行 2. Master主要功能： a.

分布式系统一致性问题解决实战 一、背景及问题描述 业务背景： 商户提交表单数据至旺铺（deco项目，以下皆称为deco），deco需要接入poi系统进行装修内容的人工审核，详细流程见下图。 问题： 店铺装修审核状态在deco系统和poi系统之间不一致，下图中1，2，3步提交流程会出现同一次提交审核流在deco系统中的装修状态为未装修，而在poi系统为审核中。同样在4，5，6步骤的审核回调过程也会有同类的状态不一致问题。两块问题都是同一技术问题，本文只以1，2，3步提交过程为例进行分析解决。 二、问题分析 1. 关系型数据事务在分布式系统中的问题 从业务中抽离出来，问题的核心原因可用下图流程模型来描述。 系统A的某个业务功能包含两步操作，第一步把数据写入A系统本地库，第二步远程调用系统B，这两步操作在A系统用一个数据库事务来包装。伪代码如下： $db->begain(); // 第一步操作本地数据库 $res = $db->update($sql_a); if (!$res) { $db->rollback(); return; } // 第二步远程调用B系统 $res = $http_request->get($url_b); if ('success' != $res) { $db->rollback(); return; } $db->commit(); 第一步有两种结果成功

首先了解一下什么是一致性哈希，这里推荐一篇博客： http://blog.csdn.net/cywosp/article/details/23397179/ 在分布式应用中，扩容和收缩是一个半自动化的过程，在此期间，应用基本上是可用的，所以不能发生大规模动荡的意外，为了最小化潜在的影响，这时候需要使用到一致性hash算法实现负载均衡和分库分表，hash路由算法在分布式场景下极为重要的角色。 consistent hashing 算法早在 1997 年就在论文 Consistent hashing and random trees 中被提出，目前在cache 系统中应用越来越广泛； 比如你有 N 个 cache 服务器（后面简称 cache ），那么如何将一个对象 object 映射到 N 个 cache 上呢，你很可能会采用类似下面的通用方法计算 object 的 hash 值，然后均匀的映射到到 N 个 cache ； hash(object)%N 一切都运行正常，再考虑如下的两种情况； 1 一个 cache 服务器 m down 掉了（在实际应用中必须要考虑这种情况），这样所有映射到 cache m 的对象都会失效，怎么办，需要把 cache m 从 cache 中移除，这时候 cache 是 N-1 台，映射公式变成了 hash(object)%(N-1) ； 2

根据百度百科的定义，CAP定理又称CAP 原则 ，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），最多只能同时三个特性中的两个，三者不可兼得。 一、CAP的定义 Consistency (一致性)： “all nodes see the same data at the same time”,即更新操作成功并返回客户端后，所有节点在同一时间的数据完全一致，这就是分布式的一致性。一致性的问题在并发系统中不可避免，对于客户端来说，一致性指的是并发访问时更新过的数据如何获取的问题。从服务端来看，则是更新如何复制分布到整个系统，以保证数据最终一致。 Availability (可用性): 可用性指“Reads and writes always succeed”，即服务一直可用，而且是正常响应时间。好的可用性主要是指系统能够很好的为用户服务，不出现用户操作失败或者访问超时等用户体验不好的情况。 Partition Tolerance (分区容错性): 即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。 分区容错性要求能够使应用虽然是一个分布式系统，而看上去却好像是在一个可以运转正常的整体。比如现在的分布式系统中有某一个或者几个机器宕掉了

分布式一致性问题 在分布式系统中一个需要解决的重要问题就是数据的复制。 分布式系统对于数据的复制需求一般都来自于以下两个原因： 为了 提高系统的可用性 ，以防止单点故障引起的系统不可用 提升系统的整体性能 ，通过负载均衡技术，能够让分布在不同地方的数据副本都能够为用户提供服务。 所谓的分布式一致性问题，是指在分布式环境中引入数据复制机制后，不同数据节点间可能出现的，并无法依靠计算机应用程序自身解决的数据不一致情况。 简单地讲，数据一致性就是指在对一个副本数据进行更新的同时，必须确保也能够更新其他的副本，否则不同副本之间的数据将不再一致。 可能会有人想到这种解决方案： 将写入的动作阻塞，直到数据复制完成后，才完成写入动作。 这似乎能解决问题，可 当应用场景中有非常多的写请求时，系统的性能将急剧下降。 总的来讲，我们无法找到一种能够满足分布式系统所有系统属性的一致性解决方案。因此如何既保证数据的一致性，同时又不影响系统运行的性能，是每一个分布式系统都需要重点考虑和权衡的。 于是就出现了以下一致性级别。 强一致性 这种一致性级别是最符合用户直觉的，它要求 系统写入什么，读出来的也会是什么 ，用户体验好，但 实现起来往往对系统的性能影响极大 。 弱一致性 这种一致性级别约束了系统在写入成功后，不承诺立即可以读到写入的值，也不具体承诺多久之后数据能够达到一致，但会尽可能保证到某个时间级别后

Nosql 本篇文章主要介绍Nosql的一些东西，以及Nosql中比较火的三个数据库Redis、Memchache、MongoDb和他们之间的区别。以下是本文章的阅读目录 一、Nosql介绍 1. Nosql简介 2. Nosql的特点和关系型数据库的区别 3. Redis，Memcache，MongoDb的特点与区别 4 .参考文章 1. Nosql介绍 Nosql的全称是Not Only Sql，这个概念早起就有人提出，在09年的时候比较火。Nosql指的是非关系型数据库，而我们常用的都是关系型数据库。就像我们常用的mysql，sqlserver一样，这些数据库一般用来存储重要信息，应对普通的业务是没有问题的。但是，随着互联网的高速发展，传统的关系型数据库在应付超大规模，超大流量以及高并发的时候力不从心。而就在这个时候，Nosql得到的告诉的发展。 2. Nosql和关系型数据库的区别 1.存储方式 　　关系型数据库是表格式的，因此存储在表的行和列中。他们之间很容易关联协作存储，提取数据很方便。而Nosql数据库则与其相反，他是大块的组合在一起。通常存储在数据集中，就像文档、键值对或者图结构。 2.存储结构 　　关系型数据库对应的是结构化数据，数据表都预先定义了结构（列的定义），结构描述了数据的形式和内容。这一点对数据建模至关重要，虽然预定义结构带来了可靠性和稳定性

群里经常卧虎藏龙，转载一篇百度大牛，投稿原创文章，大家交流学习 ，欢迎更多朋友投稿，发布原创文章和干货和大家分享交流。 引言 在互联网系统中，理想的情况下，肯定是希望系统能够同时满足“一致性”、“可用性”和“分区容忍性”。 但是基于熟悉的CAP定律也好，还是BASE理论， 我们知道，在实际情况中是不可能实现的。而在金融领域，一致性是最为关注的特性，任何情况下都必须满足一致性。关于CAP定律和BASE理论，本文不再介绍，有兴趣的同学可以自行百度一下。本文重点来阐述下关于一致性的方案，包括强一致性和最终一致性。 而在互联网领域， 很多情况下都是牺牲强一致性，来达到高可用性， ϵ 统往往只需要保证“最终一致性”，只要这个最终时间是在用户可以接受的范围内即可。 数据库本地事务 数据库事务肯定是强一致性的方案，而且是一致性最简单的方案，因为一致性是数据库的事务来保证的，业务层不需要关心细节。比较典型的应用是在返现场景下，针对带有返现的交易的退款，需要一次性退两笔交易单，采用的就是通过数据库本地事务来完成的。具体如下： 用户A花了100元购买商户B的商品，购买结束后返现给用户A 2元。 这是两笔交易，原始交易是100元，返现交易是2元。 那么发生退款时，需要保证两笔交易同时都退款。这个就是直接采用数据库本地事务实现的，即一次退款请求，两笔交易同时退款。 总结： 数据库事务的优点是简单

1. 二阶段提交算法 1.1 算法描述： 在分布式系统中，事务往往包含有多个参与者的活动，单个参与者上的活动是能够保证原子性的，而多个参与者之间原子性的保证则需要通过两阶段提交来实现，两阶段提交是分布式事务实现的关键。 　　很明显，两阶段提交保证了分布式事务的原子性，这些子事务要么都做，要么都不做。而数据库的一致性是由数据库的完整性约束实现的，持久性则是通过commit日志来实现的，不是由两阶段提交来保证的。至于两阶段提交如何保证隔离性，可以参考Large-scale Incremental Processing Using Distributed Transactions and Notifications中两阶段提交的具体实现。 　　两阶段提交的过程涉及到协调者和参与者。协调者可以看做成事务的发起者，同时也是事务的一个参与者。对于一个分布式事务来说，一个事务是涉及到多个参与者的。具体的两阶段提交的过程如下： 第一阶段： 　　首先，协调者在自身节点的日志中写入一条的日志记录，然后所有参与者发送消息prepare T，询问这些参与者（包括自身），是否能够提交这个事务； 　　参与者在接受到这个prepare T 消息以后，会根据自身的情况，进行事务的预处理，如果参与者能够提交该事务，则会将日志写入磁盘，并返回给协调者一个ready T信息，同时自身进入可提交状态；如果不能提交该事务