别再问“分库分表”了，再问就瓦解了！

这样的甜头是：毫秒数在高位，天生的 ID 整体上定时刻趋势递增;不依靠第三方体系，不变性和服从较高。

理论上 QPS 约为 409.6w/s(1000*2^12)，而且整个漫衍式体系内不会发生 ID 碰撞;可按照自身营业机动分派 bit 位。

不敷就在于：强依靠呆板时钟，假如时钟回拨，则也许导致天生 ID 一再。

综上团结数据库和 Snowflake 的独一 ID 方案，可以参考业界较为成熟的解法：Leaf——美团点评漫衍式 ID 天生体系，并思量到了高可用、容灾、漫衍式下时钟等题目：

https://tech.meituan.com/2017/04/21/mt-leaf.html 

数据迁徙、扩容题目

当营业高速成长，面对机能和存储的瓶颈时，才会思量分片计划，此时就不行停止的必要思量汗青数据迁徙的题目。

一样平常做法是先读出汗青数据，然后按指定的分片法则再将数据写入到各个分片节点中。

另外还必要按照当前的数据量和 QPS，以及营业成长的速率，举办容量筹划，推算出或许必要几多分片(一样平常提议单个分片上的单表数据量不高出 1000W)。

假如回收数值范畴分片，只必要添加节点就可以举办扩容了，不必要对分片数据迁徙。假如回收的是数值取模分片，则思量后期的扩容题目就相比拟力贫困。

什么时辰思量切分

下面报告一下什么时辰必要思量做数据切分。

①能不切分只管不要切分

并不是全部表都必要举办切分，首要照旧看数据的增添速率。切分后会在某种水平上晋升营业的伟大度，数据库除了承载数据的存储和查询外，帮忙营业更好的实现需求也是其重要事变之一。

不到万不得已不消等闲行使分库分表这个大招，停止"太过计划"和"过早优化"。

分库分表之前，不要为分而分，先极力去做力所能及的工作，譬喻：进级硬件、进级收集、读写疏散、索引优化等等。当数据量到达单表的瓶颈时辰，再思量分库分表。

②数据量过大，正常运维影响营业会见

这里说的运维指：

对数据库备份，假如单表太大，备份时必要大量的磁盘 IO 和收集 IO。譬喻 1T 的数据，收集传输占 50MB 时辰，必要 20000 秒才气传输完毕，整个进程的风险都是较量高的。

对一个很大的表举办 DDL 修改时，MySQL 会锁住全表，这个时刻会很长，这段时刻营业不能会见此表，影响很大。

假如行使 pt-online-schema-change，行使进程中会建设触发器和影子表，也必要很长的时刻。在此操纵进程中，都算为风险时刻。将数据表拆分，总量镌汰，有助于低落这个风险。

大表会常常会见与更新，就更有也许呈现锁守候。将数据切分，用空间换时刻，变相低落会见压力。

③跟着营业成长，必要对某些字段垂直拆分

举个例子，若是项目一开始计划的用户表如下：

id bigint #用户的IDname varchar #用户的名字last_login_time datetime #最近登录时刻personal_info text #私家信息..... #其他信息字段

在项目初始阶段，这种计划是满意简朴的营业需求的，也利便快速迭代开拓。

而当营业快速成长时，用户量从 10w 激增到 10 亿，用户很是的活泼，每次登录会更新 last_login_name 字段，使得 user 表被不绝 update，压力很大。

而其他字段：id，name，personal_info 是稳固的或很少更新的，此时在营业角度，就要将 last_login_time 拆分出去，新建一个 user_time 表。

personal_info 属性是更新和查询频率较低的，而且 text 字段占有了太多的空间。这时辰，就要对此垂直拆分出 user_ext 表了。

④数据量快速增添

跟着营业的快速成长，单表中的数据量会一连增添，当机能靠近瓶颈时，就必要思量程度切分，做分库分表了。此时必然要选择吻合的切分法则，提前预估好数据容量。

⑤安详性和可用性

鸡蛋不要放在一个篮子里。在营业层面上垂直切分，将不相干的营业的数据库脱离，由于每个营业的数据量、会见量都差异，不能由于一个营业把数据库搞挂而连累到其他营业。

操作程度切分，当一个数据库呈现题目时，不会影响到 100% 的用户，每个库只包袱营业的一部门数据，这样整体的可用性就能进步。

案例说明

用户中心营业场景

用户中心是一个非经常见的营业，首要提供用户注册、登录、查询/修改等成果，其焦点表为：

User(uid, login_name, passwd, sex, age, nickname) 

uid为用户ID,  主键 

login_name, passwd, sex, age, nickname,  用户属性 

任何离开营业的架构计划都是耍混混，在举办分库分表前，必要对营业场景需求举办梳理：

用户侧：前台会见，会见量较大，必要担保高可用和高同等性。

首要有两类需求：

用户登录：通过 login_name/phone/email 查询用户信息，1% 哀求属于这种范例。

用户信息查询：登录之后，通过 uid 来查询用户信息，99% 哀求属这种范例。

运营侧：靠山会见，支持运营需求，凭证年数、性别、登岸时刻、注册时刻等举办分页的查询。是内部体系，会见量较低，对可用性、同等性的要求不高。

程度切分要领

当数据量越来越大时，必要对数据库举办程度切分，上文描写的切分要领有"按照数值范畴"和"按照数值取模"。

"按照数值范畴"：以主键 uid 为分别依据，按 uid 的范畴将数据程度切分到多个数据库上。

譬喻：user-db1 存储 uid 范畴为 0~1000w 的数据，user-db2 存储 uid 范畴为 1000w~2000w uid 数据。

利益是：扩容简朴，假如容量不足，只要增进新 DB 即可。

不敷是：哀求量不匀称，一样平常新注册的用户活泼度会较量高，以是新的 user-db2 会比 user-db1 负载高，导致处事器操作率不服衡。

"按照数值取模"：也是以主键 uid 为分别依据，按 uid 取模的值将数据程度切分到多个数据库上。

譬喻：user-db1 存储 uid 取模得 1 的数据，user-db2 存储 uid 取模得 0 的 uid 数据。

利益是：数据量和哀求量漫衍匀称。

不敷是：扩容贫困，当容量不足时，新增进 DB，必要 rehash。必要思量对数据举办滑腻的迁徙。

非 uid 的查询要领

程度切分后，对付按 uid 查询的需求能很好的满意，可以直接路由到详细数据库。

而按非 uid 的查询，譬喻 login_name，就不知道详细该会见哪个库了，此时必要遍历全部库，机能会低落许多。

对付用户侧，可以回收"成立非 uid 属性到 uid 的映射相关"的方案;对付运营侧，可以回收"前台与靠山疏散"的方案。

①成立非 uid 属性到 uid 的映射相关

映射相关：譬喻：login_name 不能直接定位到数据库，可以成立 login_name→uid 的映射相关，用索引表或缓存来存储。

当会见 login_name 时，先通过映射表查询出 login_name 对应的 uid，再通过 uid 定位到详细的库。

映射表只有两列，可以承载很大都据，当数据量过大时，也可以对映射表再做程度切分。

这类 kv 名目标索引布局，可以很好的行使 cache 来优化查询机能，并且映射相关不会频仍改观，缓存掷中率会很高。

基因法：分库基因，若是通过 uid 分库，分为 8 个库，回收 uid%8 的方法举办路由，此时是由 uid 的最后 3bit 来抉择这行 User 数据详细落到哪个库上，那么这 3bit 可以看为分库基因。

上面的映射相关的要领必要特殊存储映射表，按非 uid 字段查询时，还必要多一次数据库或 cache 的会见。

假如想要消除多余的存储和查询，可以通过 f 函数取 login_name 的基因作为 uid 的分库基因。

天生 uid 时，参考上文所述的漫衍式独一 ID 天生方案，再加上最后 3 位 bit 值=f(login_name)。

当查询 login_name 时，只需计较 f(login_name)%8 的值，就可以定位到详细的库。

不外这样必要提前做好容量筹划，预估将来几年的数据量必要分几多库，要预留必然 bit 的分库基因。

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!