目录
第三章、 NoSQL数据库
传统关系型数据库：以完善的关系代数理论作为基础，可以支持结构化数据存储和管理，具有严格的标准，支持事务ACID特性，借助索引机制可以实现高效查询。但其数据模型不灵活，水平扩展能力较差，且优秀的事务机制和复杂查询不适于大规模非结构化存储。
ACID四大特性：
原子性（Atomicity）：原子性是指事务是一个不可分割的工作单位，事务中的操作要么全部成功，要么全部失败。比如在同一个事务中的SQL语句，要么全部执行成功，要么全部执行失败。如果某个SQL语句执行失败，将会回滚到事务未开启状态。
一致性（Consistency）：官网上事务一致性的概念是：事务必须使数据库从一个一致性状态变换到另外一个一致性状态。
换一种方式理解就是：事务执行失败时不会提交，保持数据一致性。
隔离性（Isolation）：事务的隔离性是多个用户并发访问数据库时，数据库为每一个用户开启的事务，不能被其他事务的操作数据所干扰，多个并发事务之间要相互隔离。事务未提交前，其他用户不能查看未提交的数据。
持久性（Durability）：持久性是指一个事务一旦被提交，它对数据库中数据的改变就是永久性的。
一、 NoSQL数据库特点
1.1 NoSQL数据库与传统关系数据库
| NoSQL数据库 |
传统关系数据库 |
|
| 扩展性 |
良好的横向扩展能力：仅需要廉价的标准化刀片服务器，即可满足很像扩展的需求 |
难以横向扩展，且纵向扩展需要通过升级硬件来实现，价格不菲 |
| 数据模型 |
采用键值，列族等菲关系数据模型，不严格满足ACID特性，允许在一个数据元素中存入不同类型的数据 |
采用关系数据模型，以完备的关系代数理论为基础，有规范的定义，严格的约束。满足ACID特性 |
| 应用场景 |
凭借良好的横向扩展能力，充当云计算基础设施，构建基于NoSQL的云数据库服务，面向“Web2.0”时代 |
超市，银行等领域的业务系统高度依赖于关系数据库来保持数据的一致性；对复杂查询分析型应用来说，关系数据库具有更好的性能 |
| 优势 |
可支持超大规模数据存储，灵活的数据模型可很好地支持Web2.0应用，具有强大的横向扩展能力等。 |
以完善的关系代数理论作为基础，有严格的标准，支持事务ACID四性，借助索引机制可实现高效查询，技术成熟，有专业公司的技术支持 |
| 劣势 |
缺乏数学理论基础，复杂查询性能不高，大都不能实现事务强一致性，很难实现数据完整性，技术尚不成熟，缺乏专业团队技术支持，维护较困难等 |
可扩展性较差，无法较好支持海量数据存储，数据模型过于死板、无法较好支持Web2.0应用，事务机制影响了系统的整体性能等 web2.0中较为鸡肋： web2.0网站系统通常不要求严格的数据库事务 web2.0不要求严格的读写实时性 web2.0通常不包含大量复杂的SQL查询 |
1.2 混合架构
案例：亚马逊公司就使用不同类型的数据库来支撑它的电子商务应用对于“购物篮”这种临时性数据，采用键值存储会更加高效当前的产品和订单信息则适合存放在关系数据库中大量的历史订单信息则适合保存在类似MongoDB【属于NoSQL】的文档数据库中
二、 NoSQL的四大类型
典型的NoSQL包括：键值数据库、列族数据库、文档数据库和图数据库
| 键值数据库 |
列族数据库 |
文档数据库 |
图数据库 |
|
| 数据模型 |
键/值对， 键是一个字符串对象值可以是任意类型的数据 |
列族 通过行键进行查询 |
“文档”其实是一个数据记录，这个记录能够对包含的数据类型和内容进行“自我描述”。类似XML，JSON |
图结构 |
| 适用范围 |
涉及频繁读写、拥有简单数据模型的应用内容缓存，比如会话、配置文件、参数、购物车等存储配置和用户数据信息的移动应用 |
分布式数据存储与管理数据在地理上分布于多个数据中心的应用程序可以容忍副本中存在短期不一致情况的应用程序拥有动态字段的应用程序拥有潜在大量数据的应用程序，大到几百TB的数据 |
存储、索引并管理面向文档的数据或者类似的半结构化数据 |
专门用于处理具有高度相互关联关系的数据，比较适合于社交网络、模式识别、依赖分析、推荐系统以及路径寻找等问题 |
| 优点 |
具有良好的伸缩性，理论上可以无限扩容。 内存键值数据库可以将数据保存在内存中便于查询，持久化键值数据库将数据存在磁盘中 |
查找速度快，可扩展性强，容易进行分布式扩展，复杂性低 |
性能好（高并发），灵活性高，复杂性低，数据结构灵活 提供嵌入式文档功能，将经常查询的数据存储在同一个文档中 既可以根据键来构建索引，也可以根据内容构建索引 数据是不规则的，每一条记录包含了所有的有关的信息而没有任何外部的引用，这条记录就是“自包含”的 记录很容易完全移动到其他服务器，因为所有信息都包含在里面了，不需要考虑其他数据 移动过程中，只有被移动的那一条记录（文档）需操作，不像关系型中每个关联的表都需锁住来保证一致性，这样ACID的保证就会更快速，读写速度会很大提升 |
灵活性高，支持复杂的图形算法，可用于构建复杂的关系图谱 |
| 缺点 |
不能对值进行查询，无法存储结构化信息，条件查询效率较低。需避免多表关联查询，把操作分解为单表操作 兼职数据库不支持回滚操作，无法支持事务 |
功能较少，大都不支持强事务一致性 |
缺乏统一的查询语法 |
复杂性高，只能支持一定的数据规模 |
三、 NoSQL的三大基石
NoSQL的三大基石包括：CAP、BASE和最终一致性
3.1 CAP
CAP理论告诉我们，一个分布式系统不可能同时满足一致性、可用性和分区容忍性这三个需求，最多只能同时满足其中两个，正所谓“鱼和熊掌不可兼得”。
| CA |
也就是强调一致性（C）和可用性（A），放弃分区容忍性（P），最简单的做法是把所有与事务相关的内容都放到同一台机器上。很显然，这种做法会严重影响系统的可扩展性。传统的关系数据库，都采用了这种设计原则，因此，扩展性都比较差 |
| CP |
也就是强调一致性（C）和分区容忍性（P），放弃可用性（A），为了保持一致性，必须等待失联分区返回数据，且等待期间无法对外提供服务 |
| AP |
也就是强调可用性（A）和分区容忍性（P），放弃一致性（C），允许在分区失联时，返回旧的数据 |
3.2 BASE
BASE的基本含义是基本可用（Basically Availble）、软状态（Soft-state）和最终一致性（Eventual consistency）。
基本可用：指一个分布式系统的一部分发生问题变得不可用时其他部分仍然可以正常使用，也就是允许分区失败的情形出现。【分区容忍性】
软状态：指状态可以有一段时间不同步具有一定的滞后性
最终一致性：
1.因果一致性：如果进程A通知进程B它已更新了一个数据项，则进程B的后续访问将获得A写入的最新值。而与进程A无因果关系的进程C的访问，仍然遵守一般的最终一致性规则
2.会话一致性：它把访问存储系统的进程放到会话（session）的上下文中，只要会话还存在，系统就保证
3.“读己之所写”一致性。如果由于某些失败情形令会话终止，就要建立新的会话，而且系统保证不会延续到新的会话
4.单调写一致性：系统保证来自同一个进程的写操作顺序执行。系统必须保证这种程度的一致性，否则就非常难以编程了
5.单调读一致性：如果进程已经看到过数据对象的某个值，那么任何后续访问都不会返回在那个值之前的值
3.3 对于HBase数据库来讲
HBase是借助底层的HDFS来实现其数据冗余备份
HDFS采用强一致性保证，在数据未完全同步到N个节点前，写操作不会成功返回，而读操作只需要读到一个值即可
第四章、 云数据库
云计算【IaaS、PaaS、SaaS】是云数据库兴起的基础：云计算实现了通过网络提供可伸缩的、廉价的分布式计算能力，用户只需要在具备网络接入条件的地方，就可以随时随地获得所需的各种IT资源
云数据库：云数据库是部署和虚拟化在云计算环境中的数据库。云数据库是在云计算的大背景下发展起来的一种新兴的共享基础架构的方法，极大地增强了数据库的存储能力
一、 云数据库的特点
云数据库具有高可扩展性、高可用性、采用多租形式和支持资源有效分发等特点
| 特性 |
|
| 动态可扩展 |
理论上无限扩展，有需求时可以及时扩展，无需求时可以立即释放数据 |
| 高可用 |
冗余存储，世界范围的数据中心，具有高容错率 |
| 低使用代价 |
采用多租户、按需服务的形式，为多用户提供服务，节省开销 |
| 易用性 |
用户不必控制运行原始数据库的机器，只需要通过URL就可以使用数据库，易迁移 |
| 高性能 |
大型分布式存储系统 |
| 免维护 |
用户无需维护 |
| 安全 |
二、 UMP架构
2.1 UMP概述
三种用户的分类，实现了资源的虚拟化，降低整体成本
| 用户类型 |
|
| 数据量和流量小的用户 |
多个小规模用户共用一个MySQL |
| 中等规模用户 |
中等规模用户独占一个MySQL |
| 需要分库分表的用户 |
大规模用户的多个MySQL实例共享同一台物理机 |
UMP架构遵循四个原则：
保持单一的系统对外入口，并为系统内部维护单一资源池。
消除单点故障，保证服务的高可用性。
具有良好可伸缩性，能动态增加、删减计算与存储节点。
保证分配给用户的资源也是弹性可伸缩的，资源之间相互隔离，确保应用和数据安全。
2.2 UMP系统架构
| 【角色】/（开源组件） |
介绍 |
特点 |
| （Mnesia） |
Mnesia是一个分布式数据库管理系统，与编程语言Erlang【上下文切换高效，并行计算支持，适合分布式、软实时系统】紧耦合。 |
支持透明的数据分片，支持事务，利用两阶段锁实现分布式事务，可以线性扩展到至少50个节点 数据库模式(schema)可在运行时动态重配置，表能被迁移或复制到多个节点来改进容错性 其在开发云数据库时被用来提供分布式数据库服务 |
| （RabbitMQ） |
RabbitMQ是一个工业级的消息队列产品 |
作为消息传输中间件来使用，可以实现可靠的消息传送 UMP集群中各个节点之间的通信，不需建立专门的连接，都是通过读写队列消息来实现的 |
| （Zookeeper） |
Zookeeper是高效和可靠的协同工作系统 |
提供分布式锁之类的基本服务（统一命名、状态同步、集群管理、分布式应用配置项的管理等），用于构建分布式应用，减轻分布式应用程序所承担的协调任务 作为全局的配置服务器：配置信息交给Zookeeper管理，发生变化时，所有服务器收到ZooKeeper信息 提供分布式锁：选出一个集群的“总管” 负责发起系统任务 监控所有MySQL实例 ： |
| （LVS） |
LVS 即Linux虚拟服务器，是一个虚拟的服务器集群系统 LVS集群采用IP负载均衡技术和基于内容请求分发技术 UMP系统借助于LVS来实现集群内部的负载均衡 |
调度器是LVS集群系统的唯一入口点，有很好的吞吐率，将请求均衡转移到不同服务器上执行，自动屏蔽故障服务器，从而将一组服务器构成一个高性能、高可用的虚拟服务器 整个服务器集群的结构对客户是透明的，而且无需修改客户端和服务器端的程序 |
| 【Controller服务器】 |
向UMP集群提供各种管理服务，实现集群成员管理、元数据存储、MySQL实例管理、故障恢复、备份、迁移、扩容等功能 |
运行了一组Mnesia分布式数据库服务，其中存储了各种系统元数据，包括集群成员、用户配置和状态信息，及用户名到后端MySQL实例地址的映射关系（或称“路由表”）等 当其它服务器组件需获取用户数据时，向其发送获取请求 为防单点故障，保证高可用性，部署了多台Controller服务器，由Zookeeper的分布式锁功能来选出一个“总管”，负责各种系统任务的调度和监控 |
| 【Web控制台】 |
Web控制台向用户提供系统管理界面 |
|
| 【Proxy服务器】 |
向用户提供访问MySQL数据库的服务，完全实现了MySQL协议。 |
Proxy服务器允许用户用已有MySQL客户端连接 通过用户名获取用户认证信息、资源配额的限制、后台MySQL实例的地址 将用户SQL查询请求会转到相应MySQL实例上。 也可以实现屏蔽MySQL实例故障、读写分离、分库分表、资源隔离、记录用户访问日志等功能 |
| 【Agent服务器】 |
部署在运行MySQL进程的机器上，用来管理每台物理机上的MySQL实例 |
执行主从切换、创建、删除、备份、迁移等操作，同时还负责收集和分析MySQL进程的统计信息、慢查询日志（Slow Query Log）和bin-log |
| 【日志分析服务器】 |
存储和分析Proxy服务器传入的用户访问日志 |
支持实时查询一段时间内的慢日志和统计报表。 |
| 【信息统计服务器】 |
定期将采集到的用户连接数、QPS数值以及MySQL实例的进程状态用RRDtool进行统计 |
可以在Web界面上可视化展示统计结果，也可以把统计结果作为今后实现弹性的资源分配和自动化的MySQL实例迁移的依据 |
| 【愚公系统】 |
是一个全量复制结合binlog分析进行增量复制的工具 |
可以实现在不停机的情况下动态扩容、缩容和迁移。 |
2.3 UMP系统功能
UMP系统是构建在一个大的集群之上的，通过多个组件协同作业，实现对用户透明的各种功能：
容灾、读写分离、分库分表、资源管理、资源调度、资源隔离和数据安全
| 功能 |
介绍 |
过程 |
| 容灾 |
对用户完全透明的故障恢复 UMP系统会为每个用户创建主从 两个MySQL实例主库和从库的状态是由Zookeeper负责维护的 |
主库宕机过程： Zookeeper探测到主库故障，通知Controller服务器 Controller服务器启动主从切换，修改“路由表” 把主库标记为不可用 借助消息中间件RabbitMQ通知所有Proxy服务器修改用户名到后端MySQL实例地址的映射关系 宕机后的主库在进行恢复处理后需再次上线过程： 在主库恢复时，会把从库的更新复制给自己 当主库数据库状态快要和从库一致时，Controller服务器命令从库停止更新，进入不可写状态，禁止用户写入 数据主库更新到和从库完全一致时，Controller服务器发起主从切换操作，并在路由表中把主库标记为可用状态 通知Proxy服务器把写操作切回主库上，用户写操作可以继续执行，之后再把从库修改为可写状态 |
| 读写分离 |
充分利用主从库实现用户读写操作的分离，实现负载均衡 |
当整个功能被开启时，负责向用户提供访问MySQL数据库服务的Proxy服务器，就会对用户发起的SQL语句进行解析，如果属于写操作，就直接发送到主库，如果是读操作，就会被均衡地发送到主库和从库上执行 |
| 分库分表 |
UMP支持对用户透明的分库分表，但需要用户创建账号时指定多实例类型，并设置实例个数和分库分表规则。 |
当采用分库分表时，系统处理用户查询的过程如下： 首先，Proxy服务器解析用户SQL语句，提取出重写和分发SQL语句所需要的信息 其次，对SQL语句进行重写，得到多个针对相应MySQL实例的子语句，然后把子语句分发到对应的MySQL实例上执行 最后，接收来自各个MySQL实例的SQL语句执行结果，合并得最终结果 |
| 资源管理 |
UMP系统采用资源池机制来管理计算资源，所有的计算资源都放在资源池内进行统一分配，资源池是为MySQL实例分配资源的基本单位 |
集群中所有服务器会根据其机型、所在机房等因素被划分多个资源池，每台服务器会被加入到相应的资源池中 对于每个具体MySQL实例，管理员会根据资源状况为该实例具体指定主库和从库所在的资源池，然后，系统的实例管理服务会本着负载均衡的原则，从资源池中选择负载较轻的服务器来创建MySQL实例 每台服务器内部采用Cgroup进一步细化资源，限制资源上限，保证进程组之间相互隔离 |
| 资源调度 |
三种用户 |
利用愚公系统实现在不停机的情况下动态扩容、缩容和迁移 |
| 资源隔离 |
同一台服务器上多个MySQL实例：Cgroup限制资源 多用户共享一个MySQL实例：Controller服务器监测用户的MySQL实例的资源消耗情况，如果明显超出配额，就通知Proxy服务器通过增加延迟的方法去限制用户的QPS【每秒查询率】 |
|
| 数据安全 |
UMP系统设计了多种机制来保证数据安全 |
SSL数据库连接：通信安全和数据完整性 协议 数据访问IP白名单：非白名单拒绝连接 记录用户操作日志：记录所有操作到日志服务器 SQL拦截：拦截指定SQL语句 |