常见的网络协议有哪些？

第一章 概述

电信网、计算机网和有线电视网 三网合一

TCP/IP是当前的因特网协议簇的总称，TCP和 IP是其中的两个最重要的协议。

RFC标准轨迹由3个成熟级构成：提案标准、草案标准和标准。

第二章 计算机网络与因特网体系结构

根据拓扑结构：计算机网络可以分为总线型网、环型网、星型网和格状网。

根据覆盖范围：计算机网络可以分为广域网、城域网、局域网和个域网。

网络可以划分成：资源子网和通信子网两个部分。

网络协议是通信双方共同遵守的规则和约定的集合。网络协议包括三个要素，即语法、语义和同步规则。

通信双方对等层中完成相同协议功能的实体称为对等实体 ，对等实体按协议进行通信。

有线接入技术分为铜线接入、光纤接入和混合光纤同轴接入技术。

无线接入技术主要有卫星接入技术、无线本地环路接入和本地多点分配业务。

网关实现不同网络协议之间的转换。

因特网采用了网络级互联技术，网络级的协议转换不仅增加了系统的灵活性，而且简化了网络互联设备。

因特网对用户隐藏了底层网络技术和结构，在用户看来，因特网是一个统一的网络。

因特网将任何一个能传输数据分组的通信系统都视为网络，这些网络受到网络协议的平等对待。

TCP/IP 协议分为 4 个协议层 ：网络接口层、网络层、传输层和应用层。

IP 协议既是网络层的核心协议 ，也是 TCP/IP 协议簇中的核心协议。

第四章 地址解析

建立逻辑地址与物理地址之间 映射的方法 通常有静态映射和动态映射。动态映射是在需要获得地址映射关系时利用网络通信协议直接从其他主机上获得映射信息。 因特网采用了动态映射的方法进行地址映射。

获得逻辑地址与物理地址之间的映射关系称为地址解析 。

地址解析协议 ARP 是将逻辑地址（ IP 地址）映射到物理地址的动态映射协议。

ARP 高速缓存中含有最近使用过的 IP 地址与物理地址的映射列表。

在 ARP 高速缓存中创建的静态表项是永不超时的地址映射表项。

反向地址解析协议 RARP 是将给定的物理地址映射到逻辑地址（ IP地址）的动态映射。RARP需要有RARP 服务器帮助完成解析。

ARP请求和 RARP请求，都是采用本地物理网络广播实现的。

在代理ARP中，当主机请求对隐藏在路由器后面的子网中的某一主机 IP 地址进行解析时，代理 ARP路由器将用自己的物理地址作为解析结果进行响应。

第五章 IP协议

IP是不可靠的无连接数据报协议，提供尽力而为的传输服务。

TCP/IP 协议的网络层称为IP层

IP数据报在经过路由器进行转发时一般要进行三个方面的处理：首部校验、路由选择、数据分片

IP层通过IP地址实现了物理地址的统一，通过IP数据报实现了物理数据帧的统一。 IP 层通过这两个方面的统一屏蔽了底层的差异，向上层提供了统一的服务。

IP 数据报由首部和数据两部分构成 。首部分为定长部分和变长部分。选项是数据报首部的变长部分。定长部分 20 字节，选项不超过40字节。

IP 数据报中首部长度以 32 位字为单位 ，数据报总长度以字节为单位，片偏移以 8 字节（ 64 比特）为单位。数据报中的数据长度 =数据报总长度－首部长度× 4。

IP 协议支持动态分片 ，控制分片和重组的字段是标识、标志和片偏移， 影响分片的因素是网络的最大传输单元 MTU ，MTU 是物理网络帧可以封装的最大数据字节数。通常不同协议的物理网络具有不同的MTU 。分片的重组只能在信宿机进行。

生存时间TTL是 IP 数据报在网络上传输时可以生存的最大时间，每经过一个路由器，数据报的TTL值减 1。

IP数据报只对首部进行校验 ，不对数据进行校验。

IP选项用于网络控制和测试 ，重要包括严格源路由、宽松源路由、记录路由和时间戳。

IP协议的主要功能 包括封装 IP 数据报，对数据报进行分片和重组，处理数据环回、IP选项、校验码和TTL值，进行路由选择等。

在IP 数据报中与分片相关的字段是标识字段、标志字段和片偏移字段。

数据报标识是分片所属数据报的关键信息，是分片重组的依据

分片必须满足两个条件： 分片尽可能大，但必须能为帧所封装 ;片中数据的大小必须为 8 字节的整数倍 ，否则 IP 无法表达其偏移量。

分片可以在信源机或传输路径上的任何一台路由器上进行，而分片的重组只能在信宿机上进行片重组的控制主要根据 数据报首部中的标识、标志和片偏移字段

IP选项是IP数据报首部中的变长部分，用于网络控制和测试目的 (如源路由、记录路由、时间戳等 )，IP选项的最大长度 不能超过40字节。

1、IP 层不对数据进行校验。

原因：上层传输层是端到端的协议，进行端到端的校验比进行点到点的校验开销小得多，在通信线路较好的情况下尤其如此。另外，上层协议可以根据对于数据可靠性的要求， 选择进行校验或不进行校验，甚至可以考虑采用不同的校验方法，这给系统带来很大的灵活性。

2、IP协议对IP数据报首部进行校验。

原因： IP 首部属于 IP 层协议的内容，不可能由上层协议处理。

IP 首部中的部分字段在点到点的传递过程中是不断变化的，只能在每个中间点重新形成校验数据，在相邻点之间完成校验。

3、分片必须满足两个条件：

分片尽可能大，但必须能为帧所封装 ;

片中数据的大小必须为8字节的整数倍，否则IP无法表达其偏移量。

第六章 差错与控制报文协议（ICMP）

ICMP 协议是 IP 协议的补充，用于IP层的差错报告、拥塞控制、路径控制以及路由器或主机信息的获取。

ICMP既不向信宿报告差错，也不向中间的路由器报告差错，而是 向信源报告差错 。

ICMP与 IP协议位于同一个层次，但 ICMP报文被封装在IP数据报的数据部分进行传输。

ICMP 报文可以分为三大类：差错报告、控制报文和请求 /应答报文。

ICMP 差错报告分为三种 ：信宿不可达报告、数据报超时报告和数据报参数错报告。数据报超时报告包括 TTL 超时和分片重组超时。

数据报参数错包括数据报首部中的某个字段的值有错和数据报首部中缺少某一选项所必须具有的部分参数。

ICMP控制报文包括源抑制报文和重定向报文。

拥塞是无连接传输时缺乏流量控制机制而带来的问题。ICMP 利用源抑制的方法进行拥塞控制 ，通过源抑制减缓信源发出数据报的速率。

源抑制包括三个阶段 ：发现拥塞阶段、解决拥塞阶段和恢复阶段。

ICMP 重定向报文由位于同一网络的路由器发送给主机，完成对主机的路由表的刷新。

ICMP 回应请求与应答不仅可以被用来测试主机或路由器的可达性，还可以被用来测试 IP 协议的工作情况。

ICMP时间戳请求与应答报文用于设备间进行时钟同步 。

主机利用 ICMP 路由器请求和通告报文不仅可以获得默认路由器的 IP 地址，还可以知道路由器是否处于活动状态。

第七章 IP 路由

数据传递分为直接传递和间接传递 ，直接传递是指直接传到最终信宿的传输过程。间接传递是指在信

源和信宿位于不同物理网络时，所经过的一些中间传递过程。

TCP/IP 采用 表驱动的方式 进行路由选择。在每台主机和路由器中都有一个反映网络拓扑结构的路由表，主机和路由器能够根据 路由表 所反映的拓扑信息找到去往信宿机的正确路径。

通常路由表中的 信宿地址采用网络地址 。路径信息采用去往信宿的路径中的下一跳路由器的地址表示。

路由表中的两个特殊表目是特定主机路由和默认路由表目。

路由表的建立和刷新可以采用两种不同 的方式：静态路由和动态路由。

自治系统 是由独立管理机构所管理的一组网络和路由器组成的系统。

路由器自动获取路径信息的两种基本方法是向量—距离算法和链路 —状态算法。

1、向量 — 距离 (Vector-Distance，简称 V—D)算法的基本思想 ：路由器周期性地向与它相邻的路由器广播路径刷新报文，报文的主要内容是一组从本路由器出发去往信宿网络的最短距离，在报文中一般用(V，D)序偶表示，这里的 V 代表向量，标识从该路由器可以到达的信宿 (网络或主机 )，D 代表距离，指出从该路由器去往信宿 V 的距离， 距离 D 按照去往信宿的跳数计。 各个路由器根据收到的 (V ，D)报文，按照最短路径优先原则对各自的路由表进行刷新。

向量 —距离算法的优点是简单，易于实现。

缺点是收敛速度慢和信息交换量较大。

2、链路 — 状态 (Link-Status，简称 L-S)算法的基本思想 ：系统中的每个路由器通过从其他路由器获得的信息，构造出当前网络的拓扑结构，根据这一拓扑结构，并利用 Dijkstra 算法形成一棵以本路由器为根的最短路径优先树， 由于这棵树反映了从本节点出发去往各路由节点的最短路径， 所以本节点就可以根据这棵最短路径优先树形成路由表。

动态路由所使用的路由协议包括用于自治系统内部的 内部网关协 议和用于自治系统之间的外部网关协议。

RIP协议在基本的向量 —距离算法的基础上 ，增加了对路由环路、相同距离路径、失效路径以及慢收敛问题的处理。 RIP 协议以路径上的跳数作为该路径的距离。 RIP 规定，一条有效路径的距离不能超过

RIP不适合大型网络。

RIP报文被封装在 UDP 数据报中传输。RIP使用 UDP 的 520 端口号。

3、RIP 协议的三个要点

仅和相邻路由器交换信息。

交换的信息是当前本路由器所知道的全部信息，即自己的路由表。

按固定的时间间隔交换路由信息，例如，每隔30秒。

4、RIP 协议的优缺点

RIP 存在的一个问题是当网络出现故障时，要经过比较长的时间才能将此信息传送到所有的路由器。

RIP 协议最大的优点就是实现简单，开销较小。

RIP 限制了网络的规模，它能使用的最大距离为15（16表示不可达）。

路由器之间交换的路由信息是路由器中的完整路由表，因而随着网络规模的扩大，开销也就增加。

5、为了防止计数到无穷问题，可以采用以下三种技术。

1）水平 分割 法(Split Horizon) 水平分割法的基本思想：路由器从某个接口接收到的更新信息不允许再从这个接口发回去。在图 7-9 所示的例子中， R2 向 R1 发送 V-D 报文时，不能包含经过 R1 去往 NET1的路径。因为这一信息本身就是 R1 所产生的。

2） 保持法 (Hold Down) 保持法要求路由器在得知某网络不可到达后的一段时间内，保持此信息不变，这段时间称为保持时间，路由器在保持时间内不接受关于此网络的任何可达性信息。

3） 毒性逆转法 (Poison Reverse)毒性逆转法是水平分割法的一种变化。当从某一接口发出信息时，凡是从这一接口进来的信息改变了路由表表项的， V-D 报文中对应这些表目的距离值都设为无穷 (16)。

OSPF 将自治系统进一步划分为区域，每个区域由位于同一自治系统中的一组网络、主机和路由器构成。区域的划分不仅使得广播得到了更好的管理，而且使 OSPF能够支持大规模的网络。

OSPF是一个链路 —状态协议。当网络处于收敛状态时， 每个 OSPF路由器利用 Dijkstra 算法为每个网络和路由器计算最短路径，形成一棵以本路由器为根的最短路径优先 (SPF)树，并根据最短路径优先树构造路由表。

OSPF直接使用 IP。在IP首部的协议字段， OSPF协议的值为 89。

BGP 是采用路径 —向量算法的外部网关协议 ， BGP 支持基于策略的路由，路由选择策略与政治、经济或安全等因素有关。

BGP 报文分为打开、更新、保持活动和通告 4 类。BGP 报文被封装在 TCP 段中传输，使用TCP的179 号端口 。

第八章 传输层协议

传输层承上启下，屏蔽通信子网的细节，向上提供通用的进程通信服务。传输层是对网络层的加强与弥补。 TCP 和 UDP 是传输层 的两大协议。

端口分配有两种基本的方式：全局端口分配和本地端口分配。

在因特网中采用一个 三元组 （协议，主机地址，端口号）来全局惟一地标识一个进程。用一个五元组（协议 ,本地主机地址 ,本地端口号 ,远地主机地址 ,远地端口号）来描述两个进程的关联。

TCP 和 UDP 都是提供进程通信能力的传输层协议。它们各有一套端口号，两套端口号相互独立，都是从0到 65535。

TCP 和 UDP 在计算校验和时引入伪首部的目的是为了能够验证数据是否传送到了正确的信宿端。

为了实现数据的可靠传输， TCP 在应用进程间 建立传输连接 。TCP 在建立连接时采用 三次握手方法解决重复连接的问题。在拆除连接时采用 四次握手 方法解决数据丢失问题。

建立连接前，服务器端首先被动打开其熟知的端口，对端口进行监听。当客户端要和服务器建立连接时，发出一个主动打开端口的请求，客户端一般使用临时端口。

TCP 采用的最基本的可靠性技术 包括流量控制、拥塞控制和差错控制。

TCP 采用 滑动窗口协议 实现流量控制，滑动窗口协议通过发送方窗口和接收方窗口的配合来完成传输控制。

TCP 的 拥塞控制 利用发送方的窗口来控制注入网络的数据流的速度。发送窗口的大小取通告窗口和拥塞窗口中小的一个。

TCP通过差错控制解决 数据的毁坏、重复、失序和丢失等问题。

UDP 在 IP 协议上增加了进程通信能力。此外 UDP 通过可选的校验和提供简单的差错控制。但UDP不提供流量控制和数据报确认 。

1、传输层（ Transport Layer）的任务 是向用户提供可靠的、透明的端到端的数据传输，以及差错控制和流量控制机制。

2 “传输层提供应用进程间的逻辑通信 ”。“逻辑通信 ”的意思是：传输层之间的通信好像是沿水平方向传送数据。但事实上这两个传输层之间并没有一条水平方向的物理连接。

TCP 提供的可靠传输服务有如下五个特征 ：

面向数据流 ; 虚电路连接 ; 有缓冲的传输 ; 无结构的数据流 ; 全双工连接

3、TCP 采用一种名为 “带重传功能的肯定确认 （ positive acknowledge with retransmission ） ”的技术作为提供可靠数据传输服务的基础。

第九章 域名系统

字符型的名字系统为用户提供了非常直观、便于理解和记忆的方法，非常符合用户的命名习惯。

因特网采用层次型命名机制 ，层次型命名机制将名字空间分成若干子空间，每个机构负责一个子空间的管理。 授权管理机构可以将其管理的子名字空间进一步划分， 授权给下一级机构管理。名字空间呈一种树形结构。

域名由圆点 “．”分开的标号序列构成 。若域名包含从树叶到树根的完整标号串并以圆点结束，则称该域名为完全合格域名FQDN。

常用的三块顶级域名 为通用顶级域名、国家代码顶级域名和反向域的顶级域名。

TCP/IP 的域名系统是一个有效的、可靠的、通用的、分布式的名字 —地址映射系统。区域是 DNS 服务器的管理单元，通常是指一个 DNS 服务器所管理的名字空间 。区域和域是不同的概念，域是一个完整的子树，而区域可以是子树中的任何一部分。

名字服务器的三种主要类型是 主名字服务器、次名字服务器和惟高速缓存名字服务器。主名字服务器拥有一个区域文件的原始版本，次名字服务器从主名字服务器那里获得区域文件的拷贝，次名字服务器通过区域传输同主名字服务器保持同步。

DNS 服务器和客户端属于 TCP/IP 模型的应用层， DNS 既可以使用 UDP，也可以使用 TCP 来进行通信。 DNS 服务器使用 UDP 和 TCP 的 53 号熟知端口。

DNS 服务器能够使用两种类型的解析： 递归解析和反复解析 。

DNS 响应报文中的回答部分、授权部分和附加信息部分由资源记录构成，资源记录存放在名字服务器的数据库中。

顶级域 cn 次级域 educn 子域 njusteducn 主机 serynjusteducn

TFTP ：普通文件传送协议（ Trivial File Transfer Protocol ）

RIP： 路由信息协议 (Routing Information Protocol)

OSPF 开放最短路径优先 (Open Shortest Path First)协议。

EGP 外部网关协议 (Exterior Gateway Protocol)

BGP 边界网关协议 (Border Gateway Protocol)

DHCP 动态主机配置协议（ Dynamic Host Configuration Protocol）

Telnet工作原理 : 远程主机连接服务

FTP 文件传输工作原理 File Transfer Protocol

SMTP 邮件传输模型 Simple Message Transfer Protocol

HTTP 工作原理

写在文前：视频版本和文字版本略有不同，想要看我深情并茂演绎，请看视频版本 (喵懂区块链22期|分片（Sharding）：以太坊太慢，“盘”他！)，思维逻辑怪，请看文案加长版。

最近以太坊由于君士坦丁堡升级（Constantinople）而出现了压倒性的积极走势，而以太坊的升级之路则犹如升级打怪一般，落入了rabbit hole，谁也不知道这洞有多深。既然是“路漫漫其修远兮”，则把脚下的每一步走好走准，则成了至关重要的点。攻破这一难点之后，以太坊的下一技术难点---Sharding分片，则又被摆到了台面上。本期《喵懂区块链》会带大家走进让以太坊快起来的法宝--- Sharding分片。

什么是sharding分片？

分片技术其实并不是什么新概念，起初是针对大型中心数据库提出的优化方案，具体来说就是将大型数据库中的数据划按照某种规则分成很多数据分片（shard），再将这些数据分片分别存放在不同的服务器中，以减小每个服务器的数据访问压力，从而提高整个数据库系统的性能。

我们举一个通俗的小例子：

比如我们平时经常使用的美团，滴滴打车等软件，就可以按照“城市”来进行分片，由于不同城市的数据不需要互通，就可以将不同城市的数据存放在不同数据库中，这样既可以把数据库服务器部署到离对应城市最近的节点上，还可以提高访问速度，何乐而不为呢？！

从上面的例子中，我大家应该对分片的概念有了初步了解，那么对应到区块链场景中来说，分片又是怎么样的呢？

以以太坊分片为例，在原有的单链系统中，公链整体的性能取决于单个节点的性能，进行分片之后，每个节点只需要承当全网部分工作，各个分片并行工作，按照Vitalik的话来说，each shard is like a separate galaxy每个分片都像是独立的小宇宙，这样效率自然噌噌噌提升！原本以太坊链全网TPS约为20，现在若增加到100个分片，那么全网TPS可以提升至2000，同理，全网容量也将提升至原来的100倍。

“每个节点只需要承担全网部分工作”，这就会引出几大问题，1怎么确定这个节点是负责哪个分片的工作？2哪些交易应该归类到哪些分片当中去？3每个节点是否只需要储存自己所在分片的交易信息（账本）？

根据以上问题的实现与否，我们可以将分片依次分为三种类型：网络分片，交易分片，状态分片。

网络分片：如何将全网节点划分到不同分片当中去。

交易分片：如何将全网交易划分到不同分片当中去。

状态分片：如何让各个节点只维护各自分片内的账本，但又不影响整个系统的安全性。

主链和分片链的区别和联系？

分片的类型我们已经明白了，那么主链（Main chain）和分片链（shard chain）有什么不同呢？

向左转|向右转

在主链中，我们知道记账的人叫做矿工，账本是存在区块当中，对应到分片链当中，则是Collator校对人和Collation校对块。

类似于区块的构成，Collation校对块也包含Collation header校对头和tansaction list具体的交易信息。

向左转|向右转

对比下来，主链和分片链本身来说，还是大同小异，但是一但要把他们联系起来，问题就变得复杂了，这里我们举个通俗的小例子类比一下：

假设，

以太坊主链=温州银行

每个分片=温州银行分行

比如：

shard1（分片1）=温州银行（杭州分行）

Shard2（分片2）=温州银行（宁波分行）

……

在这个系统中，我们就会清晰看到几大问题：1各大分行的账本如何汇总到总行里去？2各大分行的账本如何互联？

对应到主链和分片链系统当中来，则变成了1分片链和主链如何实现跨链链接？2分片之间怎么互联？甚至分叉的场景要怎么办

分片链和主链如何实现跨链链接？

为了将分片链加入到主链中，在主链上需要有一个叫做验证人管理员合约（Validator Manager Contract）VMC的特殊合约。VMC具体是这样的：

向左转|向右转

所有的验证人把它们的保证金（stake）存入 VMC当中，这些验证人就会被收录在VMC的common validator pool验证人备选池中。系统将会“隔一段时间”根据stake权益的多少随机为每个分片抽取一名验证人，将各个分片的collation header校对头信息同步到主链中去。

这里的“隔一段时间”，我们需要额外解释一下：“时间”，也叫period周期，这到底是怎么确定的呢？答案是主要看开发人员在最终代码中的实现为准，比如说我们把周期定为5个区块，那么就意味着主链出5个区块，所有分片链分别出一个collation校对块，这就间接决定了分片链的出块时间。

这种随机的形式，使得验证者无法提前预测他们何时会成为验证者，也无法预测会成为哪个分片的验证人，从而预防作恶的可能性。

如果一旦发现我们的分片验证人作恶了，他的stake权益就会被剥夺。

跨分片通信（cross-shard communication）怎么办？

比如说一个转账方小A在分片M中，收款方小B在分片N中，小A可以通过主链这个桥梁，完成扣款操作，并创建一个带有ID的 receipt收据，代表着“自己已经完成了扣款操作”，收款方小B可以根据这个 receipt ID 创建一个receipt-consuming收据消费交易，“消费”成功了之后，收款也就成功了。

向左转|向右转

分片链分叉了怎么办？（fork choice rule）

在以往的分叉情况中，都是“以最长链为主链”，在分片当中，分叉规则是“以最长主链里面的最长分片链为有效分片链（the longest valid shard chain within the longest valid main chain）”。

什么意思呢？我们举个例子：

一条主链出现了分叉，一条分叉连续跟了两个区块，同时也跟了两个Collation校对块，另一条则是一个区块和一个校对块，那么很明显，第一条是有效链。

向左转|向右转

接下来，第二条链又加了一个区块，变成两个区块和一个Collation校对块，依然很明显，第一条链仍然是有效链：

向左转|向右转

接下来，第一条链上又加了一个区块，虽然这条链上只有一个Collation校对块，但是它的主链长度已经超过了第一条，那么第二条则成为了现在的有效链，这就是分片场景下的分叉规则，首先比较主链长度，再比较分片链长度！

向左转|向右转

以太坊分片的实现是一个漫长的过程，就连Vitalik自己也说将会分阶段来逐步实现，分片到底能不能从理论走向实践，我们还是小小期待一下吧。

参考资料：

https://githubcom/ethereum/sharding/blob/develop/docs/docmd

https://www8btccom/article/348469

https://ethfansorg/posts/ethereum-sharding-and-finality

http://wwwqukuaiwangcomcn/news/11390html

分片是MongoDB提供的一种机制，其可以将大型的集合分割保存到不同的服务器上。与其他的分区方案相比，MongoDB几乎能自动为我们完成所有事情。只要我们进行简单的配置，并告诉MongoDB要分配的数据，它就可以自动维护数据在不同服务器之间的平衡。同时根据需要增减服务器，MongoDB也会自动移动平移已有数据。

分片机制提供了如下三种优势

1 对集群进行抽象，让集群“不可见”。

MongoDB自带了一个叫做mongos的专有路由进程。mongos就是掌握统一路口的路由器，其会将客户端发来的请求准确无误的路由到集群中的一个或者一组服务器上，同时会把接收到的响应拼装起来发回到客户端。

2保证集群总是可读写。

MongoDB通过多种途径来确保集群的可用性和可靠性。将MongoDB的分片和复制功能结合使用，在确保数据分片到多台服务器的同时，也确保了每分数据都有相应的备份，这样就可以确保有服务器换掉时，其他的副本可以立即接替坏掉的部分继续工作。

3使集群易于扩展。

当系统需要更多的空间和资源的时候，MongoDB使我们可以按需方便的扩充系统容量。

实现数据分割

分片(shard)是集群中存储集合数据子集的一台或者多台服务器。在生产环境中一个分片通常是一个副本集(replica set)。

片键(key)，MongoDB以其作为依据来确定需要在不同分片服务器之间移动的数据。例如我们可以选择用户名(username)字段作为分片键，现有一用户名区间[“p”,”z”],那么wufengtinghai是属于这一区间的，那么数据最终会保存到与此区间对应的分片服务器上。

分配数据到分片服务器

分配数据到分片服务器可以使用不同的方式，了解不同的方式可以加深我们对MongoDB使用方式的理解。

一分片一区间

分配数据到分片最简单的方式莫过于一个区间一个分片。假设我们有四个分片存储用户的相关信息，则我们可能会得到如下的分片和区间的对应关系。

这种分片方式非常简单易懂，但是在一个大型繁忙的系统中却会带来许多的不便。假如大量的用户使用首字母在“a”,”f”)中的名字来注册，这将会导致分片1比较大，因此需要将其一部分文档移动到分片2上，我们可以调整分片1对应区间”a”,”c”),使分片2的区间变成”c”,”n”)。

如果移动数据后，分片2因此过载怎么办？假设分片1和分片2各有500G数据，而分片3和分片4各自有300G数据。那么按照这个方案，最终需要一连串的复制，总共算下来需要移动400G数据，考虑到需要在集群的服务器之间移动这些数据，可见移动数据量之大。

如果需要新加分片服务器进行水平扩展呢？假设此时每个分片上都有了500G数据，那么我们现在需要将分片4上的400G数据移动到分片5，将分片3的300G数据移动到分片4，将分片2的200G数据移动到分片3，将分片1的100G数据移动到分片2，整整移动了1T的数据！

随着分片数量和数据量的增长，这种噩梦将会持续下去，因此MongoDB不会采用这种方式。

一分片多区间

如果我们采用一分片多区间的方式，我们可以将分片1上的数据划分为两个区间，”a”,”d”)包含400G数据，”d”,”f”)包含100G数据，同样我们也可以对分片2做类似的处理，得到区间”f”,”j”)和“j”,”n”)。现在我们只需要将分片1上的”d”,”f”)数据移动到分片4，将分片2的“j”,”n”)的数据移动到分片3。这样我们仅仅只需要移动200G数据。

如果要添加新分片，可以从每个分片顶端取100G数据并将其移动到新的分片上，这样仅仅只需要移动400G数据即可。

MongoDB就是利用这种方式，当一个分片的数据越来越大时，其会自动分割片键区间，并将分片的数据进行分割并移动到其他分片。

REmote DIctionary Server(Redis) 是一个由Salvatore Sanfilippo写的key-value存储系统

Redis是一个开源的使用ANSIC语言编写、遵守BSD协议、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API

它通常被称为数据结构服务器，因为值(value)可以是 字符串(String), 哈希(Map), 列表(list), 集合(sets)和有序集合(sorted sets)等类型

Redis 简介

Redis是完全开源免费的，遵守BSD协议，是一个高性能的key-value数据库

Redis与其他key - value缓存产品有以下三个特点：

①Redis支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用。

②Redis不仅仅支持简单的key-value类型的数据，同时还提供list，set，zset，hash等数据结构的存储。

③Redis支持数据的备份，即master-slave模式的数据备份。

Redis 的特点

高性能：Redis 将所有数据集存储在内存中，可以在入门级 Linux 机器中每秒写(SET)11 万次，读(GET)81 万次

持久化：当所有数据都存在于内存中时，可以根据自上次保存以来经过的时间和/或更新次数，使用灵活的策略将更改异步保存在磁盘上

数据结构：Redis 支持各种类型的数据结构，例如字符串、散列、集合、列表、带有范围查询的有序集、位图、超级日志和带有半径查询的地理空间索引

原子操作：处理不同数据类型的 Redis 操作是原子操作，因此可以安全地 SET 或 INCR 键，添加和删除集合中的元素等

支持的语言：Redis 支持许多语言，如C、C++、Erlang、Go、Haskell、Java、JavaScript(Nodejs)、Lua、Objective-C、Perl、PHP、Python、R、Ruby、Rust、Scala、Smalltalk等

主/从复制：Redis 遵循非常简单快速的主/从复制。配置文件中只需要一行来设置它，而 Slave 在 Amazon EC2 实例上完成 10 MM

key 集的初始同步只需要 21 秒

分片：Redis 支持分片。与其他键值存储一样，跨多个 Redis 实例分发数据集非常容易

可移植：Redis 是用 C 编写的，适用于大多数 POSIX 系统，如 Linux、BSD、Mac OS X、Solaris 等

链路层具有最大传输单元MTU这个特性，它限制了数据帧的最大长度，不同的网络类型都有一个上限值。以太网的MTU是1500，你可以用 netstat -i 命令查看这个值。如果IP层有数据包要传，而且数据包的长度超过了MTU，那么IP层就要对数据包进行分（fragmentation）操作，使每一片的长度都小于或等于MTU。我们假设要传输一个UDP数据包，以太网的MTU为1500字节，一般IP首部为20字节，UDP首部为8字节，数据的净荷（payload）部分预留是1500-20-8=1472字节。如果数据部分大于1472字节，就会出现分片现象。

分片（sharding）是数据库分区的一种，它将大型数据库分成更小、更快、更容易管理的部分，这些部分叫做数据碎片。碎片这个词意思就是整体的一小部分。

Jason Tee表示：“简言之，分片（sharding）数据库需要将数据库（database）分成多个没有共同点的小型数据库，且它们可以跨多台服务器传播。”

技术上来说，分片（sharding）是水平分区的同义词。在实际操作中，这个术语常用来表示让一个大型数据库更易于管理的所有数据库分区。

分片（sharding）的核心理念基于一个想法：数据库大小以及数据库上每单元时间内的交易数呈线型增长，查询数据库的响应时间（response time）以指数方式增长。

另外，在一个地方创建和维护一个大型数据库的成本会成指数增长，因为数据库将需要高端的计算机。相反地，数据碎片可以分布到大量便宜得多的商用服务器上。就硬件和软件要求而言，数据碎片相对来说没什么限制。

在某些情况中，数据库分片（sharding）可以很简单地完成。按地理位置拆分用户数据库就是一个常见的例子。位于东海岸的用户被分到一台服务器上，在西海岸的用户被分在另一台服务器上。假设没有用户有多个地理位置，这种分区很易于维护和创建规则。

但是数据分片（sharding）在某些情况下会是更为复杂的过程。例如，一个数据库持有很少结构化数据，分片它就可能非常复杂，并且结果碎片可能会很难维护。

分片过程

对于发送端发送的每份IP数据报来说，其标识字段都包含一个唯一值。该值在数据报分片时被复制到每个片中。标志字段用其中一个比特来表示“更多的片”。除了最后一片外，其他每个组成数据报的片都要把该比特置1。片偏移字段指的是该片偏移原始数据报开始处的位置。另外，当数据报被分片后，每个片的总长度值要改为该片的长度值。

　　最后，标志字段中有一个比特称作“不分片”位。如果将这一比特置1，IP将不对数据报进行分片。相反把数据报丢弃并发送一个ICMP差错报文给起始端。

　　当IP数据报被分片后，每一片都成为一个分组，具有自己的IP首部，并在选择路由时与其他分组独立。这样，当数据报的这些片到达目的端时有可能会失序，但是在IP首部中有足够的信息让接收端能正确组装这些数据报片。

ES支持集群模式，是一个分布式系统，其好处主要有两个∶

es集群由多个ES 实例组成。不同集群通过集群名字来区分，可通过 clustername 进行修改，默认为elasticsearch。每个ES实例本质上是一个 JVM 进程，且有自己的名字，通过 nodename 进行修改

ES集群相关的数据称为 cluster state ，主要记录如下信息∶节点信息，比如节点名称、连接地址等；索引信息，比如索引名称、配置等

可以修改 cluster state 的节点称为master节点，一个集群只能有一个 cluster state 存储在每个节点上，master维护最新版本并同步给其他节点

master节点是通过集群中所有节点选举产生的，可以被选举的节点称为 master-eligible 节点 ，相关配置如下: nodemaster: true

处理请求的节点即为coordinating节点，该节点为所有节点的默认角色，不能取消。路由请求到正确的节点处理，比如创建索引的请求到master节点

存储数据的节点即为data节点，默认节点都是data类型，相关配置如下∶ nodedata: true

谈及副本和分片两个概念之前，我们先说一下这两个概念存在的意义： 解决系统可用性和增大系统容量

我们想象这样一个场景，我们的数据只存放在一台ES服务器上，那么一旦这台ES出现宕机或者其他不可控因素影响的话，我们除了丧失了服务的可用性外，可能还存在着数据丢失的可能。同时，单机服务的存储容量也无法应对项目对大数据量的要求。

系统可用性可以分为 服务可用性 和 数据可用性

服务可用性 含义为：当前服务挂掉后，是否有其他服务器顶替当前节点提供服务支持。

数据可用性 含义为：当前服务挂掉后，存储在当前服务器上的数据，是否还可以对外提供访问和修改的服务。

副本可以理解为是某个数据的复制体，副本和源数据内容一致。副本的存在可以有效地满足系统可用性的需求，比如说，我们可以在原有节点的基础上复制一个和源节点一模一样的节点，这样一旦原有节点挂掉了，另外一个节点也还是可以替代源节点提供服务，而且复制出来的节点拥有和源节点一样的数据，这样也保障了数据可用性。

我们在上一小节讲到可以使用副本来解决系统可用性的问题，但是这里存在一个问题，不管存在多少个副本（节点），都无法增大源节点的存储空间。在这个问题上，ES引入了Shard分片这个概念来解决问题。

看完分片的特点后可能还有人不太清楚到底什么是分片，其实分片是n/1个源节点数据。比如说原ES集群中只有一个主节点，所有的索引数据都存储在这个节点上。现在我们将某个索引数据分成3份，分别存放在3个ES节点上，那么每台ES服务器上就各自有1个分片shard。该索引的所有节点Shard分片的集合，就是索引的全部数据。

下面我们来演示一下：

为了更好的了解ES的分片机制，大家不妨在上面的案例上进一步思考两个问题：

答案是不能。原因是我们创建索引时定义的分片数量只有3个，且都已经落在了3个节点上。所以即使再增加多一个节点，也不会有对应的Shard分片可以落在新的节点上，并不能扩大 test_shard_index 的数据容量。

答案是不能。因为新增的副本也是分布在这3个节点上，还是利用了同样的资源。如果要增加吞吐量，还需要新增节点。

通过上面两个问题，相信大家已经可以认识到分片的重要性，分片数过小，会导致后续无法通过增加节点实现水平扩容；（副本）分片数过大会导致一个节点上分布过多分片，造成资源浪费，同时会影响查询性能

集群健康状况，包括以下三种: green健康状态，指所有主副分片都正常分配； yellow指所有主分片都正常分配，但是有副本分片未正常分配； red表示有主分片未分配

我们可以通过这个api查看集群的状态信息： GET _cluster/health

我们也可以通过cerebro或者head插件来直接获取当前集群的状态

需要注意的是，即使当前集群的状态为 red ，也并不代表当前的ES丧失了提供服务的能力。只是说未被分配主分片的索引无法正常存储和操作而已。

这里故障转移的意思是，当ES集群出现某个或者多个节点宕机的情况，ES实现服务可用性的应对策略。

这里我们新建一个分片为3，副本为1的索引，分片分别分布在三个节点，此时集群为 green

当master节点所在机器宕机导致服务终止，此时集群会如何处理呢

我们可以看到，从node1主节点宕机到ES恢复集群可用性的过程中，ES有着自己的故障转移机制，保障了集群的高可用性。我们也可以在自己的本地上去进行试验，建好索引后，kill掉主节点，观察集群状态就行。

同时，此时就算node2宕机了，那么node3也能够很快的恢复服务的提供能力。

我们知道，我们创建的文档最终会存储在分片上，那么在分布式集群的基础上，ES集群是怎么判断当前该文档最终应该落在哪一个分片上呢？

很显然，我们需要一个可以实现文档均匀分布到各个分片上的映射算法，那么常见的随机算法和round-robin（轮询）算法可以满足需要吗？答案是不可以，这两个算法虽然可以实现文档均匀分布分片的存储需要，但是当我们通过 DocumentId 查询文档时，ES并不能知道这个文档ID到底存储在了哪个节点的分片上，所以只能够从所有分片上检索，时间长。如果我们为这个问题建立一个文档和分片映射关系的表，虽然确实可以快速定位到文档对应的存储分片，但是当文档的数据量很大的时候，那么检索的效率也会随之变低。

对于上面这个问题，ES提供的解决方法是 建立文档到分片的映射算法

es 通过如下的公式计算文档对应的分片：

hash算法 保证可以将数据均匀地分散在分片中

routing 是一个关键参数，默认是文档id，也可以自行指定

number_of_primary_shards 是主分片数

我们可以看到，该算法与主分片数相关， 这也是分片数一旦确定后便不能更改的原因

我们已经知道了ES是如何将文档映射到分片上去了，下面我们就来详细讲解一下文档创建、读取的流程。

脑裂问题，英文为 split-brain ，是分布式系统中的经典网络问题，如下图所示:

3个节点组成的集群，突然node1的网络和其他两个节点中断

解决方案为 仅在可选举master-eligible节点数大于等于quorum时才可以进行master选举

在讲文档搜索实时性之前，先讲一下倒排索引的不可变更特性。由于倒排索引一旦生成，不可变更的特定，使得其有着以下3点好处：

下面，将针对Lucene实现文档实时性搜索的几个动作进行讲解，分析其是如何在新增文档后实现ES的搜索实时性的。

我们从上面的描述中知道，当我们新增了一个文档后会新增一个倒排索引文件 segment ，但是 segment 写入磁盘的时间依然比较耗时（难以实现实时性），所以ES借助文件系统缓存的特性， 先将 segment 在缓存中创建并开放查询来进一步提升实时性 ，该过程在es中被称为refresh。

在refresh之前文档会先存储在一个buffer中，refresh时将 buffer中的所有文档清空并生成 segment

es默认每1秒执行一次refresh，因此文档的实时性被提高到1秒 ，这也是es被称为近实时(Near Real Time)的原因

reflush虽然通过 将文档存放在缓存中 的方式实现了秒级别的实时性，但是如果在内存中的segment还没有写入磁盘前发生了宕机，那么其中的文档就无法恢复了，如何解决这个问题呢

ES 引入 translog 机制。写入文档到 buffer 时，同时将该操作写入 translog 中。

translog文件会即时写入磁盘(fsync)，在ES 6x中，默认每个请求都会落盘，我们也可以修改为每5秒写一次，这样风险便是丢失5秒内的数据，相关配置为indextranslog。同时ES每次启动时会检查translog 文件，并从中恢复数据。

flush 负责将内存中的segment写入磁盘，主要做如下的工作:

Reflush和Flush执行的时机

ES的做法是 首先删除文档，然后再创建新文档

我们上面提到，新增文档是通过新建segment来解决，删除文档是通过维护del文件来进行的，假如现在我们设置的 reflush 时间间隔为1秒，那么一小时单个ES索引就会生成3600个segment，一天下来乃至一个月下来会产生的segment文件数量更是不可想象。为了解决Segment过多可能引起的性能下降问题，ES中采用了Segment Merging（即segment合并）的方法来减少segment的数量。

执行合并操作的方式有两种，一种是ES定时在后台进行 Segment Merging 操作，还有一种是我们手动执行 force_merge_api 命令来实现合并操作。

1背景

MySQL的cluster方案有很多官方和第三方的选择，选择多就是一种烦恼，因此，我们考虑MySQL数据库满足下三点需求，考察市面上可行的解决方案：

高可用性：主服务器故障后可自动切换到后备服务器可伸缩性：可方便通过脚本增加DB服务器负载均衡：支持手动把某公司的数据请求切换到另外的服务器，可配置哪些公司的数据服务访问哪个服务器

需要选用一种方案满足以上需求。在MySQL官方网站上参考了几种解决方案的优缺点：

综合考虑，决定采用MySQL Fabric和MySQL Cluster方案，以及另外一种较成熟的集群方案Galera Cluster进行预研。

2MySQLCluster

简介：

MySQL Cluster 是MySQL 官方集群部署方案，它的历史较久。支持通过自动分片支持读写扩展，通过实时备份冗余数据，是可用性最高的方案，声称可做到99999%的可用性。

架构及实现原理：

MySQL cluster主要由三种类型的服务组成：

NDB Management Server：管理服务器主要用于管理cluster中的其他类型节点（Data Node和SQL Node），通过它可以配置Node信息，启动和停止Node。 SQL Node：在MySQL Cluster中，一个SQL Node就是一个使用NDB引擎的mysql server进程，用于供外部应用提供集群数据的访问入口。Data Node：用于存储集群数据；系统会尽量将数据放在内存中。

缺点及限制：

对需要进行分片的表需要修改引擎Innodb为NDB，不需要分片的可以不修改。NDB的事务隔离级别只支持Read Committed，即一个事务在提交前，查询不到在事务内所做的修改；而Innodb支持所有的事务隔离级别，默认使用Repeatable Read，不存在这个问题。外键支持：虽然最新的Cluster版本已经支持外键，但性能有问题（因为外键所关联的记录可能在别的分片节点中），所以建议去掉所有外键。Data Node节点数据会被尽量放在内存中，对内存要求大。

数据库系统提供了四种事务隔离级别：

ASerializable（串行化）：一个事务在执行过程中完全看不到其他事务对数据库所做的更新（事务执行的时候不允许别的事务并发执行。事务串行化执行，事务只能一个接着一个地执行，而不能并发执行。）。

BRepeatable Read（可重复读）：一个事务在执行过程中可以看到其他事务已经提交的新插入的记录，但是不能看到其他其他事务对已有记录的更新。

CRead Commited（读已提交数据）：一个事务在执行过程中可以看到其他事务已经提交的新插入的记录，而且能看到其他事务已经提交的对已有记录的更新。

DRead Uncommitted（读未提交数据）：一个事务在执行过程中可以看到其他事务没有提交的新插入的记录，而且能看到其他事务没有提交的对已有记录的更新。

3MySQL Fabric

简介：

为了实现和方便管理MySQL 分片以及实现高可用部署，Oracle在2014年5月推出了一套为各方寄予厚望的MySQL产品 -- MySQL Fabric, 用来管理MySQL 服务，提供扩展性和容易使用的系统，Fabric当前实现了两个特性：高可用和使用数据分片实现可扩展性和负载均衡，这两个特性能单独使用或结合使用。

MySQL Fabric 使用了一系列的python脚本实现。

应用案例：由于该方案在去年才推出，目前在网上暂时没搜索到有大公司的应用案例。

架构及实现原理：

Fabric支持实现高可用性的架构图如下：

Fabric使用HA组实现高可用性，其中一台是主服务器，其他是备份服务器， 备份服务器通过同步复制实现数据冗余。应用程序使用特定的驱动，连接到Fabric 的Connector组件，当主服务器发生故障后，Connector自动升级其中一个备份服务器为主服务器，应用程序无需修改。

Fabric支持可扩展性及负载均衡的架构如下：

使用多个HA 组实现分片，每个组之间分担不同的分片数据（组内的数据是冗余的，这个在高可用性中已经提到）

应用程序只需向connector发送query和insert等语句，Connector通过MasterGroup自动分配这些数据到各个组，或从各个组中组合符合条件的数据，返回给应用程序。

缺点及限制：

影响比较大的两个限制是：

自增长键不能作为分片的键；事务及查询只支持在同一个分片内，事务中更新的数据不能跨分片，查询语句返回的数据也不能跨分片。

测试高可用性

服务器架构：

功能

IP

Port

Backing store(保存各服务器配置信息)

20020016824

3306

Fabric 管理进程（Connector）

20020016824

32274

HA Group 1 -- Master

20020016823

3306

HA Group 1 -- Slave

20020016825

3306

安装过程省略，下面讲述如何设置高可用组、添加备份服务器等过程

首先，创建高可用组，例如组名group_id-1，命令：

mysqlfabric group create group_id-1

往组内group_id-1添加机器20020016825和20020016823：

mysqlfabric group add group_id-1 20020016825:3306

mysqlfabric group add group_id-1 20020016823:3306

然后查看组内机器状态：

由于未设置主服务器，两个服务的状态都是SECONDARY

提升其中一个为主服务器：

mysqlfabric group promote group_id-1 --slave_id 00f9831f-d602-11e3-b65e-0800271119cb

然后再查看状态：

设置成主服务器的服务已经变成Primary。

另外，mode属性表示该服务器是可读写（READ_WRITE)，或只读(READ_ONLY)，只读表示可以分摊查询数据的压力；只有主服务器能设置成可读写（READ_WRITE)。

这时检查25服务器的slave状态：

可以看到它的主服务器已经指向23

然后激活故障自动切换功能：

mysqlfabric group activate group_id-1

激活后即可测试服务的高可以性

首先，进行状态测试：

停止主服务器23

然后查看状态：

可以看到，这时将25自动提升为主服务器。

但如果将23恢复起来后，需要手动重新设置23为主服务器。

实时性测试：

目的：测试在主服务更新数据后，备份服务器多久才显示这些数据

测试案例：使用java代码建连接，往某张表插入100条记录，看备份服务器多久才能同步这100条数据

测试结果：

表中原来有101条数据，运行程序后，查看主服务器的数据条数：

可见主服务器当然立即得到更新。

查看备份服务器的数据条数：

但备份服务器等待了1-2分钟才同步完成（可以看到fabric使用的是异步复制，这是默认方式，性能较好，主服务器不用等待备份服务器返回，但同步速度较慢）

对于从服务器同步数据稳定性问题，有以下解决方案：

使用半同步加强数据一致性：异步复制能提供较好的性能，但主库只是把binlog日志发送给从库，动作就结束了，不会验证从库是否接收完毕，风险较高。半同步复制会在发送给从库后，等待从库发送确认信息后才返回。可以设置从库中同步日志的更新方式，从而减少从库同步的延迟，加快同步速度。 安装半同步复制：

在mysql中运行

install plugin rpl_semi_sync_master soname 'semisync_masterso';

install plugin rpl_semi_sync_slave soname 'semisync_slaveso';

SET GLOBAL rpl_semi_sync_master_enabled=ON;

SET GLOBAL rpl_semi_sync_slave_enabled=ON;

修改mycnf ：

rpl_semi_sync_master_enabled=1

rpl_semi_sync_slave_enabled=1

sync_relay_log=1

sync_relay_log_info=1

sync_master_info=1

稳定性测试：

测试案例：使用java代码建连接，往某张表插入1w条记录，插入过程中将其中的master服务器停了，看备份服务器是否有这1w笔记录

测试结果，停止主服务器后，java程序抛出异常：

但这时再次发送sql命令，可以成功返回。证明只是当时的事务失败了。连接切换到了备份服务器，仍然可用。

翻阅了mysql文档，有章节说明了这个问题：

里面提到：当主服务器当机时，我们的应用程序虽然是不需做任何修改的，但在主服务器被备份服务器替换前，某些事务会丢失，这些可以作为正常的mysql错误来处理。

数据完整性校验：

测试主服务器停止后，备份服务器是否能够同步所有数据。

重启了刚才停止主服务器后，查看记录数

可以看到在插入1059条记录后被停止了。

现在看看备份服务器的记录数是多少，看看在主服务器当机后是否所有数据都能同步过来

大约经过了几十秒，才同步完，数据虽然不是立即同步过来，但没有丢失。

12、分片：如何支持可扩展性和负载均衡

fabric分片简介：当一台机器或一个组承受不了服务压力后，可以添加服务器分摊读写压力，通过Fabirc的分片功能可以将某些表中数据分散存储到不同服务器。我们可以设定分配数据存储的规则，通过在表中设置分片key设置分配的规则。另外，有些表的数据可能并不需要分片存储，需要将整张表存储在同一个服务器中，可以将设置一个全局组（Global Group）用于存储这些数据，存储到全局组的数据会自动拷贝到其他所有的分片组中。

4Galera Cluster

简介：

Galera Cluster号称是世界上最先进的开源数据库集群方案

主要优点及特性：

真正的多主服务模式：多个服务能同时被读写，不像Fabric那样某些服务只能作备份用同步复制：无延迟复制，不会产生数据丢失热备用：当某台服务器当机后，备用服务器会自动接管，不会产生任何当机时间自动扩展节点：新增服务器时，不需手工复制数据库到新的节点支持InnoDB引擎对应用程序透明：应用程序不需作修改

架构及实现原理：

首先，我们看看传统的基于mysql Replication（复制）的架构图：

Replication方式是通过启动复制线程从主服务器上拷贝更新日志，让后传送到备份服务器上执行，这种方式存在事务丢失及同步不及时的风险。Fabric以及传统的主从复制都是使用这种实现方式。

而Galera则采用以下架构保证事务在所有机器的一致性：

客户端通过Galera Load Balancer访问数据库，提交的每个事务都会通过wsrep API 在所有服务器中执行，要不所有服务器都执行成功，要不就所有都回滚，保证所有服务的数据一致性，而且所有服务器同步实时更新。

缺点及限制：

由于同一个事务需要在集群的多台机器上执行，因此网络传输及并发执行会导致性能上有一定的消耗。所有机器上都存储着相同的数据，全冗余。若一台机器既作为主服务器，又作为备份服务器，出现乐观锁导致rollback的概率会增大，编写程序时要小心。不支持的SQL：LOCK / UNLOCK TABLES / GET_LOCK(), RELEASE_LOCK()…不支持XA Transaction

目前基于Galera Cluster的实现方案有三种：Galera Cluster for MySQL、Percona XtraDB Cluster、MariaDB Galera Cluster。

我们采用较成熟、应用案例较多的Percona XtraDB Cluster。

应用案例：

超过2000多家外国企业使用：

包括：

集群部署架构：

功能

IP

Port

Backing store(保存各服务器配置信息)

20020016824

3306

Fabric 管理进程（Connector）

20020016824

32274

HA Master 1

20020016824

3306

HA Master 2

20020016825

3306

HA Master 3

20020016823

3306

41、测试数据同步

在机器24上创建一个表：

立即在25 中查看，可见已被同步创建

使用Java代码在24服务器上插入100条记录

立即在25服务器上查看记录数

可见数据同步是立即生效的。

42、测试添加集群节点

添加一个集群节点的步骤很简单，只要在新加入的机器上部署好Percona XtraDB Cluster，然后启动，系统将自动将现存集群中的数据同步到新的机器上。

现在为了测试，先将其中一个节点服务停止：

然后使用java代码在集群上插入100W数据

查看100w数据的数据库大小：

这时启动另外一个节点，启动时即会自动同步集群的数据：

启动只需20秒左右，查看数据大小一致，查看表记录数，也已经同步过来

5对比总结

MySQL Fabric

Galera Cluster

使用案例

2014年5月才推出，目前在网上暂时没搜索到有大公司的应用案例

方案较成熟，外国多家互联网公司使用

数据备份的实时性

由于使用异步复制，一般延时几十秒，但数据不会丢失。

实时同步，数据不会丢失

数据冗余

使用分片，通过设置分片key规则可以将同一张表的不同数据分散在多台机器中

每个节点全冗余，没有分片

高可用性

通过Fabric Connector实现主服务器当机后的自动切换，但由于备份延迟，切换后可能不能立即查询数据

使用HAProxy实现。由于实时同步，切换的可用性更高。

可伸缩性

添加节点后，需要先手工复制集群数据

扩展节点十分方便，启动节点时自动同步集群数据，100w数据（100M）只需20秒左右

负载均衡

通过HASharding实现

使用HAProxy实现负载均衡

程序修改

需要切换成jdbc:mysql:fabric的jdbc类和url

程序无需修改

性能对比

使用java直接用jdbc插入100条记录，大概2000+ms

跟直接操作mysql一样，直接用jdbc插入100条记录，大概600ms

6实践应用

综合考虑上面方案的优缺点，我们比较偏向选择Galera 如果只有两台数据库服务器，考虑采用以下数据库架构实现高可用性、负载均衡和动态扩展：

如果三台机器可以考虑：

后来发现原因是Docker容器后台运行,就必须有一个前台进程！容器运行的命令如果不是那些一直挂起的命令（比如运行top，ping），就是会自动退出的。

分片是指将数据拆分,将其分散存在不同机器上的过程有时也叫分区将数据分散在不同的机器上,不需要功能强大的大型计算机就可以存储更多的数据,处理更大的负载使用几乎所有数据库软件都能进行手动分片,应用需要维护与若干不同数据库服务器的连接,每个连接还是完全独立的应用程序管理不同服务器上的不同数据,存储查村都需要在正确的服务器上进行这种方法可以很好的工作,但是也难以维护,比如向集群添加节点或从集群删除节点都很困难,调整数据分布和负载模式也不轻松MongoDB支持自动分片,可以摆脱手动分片的管理集群自动切分数据,做负载均衡。

设置分片时,需要从集合里面选一个键,用该键的值作为数据拆分的依据这个键成为片键假设有个文档集合表示的是人员,如果选择名字"name"做为片键,第一篇可能会存放名字以A-F开头的文档第二片存G-P开头的文档,第三篇存Q-Z的文档随着增加或删除片,MongoDB会重新平衡数据,是每片的流量比较均衡,数据量也在合理范围内(如流量较大的片存放的数据或许会比流量下的片数据要少些)