mysql跨库分页_微服务架构跨库分页解决的四种方案

微服务架构跨库分页解决的四种方案

1需求缘起

分页需求

互联网很多业务都有分页拉取数据的需求，例如：

(1)微信消息过多时，拉取第N页消息

(2)京东下单过多时，拉取第N页订单

(3)浏览58同城，查看第N页帖子

这些业务场景对应的消息表，订单表，帖子表分页拉取需求有这样一些特点：

(1)有一个业务主键id, 例如msg_id,order_id,tiezi_id

(2)分页排序是按照非业务主键id来排序的，业务中经常按照时间time来排序order by

在数据量不大时，可以通过在排序字段time上建立索引，利用SQL提供的offset/limit功能就能满足分页查询需求：

select * from t_msg order by time offset 200 limit 100

select * from t_order order by time offset 200 limit 100

select * from t_tiezi order by time offset 200 limit 100

此处假设一页数据为100条，均拉取第3页数据。 分库需求

高并发大流量的互联网架构，一般通过服务层来访问数据库，随着数据量的增大，数据库需要进行水平切分，分库后将数据分布到不同的数据库实例(甚至物理机器)上，以达到降低数据量，增加实例数的扩容目的。

一旦涉及分库，逃不开“分库依据”patition key的概念，使用哪一个字段来水平切分数据库呢：大部分的业务场景，会使用业务主键id。

确定了分库依据patition key后，接下来要确定的是分库算法：大部分的业务场景，会使用业务主键id取模的算法来分库，这样即能够保证每个库的数据分布是均匀的，又能够保证每个库的请求分布是均匀的，实在是简单实现负载均衡的好方法，此法在互联网架构中应用颇多。2全局视野法

如上图所述，服务层通过uid取模将数据分布到两个库上去之后，每个数据库都失去了全局视野，数据按照time局部排序之后，不管哪个分库的第3页数据，都不一定是全局排序的第3页数据。

那到底哪些数据才是全局排序的第3页数据呢，暂且分三种情况讨论。

(1)极端情况，两个库的数据完全一样

.

如果两个库的数据完全相同，只需要每个库offset一半，再取半页，就是最终想要的数据(如上图中粉色部分数据)。3业务折衷法

“全局视野法”虽然性能较差，但其业务无损，数据精准，不失为一种方案，有没有性能更优的方案呢？

“任何脱离业务的架构设计都是耍流氓”，技术方案需要折衷，在技术难度较大的情况下，业务需求的折衷能够极大的简化技术方案。 业务折衷一：禁止跳页查询

在数据量很大，翻页数很多的时候，很多产品并不提供“直接跳到指定页面”的功能，而只提供“下一页”的功能，这一个小小的业务折衷，就能极大的降低技术方案的复杂度。

如上图，不够跳页，那么第一次只能够查第一页：

(1)将查询order by time offset 0 limit 100，改写成order by time where time>0 limit 100

(2)上述改写和offset 0 limit 100的效果相同，都是每个分库返回了一页数据(上图中粉色部分)；

(3)服务层得到2页数据，内存排序，取出前100条数据，作为最终的第一页数据，这个全局的第一页数据，一般来说每个分库都包含一部分数据(如上图粉色部分)；

咦，这个方案也需要服务器内存排序，岂不是和“全局视野法”一样么？第一页数据的拉取确实一样，但每一次“下一页”拉取的方案就不一样了。

点击“下一页”时，需要拉取第二页数据，在第一页数据的基础之上，能够找到第一页数据time的最大值：

这个上一页记录的time_max，会作为第二页数据拉取的查询条件：

(1)将查询order by time offset 100 limit 100，改写成order by time where time>$time_max limit 100

(2)这下不是返回2页数据了(“全局视野法，会改写成offset 0 limit 200”)，每个分库还是返回一页数据(如上图中粉色部分)；

(3)服务层得到2页数据，内存排序，取出前100条数据，作为最终的第2页数据，这个全局的第2页数据，一般来说也是每个分库都包含一部分数据(如上图粉色部分)；

如此往复，查询全局视野第100页数据时，不是将查询条件改写为offset 0 limit 9900+100(返回100页数据)，而是改写为time>$time_max99 limit 100(仍返回一页数据)，以保证数据的传输量和排序的数据量不会随着不断翻页而导致性能下降。

4终极武器-二次查询法

有没有一种技术方案，即能够满足业务的精确需要，无需业务折衷，又高性能的方法呢？这就是接下来要介绍的终极武器：“二次查询法”。

为了方便举例，假设一页只有5条数据，查询第200页的SQL语句为select * from T order by time offset 1000 limit 5;

步骤一：查询改写

将select * from T order by time offset 1000 limit 5

改写为select * from T order by time offset 500 limit 5

并投递给所有的分库，注意，这个offset的500，来自于全局offset的总偏移量1000，除以水平切分数据库个数2。

如果是3个分库，则可以改写为select * from T order by time offset 333 limit 5

假设这三个分库返回的数据(time, uid)如下：

可以看到，每个分库都是返回的按照time排序的一页数据。