（看了楼下几个答案，发现我漏掉了一个重要的地方，日志是不需要实时发送的。）

1、接收用户的请求。
2、将请求存储到消息队列
3、后台的机器从消息队列消费，存储到数据库。

对用户是否实时上传日志，设定多少时间合适，我的看法是：5-15分钟左右。
要考虑到太长用户退出的情况，比如用户进来3分钟就退出了。那么就在用户退出之前把日志提交到服务端。

上亿用户，假设就500万用户在线吧。5分钟发送一次日志。那么500万用户平均1秒钟发送1.6万次请求。

步骤1，肯定想要做负载均衡。而且这个步骤也很重要，如果挂了，日志完全收集不到了。

1.6万次请求，里面可能包含100万条记录，也有可能包含500万条记录。看记录的数据纬度。

也就是1秒钟对数据库进行100万-1000万次查询插入。这个需要消息队列做缓冲，不然数据库肯定就挂了。

基本架构就这样吧。更多的用户最多就是增加机器而已了。

PS备注一下吧，我公司项目就是这么做的，跟下面一样。

大的原则问题是：

1. 日志并不是一个操作就会上传，客户端是每隔一段时间才会集中上传一次。
2. 负责收集日志的服务器与业务服务器是隔离的

详细单说日志业务的话，反正采用http协议，服务是基于swoole httpserver开发的，整体大概如下图所示：

不知道是不是能够满足楼主提出的问题所需的回答要点。ubuntu下没太好的画图软件，凑合看吧。

机器数量不太会算哈。个人方案，如果用户日志肯定不能实时上传，这样影响用户体验， 在app的某个流程定时上传就好了，后端由http接收，可能需要2N台服务器。收到之后写入Kafka，使用消息队列进行缓冲，不至于一下大量上传将后端打挂。

日志用途：
1.这个消费者数据筛选写入kudu。用于埋点和分析用户行为。
2.一个消费者负责实时统计，然后写入Redis，用于图标展示。
3.一个消费者可以全量存储到Es，用于排查问题，Es的检索效率这一部分相当厉害，Es可以做定期删除，只保留最近一两个月的日志。
4.一个消费者筛选部分重要日志，长期存储可以使用hbase，这样随便存。

这个服务器一定要和业务分开。

大概知道的！

• 存储问题：日志系统存储方式一般是文本不是数据库！

• 请求问题：

  • 发送方：App先本地缓存，定期或不定期或app启动后触发发送日志到服务端
  • 接收方：消息队列

歪个题，

• 一般客户端日志会先本机缓存再发送，这样后端服务的接收压力就小太多了。当然这样后面面试官的问题就被气回去了。。
• 这个量级的写入，Kafka 可能是比传统MQ 更适合应对这个场景
  Kafka、RabbitMQ、RocketMQ消息中间件的对比 —— 消息发送性能 | 阿里中间件团队博客
  按照这个测试环境和结果，假模假样的计算下，C10M(100万QPS)需要6台测试案例中一样配置的机器，在考虑上应对在线用户的峰值，按照我们以前运维tx惯常的做法，6*2=12 台
• 因为这题不考虑经济成本，存储就交给 S3 这类云存储吧，把高并发，高可用，存储性能，安全，备份这些问题都交给钱去解决吧

这个我我们是用一个text文件做保存!