（转+分享）JAVA核心知识点整理，用于面试！！！【三】 ~ Hbase/MongoDB/设计模式/ 负载均衡/ 数据库/

14. Hbase

14.1.1. 概念

base 是分布式、面向列的开源数据库（其实准确的说是面向列族）。HDFS 为 Hbase 提供可靠的 底层数据存储服务，MapReduce 为 Hbase 提供高性能的计算能力，Zookeeper 为 Hbase 提供 稳定服务和 Failover 机制，因此我们说 Hbase 是一个通过大量廉价的机器解决海量数据的高速存 储和读取的分布式数据库解决方案。

14.1.2. 列式存储

列方式所带来的重要好处之一就是，由于查询中的选择规则是通过列来定义的，因此整个数据库 是自动索引化的

这里的列式存储其实说的是列族存储，Hbase 是根据列族来存储数据的。列族下面可以有非常多 的列，列族在创建表的时候就必须指定。为了加深对 Hbase 列族的理解，下面是一个简单的关系 型数据库的表和 Hbase 数据库的表

14.1.3. Hbase 核心概念

14.1.3.1. Column Family 列族

Column Family 又叫列族，Hbase 通过列族划分数据的存储，列族下面可以包含任意多的列，实 现灵活的数据存取。Hbase 表的创建的时候就必须指定列族。就像关系型数据库创建的时候必须 指定具体的列是一样的。Hbase 的列族不是越多越好，官方推荐的是列族最好小于或者等于 3。我 们使用的场景一般是 1 个列族。

14.1.3.2. Rowkey（Rowkey 查询，Rowkey 范围扫描，全表扫描）

Rowkey 的概念和 mysql 中的主键是完全一样的，Hbase 使用 Rowkey 来唯一的区分某一行的数 据。Hbase 只支持 3 中查询方式：基于 Rowkey 的单行查询，基于 Rowkey 的范围扫描，全表扫 描。

14.1.3.3. Region 分区

 Region：Region 的概念和关系型数据库的分区或者分片差不多。Hbase 会将一个大表的数 据基于 Rowkey 的不同范围分配到不通的 Region 中，每个 Region 负责一定范围的数据访问 和存储。这样即使是一张巨大的表，由于被切割到不通的 region，访问起来的时延也很低。

14.1.3.4. TimeStamp 多版本

 TimeStamp 是实现 Hbase 多版本的关键。在 Hbase 中使用不同的 timestame 来标识相同 rowkey 行对应的不通版本的数据。在写入数据的时候，如果用户没有指定对应的 timestamp，Hbase 会自动添加一个 timestamp，timestamp 和服务器时间保持一致。在Hbase 中，相同 rowkey 的数据按照 timestamp 倒序排列。默认查询的是最新的版本，用户 可同指定 timestamp 的值来读取旧版本的数据。

14.1.4. Hbase 核心架构

Hbase 是由 Client、Zookeeper、Master、HRegionServer、HDFS 等几个组建组成

 

14.1.4.1. Client：

 Client 包含了访问 Hbase 的接口，另外 Client 还维护了对应的 cache 来加速 Hbase 的 访问，比如 cache 的.META.元数据的信息。

14.1.4.2. Zookeeper：

 Hbase 通过 Zookeeper 来做 master 的高可用、RegionServer 的监控、元数据的入口 以及集群配置的维护等工作。具体工作如下：

1. 通过 Zoopkeeper 来保证集群中只有 1 个 master 在运行，如果 master 异 常，会通过竞争机制产生新的 master 提供服务

2. 通过 Zoopkeeper 来监控 RegionServer 的状态，当 RegionSevrer 有异常的 时候，通过回调的形式通知 Master RegionServer 上下限的信息

3. 通过 Zoopkeeper 存储元数据的统一入口地址。

14.1.4.3. Hmaster

 master 节点的主要职责如下：

1. 为 RegionServer 分配 Region

2. 维护整个集群的负载均衡

3. 维护集群的元数据信息发现失效的 Region，并将失效的 Region 分配到正常 RegionServer 上当 RegionSever 失效的时候，协调对应 Hlog 的拆分

14.1.4.4. HregionServer

 HregionServer 直接对接用户的读写请求，是真正的“干活”的节点。它的功能概括如 下：

1. 管理 master 为其分配的

2. 处理来自客户端的读写请求

3. 负责和底层 HDFS 的交互，存储数据到 HDFS

4. 负责 Region 变大以后的拆分

5. 负责 Storefile 的合并工作

14.1.4.5. Region 寻址方式（通过 zookeeper .META）

第 1 步：Client 请求 ZK 获取.META.所在的 RegionServer 的地址。

第 2 步：Client 请求.META.所在的 RegionServer 获取访问数据所在的 RegionServer 地 址，client 会将.META.的相关信息 cache 下来，以便下一次快速访问。

第 3 步：Client 请求数据所在的 RegionServer，获取所需要的数据。

14.1.4.6. HDFS

 HDFS 为 Hbase 提供最终的底层数据存储服务，同时为 Hbase 提供高可用（Hlog 存储在

HDFS）的支持

14.1.5. Hbase 的写逻辑

14.1.5.1. Hbase 的写入流程

从上图可以看出氛围 3 步骤：

获取 RegionServer

第 1 步：Client 获取数据写入的 Region 所在的 RegionServer

请求写 Hlog

第 2 步：请求写 Hlog, Hlog 存储在 HDFS，当 RegionServer 出现异常，需要使用 Hlog 来 恢复数据。

请求写 MemStore

第 3 步：请求写 MemStore,只有当写 Hlog 和写 MemStore 都成功了才算请求写入完成。 MemStore 后续会逐渐刷到 HDFS 中。

14.1.5.2. MemStore 刷盘

 

 

15. MongoDB

15.1.1. 概念

MongoDB 是由 C++语言编写的，是一个基于分布式文件存储的开源数据库系统。在高负载的情 况下，添加更多的节点，可以保证服务器性能。MongoDB 旨在为 WEB 应用提供可扩展的高性能 数据存储解决方案。

MongoDB 将数据存储为一个文档，数据结构由键值(key=>value)对组成。MongoDB 文档类似 于 JSON 对象。字段值可以包含其他文档，数组及文档数组。

15.1.2. 特点

 MongoDB 是一个面向文档存储的数据库，操作起来比较简单和容易。

 你可以在 MongoDB 记录中设置任何属性的索引 (如：FirstName="Sameer",Address="8 Ga ndhi Road")来实现更快的排序。

 你可以通过本地或者网络创建数据镜像，这使得 MongoDB 有更强的扩展性。

 如果负载的增加（需要更多的存储空间和更强的处理能力） ，它可以分布在计算机网络中的其 他节点上这就是所谓的分片。

 Mongo 支持丰富的查询表达式。查询指令使用 JSON 形式的标记，可轻易查询文档中内嵌的 对象及数组。

 MongoDb 使用 update()命令可以实现替换完成的文档（数据）或者一些指定的数据字段 。

 Mongodb 中的 Map/reduce 主要是用来对数据进行批量处理和聚合操作。

 Map 和 Reduce。Map 函数调用 emit(key,value)遍历集合中所有的记录，将 key 与 value 传 给 Reduce 函数进行处理。

 Map 函数和 Reduce 函数是使用 Javascript 编写的，并可以通过 db.runCommand 或 mapre duce 命令来执行 MapReduce 操作。

 GridFS 是 MongoDB 中的一个内置功能，可以用于存放大量小文件。

 MongoDB 允许在服务端执行脚本，可以用 Javascript 编写某个函数，直接在服务端执行，也

可以把函数的定义存储在服务端，下次直接调用即可。

 

17. 设计模式

17.1.1. 设计原则

17.1.2. 工厂方法模式

17.1.3. 抽象工厂模式

17.1.4. 单例模式

17.1.5. 建造者模式

17.1.6. 原型模式

17.1.7. 适配器模式

17.1.8. 装饰器模式

17.1.9. 代理模式

17.1.10. 外观模式

17.1.11. 桥接模式

17.1.12. 组合模式

17.1.13. 享元模式

17.1.14. 策略模式

17.1.15. 模板方法模式

17.1.16. 观察者模式

17.1.17. 迭代子模式

17.1.18. 责任链模式

17.1.19. 命令模式

17.1.20. 备忘录模式

17.1.21. 状态模式

17.1.22. 访问者模式

17.1.23. 中介者模式

17.1.24. 解释器模式

18. 负载均衡

负载均衡 建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带 宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。

 

18.1.1.1. 四层负载均衡（目标地址和端口交换）

主要通过报文中的目标地址和端口，再加上负载均衡设备设置的服务器选择方式，决定最终选择 的内部服务器。

以常见的 TCP 为例，负载均衡设备在接收到第一个来自客户端的 SYN 请求时，即通过上述方式选 择一个最佳的服务器，并对报文中目标 IP 地址进行修改(改为后端服务器 IP），直接转发给该服务 器。TCP 的连接建立，即三次握手是客户端和服务器直接建立的，负载均衡设备只是起到一个类 似路由器的转发动作。在某些部署情况下，为保证服务器回包可以正确返回给负载均衡设备，在 转发报文的同时可能还会对报文原来的源地址进行修改。实现四层负载均衡的软件有：

F5：硬件负载均衡器，功能很好，但是成本很高。

lvs：重量级的四层负载软件。

nginx：轻量级的四层负载软件，带缓存功能，正则表达式较灵活。

haproxy：模拟四层转发，较灵活。

18.1.1.2. 七层负载均衡（内容交换）

所谓七层负载均衡，也称为“内容交换”，也就是主要通过报文中的真正有意义的应用层内容，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。

七层应用负载的好处，是使得整个网络更智能化。例如访问一个网站的用户流量，可以通过七层 的方式，将对图片类的请求转发到特定的图片服务器并可以使用缓存技术；将对文字类的请求可以转发到特定的文字服务器并可以使用压缩技术。实现七层负载均衡的软件有：

haproxy：天生负载均衡技能，全面支持七层代理，会话保持，标记，路径转移；

nginx：只在 http 协议和 mail 协议上功能比较好，性能与 haproxy 差不多；

apache：功能较差

Mysql proxy：功能尚可。

18.1.2. 负载均衡算法/策略

18.1.2.1. 轮循均衡（Round Robin）

每一次来自网络的请求轮流分配给内部中的服务器，从 1 至 N 然后重新开始。此种均衡算法适合 于服务器组中的所有服务器都有相同的软硬件配置并且平均服务请求相对均衡的情况。

18.1.2.2. 权重轮循均衡（Weighted Round Robin）

根据服务器的不同处理能力，给每个服务器分配不同的权值，使其能够接受相应权值数的服务请 求。例如：服务器 A 的权值被设计成 1，B 的权值是 3，C 的权值是 6，则服务器 A、B、C 将分 别接受到 10%、30％、60％的服务请求。此种均衡算法能确保高性能的服务器得到更多的使用率，避免低性能的服务器负载过重。

18.1.2.3. 随机均衡（Random）

把来自网络的请求随机分配给内部中的多个服务器。

18.1.2.4. 权重随机均衡（Weighted Random）

此种均衡算法类似于权重轮循算法，不过在处理请求分担时是个随机选择的过程。

18.1.2.5. 响应速度均衡（Response Time 探测时间）

负载均衡设备对内部各服务器发出一个探测请求（例如 Ping），然后根据内部中各服务器对探测 请求的最快响应时间来决定哪一台服务器来响应客户端的服务请求。此种均衡算法能较好的反映 服务器的当前运行状态，但这最快响应时间仅仅指的是负载均衡设备与服务器间的最快响应时间，而不是客户端与服务器间的最快响应时间。

18.1.2.6. 最少连接数均衡（Least Connection）

最少连接数均衡算法对内部中需负载的每一台服务器都有一个数据记录，记录当前该服务器正在 处理的连接数量，当有新的服务连接请求时，将把当前请求分配给连接数最少的服务器，使均衡 更加符合实际情况，负载更加均衡。此种均衡算法适合长时处理的请求服务，如 FTP。

18.1.2.7. 处理能力均衡（CPU、内存）

此种均衡算法将把服务请求分配给内部中处理负荷（根据服务器 CPU 型号、CPU 数量、内存大小 及当前连接数等换算而成）最轻的服务器，由于考虑到了内部服务器的处理能力及当前网络运行 状况，所以此种均衡算法相对来说更加精确，尤其适合运用到第七层（应用层）负载均衡的情况下。

18.1.2.8. DNS 响应均衡（Flash DNS）

在此均衡算法下，分处在不同地理位置的负载均衡设备收到同一个客户端的域名解析请求，并在 同一时间内把此域名解析成各自相对应服务器的 IP 地址并返回给客户端，则客户端将以最先收到的域名解析 IP 地址来继续请求服务，而忽略其它的 IP 地址响应。在种均衡策略适合应用在全局负 载均衡的情况下，对本地负载均衡是没有意义的。

18.1.2.9. 哈希算法

一致性哈希一致性 Hash，相同参数的请求总是发到同一提供者。当某一台提供者挂时，原本发往 该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。

18.1.2.10. IP 地址散列（保证客户端服务器对应关系稳定）

通过管理发送方 IP 和目的地 IP 地址的散列，将来自同一发送方的分组(或发送至同一目的地的分 组)统一转发到相同服务器的算法。当客户端有一系列业务需要处理而必须和一个服务器反复通信 时，该算法能够以流(会话)为单位，保证来自相同客户端的通信能够一直在同一服务器中进行处 理。

18.1.2.11.URL 散列

通过管理客户端请求 URL 信息的散列，将发送至相同 URL 的请求转发至同一服务器的算法。

18.1.3. LVS

18.1.3.1. LVS 原理

IPVS

LVS 的 IP 负载均衡技术是通过 IPVS 模块来实现的，IPVS 是 LVS 集群系统的核心软件，它的主要 作用是：安装在 Director Server 上，同时在 Director Server 上虚拟出一个 IP 地址，用户必须通 过这个虚拟的 IP 地址访问服务器。这个虚拟 IP 一般称为 LVS 的 VIP，即 Virtual IP。访问的请求 首先经过 VIP 到达负载调度器，然后由负载调度器从 Real Server 列表中选取一个服务节点响应用户的请求。 在用户的请求到达负载调度器后，调度器如何将请求发送到提供服务的 Real Server 节 点，而 Real Server 节点如何返回数据给用户，是 IPVS 实现的重点技术。

ipvs ： 工作于内核空间，主要用于使用户定义的策略生效

ipvsadm : 工作于用户空间，主要用于用户定义和管理集群服务的工具

ipvs 工作于内核空间的 INPUT 链上，当收到用户请求某集群服务时，经过 PREROUTING 链，经 检查本机路由表，送往 INPUT 链；在进入 netfilter 的 INPUT 链时，ipvs 强行将请求报文通过 ipvsadm 定义的集群服务策略的路径改为 FORWORD 链，将报文转发至后端真实提供服务的主机。

18.1.3.1. LVS NAT 模式

 

①.客户端将请求发往前端的负载均衡器，请求报文源地址是 CIP(客户端 IP),后面统称为 CIP)，目 标地址为 VIP(负载均衡器前端地址，后面统称为 VIP)。

②.负载均衡器收到报文后，发现请求的是在规则里面存在的地址，那么它将客户端请求报文的目 标地址改为了后端服务器的 RIP 地址并将报文根据算法发送出去。

③.报文送到 Real Server 后，由于报文的目标地址是自己，所以会响应该请求，并将响应报文返还 给 LVS。

④.然后 lvs 将此报文的源地址修改为本机并发送给客户端。

注意：在 NAT 模式中，Real Server 的网关必须指向 LVS，否则报文无法送达客户端

特点：

1、NAT 技术将请求的报文和响应的报文都需要通过 LB 进行地址改写，因此网站访问量比较大的 时候 LB 负载均衡调度器有比较大的瓶颈，一般要求最多之能 10-20 台节点

2、只需要在 LB 上配置一个公网 IP 地址就可以了。

3、每台内部的 realserver 服务器的网关地址必须是调度器 LB 的内网地址。

4、NAT 模式支持对 IP 地址和端口进行转换。即用户请求的端口和真实服务器的端口可以不一致。

优点： 集群中的物理服务器可以使用任何支持 TCP/IP 操作系统，只有负载均衡器需要一个合法的 IP 地 址。

缺点：

扩展性有限。当服务器节点（普通 PC 服务器）增长过多时,负载均衡器将成为整个系统的瓶颈，因 为所有的请求包和应答包的流向都经过负载均衡器。当服务器节点过多时，大量的数据包都交汇 在负载均衡器那，速度就会变慢！

18.1.3.2. LVS DR 模式（局域网改写 mac 地址）

①.客户端将请求发往前端的负载均衡器，请求报文源地址是 CIP，目标地址为 VIP。

②.负载均衡器收到报文后，发现请求的是在规则里面存在的地址，那么它将客户端请求报文的源 MAC 地址改为自己 DIP 的 MAC 地址，目标 MAC 改为了 RIP 的 MAC 地址，并将此包发送给 RS。

③.RS 发现请求报文中的目的 MAC 是自己，就会将次报文接收下来，处理完请求报文后，将响应 报文通过 lo 接口送给 eth0 网卡直接发送给客户端。

注意：需要设置 lo 接口的 VIP 不能响应本地网络内的 arp 请求。

总结：

1、通过在调度器 LB 上修改数据包的目的 MAC 地址实现转发。注意源地址仍然是 CIP，目的地址仍然是 VIP 地址。

2、请求的报文经过调度器，而 RS 响应处理后的报文无需经过调度器 LB，因此并发访问量大时使用效率很高（和 NAT 模式比）

3、因为 DR 模式是通过 MAC 地址改写机制实现转发，因此所有 RS 节点和调度器 LB 只能在一个局域网里面

4、RS 主机需要绑定 VIP 地址在 LO 接口（掩码 32 位）上，并且需要配置 ARP 抑制。

5、RS 节点的默认网关不需要配置成 LB，而是直接配置为上级路由的网关，能让 RS 直接出网就 可以。

6、由于 DR 模式的调度器仅做 MAC 地址的改写，所以调度器 LB 就不能改写目标端口，那么 RS 服务器就得使用和 VIP 相同的端口提供服务。

7、直接对外的业务比如 WEB 等，RS 的 IP 最好是使用公网 IP。对外的服务，比如数据库等最好 使用内网 IP。

优点：

和 TUN（隧道模式）一样，负载均衡器也只是分发请求，应答包通过单独的路由方法返回给客户 端。与 VS-TUN 相比，VS-DR 这种实现方式不需要隧道结构，因此可以使用大多数操作系统做为 物理服务器。

DR 模式的效率很高，但是配置稍微复杂一点，因此对于访问量不是特别大的公司可以用 haproxy/nginx取代。日1000-2000W PV或者并发请求1万一下都可以考虑用haproxy/nginx。

缺点： 所有 RS 节点和调度器 LB 只能在一个局域网里面

18.1.3.3. LVS TUN 模式（IP 封装、跨网段）

①.客户端将请求发往前端的负载均衡器，请求报文源地址是 CIP，目标地址为 VIP。

②.负载均衡器收到报文后，发现请求的是在规则里面存在的地址，那么它将在客户端请求报文的 首部再封装一层 IP 报文,将源地址改为 DIP，目标地址改为 RIP,并将此包发送给 RS。

③.RS 收到请求报文后，会首先拆开第一层封装,然后发现里面还有一层 IP 首部的目标地址是自己 lo 接口上的 VIP，所以会处理次请求报文，并将响应报文通过 lo 接口送给 eth0 网卡直接发送给客 户端。

注意：需要设置 lo 接口的 VIP 不能在共网上出现

总结：

1.TUNNEL 模式必须在所有的 realserver 机器上面绑定 VIP 的 IP 地址

2.TUNNEL 模式的 vip ------>realserver 的包通信通过 TUNNEL 模式，不管是内网和外网都能通 信，所以不需要 lvs vip 跟 realserver 在同一个网段内。

3.TUNNEL 模式 realserver 会把 packet 直接发给 client 不会给 lvs 了

4.TUNNEL 模式走的隧道模式，所以运维起来比较难，所以一般不用。

优点：

负载均衡器只负责将请求包分发给后端节点服务器，而 RS 将应答包直接发给用户。所以，减少了 负载均衡器的大量数据流动，负载均衡器不再是系统的瓶颈，就能处理很巨大的请求量，这种方 式，一台负载均衡器能够为很多 RS 进行分发。而且跑在公网上就能进行不同地域的分发。

缺点：

隧道模式的 RS 节点需要合法 IP，这种方式需要所有的服务器支持”IP Tunneling”(IP Encapsulation)协议，服务器可能只局限在部分 Linux 系统上。

18.1.3.4. LVS FULLNAT 模式

无论是 DR 还是 NAT 模式，不可避免的都有一个问题：LVS 和 RS 必须在同一个 VLAN 下，否则 LVS 无法作为 RS 的网关。这引发的两个问题是：

1、同一个 VLAN 的限制导致运维不方便，跨 VLAN 的 RS 无法接入。

2、LVS 的水平扩展受到制约。当 RS 水平扩容时，总有一天其上的单点 LVS 会成为瓶颈。

Full-NAT 由此而生，解决的是 LVS 和 RS 跨 VLAN 的问题，而跨 VLAN 问题解决后，LVS 和 RS 不再存在 VLAN 上的从属关系，可以做到多个 LVS 对应多个 RS，解决水平扩容的问题。

Full-NAT 相比 NAT 的主要改进是，在 SNAT/DNAT 的基础上，加上另一种转换，转换过程如下：

1. 在包从 LVS 转到 RS 的过程中，源地址从客户端 IP 被替换成了 LVS 的内网 IP。内网 IP 之间 可以通过多个交换机跨 VLAN 通信。目标地址从 VIP 修改为 RS IP.

2. 当 RS 处理完接受到的包，处理完成后返回时，将目标地址修改为 LVS ip，原地址修改为 RS IP，最终将这个包返回给 LVS 的内网 IP，这一步也不受限于 VLAN。

3. LVS 收到包后，在 NAT 模式修改源地址的基础上，再把 RS 发来的包中的目标地址从 LVS 内 网 IP 改为客户端的 IP,并将原地址修改为 VIP。

Full-NAT 主要的思想是把网关和其下机器的通信，改为了普通的网络通信，从而解决了跨 VLAN 的问题。采用这种方式，LVS 和 RS 的部署在 VLAN 上将不再有任何限制，大大提高了运维部署的 便利性。

总结

1. FULL NAT 模式不需要 LBIP 和 realserver ip 在同一个网段；

2. full nat 因为要更新 sorce ip 所以性能正常比 nat 模式下降 10%

18.1.4. Keepalive

keepalive 起初是为 LVS 设计的，专门用来监控 lvs 各个服务节点的状态，后来加入了 vrrp 的功 能，因此除了 lvs，也可以作为其他服务（nginx，haproxy）的高可用软件。VRRP 是 virtual router redundancy protocal（虚拟路由器冗余协议）的缩写。VRRP 的出现就是为了解决静态路 由出现的单点故障，它能够保证网络可以不间断的稳定的运行。所以 keepalive 一方面具有 LVS cluster node healthcheck 功能，另一方面也具有 LVS director failover。

18.1.5. Nginx 反向代理负载均衡

普通的负载均衡软件，如 LVS，其实现的功能只是对请求数据包的转发、传递，从负载均衡下的节 点服务器来看，接收到的请求还是来自访问负载均衡器的客户端的真实用户；而反向代理就不一样了，反向代理服务器在接收访问用户请求后，会代理用户 重新发起请求代理下的节点服务器最后把数据返回给客户端用户。在节点服务器看来，访问的节点服务器的客户端用户就是反向代

理服务器，而非真实的网站访问用户。

18.1.5.1. upstream_module 和健康检测

ngx_http_upstream_module 是负载均衡模块，可以实现网站的负载均衡功能即节点的健康检 查，upstream 模块允许 Nginx 定义一组或多组节点服务器组，使用时可通过 proxy_pass 代理方式把网站的请求发送到事先定义好的对应 Upstream 组 的名字上。

 

18.1.5.1. proxy_pass 请求转发

proxy_pass 指令属于 ngx_http_proxy_module 模块，此模块可以将请求转发到另一台服务器， 在实际的反向代理工作中，会通过 location 功能匹配指定的 URI，然后把接收到服务匹配 URI 的 请求通过 proyx_pass 抛给定义好的 upstream 节点池

 

 

18.1.6. HAProxy

19. 数据库

19.1.1. 存储引擎

19.1.1.1. 概念

数据库存储引擎是数据库底层软件组织，数据库管理系统（DBMS）使用数据引擎进行创建、查询、 更新和删除数据。不同的存储引擎提供不同的存储机制、索引技巧、锁定水平等功能，使用不同 的存储引擎，还可以 获得特定的功能。现在许多不同的数据库管理系统都支持多种不同的数据引擎。存储引擎主要有： 1. MyIsam , 2. InnoDB, 3. Memory, 4. Archive, 5. Federated 。

19.1.1.2. InnoDB（B+树）

InnoDB 底层存储结构为B+树， B树的每个节点对应innodb的一个page，page大小是固定的， 一般设为 16k。其中非叶子节点只有键值，叶子节点包含完成数据。

适用场景：

1）经常更新的表，适合处理多重并发的更新请求。

2）支持事务。

3）可以从灾难中恢复（通过 bin-log 日志等）。

4）外键约束。只有他支持外键。

5）支持自动增加列属性 auto_increment。

19.1.1.3. TokuDB（Fractal Tree-节点带数据）

TokuDB 底层存储结构为 Fractal Tree,Fractal Tree 的结构与 B+树有些类似, 在 Fractal Tree 中，每一个 child 指针除了需要指向一个 child 节点外，还会带有一个 Message Buffer ，这个 Message Buffer 是一个 FIFO 的队列，用来缓存更新操作。

例如，一次插入操作只需要落在某节点的 Message Buffer 就可以马上返回了，并不需要搜索到叶 子节点。这些缓存的更新会在查询时或后台异步合并应用到对应的节点中

 

TokuDB 在线添加索引，不影响读写操作, 非常快的写入性能， Fractal-tree 在事务实现上有优 势。 他主要适用于访问频率不高的数据或历史数据归档。

19.1.1.4. MyIASM

MyIASM是 MySQL默认的引擎，但是它没有提供对数据库事务的支持，也不支持行级锁和外键， 因此当 INSERT(插入)或 UPDATE(更新)数据时即写操作需要锁定整个表，效率便会低一些。

ISAM 执行读取操作的速度很快，而且不占用大量的内存和存储资源。在设计之初就预想数据组织 成有固定长度的记录，按顺序存储的。---ISAM 是一种静态索引结构。 缺点是它不 支持事务处理。

19.1.1.5. Memory

Memory（也叫 HEAP）堆内存：使用存在内存中的内容来创建表。每个 MEMORY 表只实际对应 一个磁盘文件。MEMORY 类型的表访问非常得快，因为它的数据是放在内存中的，并且默认使用 HASH 索引。但是一旦服务关闭，表中的数据就会丢失掉。 Memory 同时支持散列索引和 B 树索引，B树索引可以使用部分查询和通配查询，也可以使用<,>和>=等操作符方便数据挖掘，散列索 引相等的比较快但是对于范围的比较慢很多。

19.1.2. 索引

索引（Index）是帮助 MySQL 高效获取数据的数据结构。常见的查询算法,顺序查找,二分查找,二 叉排序树查找,哈希散列法,分块查找,平衡多路搜索树 B 树（B-tree）

19.1.2.1. 常见索引原则有

1.选择唯一性索引 1．唯一性索引的值是唯一的，可以更快速的通过该索引来确定某条记录。

2.为经常需要排序、分组和联合操作的字段建立索引：

3．为常作为查询条件的字段建立索引。

4．限制索引的数目： 越多的索引，会使更新表变得很浪费时间。

5.尽量使用数据量少的索引

6．如果索引的值很长，那么查询的速度会受到影响。 尽量使用前缀来索引

7．如果索引字段的值很长，最好使用值的前缀来索引。

7．删除不再使用或者很少使用的索引

8 . 最左前缀匹配原则，非常重要的原则。

10 . 尽量选择区分度高的列作为索引 区分度的公式是表示字段不重复的比例

11 .索引列不能参与计算，保持列“干净”：带函数的查询不参与索引。

12 .尽量的扩展索引，不要新建索引。

19.1.3. 数据库三范式

范式是具有最小冗余的表结构。3 范式具体如下：

19.1.3.1. 第一范式(1st NF －列都是不可再分)

第一范式的目标是确保每列的原子性:如果每列都是不可再分的最小数据单元（也称为最小的原子单元），则满足第一范式（1NF）

19.1.3.2. 第二范式(2nd NF－每个表只描述一件事情)

首先满足第一范式，并且表中非主键列不存在对主键的部分依赖。 第二范式要求每个表只描述一件事情。

19.1.3.3. 第三范式(3rd NF－ 不存在对非主键列的传递依赖)

第三范式定义是，满足第二范式，并且表中的列不存在对非主键列的传递依赖。除了主键订单编号外，顾客姓名依赖于非主键顾客编号。

19.1.4. 数据库是事务

事务(TRANSACTION)是作为单个逻辑工作单元执行的一系列操作，这些操作作为一个整体一起向 系统提交，要么都执行、要么都不执行 。事务是一个不可分割的工作逻辑单元 事务必须具备以下四个属性，简称 ACID 属性：

原子性（Atomicity）

1. 事务是一个完整的操作。事务的各步操作是不可分的（原子的）；要么都执行，要么都不执 行。

一致性（Consistency）

2. 当事务完成时，数据必须处于一致状态。

隔离性（Isolation）

3. 对数据进行修改的所有并发事务是彼此隔离的，这表明事务必须是独立的，它不应以任何方 式依赖于或影响其他事务。

永久性（Durability）

4. 事务完成后，它对数据库的修改被永久保持，事务日志能够保持事务的永久性。

19.1.5. 存储过程(特定功能的 SQL 语句集)

一组为了完成特定功能的 SQL 语句集，存储在数据库中，经过第一次编译后再次调用不需要再次 编译，用户通过指定存储过程的名字并给出参数（如果该存储过程带有参数）来执行它。存储过 程是数据库中的一个重要对象。

存储过程优化思路：

1. 尽量利用一些 sql 语句来替代一些小循环，例如聚合函数，求平均函数等。

2. 中间结果存放于临时表，加索引。

3. 少使用游标。sql 是个集合语言，对于集合运算具有较高性能。而 cursors 是过程运算。比如 对一个 100 万行的数据进行查询。游标需要读表 100 万次，而不使用游标则只需要少量几次 读取。

4. 事务越短越好。sqlserver 支持并发操作。如果事务过多过长，或者隔离级别过高，都会造成 并发操作的阻塞，死锁。导致查询极慢，cpu 占用率极地。

5. 使用 try-catch 处理错误异常。

6. 查找语句尽量不要放在循环内。

19.1.6. 触发器(一段能自动执行的程序)

触发器是一段能自动执行的程序，是一种特殊的存储过程，触发器和普通的存储过程的区别是： 触发器是当对某一个表进行操作时触发。诸如：update、insert、delete 这些操作的时候，系统 会自动调用执行该表上对应的触发器。SQL Server 2005 中触发器可以分为两类：DML 触发器和 DDL 触发器，其中 DDL 触发器它们会影响多种数据定义语言语句而激发，这些语句有 create、 alter、drop 语句。

19.1.7. 数据库并发策略

并发控制一般采用三种方法，分别是乐观锁和悲观锁以及时间戳。

19.1.7.1. 乐观锁

乐观锁认为一个用户读数据的时候，别人不会去写自己所读的数据；悲观锁就刚好相反，觉得自 己读数据库的时候，别人可能刚好在写自己刚读的数据，其实就是持一种比较保守的态度；时间 戳就是不加锁，通过时间戳来控制并发出现的问题。

19.1.7.2. 悲观锁

悲观锁就是在读取数据的时候，为了不让别人修改自己读取的数据，就会先对自己读取的数据加 锁，只有自己把数据读完了，才允许别人修改那部分数据，或者反过来说，就是自己修改某条数 据的时候，不允许别人读取该数据，只有等自己的整个事务提交了，才释放自己加上的锁，才允 许其他用户访问那部分数据。

19.1.7.3. 时间戳

时间戳就是在数据库表中单独加一列时间戳，比如“TimeStamp”，每次读出来的时候，把该字 段也读出来，当写回去的时候，把该字段加1，提交之前 ，跟数据库的该字段比较一次，如果比数 据库的值大的话，就允许保存，否则不允许保存，这种处理方法虽然不使用数据库系统提供的锁 机制，但是这种方法可以大大提高数据库处理的并发量， 以上悲观锁所说的加“锁”，其实分为几种锁，分别是：排它锁（写锁）和共享锁（读锁）。

19.1.8. 数据库锁

19.1.8.1. 行级锁

行级锁是一种排他锁，防止其他事务修改此行；在使用以下语句时，Oracle 会自动应用行级锁：

1. INSERT、UPDATE、DELETE、SELECT … FOR UPDATE [OF columns] [WAIT n | NOWAIT];

2. SELECT … FOR UPDATE 语句允许用户一次锁定多条记录进行更新

3. 使用 COMMIT 或 ROLLBACK 语句释放锁。

19.1.8.2. 表级锁

表示对当前操作的整张表加锁，它实现简单，资源消耗较少，被大部分 MySQL 引擎支持。最常使 用的 MYISAM 与 INNODB 都支持表级锁定。表级锁定分为表共享读锁（共享锁）与表独占写锁 （排他锁）。

19.1.8.1. 页级锁

页级锁是 MySQL 中锁定粒度介于行级锁和表级锁中间的一种锁。表级锁速度快，但冲突多，行级 冲突少，但速度慢。所以取了折衷的页级，一次锁定相邻的一组记录。BDB 支持页级锁

19.1.9. 基于 Redis 分布式锁

1. 获取锁的时候，使用 setnx（SETNX key val：当且仅当 key 不存在时，set 一个 key 为 val 的字符串，返回 1；若 key 存在，则什么都不做，返回 0）加锁，锁的 value 值为一个随机生成的 UUID，在释放锁的时候进行判断。并使用 expire 命令为锁添

加一个超时时间，超过该时间则自动释放锁。

2. 获取锁的时候调用 setnx，如果返回 0，则该锁正在被别人使用，返回 1 则成功获取 锁。 还设置一个获取的超时时间，若超过这个时间则放弃获取锁。

3. 释放锁的时候，通过 UUID 判断是不是该锁，若是该锁，则执行 delete 进行锁释放。

19.1.10. 分区分表

分库分表有垂直切分和水平切分两种。

垂直切分(按照功能模块)

 将表按照功能模块、关系密切程度划分出来，部署到不同的库上。例如，我们会建立定义数 据库 workDB、商品数据库 payDB、用户数据库 userDB、日志数据库 logDB 等，分别用于存储项目数据定义表、商品定义表、用户数据表、日志数据表等。

 

水平切分(按照规则划分存储)

 当一个表中的数据量过大时，我们可以把该表的数据按照某种规则，例如 userID 散列，进行划分，然后存储到多个结构相同的表，和不同的库上。

 

19.1.11. 两阶段提交协议

分布式事务是指会涉及到操作多个数据库的事务,在分布式系统中，各个节点之间在物理上相互独立，通过网络进行沟通和协调。

XA 就是 X/Open DTP 定义的交易中间件与数据库之间的接口规范（即接口函数），交易中间件用它来通知数据库事务的开始、结束以及提交、回滚等。 XA 接口函数由数据库厂商提供。

二阶段提交(Two-phaseCommit)是指，在计算机网络以及数据库领域内，为了使基于分布式系统 架构下的所有节点在进行事务提交时保持一致性而设计的一种算法(Algorithm)。通常，二阶段提 交也被称为是一种协议(Protocol))。在分布式系统中，每个节点虽然可以知晓自己的操作时成功或者失败，却无法知道其他节点的操作的成功或失败。当一个事务跨越多个节点时，为了保持事

务的 ACID 特性，需要引入一个作为协调者的组件来统一掌控所有节点(称作参与者)的操作结果并最终指示这些节点是否要把操作结果进行真正的提交(比如将更新后的数据写入磁盘等等)。因此，二阶段提交的算法思路可以概括为：参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。

19.1.11.1. 准备阶段

事务协调者(事务管理器)给每个参与者(资源管理器)发送 Prepare 消息，每个参与者要么直接返回失败(如权限验证失败)，要么在本地执行事务，写本地的 redo 和 undo 日志，但不提交，到达一种“万事俱备，只欠东风”的状态。

19.1.11.2. 提交阶段

如果协调者收到了参与者的失败消息或者超时，直接给每个参与者发送回滚(Rollback)消息；否则， 发送提交(Commit)消息；参与者根据协调者的指令执行提交或者回滚操作，释放所有事务处理过 程中使用的锁资源。(注意:必须在最后阶段释放锁资源)

19.1.11.3. 缺点

同步阻塞问题

1、执行过程中，所有参与节点都是事务阻塞型的。

单点故障

2、由于协调者的重要性，一旦协调者发生故障。参与者会一直阻塞下去。

数据不一致（脑裂问题）

3、在二阶段提交的阶段二中，当协调者向参与者发送 commit 请求之后，发生了局部网络异 常或者在发送 commit 请求过程中协调者发生了故障，导致只有一部分参与者接受到了 commit 请求。于是整个分布式系统便出现了数据部一致性的现象(脑裂现象)。

二阶段无法解决的问题（数据状态不确定）

4、协调者再发出 commit 消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了。那 么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道 事务是否被已经提交。

19.1.12. 三阶段提交协议

三阶段提交（ Three-phase commit ） ， 也 叫 三 阶 段 提 交 协 议 （ Three-phase commit protocol），是二阶段提交（2PC）的改进版本。

与两阶段提交不同的是，三阶段提交有两个改动点。

1、引入超时机制。同时在协调者和参与者中都引入超时机制。

2、在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是 一致的。也就是说，除了引入超时机制之外，3PC 把 2PC 的准备阶段再次一分为二，这样三阶段提交就有 CanCommit、PreCommit、DoCommit 三个阶段。

19.1.12.1. CanCommit 阶段

协调者向参与者发送 commit 请求，参与者如果可以提交就返回 Yes 响应，否则返回 No 响应。

19.1.12.2. PreCommit 阶段

协调者根据参与者的反应情况来决定是否可以继续进行，有以下两种可能。假如协调者从所有的 参与者获得的反馈都是 Yes 响应，那么就会执行事务的预执行假如有任何一个参与者向协调者发送 了 No 响应，或者等待超时之后，协调者都没有接到参与者的响应，那么就执行事务的中断。

19.1.12.3. doCommit 阶段

该阶段进行真正的事务提交，主要包含 1.协调这发送提交请求 2.参与者提交事务 3.参与者响应反 馈（ 事务提交完之后，向协调者发送 Ack 响应。）4.协调者确定完成事务。

19.1.13. 柔性事务

19.1.13.1. 柔性事务

在电商领域等互联网场景下，传统的事务在数据库性能和处理能力上都暴露出了瓶颈。在分布式 领域基于 CAP 理论以及 BASE 理论，有人就提出了 柔性事务 的概念。CAP（一致性、可用性、分 区容忍性）理论大家都理解很多次了，这里不再叙述。说一下 BASE 理论，它是在 CAP 理论的基 础之上的延伸。包括 基本可用（Basically Available）、柔性状态（Soft State）、最终一致性 （Eventual Consistency）。 通常所说的柔性事务分为：两阶段型、补偿型、异步确保型、最大努力通知型几种。

两阶段型

1、就是分布式事务两阶段提交，对应技术上的 XA、JTA/JTS。这是分布式环境下事务处理的 典型模式。

补偿型

2、TCC 型事务（Try/Confirm/Cancel）可以归为补偿型。

WS-BusinessActivity 提供了一种基于补偿的 long-running 的事务处理模型。服务器 A 发起事务， 服务器 B 参与事务，服务器 A 的事务如果执行顺利，那么事务 A 就先行提交，如果事务 B 也执行 顺利，则事务 B 也提交，整个事务就算完成。但是如果事务 B 执行失败，事务 B 本身回滚，这时 事务 A 已经被提交，所以需要执行一个补偿操作，将已经提交的事务 A 执行的操作作反操作，恢 复到未执行前事务 A 的状态。这样的 SAGA 事务模型，是牺牲了一定的隔离性和一致性的，但是 提高了 long-running 事务的可用性。

 

异步确保型

3、通过将一系列同步的事务操作变为基于消息执行的异步操作, 避免了分布式事务中的同步

阻塞操作的影响。

最大努力通知型（多次尝试）

4、这是分布式事务中要求最低的一种, 也可以通过消息中间件实现, 与前面异步确保型操作不 同的一点是, 在消息由 MQ Server 投递到消费者之后, 允许在达到最大重试次数之后正常 结束事务。

19.1.14. CAP

CAP 原则又称 CAP 定理，指的是在一个分布式系统中， Consistency（一致性）、 Availability （可用性）、Partition tolerance（分区容错性），三者不可得兼。

一致性（C）：

1. 在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份 最新的数据副本）

可用性（A）：

2. 在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备 高可用性）

分区容忍性（P）：

3. 以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性， 就意味着发生了分区的情况，必须就当前操作在 C 和 A 之间做出选择。

 

 

                                     ------------------------------------------- < END >---------------------------------------

 

 

 

 

 

 

 

 

 

本文地址：https://blog.csdn.net/qq_31653405/article/details/107185550