引子

先简单的问一下，你如何解决这样的需求：

对一堆数据按某字段排序，获取第100-10条的数据。

假设你面对的数据是个单节点，简单来说，就是一个mysql数据库，很自然地用

select a from tb order by a limit 100, 10;

你面对的是10个甚至100个节点呢

按照常理，我们会先把所有节点的前110条数据拉到一个公用节点上，再排序，前文已述。

咱们把数字改一下，要获取第[100万， 100万+10]中间的数据10条数据，这个方法就不能用了。

问题变成：

对分布在几十个节点上的上亿条数据要求1秒内排序。

在中，我提到让各数据节点活动起来，不再只承担存储的功能，还要相互发现，相互问答，即“你那有这个数据吗”，“你那这个数据排多少名”。

就好像把全服的机器当成了神经网络中的一个个神经元，互相启发，理解新世界，产生乘法功能。

言归正传，接下来，我给大家实现一下这个需求。

咱们把目标按数据源分两种，先对内存型排序，再进行磁盘型排序，咱们这篇是头一种。

统一目标

咱们简单统一下试验目标。

1.有10个节点，每个节点存储100万条数据，都放在缓存中。

2.内存中的数据是排序过的。

“神马？数据源中的原始数据都是排好序的，那岂不是很简单，那你这个排序还有什么价值？”

这个问题这段时间一直困扰着我，因为部分同学没看明白前文，而钉我问我鄙视我（微笑）。

“对单节点数据源的排序成本很高吗”，我一般会这么反问，很显然，相比于海量节点的排序，单个节点内的数据排序成本很低。

“每个节点的数据源都是排好序的，所有节点间的数据排序就完成了吗”，不是的，中国有首富榜，印度有首富榜，就算中国比印度富一点（如有意见，纯属意淫），要获取中印共榜后的前10名，总不能只用中国的前10了事吧。

架构设计

既然咱们是来开发试验的，而且是分布式节点，咱们就得设计架构。

架构目标

1.各节点能够快速互相发现，互相通信。

2.节点掉线被系统实时发现，并做冗灾。

3.支持运行时新增节点。

试验采用的架构：

config：负责节点注册，节点发现。

server：数据源节点，试验中有10台server。

service:对外服务，承接外部http访问，转为server查询，再将返回结果合并发给用户。

试验目标

单次查询与skip的大小无关，不能查询说查询100万以上的排序比查询100条以内的慢。（这一条是不是太屌了）

响应时间控制在100ms以内。

那咱们就开始吧。

开始前先放一下效果吧，怕大家没信心看下去。

效果展示

第一张图：同样是获取100条，分别是从第10条，10000条， 1000万条起。

第二张图：获取从100万开始的1000条数据。

skip	耗时（limit=100)	耗时(limit=1000)
10000	64ms	29ms
10	20ms	38ms
1000000	23ms	58ms

可以看出，请求耗时与skip, limit并没有线型关系，从哪里开始取，取多少条，响应时间都差不多。

也就是说，当你要从分布式存储中获取第100万开始的100条数据，与从第10条开始的100条数据，所得时间相当，而且在100ms以内，达到实时效果。

语言选择

我选择的语言是c++，因为我觉得对内存，存储啥的，它要擅长一些。不过我尽量写的简单通俗一点，并力争在不久后用java来实现开源。

分布式处理

分布式处理的config-service-server以前的文章里已经写过，框架具备自发现，动态扩容的特点，读者想要了解的话，我在以后的文章里可以继续写。

协议设计

外部协议

/topkn&k=1000&n=100k: skipn:limit

内部协议

内部节点相互通信频繁，且是双向的，因此我采用protobuf协议，方便扩展，速度也是扛扛的。

server功能：

message ServerRequest{    optional ServerBGQuery    bg = 4;              //service -> server请求， “hey, 我要从100万开始的100条数”    optional ServerBGIndexReq  bg_index = 5;       //server -> server 问索引，"hey 你那边这个数的索引是多少“    optional ServerBGIndexSync bg_sync = 6;        //server ->sync 同步查询结果， "hey, 我已经确认了查询结果，我同步给你吧”}message ServerResponse{    optional ServerBGResponse bg = 4;              //server -> service 响应， “hey，这是我查询完的结果，请收”    optional ServerBGIndexResponse bg_index = 5;   //server -> server 答索引  “hey，这个数在我这边的索引是这个”}

service

节点流程图

service起来服务代理的作用，承接外部http访问，转为server查询，再将返回结果合并发给用户。

接入请求，比较简单，只接收/topkn的get请求

service.handleGetReq("/topkn", [this](const BGCon& con){     this->OnHttpPostRequestTopKN(con);});

解析参数：

发送请求给后端的server:

所用到的协议：

message ServerBGQuery{    required int64          _s = 1;           //为这次查询取个ID吧    required int64          flag = 2;         //为这次查询立个flag    required int64          k = 3;            //skip    required int64          n = 4;            //limit}

server返回

void Service::OpBackBG(const BGCon& con, const ServerBGResponse& response){     for(auto&& v : response.vs()){       auto vit = _ctx->_v.find(v.v());       if(vit == _ctx->_v.end()){             BigValuePtr bv(new BigValue{v.v(), v.count(), v.index()});             _ctx->_v.insert(std::make_pair(v.v(), bv));        }        else{             BigValuePtr bv = vit->second;             bv->count += v.count();             bv->index += v.index();        }    }}

代码中的response代表某个server，response.vs()是它返回来的数据。

可以看见， service对所有server的数据进行整合。

涉及的协议：

message ServerBGResponse{    required int64              _s = 1;       //查询的ID    repeated ServerBGIndex      vs =  9;      //某节点中所包含的数据， “hei, 这里是我在本次查询中包含的数据”} message ServerBGIndex{    required int64 v = 1;                     //某个数    required int64 index = 2;                 //这个数的索引是多少    required int64 count = 3;                 //这个数有多少个}

service的业务功能没多少个，流程也很简单，就是起个请求代理与数据合并的功能。

server

server的的节点逻辑用一个图来表示最好不过了。

再来个简图

逻辑处理

server的响应逻辑，可以分成3个，就是实现下面的三条协议。

message ServerRequest{    optional ServerBGQuery    bg = 4;              //service -> server请求， “hey, 我要从100万开始的100条数”    optional ServerBGIndexReq  bg_index = 5;       //server -> server 问索引，"hey 你那边这个数的索引是多少“    optional ServerBGIndexSync bg_sync = 6;        //server ->sync 同步查询结果， "hey, 我已经确认了查询结果，我同步给你吧”}

对应的处理函数：