這兩服務都是上報統計服務。。寫法功能，代碼邏輯都是類似。

 

下面是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流程類似。

具體上報細節。以後再補