分布式事务

http://mp.weixin.qq.com/s?__biz=MzA5Nzc4OTA1Mw==&mid=2659598134&idx=1&sn=f5f73354d162a7561b3d73c204a4d1f5&scene=0#wechat_redirect http://www.tuicool.com/articles/MzA7juE http://www.infoq.com/cn/articles/solution-of-distributed-system-transaction-consistency 来源： oschina 链接： https://my.oschina.net/u/1382024/blog/755937

转载自 https://www.cnblogs.com/wetest/p/6806506.html 和 https://www.cnblogs.com/dudu0614/p/8821811.html 什么是分布式系统 分布式这一概念，一直都是后端工程师绕不过去的一个坎，今天，我们就一起来看看到底什么是分布式系统，又有哪些分布式技术世我们需要学习的。 根据百度百科的介绍，分布式系统（distributed system）是建立在网络之上的软件系统。正是因为软件的特性，所以分布式系统具有高度的内聚性和透明性。因此，网络和分布式系统之间的区别更多的在于高层软件（特别是操作系统），而不是硬件。 从分布式系统的诞生说起 我们常常会听说，某个互联网应用的服务器端系统多么牛逼，比如QQ、微信、淘宝。那么，一个互联网应用的服务器端系统，到底牛逼在什么地方？为什么海量的用户访问，会让一个服务器端系统变得更复杂？本文就是想从最基本的地方开始，探寻服务器端系统技术的基础概念。 承载量是分布式系统存在的原因 当一个互联网业务获得大众欢迎的时候，最显著碰到的技术问题，就是服务器非常繁忙。当每天有1000万个用户访问你的网站时，无论你使用什么样的服务器硬件，都不可能只用一台机器就承载的了。因此，在互联网程序员解决服务器端问题的时候，必须要考虑如何使用多台服务器，为同一种互联网应用提供服务，这就是所谓

作者：翟飞 在分布式系统中，为了保证数据的高可用，通常，我们会将数据保留多个副本(replica)，这些副本会放置在不同的物理的机器上。为了对用户提供正确的 CRUD 等语义，我们需要保证这些放置在不同物理机器上的副本是一致的。分布式事务在现在遍地都是分布式部署的系统中几乎是必要的。 我们先聊一下啥是事务？ 分布式事务、事务隔离级别、ACID我相信大家这些东西都耳熟能详了，那什么是事务呢？ 概念： 一般是指要做的或所做的事情。 指作为单个逻辑工作单元执行的一系列操作，要么全部执行，要么全部不执行。 简单的说，事务就是并发控制的单位，是用户定义的一个操作序列。 特性： 事务是恢复和并发控制的基本单位。 事务应该具有4个属性：原子性、一致性、隔离性、持久性。这四个属性通常称为ACID特性。 原子性（atomicity）：一个事务是一个不可分割的工作单位，事务中包括的操作要么都做，要么都不做。 一致性（consistency）：事务必须是使数据库从一个一致性状态变到另一个一致性状态。一致性与原子性是密切相关的。 隔离性（isolation）：一个事务的执行不能被其他事务干扰。即一个事务内部的操作及使用的数据对并发的其他事务是隔离的，并发执行的各个事务之间不能互相干扰。 持久性（durability）：持久性也称永久性（permanence），指一个事务一旦提交

今天我们用10分钟，重点梳理一遍以下几方面： 数据库知识点汇总； 数据库事务特性和隔离级别； 详解关系型数据库、索引与锁机制； 数据库调优与最佳实践； 面试考察点及加分项。 一、数据库的不同类型 1.常用的关系型数据库 Oracle：功能强大，主要缺点就是贵 MySQL：互联网行业中最流行的数据库，这不仅仅是因为MySQL的免费。可以说关系数据库场景中你需要的功能，MySQL都能很好的满足，后面详解部分会详细介绍MySQL的一些知识点 MariaDB：是MySQL的分支，由开源社区维护，MariaDB虽然被看作MySQL的替代品，但它在扩展功能、存储引擎上都有非常好的改进 PostgreSQL：也叫PGSQL，PGSQL类似于Oracle的多进程框架，可以支持高并发的应用场景，PG几乎支持所有的SQL标准，支持类型相当丰富。PG更加适合严格的企业应用场景，而MySQL更适合业务逻辑相对简单、数据可靠性要求较低的互联网场景。 2.NoSQL数据库（非关系型数据库） Redis：提供了持久化能力，支持多种数据类型。Redis适用于数据变化快且数据大小可预测的场景。 MongoDB：一个基于分布式文件存储的数据库，将数据存储为一个文档，数据结构由键值对组成。MongoDB比较适合表结构不明确，且数据结构可能不断变化的场景，不适合有事务和复杂查询的场景。 HBase：建立在HDFS

Dubbo-大波-服务化框架 dubbo_百度搜索 Dubbo与Zookeeper、SpringMVC整合和使用（负载均衡、容错） - 好库文摘 User Guide-zh - Dubbo - Alibaba Open Sesame User Guide-zh - Dubbo - Alibaba Open Sesame 简单之美 | Dubbo架构设计详解 DUBBO Hprose RPC框架 java rpc_百度搜索 谁能用通俗的语言解释一下什么是 RPC 框架？ - 知乎 Java程序员的现代RPC指南 - 西代零零发 - 博客频道 - CSDN.NET Hprose_百度搜索 Hprose Hprose Home Hprose首页、文档和下载 - 高性能跨语言 RPC - 开源中国社区 项目 - 码云 - 开源中国 hprose/hprose-doc: Hprose 文档汇总 hprose_百度百科 thrift 和 Hprose有什么区别吗?_百度知道 hprose具体用途案例是什么，看到这个东西但是想不出来具体应用实例和优势？ - 知乎 Hprose使用经历 - xiang_quan123的专栏 - 博客频道 - CSDN.NET Hprose 2.0.0 for HTML5 发布，高性能跨语言RPC - 开源中国社区 为什么采用hprosehttpclient

分布式事务 1.什么是事务 　　事务是用于访问和修改各种数据项的一个程序单位，这个程序要么全部执行，要么全部放弃。 2.为什么会引入事务的概念 　　针对于数据库来说，对数据文件的记录进行访问或修改，对这些数据项的修改封装起来来保证对数据项的访问或修改的原子性、一致性、隔离性、持久性。 3.事务的属性 　　（1）原子性：所有的工作要么在数据库中保存下来，要么全部回滚，全部不保留； 　　（2）一致性：事务完成或者撤销之后应该处于一致的状态； 　　（3）隔离性：多个事务同时进行互相互不干扰； 　　（4）持久性：事务提交后，所做的工作就被永久的保存下来。 4.事务的实现 　　（1）私有工作空间与影子更新 　　当进程启动事务T时，分配一个私有工作空间W，在提交或终止T前所有的读写操作都是在W中进行。 　　 　　在（a）中，在对某文件进行访问时，共有三个数据块，在磁盘中对应于盘块0,、盘块1、盘块2，（b）当进程启动该事务时，便分配给它一个私有工作空间，如果我们现在要对盘块0和盘块3进行修改操作，那么就会在相应的0'和3’中进行，所有对文件的访问都是在私有工作空间进行的，在事务提交之前，对文件没有产生影响，访问的索引节点还是起初的索引节点，（c）在事务提交之后，那么影子块就会变成真正的盘块，私有工作空间的索引节点替代起初的索引节点。 　　（2）先写日志（WAL） 　　日志能够记录事务标识

https://www.cnblogs.com/soundcode/p/5590710.html 编者按：本文由「高可用架构后花园」群讨论整理而成。 有人的地方，就有江湖 有江湖的地方，就有纷争 问题的起源 在电商等业务中，系统一般由多个独立的服务组成，如何解决分布式调用时候数据的一致性？ 具体业务场景如下，比如一个业务操作，如果同时调用服务 A、B、C，需要满足要么同时成功；要么同时失败。A、B、C 可能是多个不同部门开发、部署在不同服务器上的远程服务。 在分布式系统来说，如果不想牺牲一致性，CAP 理论告诉我们只能放弃可用性，这显然不能接受。为了便于讨论问题，先简单介绍下数据一致性的基础理论。 强一致 当更新操作完成之后，任何多个后续进程或者线程的访问都会返回最新的更新过的值。这种是对用户最友好的，就是用户上一次写什么，下一次就保证能读到什么。根据 CAP 理论，这种实现需要牺牲可用性。 弱一致性 系统并不保证续进程或者线程的访问都会返回最新的更新过的值。系统在数据写入成功之后，不承诺立即可以读到最新写入的值，也不会具体的承诺多久之后可以读到。 最终一致性 弱一致性的特定形式。系统保证在没有后续更新的前提下，系统 最终 返回上一次更新操作的值。在没有故障发生的前提下，不一致窗口的时间主要受通信延迟，系统负载和复制副本的个数影响。DNS 是一个典型的最终一致性系统。 在工程实践上

数据库存储引擎是数据库底层软件组织，数据库管理系统（DBMS）使用数据引擎进行创建、查询、更新和删除数据。不同的存储引擎提供不同的存储机制、索引技巧、锁定水平等功能，使用不同的存储引擎，还可以 获得特定的功能。现在许多不同的数据库管理系统都支持多种不同的数据引擎。MySql的核心就是存储引擎。 存储引擎查看 MySQL给开发者提供了查询存储引擎的功能，我这里使用的是MySQL5.1，可以使用： SHOW ENGINES 命令来查看MySQL使用的引擎，命令的输出为（我用的Navicat Premium）： 看到MySQL给用户提供了这么多存储引擎，包括处理事务安全表的引擎和出来了非事物安全表的引擎。 如果要想查看数据库默认使用哪个引擎，可以通过使用命令： SHOW VARIABLES LIKE 'storage_engine'; 来查看，查询结果为： 在MySQL中，不需要在整个服务器中使用同一种存储引擎，针对具体的要求，可以对每一个表使用不同的存储引擎。Support列的值表示某种引擎是否能使用：YES表示可以使用、NO表示不能使用、DEFAULT表示该引擎为当前默认的存储引擎 。下面来看一下其中几种常用的引擎。 ========================以上是转载的http://blog.csdn.net/zhangyuan19880606/article/details

99% 的人都能看懂的「补偿」以及最佳实践 也许你对降级已经有了一些认识，这次，我们来聊一聊在保证对外高可用的同时，憋出的“内伤”该如何通过「补偿」机制来自行消化。 「补偿」机制的意义 以电商的购物场景为例： 客户端 ----> 购物车微服务 ----> 订单微服务 ----> 支付微服务。 这种调用链非常普遍。 那么为什么需要考虑补偿机制呢？ 正如之前几篇文章所说，一次跨机器的通信可能会经过 DNS 服务，网卡、交换机、路由器、负载均衡等设备，这些设备都不一定是一直稳定的，在数据传输的整个过程中，只要任意一个环节出错，都会导致问题的产生。 而在分布式场景中，一个完整的业务又是由多次跨机器通信组成的，所以产生问题的概率成倍数增加。 但是，这些问题并不完全代表真正的系统无法处理请求，所以我们应当尽可能的自动消化掉这些异常。 可能你会问，之前也看到过「补偿」和「事务补偿」或者「重试」，它们之间的关系是什么？ 你其实可以不用太纠结这些名字，从目的来说都是一样的。就是一旦某个操作发生了异常，如何通过内部机制将这个异常产生的「不一致」状态消除掉。 题外话：在笔者看来，不管用什么方式，只要通过额外的方式解决了问题都可以理解为是「补偿」，所以「事务补偿」和「重试」都是「补偿」的子集。前者是一个逆向操作，而后者则是一个正向操作。 只是从结果来看，两者的意义不同。「事务补偿」意味着“放弃”

分布式事务解决方案整理 1.2PC/3PC模式 1.1 介绍： 依赖资源管理器(mysql, redis)支持XA协议， 数据库充当RM角色，应用需要充当TM的角色，即生成全局的txId，调用XAResource接口，把多个本地事务协调为全局统一的分布式事务, 所有结点要么全做要么全不做。 1.2 特点: 需要依赖资源管理器RM(数据库)对XA的支持。 整个处理过程需要锁住事务资源，性能比较低。 场景一： 1）协调者节点向所有参与者节点发出”正式提交(commit)”的请求。 2）参与者节点正式完成操作，并释放在整个事务期间内占用的资源。 3）参与者节点向协调者节点发送”完成”消息。 4）协调者节点受到所有参与者节点反馈的”完成”消息后，完成事务。 场景二： 1）协调者节点向所有参与者节点发出”回滚操作(rollback)”的请求。 2）参与者节点利用之前写入的Undo信息执行回滚，并释放在整个事务期间内占用的资源。 3）参与者节点向协调者节点发送”回滚完成”消息。 4）协调者节点受到所有参与者节点反馈的”回滚完成”消息后，取消事务。 2. TCC模式 2.1介绍 2PC的另类实现，TCC事务机制相对于传统事务机制（X/Open XA Two-Phase-Commit），其特征在于它不依赖资源管理器(RM)对XA的支持，而是通过对业务逻辑的调度来实现分布式事务，