分布式一致性

前两天发了工资，第一反应是想着要给远方的女朋友一点惊喜！于是打开了平安银行的APP给女朋友转点钱！填写上对方招商银行卡的卡号、开户名，一键转账！搞定！在我点击的那瞬间，就收到了app的账户变动的提醒，并且出现了图一所示的提示界面：“处理中，正在等待对方银行返回结果…”。嗯！毕竟是跨行转账嘛，等个几秒也正常！脑海开始浮现出女朋友收到转账后惊喜与感动的画面！    然而，一切并没有那么顺利，刚过一会儿，app却如图二所示的提示我“由于收款人户名不符”导致转账失败！！！       刚刚都已经从我卡里扣过钱了，现在却提示我转账失败，银行会不会把我的钱给吞了？转账失败的钱还能退换给我吗？正在我紧张、焦虑、坐立不安之时又收到一条app冲正的消息，刚刚转账失败的钱已经退还给我了，看来我多虑了……这也证明咱平安银行的app还是比较安全靠谱的！ 为啥从我卡里扣钱那么迅速，而对方却要几秒才能到账？并且转账失败后，扣除的钱还能及时的返还到我的卡里？万一钱返还失败怎么办？又或者我转一次钱，对方却收到了两次转账的申请又该如何？带着这些问题，我脑海中浮现出“事务”二字！ 在我们还在“牙牙学语”的时候，老师经常会通过转账的栗子来跟我们讲解事务，但跟这里场景不一样的是，老师讲的是本地事务，而这里面对的是分布式事务！我们先来简单回顾一下本地事务！ 本地事务 谈到本地事务，大家可能都很熟悉

转载： https://www.jdon.com/artichect/acid-cap.html ACID和CAP的详尽比较 事务机制ACID和CAP理论是数据管理和分布式系统中两个重要的概念，很不巧，这两个概念中都有相同的“C”代表 "Consistency" 一致性，但是实际上是完全不同的意义，下面是比较两个概念的不同之处。 什么是ACID？ 事务的定义和实现一直随着数据管理的发展在演进，当计算机越来越强大，它们就能够被用来管理越来越多数据，最终，多个用户可以在一台计算机上共享数据，这就导致了一个问题，当一个用户修改了数据而另外一个还在使用旧数据进行计算过程中，这里就需要一些机制来保证这种情况不会发生。 ACID规则原来是在1970被Jim Gray定义，ACID事务解决了很多问题，但是仍然需要和性能做平衡协调，事务越强，性能可能越低，安全可靠性和高性能是一对矛盾。 一个事务是指对数据库状态进行改变的一系列操作变成一个单个序列逻辑元操作，数据库一般在启动时会提供事务机制，包括事务启动 停止 取消或回滚。 但是上述事务机制并不真的实现“事务”，一个真正事务应该遵循ACID属性，ACID事务才真正解决事务，包括并发用户访问同一个数据表记录的头疼问题。 ACID的定义： Atomic原子性: 一个事务的所有系列操作步骤被看成是一个动作，所有的步骤要么全部完成要么一个也不会完成

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

二、集群/分布式/微服务/SOA是什么？ 像我这种技术小白，看到这些词( 集群/分布式/微服务/SOA )的时候，感觉就是遥不可及的(高大尚的技术！！)。就好像刚学Java面向对象的时候，在论坛上翻阅资料的时候，无意看到"面向切面编程"，也认为这是遥不可及的(高大尚的技术！！)。 但真正接触到"面向切面编程"的时候，发现原来就是如此啊，也没什么大不了的。只不过当时被它的名字给唬住了… 不知道各位在刚接触这些名字 集群/分布式/微服务/SOA 的时候，有没有被唬住了呢？？ 下面我就简单说说这些名词的意思 2.1什么是集群 以下内容来源维基百科： 计算机集群简称集群是一种计算机系统，它通过一组松散集成的计算机软件和/或硬件连接起来高度紧密地协作完成计算工作。在某种意义上，他们可以被看作是一台计算机。集群系统中的单个计算机通常称为节点，通常通过局域网连接，但也有其它的可能连接方式。集群计算机通常用来改进单个计算机的计算速度和/或可靠性。一般情况下集群计算机比单个计算机，比如工作站或超级计算机性能价格比要高得多 集群技术特点： 通过 多台计算机 完成同一个工作，达到更高的效率。 两机或多机内容、工作过程等完全一样 。如果一台死机，另一台可以起作用。 在维基百科上说得也挺明白的了，我来举个 例子 吧。 小周在公司写Java程序，但公司业务在发展，一个Java开发者可能 忙不过来

区块链系统是一个分布式系统，而分布式系统的首要问题是一致性的保障。 一致性 　　定义：一致性（consistency），早期也叫agreement，是指对于分布式系统中的多个服务节点，给定一系列操作，在约定协议的保障下，试图使得他们对处理结果达成“某种程度”的认同。 一致性并不代表结果正确与否，而是系统对外呈现的状态一致与否；例如，所有节点都达成失败状态也是一种一致。 　　将可能引发不一致的并行操作进行串行化 是现代分布式系统处理一致性问题的的基础思路。 　　事件的先后顺序十分重要，这也是解决分布式系统领域很多问题的核心秘诀：把多件事情进行排序，并且这个顺序还得是大家都认可的。 共识算法 　　共识（consensus）在很多时候会与一致性（consistency）术语放在一起讨论。严谨地讲，两者的含义并不完全相同。 　　 一致性 往往指分布式系统中多个副本对外呈现的数据的 状态 。 共识 则描述了分布式系统中多个节点之间，彼此对某个状态达成一致结果的 过程 。因此，一致性描述的是结果状态，共识则是一种手段。达成某种共识并不意味着就保障了一致性。 　　在实践中，要保障系统满足不同程度的一致性，核心过程往往需要通过共识算法来达成。共识算法解决的是对某个提案（proposal） 大家达成一致意见的过程 。 提案的含义在分布式系统中十分宽泛，比如多个事件发生的顺序、某个键对应的值

在弄清楚这个问题之前，我们先了解一下什么是分布式的CAP定理。 根据百度百科的定义，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 (分区容错性): 即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。 分区容错性要求能够使应用虽然是一个分布式系统，而看上去却好像是在一个可以运转正常的整体

本人免费整理了Java高级资料，涵盖了Java、Redis、MongoDB、MySQL、Zookeeper、Spring Cloud、Dubbo高并发分布式等教程，一共30G，需要自己领取。 传送门： https://mp.weixin.qq.com/s/JzddfH-7yNudmkjT0IRL8Q 目录 一、分布式锁 数据库的唯一索引 Redis 的 SETNX 指令 Redis 的 RedLock 算法 Zookeeper 的有序节点 二、分布式事务 2PC 本地消息表 三、CAP 一致性 可用性 分区容忍性 权衡 四、BASE 基本可用 软状态 最终一致性 五、Paxos 执行过程 约束条件 六、Raft 单个 Candidate 的竞选 多个 Candidate 竞选 数据同步 一、分布式锁 在单机场景下，可以使用语言的内置锁来实现进程同步。但是在分布式场景下，需要同步的进程可能位于不同的节点上，那么就需要使用分布式锁。 阻塞锁通常使用互斥量来实现： 互斥量为 0 表示有其它进程在使用锁，此时处于锁定状态； 互斥量为 1 表示未锁定状态。 1 和 0 可以用一个整型值表示，也可以用某个数据是否存在表示。 数据库的唯一索引 获得锁时向表中插入一条记录，释放锁时删除这条记录。唯一索引可以保证该记录只被插入一次，那么就可以用这个记录是否存在来判断是否存于锁定状态。

BASE理论 : BASE理论是对CAP理论的延伸，核心思想是即使无法做到强一致性（Strong Consistency，CAP的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性（Eventual Consitency）。 BASE是指基本可用（Basically Available）、软状态（ Soft State）、最终一致性（ Eventual Consistency）。 基本可用（Basically Available）: 基本可用是指分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用。 软状态（ Soft State）: 软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据至少会有三个副本，允许不同节点间副本同步的延时就是软状态的体现。mysql replication的异步复制也是一种体现。 最终一致性（ Eventual Consistency）: 最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。 BASE思想的主要实现有 1.按功能划分数据库 2.sharding碎片 BASE思想主要强调基本的可用性，如果你需要High 可用性，也就是纯粹的高性能，那么就要以一致性或容错性为牺牲。 来源： oschina 链接：

2PC和3PC 2PC(Two-Phare Commit) 阶段一：提交事务请求 　　1 - 事务询问 协调者像所有参与者发送事务内容，询问是否可以执行事务提交操作，并开始等待各参与者的响应。 　　2 - 执行事务 各参与者执行事务，并记录Undo和Redo信息（Undo和Redo是数据库用来commit和rollback的记录文件） 　　3 - 各参与者向协调者反馈事务询问的响应 如果参与者事务执行成功，则返回给协调者yes，否则返回给协调者no 阶段二：执行事务提交 　　1 - 执行事务提交（所有的参与者均返回yes） 　　　　1 - 发送提交请求 协调者向所有参与者发送提交请求 　　　　2 - 事务提交 参与者接收到协调者发出的请求后，完成自己的事务提交，并在提交完成后释放这个事务执行期间占据的资源 　　　　3 - 反馈事务提交结果 参与者在完成事务后，像协调者发送Ack消息 　　　　4 - 完成事务 协调者接收到所有参与者返回的Ack消息，完成整个分布式事务 　　2 - 执行事务回滚（非所有参与者均返回yes） 　　　　1 - 发送回滚请求 协调者向所有参与者发送rollback请求 　　　　2 - 事务回滚 参与者接收到协调者发出的请求后，完成自己的事务回滚，并在提交完成后释放这个事务执行期间占据的资源 　　　　3 - 反馈事务回滚结果 参与者在完成各自的事务回滚后

转：https://www.cnblogs.com/sujing/p/11006424.html 前两天发了工资，第一反应是想着要给远方的女朋友一点惊喜！于是打开了平安银行的APP给女朋友转点钱！填写上对方招商银行卡的卡号、开户名，一键转账！搞定！在我点击的那瞬间，就收到了app的账户变动的提醒，并且出现了图一所示的提示界面：“处理中，正在等待对方银行返回结果…”。嗯！毕竟是跨行转账嘛，等个几秒也正常！脑海开始浮现出女朋友收到转账后惊喜与感动的画面！       然而，一切并没有那么顺利，刚过一会儿，app却如图二所示的提示我“由于收款人户名不符”导致转账失败！！！       刚刚都已经从我卡里扣过钱了，现在却提示我转账失败，银行会不会把我的钱给吞了？转账失败的钱还能退换给我吗？正在我紧张、焦虑、坐立不安之时又收到一条app冲正的消息，刚刚转账失败的钱已经退还给我了，看来我多虑了……这也证明咱平安银行的app还是比较安全靠谱的！    为啥从我卡里扣钱那么迅速，而对方却要几秒才能到账？并且转账失败后，扣除的钱还能及时的返还到我的卡里？万一钱返还失败怎么办？又或者我转一次钱，对方却收到了两次转账的申请又该如何？带着这些问题，我脑海中浮现出“事务”二字！    在我们还在“牙牙学语”的时候，老师经常会通过转账的栗子来跟我们讲解事务，但跟这里场景不一样的是，老师讲的是本地事务