数据库一致性

NoSQL入门和概述目录导航： NoSQL入门概述 3V+3高 当下的NoSQL经典应用 NoSQL数据模型简介 NoSQL数据库的四大分类 在分布式数据库中CAP原理CAP+BASE NoSQL 入门概述 互联网时代背景下的大机遇，为什么用NoSQL 单机MySQL的美好年代 在90年代，一个网站的访问量一般都不大，用单个数据库完全可以轻松应付。在那个时候，更多的都是静态网页，动态交互类型的网站不多。 上述架构下，我们来看看数据存储的瓶颈是什么？ 数据量的总大小，一个机器放不下时 数据的索引（B+ Tree）一个机器的内存放不下时 访问量（读写混合）一个实例不能承受 如过满足了上述1 or 3个，需要进化... Memcached（缓存）+ MySQL + 垂直拆分 后来，随着访问量的上升，几乎大部分使用MySQL架构的网站在数据库上都开始出现了性能问题，web程序不再仅仅专注在功能上，同时也在追求性能。程序员们开始大量的使 用缓存技术来缓解数据库的压力，优化数据库的结构和索引。开始比较流行的是通过文件缓存来缓解数据库压力，但是当访问量继续增大的时候，多台web机器通过文件缓存不能 共享，大量的小文件缓存也带了了比较高的IO压力。在这个时候，Memcached就自然的成为一个非常时尚的技术产品。 Memcached作为一个独立的分布式的缓存服务器

　　 NoSql数据模型简介 　　聚合模型：KV键值，BSON 　　列族： 　　图形，这里的图形不是指真正的图形，而是关系图 　　 NoSql数据库的四大分类 　　KV键值：BerkeleyDB,Redis,tair,memcache 　　文档型数据库：couchDB,mongoDB 　　列存储数据库：Cassandra,HBase,分布式文件系统 　　图关系数据库：Neo4J,InfoGrid 　　对比： 　　 分布式数据库的CAP+BASE 　　传统的ACID：A(atom icity):原子性 C(Consistency):一致性 I(Isolation):独立性 D(Durability):持久性 　　CAP：C(Consistency)：强一致性；A(Availability)：可用性；P(Patition Tolerance)：分区容错性 　　 CAP3进2： 　　CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。 　　而由于当前的网络硬件肯定会出现延迟丢包等问题，所以 　　分区容忍性是我们必须需要实现的。 　　所以我们只能在一致性和可用性之间进行权衡，没有NoSQL系统能同时保证这三点。 ======================================================================================

入门概述： 1.为什么要用到NoSQL 　　a) 单机MySQL的美好年代，在90年代，一个网站的访问量一般都不大，用单个数据库完全可以轻松应付。在那个时候，更多的都是静态网页，动态交互类型的网站不多。 　　上述架构下，我们来看看数据存储的瓶颈是什么？ 　　1.数据量的总大小 一个机器放不下时 　　2.数据的索引（B+ Tree）一个机器的内存放不下时 　　3.访问量(读写混合)一个实例不能承受 　　 如果满足了上述1 or 3个，进化...... 　　b) Memcached(缓存)+MySQL+垂直拆分，后来，随着访问量的上升，几乎大部分使用MySQL架构的网站在数据库上都开始出现了性能问题，web程序不再仅仅专注在功能上，同时也在追求性能。程序员们开始大量的使用缓存技术来缓解数据库的压力，优化数据库的结构和索引。开始比较流行的是通过文件缓存来缓解数据库压力，但是当访问量继续增大的时候，多台web机器通过文件缓存不能共享，大量的小文件缓存也带了了比较高的IO压力。在这个时候，Memcached就自然的成为一个非常时尚的技术产品。 　　 Memcached作为一个独立的分布式的缓存服务器，为多个web服务器提供了一个共享的高性能缓存服务，在Memcached服务器上，又发展了根据hash算法来进行多台Memcached缓存服务的扩展

原文网址：http://geek.csdn.net/news/detail/97879 【 摘要 】本文谈及一些分布式系统的理论和思想，包括 CAP、BASE、NWR 等。并简单分析一些主流数据库分布式方案的利弊，以便我们在开发时更深入全面地进行思考、选择和设计。以下为正文： 在讨论常见架构前，先简单了解下 CAP 理论： CAP是Consistency、Availablity和Partition-tolerance的缩写。分别指： 一致性（Consistency）：每次读操作都能保证返回的是最新数据； 可用性（Availablity）：任何一个没有发生故障的节点，会在合理的时间内返回一个正常的结果； 分区容忍性（Partition-tolerance）：当节点间出现网络分区，照样可以提供服务。 CAP理论指出：CAP三者只能取其二，不可兼得。其实这一点很好理解： 首先，单机系统都只能保证CP； 有两个或以上节点时，当网络分区发生时，集群中两个节点不能互相通信。此时如果保证数据的一致性C，那么必然会有一个节点被标记为不可用的状态，违反了可用性A的要求，只能保证CP； 反之，如果保证可用性A，即两个节点可以继续各自处理请求，那么由于网络不通不能同步数据，必然又会导致数据的不一致，只能保证AP。 一、单实例 单机系统很显然，只能保证CP，牺牲了可用性A。单机版的MySQL、Redis

hbase 是 nosql的一种。nosql的话，不需要sql作为查询语言，也不需要固定的表模式（table schema），也不怎么有sql的join操作，一般都能水平扩展，放宽ACID属性（因为CAP定理）。Hbase是C+P类型的，强一致性（仅支持单行事务）。最常见的应用场景还是采集的网页数据的存储，日志信息的存储，不需要完全结构化的应用。hbase 是 OLTP应用为主。 hive不一样，针对OLAP应用，底层不是hbase（支持么？），而是hdfs。存储靠hdfs，所以所谓的hive表，就是纯逻辑表，只是表的定义，即表的元数据。hive告诉机器，如何将数据文件解析，然后结构化为一张数据库表，并提供sql查询。hive一般用于查询分析统计，而不是其他的CUD操作，他去做增量实时同步相当困难。 hive是基于MR处理数据，MR是基于行的处理，hbase是基于列的处理，适合大数据的随机访问。hbase的表是稀疏的存储，用户可以给行定义各种不同的列，而hive是稠密的，定义了多少列，那么每一行都有存储固定列数的数据。hive因为是MR，所以数据处理不能低延迟，而hbase支持实时查询。hive不提供 row-level的更新，他适合的是 append-only的数据批处理，比如日志。而hbase，支持row-level的更新。hql是完整的sql实现，分析历史数据绝佳

什么场景下会产生分布式事务？ 在支付异步回调的情况下，支付宝发送http请求给第三方平台，第三方平台需要更改支付状态以及订单状态，在此场景下，第三方平台更改本地支付数据库的支付状态后，通知订单服务更改订单的状态，在此程序后，如果代码出现异常，由于有声明式事务的存在，本地支付服务的数据库会进行回滚，变成未支付状态，但是订单服务的状态却无法回滚，订单服务的订单的状态变成已支付状态，这就出现了订单数据库和支付数据库数据不一致的情况，这便是分布式事务产生的场景之一。 什么是分布式事务？ 分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。以上是百度百科的解释，简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。 分布式事务的理论 1、cap理论 1）数据一致性（consistency） 如果系统对一个写操作返回成功，那么之后的读请求都必须读到这个新数据；如果返回失败，那么所有读操作都不能读到这个数据，对调用者而言数据具有强一致性(strong consistency) (又叫原子性 atomic、线性一致性 linearizable consistency) 一致性指

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 本系列七篇文章列表如下： 微服务实战（一）：微服务架构的优势与不足 微服务实战（二）：使用API Gateway 微服务实战（三）：深入微服务架构的进程间通信 微服务实战（四）：服务发现的可行方案以及实践案例 微服务实践（五）：微服务的事件驱动数据管理 微服务实践（六）：选择微服务部署策略 微服务实践（七）：从单体式架构迁移到微服务架构 【编者的话】本文是使用微服务创建应用系列的第五篇文章。第一篇文章介绍了微服务架构模式，并且讨论了使用微服务的优缺点；第二和第三篇描述了微服务架构模块间通讯的不同方面；第四篇研究了服务发现中的问题。本篇中，我们从另外一个角度研究一下微服务架构带来的分布式数据管理问题。 1.1 微服务和分布式数据管理问题 单体式应用一般都会有一个关系型数据库，由此带来的好处是应用可以使用 ACID transactions，可以带来一些重要的操作特性： 原子性 – 任何改变都是原子性的 一致性 – 数据库状态一直是一致性的 隔离性 – 即使交易并发执行，看起来也是串行的 Durable – 一旦交易提交了就不可回滚 鉴于以上特性，应用可以简化为：开始一个交易，改变（插入，删除，更新）很多行，然后提交这些交易。 使用关系型数据库带来另外一个优势在于提供SQL（功能强大，可声明的，表转化的查询语言

前言 随着大型网站的各种高斌发访问、海量数据处理等场景越来越多，如何实现网站的高可用、易伸缩、可扩展、安全等目标就显得越来越重要。为了解决这样一系列问题。大型网站的架构也在不断发展。提高大型网站的高可用架构，就不得不提 分布式系统（Distributed Systems） 。下面说一下分布式系统及其相关的概念 在学习分布式系统之前，先了解一下与之相对应的集中式系统是什么样的。 集中式系统 集中式系统，主要指IBM、HP一个主机带多个终端。终端没有数据处理能力，仅负责数据的录入和输出。而运算、存储等全部在主机上进行，也就是我们平常说的单机服务器。 集中式系统的最大特点就是不熟结构非常简单，底层一般采用IBM、HP等厂商购买的昂贵的大型主机。因此无需要考虑如何对服务进行多节点的部署，也就不用考虑各节点的分布式协作问题。但是，由于采用单机部署、和可能带来系统大而复杂、难于维护、发生单点故障（单个点发生故障的时候会波及到整个系统或者网络，从而导致整个系统或者网络的瘫痪）、扩展性差等问题。 说完集中式系统，再来说一个与分布式很相似的概念-集群 集群 集群是一组独立的计算机系统构成一个松耦合的多处理器系统，它们之间通过网络实现进程间的通信。用来提供比集中式系统更具扩展性与可用性的服务平台。集群有两个关键的特性： 可扩展性，集群的性能不限于单一的服务实体，新的服务实体可以动态地添加到集群

一、前言 　　 在大数据系统中，分布式系统已经成为一个无法避免的组件，如zookeeper已经成为了工业届的标准。所以对于大数据的研究，也必须要研究分布式系统的特点。 二、集中式系统 　　由一台或多台计算机组成的中心节点，数据集中存储在这个中心节点中，并且整个系统的所有业务单元都集中部署在这个中心节点上，系统的所有功能均由其集中处理。其部署简单，不用考虑多个节点间的分布式协作问题。 三、分布式系统 　　分布式系统是一个由硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统。其拥有如下特点 　　 3.1 分布性 　　分布式系统中的多台计算机都会在空间中随意分布，同时，机器的分布情况也会随时变动。 　 　3.2 对等性 　　分布式系统中的计算机没有主/从之分，既没有控制整个系统的主机，也没有被控制的从机，组成分布式系统的所有计算机节点都是对等的， 副本 指的是分布式系统对数据和服务提供的一种冗余方式，为了对外提供高可用的服务，我们往往会对数据和服务进行副本处理。 数据副本 是指在不同的节点上持久化同一份数据，当某一个节点上存储的数据丢失时，可以从副本上读取到该数据，这是解决分布式系统数据丢失问题最为有效的手段。 服务副本 是只多个节点提供同样的服务，每个节点都有能力接受来自外部的请求并进行相应的处理。 　 　3.3 并发性 　　同一分布式系统中的多个节点

一、引言 1.什么是session Session 是服务器用来保存用户操作的一系列会话信息，由Web容器进行管理。最常见的，会把用户的登录信息、用户信息存储在 session 中，以保持登录状态。 2.session的创建 在会话开始时，分配一个唯一的会话标识 SessionID（sessionid 是一个会话的key，浏览器第一次访问服务器会在服务器端生成一个 session， 有一个 sessionId 和它对应。），并通过 Cookie 将这个标识告诉浏览器（客户端会将 sessionID 保存在 cookie 中。）， 以后每次请求的时候，浏览器都会带上这个会话标识SessionID来告诉Web服务器这个请求是属于哪个会话的。 在Web服务器上，各个会话都有独立的存储，保存不同会话的信息。如果遇到禁用Cookie的情况， 一般的做法就是把这个会话标识放到URL的参数中。 3.session共享 分布式情况下，如果每台服务器都session存在自己的内存中，不同服务器之间就会造成数据不一致问题， 这时候就需要session共享。单机情况下，不存在Session共享的情况。分布式情况下， 如果不进行Session共享会出现数据不一致，比如：会导致请求落到不同服务器要重复登录的情况。 二、解决方案 1.session复制 应用服务器开启web容器的session复制功能