互联网项目中常用的相关数据库为MySQL，随着用户和业务的增加，传统的单库单表模式难以满足大量的业务数据存储和查询，单库单表中的大量数据写入、查询效率非常慢，此时应采用分库单表战略解决。
一、业务场景介绍。假设目前有一个电子商务系统使用MySQL，设计大数据存储、高并发、高性能可扩展的计划，数据库有用户表。用户非常多，为了实现高扩展性，如何设计？OK让我们先看看传统的配方式。当然，也有知道根据省/地区和一定业务关系进行数据库分割的伙伴。OK，问题来了，如何保证合理地将数据存储在不同库的表里？减少库存并发压力？我应该如何制定分库表的规则？别着急，这不是来的。
二、水平分库分表方法。
1.RANGE。
第一种方法可以指定一个数据范围来进行表格分割，比如1-10000，1-20000，10000，1000，000，1000，000，1000，000，如下图所示。当然，该方法需要维护表的ID，特别是在分布环境下，该分布ID建议在不使用第三方分布工具的情况下使用Redis，Redis的incr操作可以简单地维护分布式的表的ID。RANGE方法的优点:扩展简单，提前建造库、表即可。RANGE方法的缺点:大部分读写访问新数据，有IO瓶颈，新库压力过大，不推荐采用。
2.HASH取模。
关于上述RANGE方式的表有IO瓶颈的问题，可以根据用户IDHASG的取模方式进行库存表，这样，数据可以分散在不同的库和表中，以避免IO瓶颈问题。HASH取模方法的优点:保证数据均匀分散在不同的仓库和表中，减轻了数据仓库的压力。HASH取模方法的缺点:扩大麻烦，转移数据时，必须每次重新计算hash值分配给不同的库和表。
3.一致性HASH。
通过HASH取模也不是最完美的方法，那么什么呢？使用一致性HASH算法可以完美解决问题。
普通HASH算法:普通哈希算法将任意长度的二进值反映为短固定长度的二进值，这个小的二进值称为哈希值。哈希值是数据唯一紧凑的数值表示形式。
普通hash算法在分布式应用中的不足:在分布式存储系统中，将数据存储在具体的节点上。如果我们使用普通hash算法进行路由，将数据映射到具体的节点上，如key%n，key是数据的key，n是机器的节点数，如果有机器参加或退出集团，所有的数据映射都会失效，如果是持续存储，则必须转移数据，如果是分布式的缓存，其他缓存就会失效。
一致性HASH算法:根据常用的hash算法，将对应的key哈希放入具有2^32次方节点的空间，即0~(2^32)-1的数字空间。现在我们可以把这些数字的头尾连接起来，想象成一个封闭的环形。如果这个圆第一个尾巴是连接的，假设现在有三个数据库服务器节点node1、node2、node3三个节点，每个节点都负责自己的用户数据存储，假设用户user1、user2、user3、服务器节点。OK，现在假设node3节点无效。user3落在node1上，以前的node1和node2的数据没有变化，假设追加了节点node4。你会发现user3会掉到node4节点的追加和删除的分析，一致性的哈希算法在维持单调性的同时，数据的转移最小化，这种算法非常适合分布式集团，避免了大量的数据转移，减少了服务器的压力。
当然，还有一个问题需要解决，那就是平衡。从图中可以看出，当服务器节点较少时，会出现一个问题，即大量数据必须集中在一个节点上，极少数据集中在另一个节点上。为了解决这种数据倾斜问题，一致性哈希算法引入了虚拟节点机制，即对每个服务节点计算多个哈希，在每个计算结果位置放置一个节点，称为虚拟节点。具体做法可以先确定各物理节点相关的虚拟节点数，然后在ip或主机名称后面增加编号。例如，上述情况可以为每个服务器计算三个虚拟节点，因此可以分别计算node1-1、node1-2、node1-3、node2-1、node2-2、node2-3、node3-1、node3-2和node3-3的哈希值，形成九个虚拟节点。例如，user1位于node1-1、node1-2、node1-3，实际上位于node1这个节点，可以解决服务节点少时数据倾斜的问题。当然，这个虚拟节点的数量不是固定的，而是固定的，至少是3个，这里只是一个例子，具体的虚拟节点的数量需要根据实际的业务状况来决定。一致性HASH方法的优点:通过虚拟节点方式，可以保证数据的均匀分散在不同的仓库和表中，增加、删除节点不影响其他节点的数据，可用性高，灾害性强。一致性取模方法的缺点:嗯，与以上两种相比，可以认为没有。
还没有评论，来说两句吧...