当前的业务大致可以描述为：
目前有一个客户端C，用于接收外部的数据，客户端的相关操作需要通过UDP进行指令的传输，并会回传相关状态（即每个数据项的状态）。
需要设计一个服务端S，用于接收任务，并根据任务来向客户端分配数据接收任务，其中对于客户端进行容器封装，并支持拓展。
实现思路为：
- 将客户端进行镜像化将客户端的相关指令进行封装进行UDP的客户端和服务端的编写
- UDPClient用于发送UDP指令给CUDPServer用户接收C的状态反馈
- 通过容器中的C目前的外部数据项个数进行均衡分配（加权）根据指定的关系进行分配（指定）直接进行均衡分配（非加权）
目前设计为：鉴于容器的状态变动频繁，这里将容器的状态放入redis中进行存储和维护，其中包含了以下字段：
{
"name":名称,
"cid":容器id,
"hostIp":主机ip,
"publicPort":外部端口,
"num":外部数据项数量,
"running":是否运行中,
"hasNum":是否包含外部数据项
}
在每次进行了数据项的修改之后，都需要去更新redis中的num数值，在初次加入数据项和移除所有数据项时，还需要更新hasNum，对于running字段在容器进行启动和停止时进行更新。
问题几个字段的更新频率为：
num>>hasNum>running>其他字段
在实现之后发现了一个问题：目前的num的更新策略为，在向客户端进行外部数据项的新增和删除的时候进行更新，但是在这个过程中，并无法直接检测到添加或者删除是否成功（因为用户完全可能添加一个完全不可用的数据项，或者由于网络问题，并没有发送成功UDP指令），这时进行的num字段的更新就是无效的，甚至是noise的，因为影响到了后期的任务分配。
上述情况摆出的问题就是：
- 如何获取客户端中的真实外部数据项数量如何将客户端的数量和容器对应
获取心跳包中的发送方ip和端口，欲获取到的ip为外部ip和外部端口，通过外部端口可以唯一确定一个容器。
新增一个redis键值对，用于维护客户端中的数量，结构为：
{
"端口号":数量
}
之后获取容器信息的时候，再从redis中获取实时数量，并进行更新。
发现的问题在物理网络环境下，获取到的UDP发送方的地址为物理地址，端口为容器内部端口。。。
由于容器内部端口都是一致的，导致通过这种方式进行容器的区分产生了困难。
次级解决方案与客户端协商一个新的字段INDEX，该字段作为环境变量在容器创建时进行设置，并在发送心跳包的时候带上。这样就可以建立一个容器和index之间的一一对应关系。
这时，redis中的新的键则改为：
{
"index":数量
}
在获取容器中的数量时，可以先通过containerId获取到contaienr中设定的index信息，然后通过redis获取容器中的数据项数量。
