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补充一些功能，这样平台就一点点累积起来。