数据库|谈一谈数据分片( 二 )

垂直分片需要对架构和设计进行调整。通常来讲，是来不及应对互联网业务需求快速变化的；而且，它也无法真正地解决单点瓶颈。垂直拆分可以缓解数据量和访问量带来的问题，但无法根治。如果垂直拆分之后，表中的数据量依然超过单节点所能承载的阈值（比如我司在前段时间的618大促的时候，其他业务节点都没有问题，只有营销节点CPU打满，以至于拖累整个支付链不可用），则需要水平分片来进一步处理。
水平分片水平分片又叫做横向拆分（就像一个公司会在不同的城市设置不同的分公司去处理日常工作）。相对于垂直分片，它不再将数据根据业务逻辑归类，而是通过某个字段（或某几个字段），根据某种规则将数据分散至多个节点或表中，每个分片仅包含数据的一部分。例如：根据主键分片，偶数主键的记录放入 0 库（或表），奇数主键的记录放入 1 库（或表）。

水平分片从理论上突破了单机数据量处理的瓶颈，并且扩展相对自由，是分库分表的标准解决方案。
问题虽然数据分片解决了性能、可用性以及单点备份恢复等问题，但分布式的架构也引入了新的问题。
复杂的数据库操作面对散乱的分库分表之后的数据，开发工程师和数据库管理员对数据库的操作变得复杂就是其中的重要挑战之一。他们需要知道数据需要从哪个具体的数据库的哪个表中获取。
你想想看，原来我们都在同一个地方办公，你想叫张三、李四都很容易，但现在大家都分派在天南海北，交流起来就不方便。
数据聚合能够正确地运行在单节点数据库中的 SQL ，在分片之后的数据库中并不一定能够正确运行。例如，分表导致表名称的修改，或者分页、排序、聚合分组等操作的不正确处理。
比如，我们想查询订单表的前10条数据，以前只要一条SQL语句搞定，现在分到不同的数据节点，这时再想分页查询会让你崩溃。

分布式事务（跨库事务）采用分表策略，在降低一个表数据量的情况下，尽量使用本地事务，因为都在一个数据节点下就可以避免跨库事务的问题。
在不能避免跨库事务的场景，有些业务还是要保证事务的一致性，基于 XA 分布式事务在高并发的场景中性能无法满足需要，大多采用最终一致性的柔性事务代替强一致事务。

写在最后好兄弟可以点赞并关注我。