_maxPageSize /tars/hash<max_page_size> 配置中默认是29
_maxPageNum /tars/hash<max_page_num> 配置中默认是30
过滤条件。配在 /tars/filter中
NotifyF.tars 接口实现
reportServer 框架上报的信息, 保存于数据库中
实际执行的函数是 reportNotifyInfo.此种模式下如下：
1、上报的内容是sResult中，检查服务的过滤规则，如果上报内容的在过滤中，此次上报取消.
2、将上报内容生成sql语句，写入 "t_server_notifys"中。
看了下此函数使用之处 几乎都是NodeServer中操作完毕之后，会调用此函数 上报操作内容。
notifyServer 业务上报的信息, 用于报警
此函数看调用处.貌似已废弃。替换成reportNotifyInfo。
实际执行的函数是 reportNotifyInfo.此种模式下如下：
将内容格式整理下，存在 内存的。g_notifyHash 中。
这里的写法比较有意思的地方是，g_notifyHash是 TarsHashMap<NotifyKey, NotifyInfo, ThreadLockPolicy, MemStorePolicy>类型，此数据结构设计的比较牛逼，进程重启也不会丢数据。
key是 {
NotifyKey stKey0;
stKey0.name = info.sApp + info.sServer;
stKey0.ip = current->getIp();
stKey0.page = 0;
}
一直都是在拿第0页做开始。第0页没满，直接塞到第0页的NotifyInfo.notifyItems这个vector中。若第0页满了（判断满的条件是 NotifyInfo.notifyItems.size()>=_maxPageSize）则将第0页置换出去.被置换的页码是从1-_maxPageNum-1.轮询过去。。
getNotifyInfo 获取上报信息
从上面的 g_notifyHash 读取对应内容。
根据指定的NotifyKey
{
name;//(app+server)
ip;
page;//页码
}
根据此key获取指定g_notifyHash的内容。。
未看到调用之处.
reportNotifyInfo 上报框架信息以及业务告警信息
此函数是reportServer和notifyServer的具体实现。详细看上面介绍。
看代码实现。。TarsRemoteNotify中的 TarsRemoteNotify::notify()和TarsRemoteNotify::report()全部都是执行的REPORT类型了。也就是全部都是 reportServer了？？这么奇怪的吗？
LoadDbThread 从db加载set相关信息的线程类
定时频率30s一次.从 t_server_conf 中读取 所有服务的set方面信息。并用
app+server+nodename 做可以;set_name+set_area+set_group做value。放在缓存中。
这个set信息用于在 notifyServer和reportServer时生成的上报数据里面的sSet字段所用.