数据库一致性

本人免费整理了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 链接：

事务是MySQL等关系型数据库区别于NoSQL的重要方面，是保证数据一致性的重要手段。 本文将首先介绍 MySQL 事务相关的基础概念，然后介绍事务的ACID 特性，并分析其实现原理。 MySQL博大精深，文章疏漏之处在所难免，欢迎批评指正。 一、基础概念 事务（Transaction）是访问和更新数据库的程序执行单元；事务中可能包含一个或多个sql语句，这些语句要么都执行，要么都不执行。作为一个关系型数据库，MySQL支持事务，本文介绍基于MySQL5.6。 首先回顾一下MySQL事务的基础知识。 （1）. 逻辑架构和存储引擎 图片来源：https://blog.csdn.net/fuzhongmin05/article/details/70904190 如上图所示，MySQL服务器逻辑架构从上往下可以分为三层： （1）第一层：处理客户端连接、授权认证等。 （2）第二层：服务器层，负责查询语句的解析、优化、缓存以及内置函数的实现、存储过程等。 （3）第三层：存储引擎，负责MySQL中数据的存储和提取。 MySQL 中服务器层不管理事务，事务是由存储引擎实现的。 MySQL支持事务的存储引擎有InnoDB、NDB Cluster等，其中InnoDB的使用最为广泛；其他存储引擎不支持事务，如MyIsam、Memory等。 如无特殊说明，后文中描述的内容都是基于InnoDB。 （2）.

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还是比较安全靠谱的！    为啥从我卡里扣钱那么迅速，而对方却要几秒才能到账？并且转账失败后，扣除的钱还能及时的返还到我的卡里？万一钱返还失败怎么办？又或者我转一次钱，对方却收到了两次转账的申请又该如何？带着这些问题，我脑海中浮现出“事务”二字！    在我们还在“牙牙学语”的时候，老师经常会通过转账的栗子来跟我们讲解事务，但跟这里场景不一样的是，老师讲的是本地事务

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

第一章 MySql存储引擎 1.Innodb存储引擎 支持事务，其特点是行锁设计、支持外键。 Innodb是Mysql默认的存储引擎。 2.MyISAM存储引擎 MyIsam存储引擎不支持事务和表锁设计，但是支持全文索引。 第五章 索引与算法 1.常见的索引：B+树索引、全文索引、哈希索引。 2.B+树，是通过二叉查找树，再由平衡二叉树，B树演化而来。 二叉查找树 二叉查找树：左子树的值总是小于根的值，右子树的值总是大于根的值。可以通过中序遍历得到值的排序输出。 平均查找速度比顺序查找来得快。 平衡二叉树(AVL树) 平衡二叉树：首先符合二叉查找树的定义，其次必须满足任何节点的两个子树的高度的最大差为1。 B+树 B+树：是为磁盘或其他直接存取辅助设备设计的一种平衡树。 在B+树中，所有记录节点都是按键值对的大小顺序存放在同一层的叶子节点上，由各叶子节点指针进行连接。 优点 :B+树的高度一般都在2--4层。也就是查找某一键值的行记录时最多只需要2--4次IO就可以了。 B+树索引 B+树索引，分为聚集索引和辅助索引。 聚集索引和辅助索引的区别：叶子节点存放的是否是一整行的信息。 聚集索引 聚集索引：就是按照每张表的主键构造一颗B+树，同时叶子节点存放的即为整张表的行记录数据，也将聚集索引的叶子节点称为数据页。 辅助索引 辅助索引：叶子节点并不包含行记录的全部数据

session 内存 tomcat创建。 session和cookie是一对一，cookie会保存sessionId-->>>JsessionId 分布式下session一致性问题解决方案 方案1 基于ngnix的ip_hash策略来做负载均衡 原理 根据ip做hash计算，同一个ip的请求始终会定位到同一台tomcat 缺点:如果一台tomcat宕机，就会出现用户session的缺失。 方案2 基于服务器session复制 原理: tomcat服务器创建session后，会通过组播方式把session发送到组播地址中的其他服务器上 优点:侵入式较少 需要配置web.xml 分布式。session备份、 缺点 延迟 受限内存资源。高流量 带宽占用较大、不灵活 方案3 Session集中统一管理 原理 session不由tomcat管理，而是统一放到一个地方集中式管理，读取和写入session都依赖第三方软件 例如 redis mongodb mysql等等 优点:大型分布式环境首选方案。 spring 如果做到session集中管理 HttpSession是一个接口 --Servlet容器会实现HttpSession接口 给出实现(TomCat有一个Session容器) Spring Session本质:覆盖原有tomcat容器的HttpSession实现 Spring

本文由 宜信-高级架构师-梁鑫投稿， 之前在社区分享过两篇文章，分别介绍了一下在公司项目中搭建springcloud框架的经验和我们自己研发的几个微服务组件。在这个过程中，我们还需要解决微服务架构中特别需要注意的一个问题————session一致性。在此，抱着学习的态度把我的解决方案跟大家再次分享一下。 一.背景.绕不开的session一致性 采用微服务架构以后，把原先单一的节点拆解成了多个微服务节点。在采用微服务架构之前，我们的项目普遍采用的都是分布式集群架构，多数的公司项目都采用IP哈希的方式进行session的跟踪，这样做非常简单，只需要在nginx简单配置即可，但我们采用springcloud微服务架构之后，session一致性保持就成了我们必须要解决的问题。 二.Session一致性的常见方式 简单说一下session和session一致性。服务为访问他的用户构造了一组信息，称之为会话(session)，当该用户在限定时间内每次发起http访问时，服务端能自动感知到是该用户在发起访问，称之为会话保持(session一致性) 2.1、IP哈希 使用反向代理(nginx)，对用户的IP进行hash操作，确保唯一IP地址每次都访问一个相同的服务。 2.2、Session复制 把每个用户的session都同步复制到集群中的每一个服务节点，这样无论用户访问哪个服务节点

在说分布式事务之前，先回顾下事务的相关知识点。 事务 概念 事务指的是一系列数据库操作，它是保证数据库正确性的基本逻辑单元，拥有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，事务取消，操作废弃。 特性 事务是对数据库的一系列操作，是保证数据库正确性的基本逻辑单元