2019创青春-新网银行金融科技挑战赛-分布式赛道-比赛总结

目录

1. 初赛
   1. 自主实现的判题机代码
      1. windows 10 本地测试 950 节点的资源占用：
      2. 结果评估（自动输出）：
      3. 最坏情况路由分析（手动的）：
   2. 可视化程序
   3. 基本思路
2. 决赛
   1. 决赛的问题
   2. 相关链接

2020 年 4 月 2 日更新，接到新网银行电话，要求移除 github 上相关代码，我们已经把我们发布的代码设为私有。

大概 10 月中旬看到了一封 SegmentFault 的邮件，提到这个比赛，发现分布式赛道的题目很有意思。

比赛是 9 月 18 日开始 11 月 15 日结束，但是由于比较忙，直到 10 月底我才第一提交代码，11 月初我们正式组队 (已失效) 开始参加初赛，我们几乎都是使用业余时间完成初赛代码 (已失效)。后来有幸进入决赛，在成都参加了线下马拉松，决赛我们有不少失误，虽然成绩远没有预期的理想，但是我们收获很多。

初赛

我们获得了 1124.82 的最总成绩。（满分 1200）

我们的特色主要是可视化和辅助工具。我们队的时间非常紧张，因为参赛太晚，而且工作日学校还有很多事情。准确评估解决方案的效果和缺陷，快速迭代，是我们初赛取得好成绩的关键。

自主实现的判题机代码

我们实现的初赛判题机代码仓库 (已失效)

虽然时间很紧张，但是我们还是仔细阅读了判题机的所有代码。（比赛期间是提供了判题机代码的，现在似乎没有了）还写了一个代码阅读笔记，虽然耗时，但是值得。

为了更高效的实现自动化结果评估和拓扑、路由可视化，我们自己动手写了一个判题机。主要的理由是：

1. 我对 c++ 不够熟悉
2. 我希望使用 阻塞套接字
3. 输出结构化日志
4. 判题机自动启动、停止客户端进程
5. 使用消息驱动（异步）
6. 跨平台

上述目标基本实现了。

windows 10 本地测试 950 节点的资源占用：

图截的不好，这里主要看内存，CPU 占用高是因为这是启动过程中大量创建进程。实际运行过程用 CPU 负载不高。主要是内存占用高。

结果评估（自动输出）：

最坏情况路由分析（手动的）：

消息哈希：4658B1314C

源点：943 (主根 897)

目标：401 （主根 385）

时延：2.21

转发跳数：19

路由：

[943, 0.6682496070861816]
[920, 1.824514627456665]
[908, 2.1567699909210205]
[902, 2.199902057647705]
[899, 2.242053747177124]
[898, 2.2840933799743652]
[897, 2.326270580291748] (到达本树主根)
[1, 2.3676204681396484]
[65, 2.409736394882202]
[129, 2.451462745666504]
[193, 2.493069887161255]
[257, 2.5348517894744873]
[321, 2.576202630996704]
[385, 2.617375612258911] （到达目标主根）
[386, 2.6591007709503174]
[387, 2.70068359375]
[389, 2.741595983505249]
[393, 2.7833566665649414]
[401, 2.8250982761383057]]

可视化程序

环形拓扑，使用了 svg 和原生 javascript。

树环拓扑，使用 echarts 的力导向图。

基本思路

实现静态路由作为网络的主干，两个优化分支：

1. 通过局部的动态路由算法。

2. 整体的拓扑调整，不断向最有拓扑演进（此策略我们做的效果不好）

3. 环形拓扑

   

4. 树环拓扑

   示意图：

   

   可视化图：

   

3. 临时链路优化

对于路由条数超过阈值的消息，在按照路由转发的同时，尝试建立一条直通链路（有可能失败），直接发送。

决赛

决赛的场景有了较大的改变。相比之下，拓扑不再那么重要，而路由算法更能影响分数。

两种思路：

1. 由于节点改变服务类型的时延极高，因此我们在节点处理当前数据包，预先将下一跳节点的服务类型切换为数据包下一个服务类型，边移动边处理

2. 固定角色，两套路由：一套是路由到指定服务，一套到指定节点。

   我们获取了初始的服务状态，发现分布比较均匀，且各类型服务都有：

   服务分布：

   

   服务类型比例：

   

   决赛的问题

   我们两种思路都没能做的完善，虽然我们几乎没怎么休息。决赛里我们确实失去了初赛时候的很多优势。没有充足的时间调试。初赛我们的 python 方案完全抛弃了官方的示例程序。而是自己实现的，但是决赛里我们没有这么做，主要是考虑时间问题。而决赛的 c++ 示例程序中潜藏的问题非常的多，让我们应接不暇，最终我们只好彻底放弃了 c++ 方案的开发而集中力量开发 python 方案。非常遗憾的是我们的两种思路都没能做好。

相关链接

比赛官网
DC竞赛-分布式路由赛道初赛
初赛代码仓库 (已失效)
判题机代码仓库 (已失效)