2020/04/25 03-Master端数据存储设计和实现

注册数据到了master，master需要进行管理，用户通过web页面提交的任务也需要管理起来，有用户就需要数据库，建user表，建权限表，web实现对用户的访问控制，一旦用户验证通过后，用户提交的数据必须通过数据库持久化记录下来，也就是用户几点几分登录了，发了什么任务交给什么机器，都需要保存下来。

现在要解决agent发来的reg注册信息如何解决，现在是agent自己看有没有id文件，没有就自己创建一个，然后发给master来注册

保存agent和task对象的状态

下面要设计agent类，用一个个实例来存储注册后的信息，agent要建立类，并且实例化，用户发过来的数据有id，hostname，时间戳，ip，用户注册的时间还是要记录一下的，可以用自己的时间，可以在这里做时间校验，时间差异大，就没资格成为agent，可以加一个时间校验，注册完，返回一个none

在客户端，cm关心这个ack，如果是none，相当于自己出了问题


官网里还可以放异常处理
拿到字典之后，会拿到一个时间戳，然后进行时间校验，如果过失败就raise 一个exception，也可以约定好写一个类，放到common里，写一个异常类继承出来，自己写一个时间校验失败的异常类，抛出去，这样别人引用common里的这个异常类，就可以解开了

暂时不自己写异常类

注册时间可以有几种方案，客户端发来的时间，2.用服务器自己的时间，剩下的是self.id=id等，记录agent,如果写的好一点，应该在注册信息里加个状态，告诉是running还是失败，成功。
现在先使用最简单防范，初次注册

这里主要是如何将agent信息封装成一个类来，来记录这些信息

还可以提供一个字段outputs，每一个agent执行任务，如果像遍历所有的任务和结果，可以放在这个字典里。告诉你这个agent上曾经运行多少任务，每个任务的结果


这个agent和agent包里的agent是两回事情

这是来帮我们存储注册信息的

现在看task，每一个任务都不同，肯定有id，任务谁派发的，可以把脚本拿到（命令的列表，其实就是shell），有时候关心任务跑起来，真正执行完的时间，可以给一个时间的上限

还有就是选择哪台主机。其实就是列表，一个个id对应前面webserver传过来的id

这个是当前的小任务，必须发到几台机器上去执行，这是所有agent能选择的id的列表

还有必须有的状态，任务的状态转化非常重要，还有并发的上限数，不能1000台都要执行，就一下执行1000台，就是最大同时又几个agent可以跑，现在可以告诉对方，最大并发是多少

现在加入下发任务指派10个agent来执行，加入成功了9个，失败了1个就需要定义这个任务是否成功了，可以定义至少几台失败，至多几台失败，达到阈值就认为是失败，失败有失败的策略，可以重新下发任务再次尝试

还可以用几率来判断rate

设定一些阈值来判断是否成功，比如10个节点，有5个节点计算出来的达到了设定范围，不是所有计算会有一个准确值，有些计算是迭代的计算，是收链的计算，每一次得到的结果不一样。
如果10台，有6台算出的结果是符合要求的，此次任务成功，所以下发任务还可以带标准值，或者区间，是你想要的就return 0，不是就return其他的

这样前端webserver可以想象成一个页面，用户填一个脚本，选一个时间，可以选择机器，然后选择最大并发数，同时有几台可以执行

有并发数，和失败的计数，这样就差不多了


现在改个最大并发是1

可以用repr来进行展示

现在造出一个个任务，实例，就需要存储，需要做持久化。
master要管理所有的agent

message放在cm中，类似handler，所以它来存储不太合适

专门有个东西可以做持久化，可以写model类，storage，负责数据存储，需要把agents注册的agent的字典和tasks任务字典，存进去。
可以写方法，方法里做判断在注入

这里先修改，把三项传进去

现在没有考虑有一些agent被删掉了，这些废的agent怎么办，目前先考虑信息如何存储，现在这样注册一次就是新的agent，即使这个agentid已经在agents存在了，还是要覆盖的

可以把已经存在的id的值，更新一下就行了，这句话没有问题，只是同一个id覆盖了

可以进行判断一下,有就更新，没有就新增

在写message的时候，所有内容分开了，各自完成各自的事情

只要是存储都加入store，这里只暴露接口，通过rpc暴露接口调用，把信息发给store，至于信息存不存在于store

存下来就可以在storage里看到信息了

有时候没有注册，heartbeat也带了信息，但是怕最后真正去自己去构建的时候，heartbeat和现在的heartbeat设计不一样，如果只是带时间戳和id，就没什么好更新的，只能更新状态，是否掉线，heartbeat掉线了还要更新agent对象上的某一个

这里只是在store里存储什么信息，跟之前的heartbeat不一样，假设heartbeat信息只有id和时间戳，agent上加一个信息，就是最后一次报道时间

agent上加一个信息，就是最后一次报道时间lastupdatetime

heartbeat来了之后回调用storage，也就是现在改成reg的这个方法

每一次heartbeat都会去里面，找已经 有的，把最后一次更新的时间戳时间写进来

还需要再起一个线程，就要遍历里面的所有数值，遍历之后就拿当前时间进行比较

借助redis，就不怕过期，不仅要对heartbeat更新，还要再起一个线程对同一个进行遍历，如果出错，一边写一边读，就有可能冲突，就可以借助redis

heartbeat最后这样比较好，如果有其他信息修改，就单令再发修改，再写几个方法，这些方法只是偶尔做，注册也是注册几下，心跳比较多，也可以想办法单另出来。

心跳的业务只是做了一件事情，告诉你刚才来过，说明是ok的

这里都是调用store方法

message就负责消息处理，rpc调用接口的暴露

关于持久化和存储都交给store

这样就实现了agent动态注册

一个人做，就按照现在的方式，agent主要实现一部分功能，master主要实现一部分功能，把他们串起来，然后看前后打通之后，再对agent，master补充一些功能，这样平台就一点点累积起来。