数据库一致性

The database remains in a consistent state at all times ― after each commit or rollback, and while transactions are in progress. If related data is being updated across multiple tables, queries see either all old values or all new values, not a mix of old and new values. 数据库始终保持一致状态 - 每次提交或回滚后，以及事务正在进行中。如果跨多个表更新相关数据，查询将查看所有旧值或所有新值，而不是旧值和新值的混合。 一致性侧重事务执行前后的状态(结果)。 来源：博客园 作者： 护花使者 链接：https://www.cnblogs.com/chenmz1995/p/11490651.html

分布式系统一致性问题解决实战 一、背景及问题描述 业务背景： 商户提交表单数据至旺铺（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(); 第一步有两种结果成功

根据百度百科的定义，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元。 那么发生退款时，需要保证两笔交易同时都退款。这个就是直接采用数据库本地事务实现的，即一次退款请求，两笔交易同时退款。 总结： 数据库事务的优点是简单

在整合Spring和Mybatis时控制台报错了，错误如下： Caused by: org.apache.ibatis.builder.BuilderException: Error parsing Mapper XML. Cause: java.lang.IllegalArgumentException: Result Maps collection already contains value for com.blog.dao.CategoryMapper.BaseResultMap 内容大概就是说CategoryMapper中有多个相同的ResultMap。 我就纳闷了，我用Mybatis逆工程插件的生成的文件，怎么会有错，于是我去看CategoryMapper.xml，结果---- 不仅有2个相同的ResultMaps，甚至连增删改查的sql语句都各有2段一毛一样的…… 什么鬼？这时，我突然想起在使用逆工程时我执行了2次，第一次失败了，然后修改后又执行了一次，就成功了。 我猜想这就是和数据库事务的原子性一致性一样，这逆工程是不讲究一致性（我猜的，不知道是不是，求指教），执行到一半时出错了，不会回滚，生成的那一半文件不会删除，等下次再重复执行时，就把相同的内容往之前成功生成的文件里追加，于是一个文件里就有2份一样的数据…… 解决方法： 找到对应的mapper文件

前两天发了工资，第一反应是想着要给远方的女朋友一点惊喜！于是打开了平安银行的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原子性: 一个事务的所有系列操作步骤被看成是一个动作，所有的步骤要么全部完成要么一个也不会完成

区块链系统是一个分布式系统，而分布式系统的首要问题是一致性的保障。 一致性 　　定义：一致性（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 (分区容错性): 即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。 分区容错性要求能够使应用虽然是一个分布式系统，而看上去却好像是在一个可以运转正常的整体