数据库架构选型与落地，看这篇就够了

随着时间和业务的发展，数据库中的数据量增长是不可控的，库和表中的数据会越来越大，随之带来的是更高的 磁盘 、 IO 、 系统开销 ，甚至 性能 上的瓶颈，而单台服务器的 资源终究是有限 的。

因此在面对业务扩张过程中，应用程序对数据库系统的 健壮性 ， 安全性 ， 扩展性 提出了更高的要求。

以下，我从数据库架构、选型与落地来让大家入门。

数据库会面临什么样的挑战呢？

业务刚开始我们只用单机数据库就够了，但随着业务增长，数据规模和用户规模上升，这个时候数据库会面临IO瓶颈、存储瓶颈、可用性、安全性问题。

为了解决上述的各种问题，数据库衍生了出不同的架构来解决不同的场景需求。

将数据库的写 *** 作和读 *** 作分离，主库接收写请求，使用多个从库副本负责读请求，从库和主库同步更新数据保持数据一致性，从库可以水平扩展，用于面对读请求的增加。

这个模式也就是常说的读写分离，针对的是小规模数据，而且存在大量读 *** 作的场景。

因为主从的数据是相同的，一旦主库宕机的时候，从库可以 切换为主库提供写入 ，所以这个架构也可以提高数据库系统的 安全性 和 可用性 ；

优点：

缺点：

在数据库遇到 IO瓶颈 过程中，如果IO集中在某一块的业务中，这个时候可以考虑的就是垂直分库，将热点业务拆分出去，避免由 热点业务 的 密集IO请求 影响了其他正常业务，所以垂直分库也叫 业务分库 。

优点：

缺点：

在数据库遇到存储瓶颈的时候，由于数据量过大造成索引性能下降。

这个时候可以考虑将数据做水平拆分，针对数据量巨大的单张表，按照某种规则，切分到多张表里面去。

但是这些表还是在同一个库中，所以库级别的数据库 *** 作还是有IO瓶颈（单个服务器的IO有上限）。

所以水平分表主要还是针对 数据量较大 ，整体业务 请求量较低 的场景。

优点：

缺点：

四、分库分表

在数据库遇到存储瓶颈和IO瓶颈的时候，数据量过大造成索引性能下降，加上同一时间需要处理大规模的业务请求，这个时候单库的IO上限会限制处理效率。

所以需要将单张表的数据切分到多个服务器上去，每个服务器具有相应的库与表，只是表中数据集合不同。

分库分表能够有效地缓解单机和单库的 性能瓶颈和压力 ，突破IO、连接数、硬件资源等的瓶颈。

优点：

缺点：

注：分库还是分表核心关键是有没有IO瓶颈 。

分片方式都有什么呢？

RANGE（范围分片）

将业务表中的某个 关键字段排序 后，按照顺序从0到10000一个表，10001到20000一个表。最常见的就是 按照时间切分 （月表、年表）。

比如将6个月前，甚至一年前的数据切出去放到另外的一张表，因为随着时间流逝，这些表的数据被查询的概率变小，银行的交易记录多数是采用这种方式。

优点：

缺点：

HASH（哈希分片）

将订单作为主表，然后将其相关的业务表作为附表，取用户id然后 hash取模 ，分配到不同的数据表或者数据库上。

优点：

缺点：

讲到这里，我们已经知道数据库有哪些架构，解决的是哪些问题，因此， 我们在日常设计中需要根据数据的特点，数据的倾向性，数据的安全性等来选择不同的架构 。

那么，我们应该如何选择数据库架构呢？

虽然把上面的架构全部组合在一起可以形成一个强大的高可用，高负载的数据库系统，但是架构选择合适才是最重要的。

混合架构虽然能够解决所有的场景的问题，但是也会面临更多的挑战，你以为的完美架构，背后其实有着更多的坑。

1、对事务支持

分库分表后（无论是垂直还是水平拆分），就成了分布式事务了，如果依赖数据库本身的分布式事务管理功能去执行事务，将付出高昂的性能代价（XA事务）；如果由应用程序去协助控制，形成程序逻辑上的事务，又会造成编程方面的负担（TCC、SAGA）。

2、多库结果集合并 （group by，order by）

由于数据分布于不同的数据库中，无法直接对其做分页、分组、排序等 *** 作，一般应对这种多库结果集合并的查询业务都需要采用数据清洗、同步等其他手段处理（TIDB、KUDU等）。

3、数据延迟

主从架构下的多副本机制和水平分库后的聚合库都会存在主数据和副本数据之间的延迟问题。

4、跨库join

分库分表后表之间的关联 *** 作将受到限制，我们无法join位于不同分库的表（垂直），也无法join分表粒度不同的表（水平）， 结果原本一次查询就能够完成的业务，可能需要多次查询才能完成。

5、分片扩容

水平分片之后，一旦需要做扩容时。需要将对应的数据做一次迁移，成本代价都极高的。

6、ID生成

分库分表后由于数据库独立，原有的基于数据库自增ID将无法再使用，这个时候需要采用其他外部的ID生成方案。

一、应用层依赖类（JDBC）

这类分库分表中间件的特点就是和应用强耦合，需要应用显示依赖相应的jar包（以Java为例），比如知名的TDDL、当当开源的 sharding-jdbc 、蘑菇街的TSharding等。

此类中间件的基本思路就是重新实现JDBC的API，通过重新实现 DataSource 、 PrepareStatement 等 *** 作数据库的接口，让应用层在 基本 不改变业务代码的情况下透明地实现分库分表的能力。

中间件给上层应用提供熟悉的JDBC API，内部通过 sql解析 、 sql重写 、 sql路由 等一系列的准备工作获取真正可执行的sql，然后底层再按照传统的方法（比如数据库连接池）获取物理连接来执行sql，最后把数据 结果合并 处理成ResultSet返回给应用层。

优点

缺点

二、中间层代理类（Proxy）

这类分库分表中间件的核心原理是在应用和数据库的连接之间搭起一个 代理层 ，上层应用以 标准的MySQL协议 来连接代理层，然后代理层负责 转发请求 到底层的MySQL物理实例，这种方式对应用只有一个要求，就是只要用MySQL协议来通信即可。

所以用MySQL Navicat这种纯的客户端都可以直接连接你的分布式数据库，自然也天然 支持所有的编程语言 。

在技术实现上除了和应用层依赖类中间件基本相似外，代理类的分库分表产品必须实现标准的MySQL协议，某种意义上讲数据库代理层转发的就是MySQL协议请求，就像Nginx转发的是Http协议请求。

比较有代表性的产品有开创性质的Amoeba、阿里开源的Cobar、社区发展比较好的 Mycat （基于Cobar开发）等。

优点

缺点

JDBC方案 ：无中心化架构，兼容市面上大多数关系型数据库，适用于开发高性能的轻量级 OLTP 应用（面向前台）。

Proxy方案 ：提供静态入口以及异构语言的支持，适用于 OLAP 应用（面向后台）以及对分片数据库进行管理和运维的场景。

混合方案 ：在大型复杂系统中存在面向C端用户的前台应用，也有面向企业分析的后台应用，这个时候就可以采用混合模式。

JDBC 采用无中心化架构，适用于 Java 开发的高性能的轻量级 OLTP 应用；Proxy 提供静态入口以及异构语言的支持，适用于 OLAP 应用以及对分片数据库进行管理和运维的场景。

ShardingSphere是一套开源的分布式数据库中间件解决方案组成的生态圈，它由 Sharding-JDBC 、 Sharding-Proxy 和 Sharding-Sidecar （计划中）这3款相互独立的产品组成，他们均提供标准化的数据分片、分布式事务和数据库治理功能，可适用于如Java同构、异构语言、容器、云原生等各种多样化的应用场景。

ShardingSphere提供的核心功能：

Sharding-Proxy

定位为透明化的 数据库代理端 ，提供封装了 数据库二进制协议的服务端版本 ，用于完成对 异构语言的支持 。

目前已提供MySQL版本，它可以使用 任何兼容MySQL协议的访问客户端 (如：MySQL Command Client, MySQL Workbench, Navicat等) *** 作数据，对DBA更加友好。

向 应用程序完全透明 ，可直接当做MySQL使用。

适用于任何兼容MySQL协议的客户端。

Sharding-JDBC

定位为 轻量级Java框架 ，在Java的JDBC层提供的额外服务。 它使用客户端直连数据库，以jar包形式提供服务，无需额外部署和依赖，可理解为 增强版的JDBC驱动，完全兼容JDBC和各种ORM框架 。

以电商SaaS系统为例，前台应用采用Sharding-JDBC，根据业务场景的差异主要分为三种方案。

分库（用户）

问题解析：头部企业日活高并发高，单独分库避免干扰其他企业用户，用户数据的增长缓慢可以不分表。

拆分维度：企业ID分库

拆分策略：头部企业单独库、非头部企业一个库

分库分表（订单）

问题解析：订单数据增长速度较快，在分库之余需要分表。

拆分维度：企业ID分库、用户ID分表

拆分策略：头部企业单独库、非头部企业一个库，分库之后用户ID取模拆分表

单库分表（附件）

问题解析：附件数据特点是并发量不大，只需要解决数据增长问题，所以单库IO足以支撑的情况下分表即可。

拆分维度：用户ID分表

拆分策略：用户ID取模分表

问题一：分布式事务

分布式事务过于复杂也是分布式系统最难处理的问题，由于篇幅有限，后续会开篇专讲这一块内容。

问题二：分布式ID

问题三：跨片查询

举个例子，以用户id分片之后，需要根据企业id查询企业所有用户信息。

sharding针对跨片查询也是能够支持的，本质上sharding的跨片查询是采用同时查询多个分片的数据，然后聚合结果返回，这个方式对资源耗费比较大，特别是对数据库连接资源的消耗。

假设分4个数据库，8个表，则sharding会同时发出32个SQL去查询。一下子消耗掉了32个连接；

特别是针对单库分表的情况要注意，假设单库分64个表，则要消耗64个连接。如果我们部署了2个节点，这个时候两个节点同时查询的话，就会遇到数据库连接数上限问题（mysql默认100连接数）

问题四：分片扩容

随着数据增长，每个片区的数据也会达到瓶颈，这个时候需要将原有的分片数量进行增加。由于增加了片区，原先的hash规则也跟着变化，造成了需要将旧数据做迁移。

假设原先1个亿的数据，hash分64个表，现在增长到50亿的数据，需要扩容到128个表，一旦扩容就需要将这50亿的数据做一次迁移，迁移成本是无法想象的。

问题五：一致性哈希

首先，求出每个 服务器的hash值 ，将其配置到一个 0~2^n 的圆环上 （n通常取32）

其次，用同样的方法求出待 存储对象的主键 hash值 ，也将其配置到这个圆环上。

然后，从数据映射到的位置开始顺时针查找，将数据分布到找到的第一个服务器节点上。

一致性hash的优点在于加入和删除节点时只会影响到在哈希环中相邻的节点，而对其他节点没有影响。

所以使用一致性哈希在集群扩容过程中可以减少数据的迁移。

好了，这次分享到这里，我们日常的实践可能只会用到其中一种方案，但它不是数据库架构的全貌，打开技术视野，才能更好地把存储工具利用起来。

老规矩，一键三连，日入两千，点赞在看，年薪百万！

本文作者：Jensen

7年Java老兵，小米主题设计师，手机输入法设计师，ProcessOn特邀讲师。

曾涉猎航空、电信、IoT、垂直电商产品研发，现就职于某知名电商企业。

技术公众号 【架构师修行录】 号主，专注于分享日常架构、技术、职场干货，Java Goals：架构师。

交个朋友，一起成长！

通过之前的学习，我们已经了解了哈希函数在散列表中的应用，哈希函数就是哈希算法的一个应用。那么在这里给出哈希的定义： 将任意长度的二进制值串映射为固定长度的二进制值串，这个映射规则就是哈希算法，得到的二进制值串就是哈希值 。

要设计一个好的哈希算法并不容易，它应该满足以下几点要求：

哈希算法的应用非常广泛，在这里就介绍七点应用：

有很多著名的哈希加密算法：MD5、SHA、DES...它们都是通过哈希进行加密的算法。

对于加密的哈希算法来说，有两点十分重要：一是很难根据哈希值反推导出原始数据；二是散列冲突的概率要很小。

当然，哈希算法不可能排除散列冲突的可能，这用数学中的 鸽巢原理 就可以很好解释。以MD5算法来说，得到的哈希值为一个 128 位的二进制数，它的数据容量最多为 2 128 bit，如果超过这个数据量，必然会出现散列冲突。

在加密解密领域没有绝对安全的算法，一般来说，只要解密的计算量极其庞大，我们就可以认为这种加密方法是较为安全的。

假设我们有100万个图片，如果我们在图片中寻找某一个图片是非常耗时的，这是我们就可以使用哈希算法的原理为图片设置唯一标识。比如，我们可以从图片的二进制码串开头取100个字节，从中间取100个字节，从结尾取100个字节，然后将它们合并，并使用哈希算法计算得到一个哈希值，将其作为图片的唯一标识。

使用这个唯一标识判断图片是否在图库中，这可以减少甚多工作量。

在传输消息的过程中，我们担心通信数据被人篡改，这时就可以使用哈希函数进行数据校验。比如BT协议中就使用哈希栓发进行数据校验。

在散列表那一篇中我们就讲过散列函数的应用，相比于其它应用，散列函数对于散列算法冲突的要求低很多（我们可以通过开放寻址法或链表法解决冲突），同时散列函数对于散列算法是否能逆向解密也并不关心。

散列函数比较在意函数的执行效率，至于其它要求，在之前的我们已经讲过，就不再赘述了。

接下来的三个应用主要是在分布式系统中的应用

复杂均衡的算法很多，如何实现一个会话粘滞的负载均衡算法呢？也就是说，我们需要在同一个客户端上，在一次会话中的所有请求都路由到同一个服务器上。

最简单的办法是我们根据客户端的 IP 地址或会话 ID 创建一个映射关系。但是这样很浪费内存，客户端上线下线，服务器扩容等都会导致映射失效，维护成本很大。

借助哈希算法，我们可以很轻松的解决这些问题：对客户端的 IP 地址或会话 ID 计算哈希值，将取得的哈希值域服务器的列表的大小进行取模运算，最后得到的值就是被路由到的服务器的编号。

假设有一个非常大的日志文件，里面记录了用户的搜索关键词，我们想要快速统计出每个关键词被搜索的次数，该怎么做呢？

分析一下，这个问题有两个难点：一是搜索日志很大，没办法放到一台机器的内存中；二是如果用一台机器处理这么大的数据，处理时间会很长。

针对这两个难点，我们可以先对数据进行分片，然后使用多台机器处理，提高处理速度。具体思路：使用 n 台机器并行处理，从日志文件中读出每个搜索关键词，通过哈希函数计算哈希值，然后用 n 取模，最终得到的值就是被分配的机器编号。

这样，相同的关键词被分配到了相同的机器上，不同机器只要记录属于自己那部分的关键词的出现次数，最终合并不同机器上的结果即可。

针对这种海量数据的处理问题，我们都可以采用多机分布式处理。借助这种分片思路，可以突破单机内存、CPU等资源的限制。

处理思路和上面出现的思路类似：对数据进行哈希运算，对机器数取模，最终将存储数据（可能是硬盘存储，或者是缓存分配）分配到不同的机器上。

你可以看一下上图，你会发现之前存储的数据在新的存储规则下全部失效，这种情况是灾难性的。面对这种情况，我们就需要使用一致性哈希算法。

哈希算法是应用非常广泛的算法，你可以回顾上面的七个应用感受一下。

其实在这里我想说的是一个思想： 用优势弥补不足 。

例如，在计算机中，数据的计算主要依赖 CPU ，数据的存储交换主要依赖内存。两者一起配合才能实现各种功能，而两者在性能上依然无法匹配，这种差距主要是： CPU运算性能对内存的要求远高于现在的内存能提供的性能。

也就是说，CPU运算很快，内存相对较慢，为了抹平这种差距，工程师们想了很多方法。在我看来，散列表的使用就是利用电脑的高计算性能（优势）去弥补内存速度（不足）的不足，你仔细思考散列表的执行过程，就会明白我的意思。

以上就是哈希的全部内容

1.节点区域分区:

使用特定的数据,如redis的键或用户ID,再根据节点数量N使用公式:hash(key)%N计算出hash值,用来决定数据映射到哪一个节点上.

这种方案的问题是:

当节点数量变化时,需要重新计算hash,会导致数据的重新迁移.

2.一致性hash算法

一致性hash算法实现思路是为系统中每一个节点分配一个token,范围在0~2^32,这些token构成一个hash环.数据的读写执行节点查找 *** 作时,先根据key计算hash值,然后顺时针找到第一个大于等于该hash的token节点.

好处:

这种方式最大的好处就是,在加入或删除节点时,只影响hash环中相邻的两个节点,对其他节点无影响.

问题:

3.虚拟槽算法

使用分散度较好的hash函数,将所有的数据映射到 比如0~16383(2^14)范围的槽中(slot).这个槽的数量一般远远大于实例的数量.

槽是集群数据管理和迁移的基本单位.采用大范围槽的主要目的是为了方便数据拆分和集群扩展.

每一个实例会映射一部分范围的槽.

特点:

1.解耦数据和节点之间的关系,简化扩容和锁容的难度

2.节点自身维护槽的映射关系,不需要客户端或代理服务维护槽分区的元数据.

3.支持节点,槽,键之间的映射查询,用于数据路由,在线伸缩灯场景.

HashTags（面试）

Mset k1 v1 k2 v2 k3 v3

通过分片手段，可以将数据合理的划分到不同的节点上，这本来是一件好事。但是有的时候，我们希望对相关联的业务以原子性方式进行 *** 作。举个简单的例子

我们在单节点上执行MSET （m表示多个，一次向redis设置多个key和值）, 它是一个原子性的 *** 作，我们要求所有给定的key要在同一时间内被设置，不能出现某些指定的key被更新另一些指定的key没有被更新的情况。但是在集群环境下，我们仍然可以执行MSET命令，但它的 *** 作不在是原子 *** 作，会存在某些指定的key被更新，而另外一些指定的key没有改变，原因是多个key可能会被分配到不同的机器上。

所以，这里就会存在一个矛盾点，及要求key尽可能的分散在不同机器，又要求某些相关联的key分配到相同机器。

这个也是在面试的时候会容易被问到的内容。怎么解决呢？

从前面的分析中我们了解到，分片其实就是一个hash的过程，对key做hash取模然后划分到不同的机器上。所以为了解决这个问题，我们需要考虑如何让相关联的key得到的hash值都相同呢？如果key全部相同是不现实的，所以怎么解决呢？在redis中引入了HashTag的概念，可以使得数据分布算法可以根据key的某一个部分进行计算，然后让相关的key落到同一个数据分片；

举个简单的例子，假如对于用户的信息进行存储，

redis:store:1001、redis:store:1002

那么通过hashtag的方式，

redis:{store}:1001、redis:{store}:1002表示

当一个key包含 {} 的时候，就不对整个key做hash，而仅对 {} 包括的字符串做hash。

---