自适应负载均衡的设计实现

 

初赛：《自适应负载均衡的设计实现》

赛题背景

负载均衡是大规模计算机系统中的一个基础问题。灵活的负载均衡算法能够将请求合理地分配到负载较少的服务器上。理想状态下，一个负载均衡算法应该可以最小化服务响应时间(RTT)，使系统吞吐量最高，保持高性能服务能力。自适应负载均衡是指不管处在空闲、稳定仍是繁忙状态，负载均衡算法都会自动评估系统的服务能力，更好的进行流量分配，使整个系统始终保持较好的性能，不产生饥饿或者过载、宕机。

要求
修改题目提供的扩展接口(UserLoadBalance)，实现一套自适应负载均衡机制。要求可以具有如下能力：
一、Gateway(Consumer) 端可以自动根据服务处理能力变化动态最优化分配请求保证较低响应时间，较高吞吐量；
二、Provider 端能自动进行服务容量评估，当请求数量超过服务能力时，容许拒绝部分请求，以保证服务不过载；
三、当请求速率高于全部的 Provider 服务能力之和时，容许 Gateway( Consumer ) 拒绝服务新到请求。

 

评测

一、PTS 做为压测请求客户端向 Gateway(Consumer) 发起 HTTP 请求，Gateway(Consumer) 加载用户实现的负载均衡算法选择一个 Provider，Provider 处理请求，返回结果。
二、每一个 Provider 的服务能力(处理请求的速率)都会动态变化：

• 三个 Provider 的总处理能力会分别在小于/约等于/大于请求量三个状态变更；
• 三个 Provider 任意一个的处理能力都小于总请求量。

三、评测分为预热和正式评测两部分，预热部分不计算成绩，正式评测部分计算成绩。
四、正式评测阶段，PTS 以固定链接数(1024) 向 Gateway 发送请求，1分钟后中止；
五、以 PTS 统计的成功请求数和最大 TPS 做为排名依据。成功请求数越大，排名越靠前。成功数相同的状况下，按照最大 TPS 排名。

排名示例：

名次	成功请求数	最大 TPS
1	1,000,000	9,999
2	1,000,000	9,998
3	800,000	10,000

 

特别说明
一、因为初赛选手众多，每支参赛队伍天天给予 5 次评测机会，请珍惜使用；
二、请务必在本地验证经过之后再提交评测，除评测环境形成的跑分失败外，其他状况均视为机会已被使用；
三、除环境因素外，恕不能提供针对具体实现的排错支持。

赛题详细说明
赛题组将进行持续更新，请点击连接：
https://code.aliyun.com/middlewarerace2019/adaptive-loadbalance

 

复赛：《实现一个进程内基于队列的消息持久化存储引擎》

赛题背景
Apache RocketMQ做为的一款分布式的消息中间件，历年双十一承载了万亿级的消息流转，为业务方提供高性能低延迟的稳定可靠的消息服务。随着业务的逐步发展和云上的输出，各类依赖消息做为输入输出的流计算场景层出不穷，这些都给RocketMQ带来了新的挑战。请实现一个进程内消息持久化存储引擎，可支持简单的聚合计算，如指定时间窗口的内对于消息属性某些字段的求和、求平均等。

要求
实现一个进程内消息持久化存储引擎，要求包含如下功能：

• 发送消息功能
• 根据必定的条件作查询或聚合计算，包括

A. 查询必定时间窗口内的消息
B. 对必定时间窗口内的消息属性某个字段求平均，以及求和

例子：t表示时间，时间窗口(1000, 1002)表示: t>1000 & t<1002

消息内容简化成两个字段，一个是业务字段a（整数），一个是时间戳（long）。实际存储格式用户本身定义，只要能实现对应的读写接口就好。

详细内容将于复赛以前更新

 

https://tianchi.aliyun.com/competition/entrance/231714/information

 

https://code.aliyun.com/middlewarerace2019/adaptive-loadbalance