venus-messager 代码解析 笔记

messager管理了message，node，address，share-params,actor-config等主要的功能。

1. models包是对数据库的抽象实现，所以对数据库的操作都是通过这个包。其中内部的repo package 包含了以上5个（message，node，address，share-params,actor-config）数据库表的对外接口。mysql和sqlite包具体实现了对5个数据库表的业务逻辑。
2. api/messager_impl.go是对外的rpc接口实现，其逻辑调用service包下面的实现，service包再调用repo数据库相关的操作。
3. api/messager_impl.go包的方法会通过auth的client来调用auth服务，进行权限验证。
4. service/message_service.go等service会通过venus节点的client来调用链服务的mpool信息，然后再调用repo（数据库）的方法，读取数据库的内容，然后和节点mpool中得到的消息信息进行对比，再给出结果。
5. IMessager接口有两个：1. 对venus-messager repo数据库的接口。2. 对venus-mpool的接口
6. type NodeConfig struct { Url string toml:"url" Token string toml:"token" // 这个好像没有什么用处？ }
7. cli包实现了cmd接口，接口的实现其实是通过调用venus-messager rpc来实现其逻辑的。
8. filestore/fsRepo的命名非常具有迷惑性，其实就是一个存储配置文件和数据文件的地方。
9. messager连接gateway主要做的事情就是通过gateway找到wallet进行签名。但是为什么不直接调用venusa-wallet的接口进行签名呐？是因为希望wallet完全在内网，进行安全性考虑吗？
10. unfill/filled状态分表表示messager接收到消息但是还没有预估签名/ messager已经预估并把消息发送到网络当中。
11. 调用messager的send接口，或者pushmessage接口都只是把消息存储在数据库中，而不会主动触发p2p向别的messager节点进行消息的广播，也不会主动触发publisher调用node的rpc接口把消息放到链上的mpool。而是通过对node节点事件（newhead的新区块事件）的监听，来触发对本地消息的处理。具体逻辑是：messager服务启动时，就开始监听node节点服务，当收到节点消息的事件时，根据获取的消息，去更新本地数据库中消息的state状态，然后select选择从数据库中获取两类的msg。1. fill消息，是已经推送给node节点的消息，但是还没有上链，根据监听到的newhead，获取最新nonce，然后从数据库中按照大于nonce的条件，搜索出fill的消息。2. unfill消息，即没有给node节点推送过的消息。
12. messager内部的p2ppublisher是利用p2p协议（pubsub协议）给别人的node节点进行消息的广播，而对于自己的node节点直接使用rpc接口进行消息的上链。