这两服务都是上报统计服务。。写法功能，代码逻辑都是类似。
下面是PropertyServer的介绍
此服务，应该性能瓶颈在db。所以采取的策略是，把上报的数据，放在内存缓存中。后面再异步批量写入db而且是分多个db。
为了尽量挖掘性能，在内存中，有着一组 继承于TarsHashMap的 hashMap.双buff。。
PropertyF.tar 实现流程
reportPropMsg 上报属性统计信息 Prop = property
接到上报数据后，加入上面的双buff的hashMap中。
PropertyReapThread 用于执行定时操作的线程类
此线程数为1个
这个线程，轮番拿上面的 双buff的hashMap 入库。。
这里的过程大致是，从hashMap中获取数据后，轮着往db指定ReapSSDProcThread线程中存放.
搞双buff的好处很明显。一边是读，一边是写，不用加锁。互相不影响。
此线程3s轮询一次。
ReapSSDProcThread 向数据库插入数据的线程类
此线程数为 _dbIpNum * _oneDbHasThreadNum
_dbIpNum 取值取决于两个数， “/tars/multidb/”配的db数 配置文件配了2个，实际视情况而定；还有个是，配在/tars/reapSql<insertThreadByMachine>，代码默认是4。这两个值中取更小的那个
_oneDbHasThreadNum 取值取决于两个数，一个db所对的线程数 /tars/reapSql<insertThreadByDB> 代码默认是2；还有个数是上麦的配置的multidb数。这两个值中取更大的那个。
数据所插入的表名是配在对应 /tars/multidb/" + vDb[i] + "<tbname> 中的。默认是 "t_propert_0" + TC_Common::tostr(i) + "_")。酱紫的。
数据插入是，累积到100条一次批量插入。最后不足100条时，一次插入。
如果插入db操作时间超过. 40 * _insertInterval.则，发sendAlarmSMS(sMsg)。。这个是短信告警吗?
其中_insertInterval 值是 配在/tars/hashmap<insertInterval>中。默认配置是5s.。并且此值不小于5s
上报端 上报详解
在Application::waitForQuit中。定时5S一次检测下。距离上次上报超过10s，则执行一次 "统计服务端相应队列大小的上报的对象"上报.
StatServer流程类似。
具体上报细节。以后再补
