分布式一致性

分布式事务解决方案： 一. 基于XA协议的两阶段提交； 二.消息事务+最终一致性 所谓的消息事务就是基于消息中间件的两阶段提交，本质上是对消息中间件的一种特殊利用，它是将本地事务和发消息放在了一个分布式事务里，保证要么本地操作成功成功并且对外发消息成功，要么两者都失败。 开源的RocketMQ就支持这一特性.该方案采用最终一致的，牺牲了一致性，换来了性能的大幅度提升。存在造成数据不一致的风险。 来源： https://www.cnblogs.com/ZJOE80/p/12181728.html

之前的讲解，主要是在讲解redis如何支撑海量数据、高并发读写、高可用服务的架构 从这一讲开始，正式开始做业务系统的开发 商品详情页，缓存架构，90%是大量的业务（没有什么级数含量），10%最有级数含量的就是架构 1、上亿流量的商品详情页的多级缓存架构 采用三级缓存：nginx本地缓存+redis分布式缓存+tomcat 堆缓存的多级缓存架构 　　　　　　　　　　nginx 本地缓存 redis分布式缓存 tomcat web应用 堆缓存 实时性要求非常高的数据：库存（希望当库存变化的时候，尽可能更快将库存显示到页面上去，而不是等了很长时间，库存才反应到页面上去） 实时性要求不高的数据：商品的基本信息（名称、颜色、版本、规格参数、等等） 对于实时性较高的数据来说，采用MYSQL和redis缓存双写的方案，这样缓存的时效性最高 nginx+lua脚本 lua脚本作为代码，部署到nginx本地，做第一层的业务逻辑 2、多级缓存架构中每一层的意义 1）nginx本地缓存，扛的是热数据的高并发访问，大量的热数据的访问，即经常会访问的那些数据，就会被保留在nginx本地缓存内。 2）redis分布式缓存，扛的是很高的离散访问，支撑海量的数据，高并发的访问，高可用的服务 3）tomcat 堆缓存主要是扛redis大规模灾难的 3、最经典的缓存+数据库读写的模式：cache aside

分布式系统当中有一个著名的 CAP 理论，它也是分布式系统理论的基础。 CAP理论最早发表于2000年，由加州伯克利的教授首先在ACM PODC会议上提出猜想，两年之后，被麻省理工学院的教授Seth Gilbert和Nancy Lynch从理论上证明。从此之后，它成了分布式系统领域的公认定理。 今天这篇文章就和大家聊聊这个大名鼎鼎的CAP理论。 CAP理论描述起来其实很简单，它说的是 一个分布式系统最多只能满足C（一致性）、A（可用性）和P（分区性）这三者当中的两个 。我们先来看一下这三项分别代表了什么。 Consistency 一致性 分布式系统当中的一致性指的是 所有节点的数据一致 ，或者说是 所有副本的数据一致 。用英文描述是： All the nodes see the same data at the same time 。它和数据库事务中的一致性是两码事，在我们之前的文章里，曾经详细描述过分布式系统中的各种一致性模型，感兴趣的同学可以点击这里。 我们可以将一致性一分为二，分别从 客户端和服务端 进行探究。对于客户端而言，并不关心后端的实现，也不关心后端的节点运行情况。唯一只关心 多次并发访问下都能获得准确的符合预期的结果 。比如用户多次点击付款，也只会付款一次，余额无论什么时候查询都是当下最新的值。 而服务端关心的是会引发数据变更的请求过来，

分布式场景下，缓存与数据库的一致性是必须要绕过去的一道坎。而强一致性同步成本太高，如果追求强一致，那么没必要用缓存了，直接用mysql即可。通常考虑的，都是最终一致性。我们要做的，就是把这个最终一致性的时间降到最低。 从理论上来说，给缓存设置过期时间，是保证最终一致性的解决方案。这种方案下，我们可以对存入缓存的数据设置过期时间，所有的写操作以数据库为准，对缓存操作只是尽最大努力即可。也就是说如果数据库写成功，缓存更新失败，那么只要到达过期时间，则后面的读请求自然会从数据库中读取新值然后回填缓存。 方案一：先同步数据库，再删除缓存。 失效：应用程序先从cache取数据，没有得到，则从数据库中取数据，成功后，放到缓存中。 命中：应用程序从cache中取数据，取到后返回。 更新：先把数据存到数据库中，成功后，再让缓存失效。 看看更新操作有没有问题。 如果数据库同步成功，缓存操作失败，则让事务回滚，最终还是一致的。 如果数据库同步失败， 缓存也不会再被操作，数据是一致的。 方案二：监听binlog日志 监听binlog日志，当监听到的数据变化时，让缓存失效或更新。 实现方法：业务服务，同步数据完成后，删除缓存。定义好缓存类与数据库表的映射关系，并定义为缓存同步类型，当监听到某一表变化时，调用该同步类型对应的实现类，把数据同步到redis中。 监听biglog的工具： （1）mysql

本文转载自《金融电子化》 作者： 吉林省农村信用社联合社信息科技中心 总经理 孙刚、总经理助理 程永义 随着移动互联网的迅猛发展，分布式架构在互联网IT技术领域广泛应用并积累了大量实践经验。在互联网金融快速发展和利率市场化的大环境下，建设能够支持海量客户、具有弹性扩展能力、高效灵活的分布式架构应用系统已成为国内金融行业迫切的需要。 分布式数据库应用大势所趋 我社普惠金融平台建设，旨在“充分运用金融科技手段，优化信贷流程和客户评价模型，降低企业融资成本，纾解民营企业、小微企业融资难融资贵问题，增强金融服务实体经济能力”。 普惠金融服务是典型的互联网应用，其与传统信贷系统不同，具有互联网场景接入能力，如果沿用集中式的技术架构，在应对海量客户的互联网应用场景和总拥有成本等方面存在以下的潜在问题： 集中式架构普遍缺乏弹性伸缩的能力。随着交易量和数据量的增长，系统整体吞吐量会遇到硬件或技术的瓶颈。尤其在支持面向互联网客户相关业务时，不能有效处理瞬时爆发的高并发交易，制约了客户获取以及大规模业务营销。 集中式架构采用单体应用设计。软件开发和运行管理的最小单元是应用，管理力度较粗，容易“牵一发而动全身”，应用的开发过程不易践行轻量化敏捷开发理念，系统在运行过程中容易出现单点故障，难以有效进行故障隔离。 集中式架构系统的基础设施通常使用高端服务器和存储设备，以及传统关系型数据库

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 本文转载自《金融电子化》 作者： 吉林省农村信用社联合社信息科技中心 总经理 孙刚、总经理助理 程永义 随着移动互联网的迅猛发展，分布式架构在互联网IT技术领域广泛应用并积累了大量实践经验。在互联网金融快速发展和利率市场化的大环境下，建设能够支持海量客户、具有弹性扩展能力、高效灵活的分布式架构应用系统已成为国内金融行业迫切的需要。 分布式数据库应用大势所趋 我社普惠金融平台建设，旨在“充分运用金融科技手段，优化信贷流程和客户评价模型，降低企业融资成本，纾解民营企业、小微企业融资难融资贵问题，增强金融服务实体经济能力”。 普惠金融服务是典型的互联网应用，其与传统信贷系统不同，具有互联网场景接入能力，如果沿用集中式的技术架构，在应对海量客户的互联网应用场景和总拥有成本等方面存在以下的潜在问题： 集中式架构普遍缺乏弹性伸缩的能力。随着交易量和数据量的增长，系统整体吞吐量会遇到硬件或技术的瓶颈。尤其在支持面向互联网客户相关业务时，不能有效处理瞬时爆发的高并发交易，制约了客户获取以及大规模业务营销。 集中式架构采用单体应用设计。软件开发和运行管理的最小单元是应用，管理力度较粗，容易“牵一发而动全身”，应用的开发过程不易践行轻量化敏捷开发理念，系统在运行过程中容易出现单点故障，难以有效进行故障隔离。

NoSQL简史及定义 NoSQL 这个术语最早是在 1998 年被 Carlo Strozzi 命名在他的轻量的，开源的关系型数据库上的，但是该数据库没有提供标准的 SQL 接口； 在 2009 年再次被 Eric Evans 提起，讨论分布式开源数据库的问题，这是的 NoSQL 主要指的非关系型，分布式的，不提供关系型的 atomicity(A) ， consistency(C) ， isolation(I) ， durability(D) 即 ACID 的特性； 紧接着 2009 年在亚特兰大举行的 no:sql 讨论会是一个里程碑，当时的口号是 select fun, profit from real_world where relational=false ，因此之后对于 NoSQL 最普遍的解释为 非关系型的 ，强调 Key-Value 和 Document(文档) 数据库的优点，并非单纯的反对关系型数据库； 下面给 NoSQL 下一个定义，如果你在网上查阅资料会得到很多种定义，大家的理解不尽相同，我这里引用 http://nosql-database.org/ 网站上的定义： 下一代，主要解决以下几点：非关系数据库、分布式数据库、开源数据库和水平扩展数据库 原文信息：Next Generation Databases mostly addressing some of

前言 本文旨在讲述如何使用 Java 语言实现基于 Raft 算法的，分布式的，KV 结构的存储项目。该项目的背景是为了深入理解 Raft 算法，从而深刻理解分布式环境下数据强一致性该如何实现；该项目的目标是：在复杂的分布式环境中，多个存储节点能够保证数据强一致性。 项目地址：https://github.com/stateIs0/lu-raft-kv 欢迎 star ：） 什么是 Java 版 Raft 分布式 KV 存储 Raft 算法大部分人都已经了解，也有很多实现，从 GitHub 上来看，似乎 Golang 语言实现的较多，比较有名的，例如 etcd。而 Java 版本的，在生产环境大规模使用的实现则较少； 同时，他们的设计目标大部分都是命名服务，即服务注册发现，也就是说，他们通常都是基于 AP 实现，就像 DNS，DNS 是一个命名服务，同时也不是一个强一致性的服务。 比较不同的是 Zookeeper，ZK 常被大家用来做命名服务，但他更多的是一个分布式服务协调者。 而上面的这些都不是存储服务，虽然也都可以做一些存储工作。甚至像 kafka，可以利用 ZK 实现分布式存储。 回到我们这边。 此次我们语言部分使用 Java，RPC 网络通信框架使用的是蚂蚁金服 SOFA-Bolt，底层 KV 存储使用的是 RocksDB，其中核心的 Raft 则由我们自己实现

原文作者：VectorJin https://juejin.im/post/5e066c9ff265da33b0718f89 1. 本地事务 　　事务Transaction由一组SQL组成，具有四个ACID特性 1.1 ACID Atomicity 原子性 构成事务的一组SQL，要么全部生效，要么全不生效，不会出现部分生效的情况 Consistency 一致性 数据库经过事务操作后从一种状态转变为另一个状态。可以说原子性是从行为上描述，而一致性是从结果上描述 isolation 隔离性 事务操作的数据对象 相对于 其他事务操作的数据对象相互隔离，互不影响 durability 持久性 事务提交后，其结果就是永久性的，即使发生宕机（非磁盘损坏） 1.2 事务实现 　　对于MySQL数据库（InnoDB存储引擎）而言，隔离性是通过不同粒度的锁机制来实现事务间的隔离；原子性、一致性和持久性通过redo log 重做日志和undo log回滚日志来保证的。 　　 redo log： 当数据库对数据做修改的时候，需要把数据页从磁盘读到buffer pool中，然后在buffer pool中进行修改，那么这个时候buffer pool中的数据页就与磁盘上的数据页内容不一致，称buffer pool的数据页为dirty page 脏数据，如果这个时候发生非正常的DB服务重启

前置知识 事务: 事务提供一种机制将一个活动涉及的所有操作纳入到一个不可分割的执行单元，组成事务的所有操作只有在所有操作均能正常执行的情况下方能提交，只要其中任意一个执行失败，将导致整个事务的回滚。简单来说就是提供一种”要么什么都不做，要不全都做“的机制。 本地事务: 当事务是由资源管理器本地管理时被称为本地事务。本地事务的有点是支持严格的 ACID 特性，高效，可靠，状态可以只在资源管理器中维护，而且应用编程模型简单。但是本地事务不具备分布式事务的处理能力，隔离的最小单位受限于资源管理器。MySql 的 InnoDB 通过日志（Redo 和 Undo）和锁来保证事务。 全局事务: 当事务由全局事务管理器进行全局管理时成为全局事务，事务管理器负责管理全局事务状态和参与的资源，协同资源的一直提交回滚。 刚性事务和柔性事务 刚性事务：遵循 ACID 原则，强一致性，典型的例子就是数据库事务。 柔性事务：尊循 BASE 理论，最终一致性，允许在一定时间内，不同节点的数据不一致，但要求最终一致性。 分布式知识 CAP 分布式系统在设计时只能在一致性，可用性和分区容错性中满足两种，无法兼顾三种。 C： 在分布式环境中，一致性是指数据在多个副本之间是否能够保持一致的特性。在一致性的要求下，当一个系统在数据一致的状态下执行更新操作后，应该保证系统的数据仍然处于一致的状态。 A：