[mysql分布式存储解决方案]

1）分布式水平分段中使用的主要关键技术: 子库，子表，M-S，集群，负载平衡

2）需求分析: 每天有数十亿PV的大型Internet应用程序在DB上造成很高的负载，这对系统的稳定性提出了巨大挑战.

3）现有解决方案: 通过数据细分提高网站性能，并水平扩展数据层

水平分割有效地减少了单台计算机的负载并减少了停机的可能性.

集群解决方案: 解决由于停机而导致的单点不可访问性的问题.

读写分离策略: 极大地提高了应用程序中读取数据的速度和并发性.

典型示例: 淘宝，阿里巴巴，腾讯，其中大多数已实现了自己的分布式数据访问层（DDAL）. 淘宝基于ibatis和Spring的分布式数据访问层已经使用了很多年，其运行效率和生产效率得到了开发人员和用户的肯定.

水平分割要考虑的后续问题: 库拆分后选择和制定路由规则，然后进行扩展. 例如，如何以最少的数据迁移实现最大的容量扩展. 重要的是要考虑路由表和负载平衡的规则.

4）DB分段本质上是数据分段. 以下是来自“什么，为什么，如何”的三个方面.

什么？什么是数据分段？

.

将使用哪些特定的拆分和路由方法？举一个简单的例子: 让我们说明Blog应用程序中的日志. 例如，日志文章（文章）表具有以下字段:

article_id（int），标题（varchar（128）），内容（varchar（1024）），user_id（int）

面对这样一个表，我们如何拆分它？如何将此类数据分发到不同中的表？实际上，在分析博客的应用程序时，得出这样的结论并不困难: 在博客的应用程序中，用户分为两种类型: 浏览器和博客所有者. 浏览特定博客的浏览器实际上是在特定用户的博客下浏览，并且该博客的所有者管理他自己的博客，并且还在该特定用户的博客下（在他自己的空间中）运行. 所谓的特定用户由的字段表示为“ user_id”. 正是这个“ user_id”，这是我们需要的库的基础和规则. 为此，可以将user_id 1〜10000的所有商品信息放入DB1的商品表中，将user_id 10001〜20000的所有商品信息放入DB2的商品表中，依此类推，直到DBn. 这样，商品数据自然地分为各种以达到数据分割的目的. 下一个要解决的问题是如何找到特定的？实际上，问题也很简单明显. 由于我们使用字段user_id来区分，因此路由过程中仍然具有user_id是很自然的. 考虑一下我们刚刚介绍的博客应用程序，无论是访问其他人的博客还是管理我自己的博客，总之，我必须知道该博客的用户是谁，也就是说，我们知道该博客的user_id，使用此user_id，使用子库时的规则，依次找到特定的，例如user_id为234，人才的使用规则应位于DB1，如果user_id为12343，则使用规则人才应该位于DB2. 以此类推，使用子库规则反向路由到特定的，此过程称为“路由”.

当然，考虑数据分段的DB设计必须是非常规和非常规的DB设计. 那么正统的DB设计是哪种DB设计？

我们通常使用通常的规则. 通常，我们将根据范例自觉地设计. 当负载很高时，我们可以考虑使用相关的复制机制来提高吞吐量和读写性能. 这可能已经满足了许多需求，但是此机制的缺点仍然很明显. 的. 上面提到的“根据范例有意识地设计”. 考虑到DB设计的数据分段，将违反该通用规则和约束. 为了进行细分，我们必须在表中有多余的字段，这些字段用于区分称为子库的字段或带标签的字段，例如上面的文章示例中的user_id字段（当然，前面的示例没有很好地反映了user_id的冗余性，因为即使未将user_id字段划分为多个库，它也应该出现，如果我们选择它，它会很便宜. 当然，冗余字段的出现不仅在子的场景中，在许多大型应用中，冗余也是必要的，这涉及到高效DB的设计.

为什么？为什么要分割数据？

1）像Oracle这样的成熟且稳定的可以支持海量数据的存储和查询，但是价格并不适合所有人.

2）当负载很高时，主从模式将出现瓶颈. 在现有技术中，当负载较高时，使用相关的复制机制来实现相关的读写吞吐量性能. 此机制有两个瓶颈: 首先，有效性取决于读取操作的比例，在这种情况下，主控通常会成为瓶颈，并且需要顺序队列来执行写入操作. 主站将无法承受从站的过载和数据同步延迟. 它也将非常大，并且还将消耗CPU的计算能力. 在主机上执行写操作后，仍然需要在每个从机上运行一次. 分片可以轻松地将计算，存储和I / O并行分布到多台计算机，这可以充分利用多台计算机的处理能力，并且可以避免单点故障，提供系统可用性并犯下错误. 隔离.

3）使用免费的MySQL和廉价的Server甚至PC作为群集，以实现小型机+大型商业DB的效果分布式存储测试方案，减少大量资本投资，并降低运营成本. 为什么不这样做？

如何？如何分割数据？

首先详细阐述并解释数据分割的方法和形式.

数据分段可以是物理的，数据通过一系列分段规则分配到不同的DB服务器，并且特定的通过路由规则进行访问，因此每次访问都面对的不是单个服务器，而是N个服务器，这样可以降低一台机器的负载压力.

数据分割也可以在中，通过一系列的分割规则，数据被分发到中的不同表中，例如文章分为article_001，article_002等子表，几个子表级别构成一个逻辑上完整的商品表，这样做的目的实际上非常简单. 例如，例如，商品表中现在有5000w数据. 这时，我们需要向该表中添加新的数据. 插入完成后，将重新索引表，并创建5000w行数据. 索引的开销不可忽略. 但是相反地，如果将这张表分为100个表，则从article_001到article_100，则平均有5000w行数据，而每个子表中只有500,000行数据. 目前，我们有一个只有50w行数据的表. 插入数据后，索引创建时间将减少几个数量级，这将大大提高DB的运行效率和DB的并发性. 当然，子表的好处以及诸如写操作之类的锁定操作的好处尚不明确.

总而言之，子库减轻了单点计算机的负担；子表提高了数据操作的效率，尤其是写操作的效率.

如上所述，为了实现数据的水平分段，每个表中必须有相对冗余的字符作为分段基础和标记字段. 在常见的应用程序中，我们根据子库的三种方法和规则选择user_id作为区分字段: （当然，还有其他方法）

按数字段划分:

（1）区分user_id，对应于DB1从1到1000，DB2从1001到2000，依此类推;

优点: 部分迁移

缺点: 数据分布不均

（2）哈希取模:

散列user_id（如果user_id为数字，则使用user_id值），然后使用特定数字. 例如，如果应用程序需要将一个拆分为4个，则使用4. 该数字对user_id的哈希值（即user_id％4）执行取模运算，因此每个操作都有四种可能: 结果为1，它对应于DB1；当结果为2时，它对应于DB2；当结果为3时，它对应于DB3；当结果为0时，它对应于DB4，因此数据非常均匀地分配给4个DB.

好处: 数据分布均匀

缺点: 数据迁移过程中出现问题，无法根据计算机性能分配数据

（3）将配置保存在身份验证库中

要建立一个. 该单独存储user_id和DB之间的映射关系. 每次访问时，必须首先查询该以获得特定的信息，然后才能执行我们需要的查询操作.

优点: 灵活性强，关系

缺点: 每次查询前多查询一次，性能大大降低

以上是我们通常选择的三种开发方法. 一些复杂的项目可能会结合使用这三种方法

方法.

4）接下来分布式存储测试方案，我们将进一步介绍分布式，以解决存储和访问海量数据的问题

分布式数据解决方案提供以下功能:

（1）提供子库规则和路由规则（RouteRule称为RR），直接将上面描述中提到的三个划分规则直接嵌入到系统中，具体的嵌入方法将在以下内容中详细介绍和讨论；

（2）引入集群的概念来解决容错问题，确保数据的高可用性；

（3）介绍负载均衡策略（LoadBalancePolicy称为LB）；

（4）引入群集节点可用性检测机制，以定期检测单点计算机的可用性，以确保LB策略的正确实施并确保系统的高度稳定性；

（5）引入读/写分离以提高数据查询速度；

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/jisuanjixue/article-189031-1.html