分布式数据库

一、背景

互联网场景下的应用涉及的数据量往往是非常巨大的，传统的mysql、oracle等传统关系型数据库显然在设计的那个年代，是没有考虑当今互联网当道的世界的数据量是这么大，像支付宝、微信、FB、IG等超级应用光用户表就可达10亿+的级别，更别说在这些用户基础上衍生出来的一些关联数据（微信好友）、流水数据（淘宝订单）。
mysql单机的数据量在千万级别之后，就存在明显的瓶颈，不管是从内存还是cpu都存在瓶颈。如何解决这个问题，大数据量的解决之道：分治思想。也就是如今大行其道的分布式架构显然就提出来了。也就是一台机器不行，就多台来搞，这样就可以通过水平扩展机器来达到理论上的无上限扩展（像前段时间新冠疫情期间大家都通过钉钉上网课，钉钉紧急扩容了10W机器，其中肯定有一部分是用于数据库的）。
也就是说，分布式数据库本质上还是对传统的数据库的组合，当然也不纯粹是这么简单，比如跨库事务怎么办？跨库join怎么办？跨库唯一键怎么保证？等等问题。

二、实现机制

知道了分布式数据库的基本原理：多台mysql的组合。很容易就知道curd在底层其实就是利用mysql的能力。区别在于如何将多台服务器组合起来。
所以遇到的第一个问题就是数据进来后，如何路由到哪个节点，查询同理，如何判断数据在哪个节点。这两个问题就是数据如何分片？

2.1 范围分片

原理很简单：比如有多台机器，第一台存储id为1-1000000的数据，第二台存储1000000-2000000的数据，后续同理。
优点：随着数据越来越多，节点扩展方便，增加机器即可。
缺点：某些业务场景下，存在访问压力不均衡。比如是用户表越新的用户序号越高，那么如果有拉新活动，那么最新节点压力偏大，如果有老用户回馈活动，那么老节点压力偏大。

2.2 哈希分片

原理简单：将记录进行hash后根据节点数取模，还有一种不同节点定步长的方式也是同理。
优点：数据新旧均衡，不存在压力不均。
缺点：节点扩展麻烦，需要重新hash。