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

引言

微服务架构是一项在云中部署应用和服务的新技术。大部分围绕微服务的争论都集中在容器或其他技术是否能很好的实施微服务，而红帽说API应该是重点。

微服务可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构(在现有系统中分布一个API)区分开来。在服务公开中，许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程。

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

一、需求缘起

分页需求

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

(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取模的算法来分库，这样即能够保证每个库的数据分布是均匀的，又能够保证每个库的请求分布是均匀的，实在是简单实现负载均衡的好方法，此法在互联网架构中应用颇多。

二、全局视野法

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

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

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

.

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

三、业务折衷法

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

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

业务折衷一：禁止跳页查询

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

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

(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(仍返回一页数据)，以保证数据的传输量和排序的数据量不会随着不断翻页而导致性能下降。

四、终极武器-二次查询法

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

为了方便举例，假设一页只有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排序的一页数据。

总结

以 上就是我对  微服务架构跨库分页解决的四种方案   问题及其优化总结，分享给大家，觉得收获的话可以点个关注收藏转发一波喔，谢谢大佬们支持！

最后，每一位读到这里的网友，感谢你们能耐心地看完。希望在成为一名更优秀的Java程序员的道路上，我们可以一起学习、一起进步！都能赢取白富美，走向架构师的人生巅峰!

想了解学习Java方面的技术内容以及Java技术视频的内容可加群：722040762 验证码：简书(666 必过)欢迎大家的加入哟！