公司要求繪畫用戶肖像,運(yùn)營分析用戶喜歡哪個(gè)話題,喜歡進(jìn)入哪些頁面..我想到了做請(qǐng)求上報(bào)處理.
目前有一臺(tái)A服務(wù)器做API應(yīng)用,計(jì)劃增加一臺(tái)B服務(wù)器,記錄用戶請(qǐng)求.
我目前想到了兩個(gè)方案來記錄用戶請(qǐng)求
location / {
# 主要請(qǐng)求被發(fā)往服務(wù)器A
proxy_pass http://serverA;
# 請(qǐng)求副本被發(fā)送到服務(wù)器B
mirror /mirror;
}
location /mirror {
internal;
proxy_pass http://serverB$request_uri;
}
upstream serverA {
server A_IP_ADDRESS:PORT;
}
upstream serverB {
server B_IP_ADDRESS:PORT;
}
目前不知道這兩種方案,哪一種比較好.或者還有其他什么方案嗎?
我希望增加了消息上報(bào)請(qǐng)求盡量不要加重nginx或者A服務(wù)器wenman的負(fù)擔(dān).
A服務(wù)器目前配置,8G16核,最高QPS 500左右.
求大佬解惑
方案2,8C16G對(duì)500QPS綽綽有余,如果純分析訪問的uri,隊(duì)列都不用,nginx開access log,分析log就行
用戶畫像這種需求建議使用一些比較成熟的bi產(chǎn)品去做;
因?yàn)槌擞脩舢嬒?,未來可能還需要對(duì)產(chǎn)品的其他數(shù)據(jù)進(jìn)行統(tǒng)計(jì)分析;
你的這個(gè)需求除了全域采集,還涉及到增長分析等。
這種業(yè)務(wù)的難點(diǎn)不在接收事件上報(bào)的服務(wù)器,主要在采集的端側(cè)和分析側(cè);
采集端側(cè)需要約定采集規(guī)范、協(xié)議,需要適配各種端;
分析測(cè)主要選用一款查詢性能較好的數(shù)據(jù)庫或者數(shù)倉服務(wù),比如pgsql或者clickhouse等(不建議MySQL,百萬的數(shù)據(jù)量的復(fù)雜查詢就很慢了),一般是一些支持列式儲(chǔ)存的數(shù)據(jù)庫,后期數(shù)據(jù)量較大了需要考慮數(shù)據(jù)壓縮等服務(wù)。
整體規(guī)劃需要根據(jù)自身業(yè)務(wù)的量級(jí)和人員配置來規(guī)劃,在沒有相關(guān)經(jīng)驗(yàn)的情況下,建議了解并購買成熟云產(chǎn)品。
整個(gè)技術(shù)周期是需要考慮以下幾個(gè)技術(shù)點(diǎn):