分布式一致性

这篇文章将介绍什么是分布式事务，分布式事务解决什么问题，对分布式事务实现的难点，解决思路，不同场景下方案的选择，通过图解的方式进行梳理、总结和比较。相信耐心看完这篇文章，谈到分布式事务，不再只是有“2PC”、“3PC”、“MQ的消息事务”、“最终一致性”、“TCC”等这些知识碎片，而是能够将知识连成一片，形成知识体系。 什么是事务 介绍分布式事务之前，先介绍什么是事务。 事务的具体定义 事务提供一种机制将一个活动涉及的所有操作纳入到一个不可分割的执行单元，组成事务的所有操作只有在所有操作均能正常执行的情况下方能提交，只要其中任一操作执行失败，都将导致整个事务的回滚。 简单地说，事务提供一种“ 要么什么都不做，要么做全套（All or Nothing）”机制。 数据库事务的 ACID 属性 事务是基于数据进行操作，需要保证事务的数据通常存储在数据库中，所以介绍到事务，就不得不介绍数据库事务的 ACID 特性。 ACID 指数据库事务正确执行的四个基本特性的缩写，包含： 原子性（Atomicity） 整个事务中的所有操作，要么全部完成，要么全部不完成，不可能停滞在中间某个环节。 事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。 例如：银行转账，从 A 账户转 100 元至 B 账户，分为两个步骤：从 A 账户取 100 元。存入

大家好，今天我给大家分享的题目是微服务架构下的数据一致性保证。 今天分享第一篇， 主要内容 包括： 1.传统使用本地事务和分布式事务保证一致性。 2.传统分布式事务不是微服务中一致性的最佳选择。 3.微服务架构中应满足数据最终一致性原则。 4.微服务架构实现最终一致性的三种模式。 5.对账是最后的终极防线。 一、传统使用本地事务和分布式事务保证一致性 传统单机应用一般都会使用一个关系型数据库，好处是应用可以使用 ACID transactions。为保证一致性我们只需要：开始一个事务，改变（插入，删除，更新）很多行，然后提交事务（如果有异常时回滚事务）。更进一步，借助开发平台中的数据访问技术和框架（如Spring），我们需要做的事情更少，只需要关注数据本身的改变。 随着组织规模不断扩大，业务量不断增长，单机应用和数据库已经不足以支持庞大的业务量和数据量，这个时候需要对应用和数据库进行拆分，就出现了一个应用需要同时访问两个或两个以上的数据库情况。开始我们用分布式事务来保证一致性，也就是我们常说的两阶段提交协议（2PC）。 本地事务和分布式事务现在已经非常成熟，相关介绍很丰富，此处不多作讨论。 二、传统分布式事务不是微服务中一致性的最佳选择 首先， 对于微服务架构来说，数据访问变得更加复杂，这是因为数据都是微服务私有的，唯一可访问的方式就是通过API

无论是云计算、大数据还是互联网公司的各种应用，其后台基础设施的主要目标都是构建低成本、高性能、可扩展、易用的分布式存储系统。 大规模分布式存储系统的定义如下：分布式存储系统是大量普通PC服务器通过Internet互联，对外作为一个整体提供存储服务。 几个特点： （1）可扩展：分布式存储系统可以扩展到几百台甚至上千台的集群规模，而且，随着集群规模的增长，系统整体性能表现为线性增长 （2）低成本：自动容错、自动负载均衡机制使其可以构建在普通PC机之上。另外，线性扩展能力也使得增加、减少机器非常方便，可以实现自动运维。 （3）高性能：针对整个集群还是单台服务器，都要求分布式存储系统具备高性能。 （4）易用：分布式存储喜提需要能够提供易用的对外接口，另外，也要求具备完善的监控、运维工具。 分布式存储数据需求比较复杂，大体可以分为三类： （1）非结构化数据 （2）结构化数据 （3）半结构化数据 不同的分布式存储系统适合处理不同类型的数据，将分布式存储系统分为四类： （1）分布式文件系统：互联网应用需要存储大量的图片，视频等非结构化数据对象，这类数据以对象的形式组织，对象之间没有关联，这样的数据一般称为Blob数据（Binary Large Object二进制大对象） 分布式文件系统存储三种类型的数据：Blob对象，定长块，大文件 （2）分布式键值系统：存储关系检点的半结构化数据

更多内容，欢迎关注微信公众号：全菜工程师小辉。公众号回复关键词，领取免费学习资料。 一致性hash算法是什么？ 一致性hash算法，是麻省理工学院1997年提出的一种算法，目前主要应用于分布式缓存当中。 一致性hash算法可以有效地解决分布式存储结构下动态增加和删除节点所带来的问题。 在Memcached、Key-Value Store、Bittorrent DHT、LVS中都采用了一致性hash算法，可以说一致性hash算法是分布式系统负载均衡的首选算法。 传统hash算法的弊端 常用的算法是对hash结果取余数 (hash() mod N)：对机器编号从0到N-1，按照自定义的hash算法，对每个请求的hash值按N取模，得到余数i，然后将请求分发到编号为i的机器。但这样的算法方法存在致命问题，如果某一台机器宕机，那么应该落在该机器的请求就无法得到正确的处理，这时需要将宕掉的服务器使用算法去除，此时候会有(N-1)/N的服务器的缓存数据需要重新进行计算；如果新增一台机器，会有N /(N+1)的服务器的缓存数据需要进行重新计算。对于系统而言，这通常是不可接受的颠簸（因为这意味着大量缓存的失效或者数据需要转移）。 传统求余做负载均衡算法，缓存节点数由3个变成4个，缓存不命中率为75%。计算方法：穷举hash值为1-12的12个数字分别对3和4取模

HBase —— NoSQL_Not Only SQL NoSQL数据库： 不遵循传统的RDBMS模型 解决数据库的可伸缩性和可用性（多机器） 数据是非关系的（可切分），不使用sql语句 不针对原子性或一致性（定时同步数据）问题 —————————————————————————————— 传统关系型数据库存在瓶颈 高并发读写，每秒上万次读写请求 高存储量，分库分表难以维护 高扩展性，无法简单地通过增加硬件提升性能 高可用性，不能保证服务长时间运行时的稳定性 NoSQL的优势 优异的海量数据读写性能 灵活的数据模型 数据间无关系，易于切割、扩展 SQL与NOSQL对比 对比 NoSQL 关系型数据库 常用数据库 HBase、MongoDB、Redis Oracle、DB2、MySQL 存储格式 文档、键值对、图结构 表格式，行和列 存储规范 鼓励冗余 规范性，避免重复 存储扩展 横向扩展，分布式 纵向扩展（横向扩展有限） 查询方式 非结构化查询 结构化查询语言SQL 事务 不支持事务一致性 支持事务 性能 读写性能高 读写性能差 成本 简单易部署，开源，成本低 成本高 NoSQL的特点 最终一致性，数据并非实时一致，但最终会一致 应用程序可以增加一致性 鼓励冗余数据存储 NoSQL 不等于 大数据 nosql是为了帮助解决大数据的数据存储问题 但大数据不仅仅包含数据的存储问题（存储

原文链接：https://blog.ouyangsihai.cn/ >> MySQL事务，这篇文章就够了 在看这篇文章之前，我们回顾一下前面的几篇关于MySQL的系列文章，应该对你读下面的文章有所帮助。 InnoDB与MyISAM等存储引擎对比 面试官问你B树和B 树，就把这篇文章丢给他 MySQL的B 树索引的概念、使用、优化及使用场景 MySQL全文索引最强教程 MySQL的又一神器-锁，MySQL面试必备 0 什么是事务 事务（Transaction） 是并发控制的基本单位。所谓的事务，它是一个操作序列，这些操作要么都 执行，要么都不执行，它是一个不可分割的工作单位。事务是数据库维护数据一致性的单位，在每 个事务结束时，都能保持数据一致性。 同时，事务有着严格的地定义，必须满足四个特性，也就是我们一直说的ACID，但是，并不是说各种数据库就一定会满足四个特性，对于不同的数据库的实现来说，在不同程度上是不一定完全满足要求的，比如，Oracle数据库来说，默认的事务隔离级别是 READ COMMITTED ，是不满足隔离性的要求的。 下面我们趁热打铁，介绍一下事务的必知必会的四大特性，这几个特性也是在面试中，面试官面试MySQL的相关知识的时候，问的比较多的问题，所以，这几个特性务必需要理解并且透彻的记在心里，开个玩笑，被火车撞了，也不应该忘记这四个特性！ 1 事务的四大特性

在实际开发中，我们的大型项目都需要设计分布式架构，同时对高并发的场景进行管理，而在高并发环境中，我们通过使用redis集群来管理和控制该场景，同时，我们需要保证数据库与缓存的双写一致性，同时因为在常见的高并发场景中，我们对于微服务的控制并不能很好的应对该场景，如spring cloud和docker的结合并不能很好的解决该问题，因此我们需要相应的算法和协议来维持分布式架构的一致性。 如图所示，我们在分布式架构中，通常对于服务器的管理，我们通过观察是否存在特洛伊问题来决定使用哪种方法来解决分布式架构一致性。 在非特洛伊问题中，我们使用paxos和raft协议来维持分布式架构一致性，例如，在使用spring+spring MVC+Mybatis的开发中，我们经常使用@RequestBody 注解来返回一个json格式的网络状态，在常用的消息队列中，例如RabbitMQ,我们使用消息中间件的特性来进行程序的解耦削峰异步，通过消息中间件的作用，我们使传统RPC的方式变为了分布式，从而解决了系统的耦合性，但是对于大型业务场景，消息中间件会产生消息丢失，消息转发失败等系统问题，所以我们在设计架构的时候，通过会使用消息队列锁定算法来维持消息的稳定性，但对于高并发场景一味的使用synchronized或者乐观锁是不现实的，所以我们会使用分布式锁，自旋锁等高级锁来保持高并发场景的读写一致性。

CAP定理： 一个分布式系统 不可能 同时满足 一致性 （C:Consistency）、 可用性 （A:Availability）和 分区容错性 （P:Partition tolerance）这三个基本要求，最多只能满足 其中的两项 。 一致性 在分布式环境中，一致性是指数据在 多个副本之间 是否能够 保持强一致 的特性。 对于一个将数据副本分布在不同节点上的分布式系统来说，如果对第一个节点的数据进行了更新操作并且更新成功后，却没有使得第二个节点上的数据得到相应的更新，于是在对第二个节点的数据进行读取操作时，获取的依然是更新前的数据（称为 脏数据 ），这就是典型的分布式数据不一致情况。在分布式系统中，如果能够做到针对一个数据项的更新操作执行成功后，所有的用户都能读取到最新的值，那么这样的系统就被认为具有 强一致性 （或严格的一致性）。 可用性 可用性是指系统提供的服务必须 一直处于可用 的状态，对于用户的每一个操作请求总是能够在 有限的时间 内 返回结果 ，如果超过了这个时间范围，那么系统就被认为是不可用的。 『有限的时间内』是一个在系统设计之初就设定好的运行指标， 不同的系统会有很大的差别 。比如对于一个在线搜索引擎来说，通常在0.5秒内需要给出用户搜索关键词对应的检索结果。而对应Hive来说，一次正常的查询时间可能在20秒到30秒之间。 『返回结果

分布式系统中一致性哈希算法 此博文转载自 分布式系统中一致性哈希算法 ，博主对分布式系统中最常见的一致性哈希算法进行了非常细致的讲解，非常值得阅读！另外博主在博客园上定制的皮肤样式也是非常好看，推荐一波~ 业务场景 近年来，由于互联网的兴起，B2C、O2O等商业概念的提出和移动端的发展，使得分布式系统流行起来。分布式系统相对于单一系统而言，带来了流量大、系统高可用和高容错的便利。功能强大的同时，也意味着实现起来需要更多的技术支持。例如系统访问层的 负债均衡 、缓存层的 多实例主从复制备份 以及数据层的 分库分表 等。 我们以负载均衡为例，常见的负载均衡方法有很多，但是它们的优缺点都很明显： 随机访问策略： 系统随机访问，缺点：可能造成服务器负载压力不均衡，俗话讲就是撑的撑死，饿的饿死。 轮询策略： 请求均匀分配，如果服务器有性能差异，则无法实现性能好的服务器能够多承担一部分。 权重轮询策略： 权值需要静态配置，无法自动调节，不适合对长连接和命中率有要求的场景。 Hash取模策略： 不稳定，如果列表中某台服务器宕机，则会导致路由算法产生变化，由此导致命中率的急剧下降。 一致性哈希策略（本文重点分析） 以上几个策略，排除本篇介绍的一致性哈希策略，可能使用最多的就是 Hash取模策略 了。Hash取模策略的缺点也是很明显的，这种缺点也许在负载均衡的时候不是很明显

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