1 赛项背景与目的

云翼数据缓存中间件云原生管理平台是东方通开源贡献给openEuler项目群的云原生套件。通过将传统数据缓存中间件服务纳入管理，增加数据缓存产品的云服务能力，弥补数据缓存中间件在云原生环境下的市场空白。该平台提供Proxy节点承接统一的数据读写服务，以屏蔽产品内部的具体实现。由于增加Proxy代理后的数据读写会存在读写性能不同程度的下降以及部分指令实现的差异，需要对Proxy实现的功能进行优化。

本赛项的目标是为了实现对Proxy性能做一定的提升，考查参赛队伍对数据缓存中间件的理解与发现应用中需要着重解决的问题。

2 赛题内容

主要包含两方面要求：

(1) 通过实现Proxy模块的Pipeline功能提高指令批量处理的性能；

(2) 整体性能优化。

2.1 技术背景

数据缓存中间件云原生管理平台在原数据缓存中间件基础上增加云原生集群模式，云原生集群模式由中心节点（Center）根据k8s中服务节点（Service）的部署数量动态调整分片结构并设置分片内的主、从节点。

代理节点（Proxy）通过中心节点（Center）获得数据分片情况和各分片的主节点信息。

为了保证性能，Proxy采用基于netty的全异步通信模式，当Proxy收到客户端请求时根据不同请求做如下处理：

(1) 发布订阅命令（pubsub类），为了减少命令传递路径，此类命令直接在Proxy中处理，不会发送到后端服务节点。

(2) Lua脚本处理，直接在Proxy中解析并执行，只将其中数据访问命令（如：get、set等）发送到对应分片的服务节点执行。

(3) 多key操作命令（SeveralCallback，如：del、exists、mset、mget等）根据key的顺序依次调用对应分片的服务节点。

(4) 全分片操作命令（MultiCallback，如：keys、scan、flushdb等）遍历各分片，依次调用服务节点。

(5) 会阻塞的命令（如：blpop、brpop等），申请独立连接发送到对应分片执行，执行完成后释放连接。

(6) 其他命令，根据key调用对应分片的服务节点。

目前Proxy将收到的请求完全并发的按照上述处理逻辑处理，并没有区分不同客户端请求，对于绝大多数应用均正常，但对于客户端的Pipeline模式的调用存在问题。

通常Redis协议的客户端是工作在同步模式，即客户端发出请求，等待响应，收到响应后再发送下个请求，以此类推。这种模式下1个client实际上Proxy同时只会收到1个请求，而在Pipeline模式下客户端会依次发送多个请求，然后按照请求发送的顺序等到一组返回结果，而Proxy对依次收到的多个请求也将并发处理（将同一个客户端收到的多个请求并发发给服务节点），命令返回结果的顺序受不同命令执行时间的影响（某个命令执行完成会立即将结果发回客户端），造成返回给客户端的结果与客户端发送请求的顺序不能一一对应而出错。

本赛项要求参赛队伍通过Pipeline以及其他代码优化方式的性能提升手段，增加Proxy节点的处理能力，提升数据处理效率。

2.2 比赛要求

(1) 实现Pipeline模式支持（可使用jedis测试Pipeline模式）

(2) 不改变Proxy整体异步响应模式

(3) 对非Pipeline命令不能造成较大性能影响

(4) 不能影响正常功能使用和消息同步等。

2.3 开赛条件

本赛项正式开始比赛的要求为：报名队伍数量至少达到60支，且提交作品数量至少达到30个。若未达到报名队伍或提交作品的数量要求，则本赛项可能被延期或暂停，届时将由本赛项共建方（北京东方通科技股份有限公司）向您发出书面通知。

大赛最终解释权归开放原子开源基金会及共建方所有。