PS備注一下吧，我公司項目就是這么做的，跟下面一樣。

大的原則問題是：

1. 日志并不是一個操作就會上傳，客戶端是每隔一段時間才會集中上傳一次。
2. 負(fù)責(zé)收集日志的服務(wù)器與業(yè)務(wù)服務(wù)器是隔離的

詳細(xì)單說日志業(yè)務(wù)的話，反正采用http協(xié)議，服務(wù)是基于swoole httpserver開發(fā)的，整體大概如下圖所示：

不知道是不是能夠滿足樓主提出的問題所需的回答要點。ubuntu下沒太好的畫圖軟件，湊合看吧。

大概知道的！

• 存儲問題：日志系統(tǒng)存儲方式一般是文本不是數(shù)據(jù)庫！

• 請求問題：

  • 發(fā)送方：App先本地緩存，定期或不定期或app啟動后觸發(fā)發(fā)送日志到服務(wù)端
  • 接收方：消息隊列

機器數(shù)量不太會算哈。個人方案，如果用戶日志肯定不能實時上傳，這樣影響用戶體驗， 在app的某個流程定時上傳就好了，后端由http接收，可能需要2N臺服務(wù)器。收到之后寫入Kafka，使用消息隊列進(jìn)行緩沖，不至于一下大量上傳將后端打掛。

日志用途：
1.這個消費者數(shù)據(jù)篩選寫入kudu。用于埋點和分析用戶行為。
2.一個消費者負(fù)責(zé)實時統(tǒng)計，然后寫入Redis，用于圖標(biāo)展示。
3.一個消費者可以全量存儲到Es，用于排查問題，Es的檢索效率這一部分相當(dāng)厲害，Es可以做定期刪除，只保留最近一兩個月的日志。
4.一個消費者篩選部分重要日志，長期存儲可以使用hbase，這樣隨便存。

這個服務(wù)器一定要和業(yè)務(wù)分開。

歪個題，

• 一般客戶端日志會先本機緩存再發(fā)送，這樣后端服務(wù)的接收壓力就小太多了。當(dāng)然這樣后面面試官的問題就被氣回去了。。
• 這個量級的寫入，Kafka 可能是比傳統(tǒng)MQ 更適合應(yīng)對這個場景
  Kafka、RabbitMQ、RocketMQ消息中間件的對比 —— 消息發(fā)送性能 | 阿里中間件團(tuán)隊博客
  按照這個測試環(huán)境和結(jié)果，假模假樣的計算下，C10M(100萬QPS)需要6臺測試案例中一樣配置的機器，在考慮上應(yīng)對在線用戶的峰值，按照我們以前運維tx慣常的做法，6*2=12 臺
• 因為這題不考慮經(jīng)濟(jì)成本，存儲就交給 S3 這類云存儲吧，把高并發(fā)，高可用，存儲性能，安全，備份這些問題都交給錢去解決吧

（看了樓下幾個答案，發(fā)現(xiàn)我漏掉了一個重要的地方，日志是不需要實時發(fā)送的。）

1、接收用戶的請求。
2、將請求存儲到消息隊列
3、后臺的機器從消息隊列消費，存儲到數(shù)據(jù)庫。

對用戶是否實時上傳日志，設(shè)定多少時間合適，我的看法是：5-15分鐘左右。
要考慮到太長用戶退出的情況，比如用戶進(jìn)來3分鐘就退出了。那么就在用戶退出之前把日志提交到服務(wù)端。

上億用戶，假設(shè)就500萬用戶在線吧。5分鐘發(fā)送一次日志。那么500萬用戶平均1秒鐘發(fā)送1.6萬次請求。

步驟1，肯定想要做負(fù)載均衡。而且這個步驟也很重要，如果掛了，日志完全收集不到了。

1.6萬次請求，里面可能包含100萬條記錄，也有可能包含500萬條記錄?？从涗浀臄?shù)據(jù)緯度。

也就是1秒鐘對數(shù)據(jù)庫進(jìn)行100萬-1000萬次查詢插入。這個需要消息隊列做緩沖，不然數(shù)據(jù)庫肯定就掛了。

基本架構(gòu)就這樣吧。更多的用戶最多就是增加機器而已了。