2021华为软件精英挑战赛总结分享
2021华为软件精英挑战赛总结分享
随着大赛的结束，自己的2021软挑也落下了帷幕，很幸运在自己学业生涯的最后几个月能够再参加一次华为软挑，虽然成绩不是特别好，但已经满足了。这是自己第二次参加华为的比赛，也是最后一次参加了，很感谢主办方华为，也是因为有了去年的比赛，才很幸运地在秋招能够拿到一些offer，在此，再次感谢华为公司，希望华为以后越来越好。
比赛成绩
队伍是成渝赛区，队伍名称：哑巴湖大水怪，成绩初赛：成渝第1，复赛：成渝第3，决赛拉跨，16强。
赛题介绍
赛题本质就是一个装箱问题和资源调度问题，比赛链接如下：2021华为软件精英挑战赛。
初赛方案
初赛赛题会提前一次性给出所有天的请求信息，所以很多队伍会利用这一上帝视角来进行服务器的选型以及部署，但自己实在是能力有限，不知道该如何利用好这一有效信息，因此也就没有利用这一信息，只是简单地对当前天的请求进行处理。
初赛赛题大家的优化点主要集中在三个部分：服务器选型、虚拟机部署和迁移。
1. 服务器选型
服务器选型应该大部分队伍的方案都差不多，我们的方案也是最简单的，在练习赛的时候使用的就是按照服务器售价排序，选择第一个能容纳下当前请求的服务器，也就是选择能容纳下当前虚拟机的最便宜的服务器。后面在正式赛的时候换成了按照服务器的日常能耗来排序成绩会更好。
2. 虚拟机部署
虚拟机部署这里应该很多队伍除了评价函数不一样之外，其他策略应该都是一样的，大家应该选择的都是best fit，但是重点就在评价函数这，有些评价函数太复杂，会使得计算时间上升。
我们队伍选择部署的策略是，遍历已有的服务器，找到使当前服务器某个节点剩余空间（CPU+内存）最小的服务器，也就是说评价函数就是当前这个服务器上两个节点剩余空间的min值，也就是说我的部署方案是尽量让服务器上的某个节点剩余空间最小，这个时候不再是以服务器为单位来评价了，而是以服务器上的节点维单位来评价。在找的过程同时还会记录虚拟机的部署位置，因为对于单节点部署的虚拟机，当我们在找最佳位置的时候，实际上是找服务器上哪个节点最适合，因此在找的同时记录位置，然后直接按照这个位置来部署。
如果找不到能放下的服务器，就按照上面的选型策略来购买新服务器。
3. 迁移
迁移这一块估计大家也都差不多，基本都是按照负载率来对服务器进行排序，然后尽量把低负载服务器上的虚拟机往高负载服务器上迁移，尽量空出更多的空服务器。但是，我们的方案有所不同。在练习赛的时候，我们尝试过按负载来排序，然后将低负载往高负载迁，后面发现迁移效果不佳。然后换了一个新思路，我们将服务器按照上面存放的虚拟机个数来排序，然后将个数为1，2，4的服务器上的虚拟机删除再重新部署。注意，我这里的迁移不一定非得是低负载到高负载，而是将这些被选中的虚拟机进行重新部署，重新寻找它最佳的位置，评价函数依然和虚拟机部署的一样，这也有可能找到的位置就是原位置，那就不进行迁移（我称之为无效迁移）。
然后师弟为了减少程序运行时间，只迁移每个服务器上的第1个虚拟机，我们发现效果更好，成本更低。因此我们又将迁移方案换成对服务器按照虚拟机个数排序，然后选取每个服务器上的第1个虚拟机进行迁移，这让我们在练习赛的时候的成绩已经能够进步到成渝第2。
在正赛的时候，我们发现按照负载率排序后，然后再选取第1个虚拟机进行迁移，成本会更低，因此在正赛我们又换成了按照负载率排序。
当然，这只是粗略的方案，迁移里面还会有很多细节，比如在寻找最佳位置的时候如果找到空服务器了，那就不进行迁移；比如如果待迁移的虚拟机是当天删除的，可以选择不迁移；前一天的删除请求比较少的时候要不要迁移，因为没必要每天都迁移；负载率的定义方式不同也会有影响。这些都是我们考虑的在正式赛调参的点。
4. 额外上分点
我们知道，装箱问题的方法除了Best Fit 和 First Fit，还有BFD和FFD，就是我们对虚拟机根据大小进行排序，先部署大的，再部署小的，这可以多利用一些有效空间，减少每个服务器的碎片。
但是这个赛题每天的请求还有要删除的虚拟机，有可能某个虚拟机当天创建当天删除，所以我们准备了两个思路。
1：将每一天所有的创建请求提前，也就是先处理所有的创建请求，再处理所有的删除请求。重点在于对所有的创建请求按照虚拟机占用空间进行排序，优先处理空间大的请求。这里有一个问题，就是因为前面的删除会被延后，那么它释放出的空间就没用到。但是这个是不可避免的，我们想的就是损失一部分删除空出来的空间，通过BFD的部署来弥补。
2：对每一天每两个删除请求之间的添加请求进行排序。这种方式就是会利用上删除的空间，但是有可能占用空间大的虚拟机请求比较靠后，这就没法提前部署它们。
这两个排序方式也是我们能够作为调参的点。
另外，我们在服务器选型和虚拟机部署那里还准备了一些其他的方案，反正就是各种试。
1： 在服务器选型时，之前是选择最便宜的能容纳下当前虚拟机的服务器，那么我们在判断是否能容纳时，在虚拟机cpu和内存上乘一个系数，比如当前服务器是_server，虚拟机是_VMware，双节点部署，之前判断能否装下是 _server的每个节点的 cpu 和 内存 是否大于_VMware 的 cpu/2 和 内存/2 ，这里我们会在_VMware的这里乘一个系数，比如是1.2，那就是 1.2cpu/2 和 1.2内存/2 。
2：在虚拟机部署时，考虑先在已有服务器上找最佳位置，找不到的话再在今天购买的服务器上找最佳位置。
3：在虚拟机部署时，先在已有的热机上找最佳位置，找不到的话再在冷机上找一个日耗最小的（因为一旦服务器开启就有日耗，那么优先找一个日耗最低的，尽量减少每天的日耗）。
4：多线程，因为线上提供的运行环境是2核的，所以可以开两个线程，使用两套不同的方案，相当于多一倍的提交机会。
复赛方案
复赛在初赛的基础上几乎没变化，就是没法提前知道所有的请求，只会给你提前K的请求，当你读完前K天的请求后，需要输出第一天的结果才能继续读取第K+1天的请求，这就涉及到交互。程序的改动很小，基本就是改一下输入输出就好了。且因为交互的原因排除了使用双线程跑两套方案的策略了。另外复赛还有一个改动就是增加了每天允许迁移的虚拟机的次数，这样大家有更多的迁移机会，同时也会让程序的运行时间增加，因此在复赛练习赛的时候优化代码运行时间也是很重要的一部分。
复赛的方案我们基本只改变了一下几个地方：
1. 服务器选型
之前初赛购买新服务器时是按照售价或者能耗从小到大排序来选择服务器的，在复赛练习赛的时候发现一个数据集适合按售价排序，一个数据集适合按能耗排序。在某个小学弟的指导下，尝试了一下在前期按照能耗排序，到后期按照售价排序。这么做的原因在于前期服务器生命周期长，能耗占比比较重，而到了后期服务器存活时间短，售价占比较重。改动之后，这个地方是一个非常大的上分点。我的区分前期后期的策略就是给一个时间的百分比，在练习赛的时候是前25%的天按照能耗，后75%的天按照售价；在正式赛的时候，这里是进步最大的参数，改为了前50%天按照能耗，后50%天按照售价。
2. 虚拟机部署
虚拟机部署这的改动不大，就是改动了一小部分的评价函数，之前初赛对于部署这一块的评价函数，是选择每个服务器上两个节点剩余空间的min值，然后再取所有服务器的min值进行部署，所以是两个min。在复赛时，我们对此处做了一定的更改，对于双节点部署的虚拟机，依然是选择两个min的方案。但是对于单节点部署，我们选择的是每个服务器上两个节点剩余空间的max值，然后再取所有服务器的min值进行部署，这么做的依据是在单节点部署时尽量使服务器的A、B节点比较均衡，所以会优先部署在剩余空间大的节点上。
另外，在练习赛的时候，我们在部署的时候选择 first fit 会比 best fit 更好，但在正式赛的时候，还是 best fit 更好。
3. 迁移
复赛的迁移基本策略与初赛基本一致，因为增加了每天允许的迁移次数，因此很多队伍成绩提升的很快，而且他们能在很短的时间内把迁移次数拉满，而当时我们的方案因为选择的是 best fit，因而会存在很多无效迁移，因而时间很长，同时没有办法把迁移次数拉满。
另外，我们的方案是选择每个服务器上的第一个虚拟机进行迁移，这个地方在复赛依然是十分有效的，只是这使得我们的迁移次数剩余太多，为了拉升迁移次数，我们多增加几次迁移轮次，就是添加一个while循环的问题。
迁移这里很费时间，因为每次迁移都要遍历所有的服务器来找最佳位置，因而为了减少时间，剪枝是必不可少的。主要使用了两个方面的剪枝。
- 设置一个负载率阈值，一旦某个服务器的负载率达到了这个阈值，就不对该服务器上的虚拟机进行迁移，另外为了减少迁移时间，会设置一个动态阈值，随着迁移轮次的增加，这个阈值会减少，这样约到后面能迁移的虚拟机就越少。比如，第一轮阈值设为0.99，以后每增加一轮，负载率就减少0.005。
- 对于迁移不动的某类虚拟机，做一个标记，下次迁移如果还是该类虚拟机，就直接跳过。比如在某一次迁移中，对于某类虚拟机，如果找了一遍发现还是只能在原来的位置，那么在下次遇到这种虚拟机的时候就直接continue，不执行查找的步骤，这在一定程度上能减少很多时间。
整体的迁移方案就是这样，需要调整的就是通过设置负载率阈值、前一轮次来进行调参。
4. 最大上分点
整个复赛，因为我们的方案基本没咋变，所以在前期的时候成绩一直不理想，而且要调的参数很多，很多参数都没法同时适应两个数据集。
在练习赛的最后两天，发现了一个上分点，直接把我的方案里的很多参数给去掉了。这个最大的上分点直接让我的练习赛成绩进步到了1740左右。这个上分点就是服务器合并。
具体的说就是对于处理某一天的请求，我会把服务器分为以前已有的服务器，和当天购买的服务器，当我处理完当天
的请求后，会对当天购买的服务器做一个合并的处理，思路也很简单。就是遍历这些服务器，如果相邻的两个服务器
上的虚拟机能够被某个更大的服务器容纳，且这个更大的服务器的售价和能耗都小于之前这两个相邻的服务器的售价
之和和能耗之和，那就用这个更大的服务器来代替之前的两个服务器。
复赛正式赛需求变更点
复赛正式赛需求变更点就是允许某一天的迁移次数能突破3%限制，可以达到100%，现场分析后可知因为只有某一天才能有这个机会，所以对成绩的改动并不大，基本只有几十万的提升。我们选择的策略就是如果某一天的删除次数大于500，那么我们就在下一天使用该策略。
决赛方案
决赛的赛题变动比较大，增加了报价部分，多了与对手博弈的部分。具体的赛题更新部分我会发在github上，这里就不详细论述了。主要说一下我们的方案。
因为决赛多了博弈的部分后我不是很喜欢这种模式，又恰逢当时学校有事，感觉自己也没实力拿前八，基本就属于半放弃了，匆匆写了两个版本后基本就不管了。
版本一：动态打折。为了抢到虚拟机单子，起始设置一个较低的折扣，然后通过统计自己前一天的获单量来决定增大还是减小自己的折扣。这个方案基本是大家都知道的方案，所以被暴打。
版本二：预估自己的最低成本进行报价。会增加一个预部署的步骤，假装自己能够拿到所有的虚拟机请求，进行部署，根据每个虚拟机占用的服务器资源比，对虚拟机进行最低定价。版本二基本在前期就是成本价，因此在后期因为亏得比较多，只能按照请求给得全价来报价。这个方案练习赛也只能10几名。最后正式赛使用的就是版本二。
决赛正式赛需求变更点
在决赛正式赛的时候，需求变更点特别大，导致直接颠覆练习赛的排名，需求变更是每一天我们都可以对3个请求进行指定，这3个请求一旦指定后，就算对手的报价比你低，你也可以按照你的报价拿到。但是如果对手也指定了这个请求，那么谁出价低谁拿到。
当时一想，每天能拿到3个，大家应该都会拿存活时间较长的虚拟机，1000天就可以拿3000个，那这个上分点影响实在是太大了，一旦对手抢不过你，那基本就是吊打对面。
所以我们很快实现了这个需求点，对自己要指定的3个请求进行报价，为了避免对手也指定这3个，且价格比我们低，所以我们对于指定的请求进行了一个折扣，为了一定的随机性，我们指定了3个折扣，对于某个请求根据随机值来选择使用哪个折扣，这在练习赛的时候使得我们一直维持在前排。但这同时也暴露了我们得策略，因为只有3种折扣，对手很快就能计算出来。这也是我们很后悔的一点，应该设置一个区间打折的，只有三个，太容易被看出来了。
因为决赛是PK制的，在苟活了两轮之后被干下去了，没能进入八强，不过本身因为自己决赛并没有肝，是以一个挑战者的身份来的，所以并没有很失落。
整个软挑比赛下来就是这样，成绩中规中矩，但好在进了决赛，弥补了自己去年没能进入决赛的遗憾，具体的代码我会放在下面，因为自己代码写的太烂了，全程都只有一个文件，大家看看思路就行。
另外去年的比赛博客写了一半，拖了一年还没写完，准备趁此机会，一并写了。
本来还想取官网看看决赛的对战日志的，发现已经找不到入口了，算了算了。
初赛正式赛代码
#include 复赛正式赛代码
#include 决赛正式赛代码
#include