分布式一致性

现在Redis越来越火，为了适应技术的发展，开始学习一下Redis，在学习Redis之前先学习一下Nosql。 第一部分：入门概述 1.1 互联网时代背景下大机遇，为什么用nosql 1.1.1 单机Mysql的美好年代（好几年前） 当时的业务很相对简单，就是JSP--->Action---->Service---->DAO----->数据库，数据库也就是一个实例而已，无论是Mysql还是Oracle。把这五层缩减为三层的话便是：应用层------>DAO层------>Mysql实例。 以前一个网站的访问量一般不大，用单个数据库可以轻松应付。但是随着时代的发展，上述数据存储遇到了存储的瓶颈： 1) 数据量的总大小，一个机器放不下时(以Mysql为例，单表存储大概三百多万的数据的时候DBA就该进行预警并优化分割了) 2) 数据的索引(B+Tree)，一个机器的内存放不下时(众所周知，为表建立索引也是需要消耗内存的，当我们所建立的索引内存盛不下时) 3) 访问量（读写混合）一个实例不能承受 1.1.2 Memcached(缓存)+MySQL+垂直拆分 后来，随着访问量的上升，几乎大部分使用MySQL架构的网站在数据库上都开始出现了性能问题，web程序不再仅仅专注在功能上，同时也在追求性能。程序员们开始大量的使用缓存技术来缓解数据库的压力，优化数据库的结构和索引

1.NoSQL是什么？ 　　NoSQL 是 Not Only SQL 的缩写，意即"不仅仅是SQL"的意思，泛指非关系型的数据库。强调Key-Value Stores和文档数据库的优点，而不是单纯的反对RDBMS。 　　NoSQL产品是传统关系型数据库的功能阉割版本，通过减少用不到或很少用的功能，来大幅度提高产品性能 2.NoSQL是怎么产生的？ 　　随着web2.0技术的发展，其促使了物联网和移动互联网迅猛发展。传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的 SNS 类型的web2.0纯 动态网 站已经显得力不从心，暴露了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。 　　NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用难题。 3.NoSQL的特点: 模式自由：NoSQL数据库不像传统的关系型数据库需要定义数据库，数据表等结构才可以存取数据，其在增删数据时不需要做数据的完整性检查。数据表中的每一条记录都可能有不同的属性和格式。 逆范式化：为了减少数据冗余，增强数据一致性，在关系型数据库设计时，要遵循 范式 要求，数据表至少要满足第三范式。这样多个表之间建立各种关联关系就不容易数据库的横向扩展；并且这些连接操作也会降低数据库的查询效率。而NoSQL数据库去除约束，放宽事务保障

CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。 而由于当前的网络硬件肯定会出现延迟丢包等问题，所以 分区容忍性是我们必须需要实现的。 所以我们只能在一致性和可用性之间进行权衡，没有NoSQL系统能同时保证这三点。 ======================================================================================================================= C:强一致性 A：高可用性 P：分布式容忍性 CA 传统Oracle数据库 AP 大多数网站架构的选择 CP Redis、Mongodb 注意：分布式架构的时候必须做出取舍。 一致性和可用性之间取一个平衡。多余大多数web应用，其实并不需要强一致性。 因此牺牲C换取P，这是目前分布式数据库产品的方向 ======================================================================================================================= 一致性与可用性的决择 对于web2.0网站来说，关系数据库的很多主要特性却往往无用武之地 数据库事务一致性需求 　　很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低，

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

本文转自： https://www.cnblogs.com/bangerlee/p/5991417.html 本文转自 https://www.cnblogs.com/bangerlee/p/5268485.html 本系列文章将整理到我在GitHub上的《Java面试指南》仓库，更多精彩内容请到我的仓库里查看 https://github.com/h2pl/Java-Tutorial 喜欢的话麻烦点下Star哈 文章首发于我的个人博客： www.how2playlife.com 该系列博文会告诉你什么是分布式系统，这对后端工程师来说是很重要的一门学问，我们会逐步了解分布式理论中的基本概念，常见算法、以及一些较为复杂的分布式原理，同时也需要进一步了解zookeeper的实现，以及CAP、一致性原理等一些常见的分布式理论基础，以便让你更完整地了解分布式理论的基础，为后续学习分布式技术内容做好准备。 如果对本系列文章有什么建议，或者是有什么疑问的话，也可以关注公众号【Java技术江湖】联系作者，欢迎你参与本系列博文的创作和修订。 <!-- more --> 引言 《分布式系统理论进阶 - Paxos》 介绍了一致性协议Paxos，今天我们来学习另外两个常见的一致性协议——Raft和Zab。通过与Paxos对比，了解Raft和Zab的核心思想、加深对一致性协议的认识。 Raft

更好的样式前往 我的Github笔记 查看 小说搜索 https://biqi.org/ <md文档排版不好> 数据模型 组合键：Table + HashKey + SortKey Table实现业务数据的隔离 HashKey决定数据在那个分片 SortKey决定数据在分片内的排序 一致性协议 使用PacificA协议，保证多副本数据的一致性。 <!-- addition --> 机器 Pegasus分布式集群至少需要准备这些机器： MetaServer link： Meta Server 的设计 要求：2~3台机器，无需SSD盘。 作用：用来保存表和表的分片信息。 ReplicaServer： link： Replica Server 的设计 要求至少3台机器，建议挂SSD盘。譬如一台服务器挂着8块或者12块SSD盘。这些机器要求是同构的，即具有相同的配置。 作用：至少三台ReplicaServer。每一个ReplicaServer都是由多个Replica组成的。每一个Replica表示的是一个数据分片的Primary或Secondary。 Collector：可选角色，1台机器，无需SSD盘。该进程主要用于收集和汇总集群的统计信息，负载很小，建议放在MetaServer的其中一台机器上。 Replica 一个数据分片对应3个Replica。 Replica有两个种类

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实现，分析历史数据绝佳