最近参加高级php面试，笔记题最后一题必答题老是下面这个日志系统设计问题，有没有高手能够给出完美答案？

Question

APP有上亿用户使用，为了深刻挖掘用户需求，需要设计一个日志收集系统，用于收集用户日常使用情况，请用你知道的知识设计一套这样的日志收集系统。假设，用户每次操作、点击APP都将发起请求。请给出系统架构设计图，数据库存储方式，需要的机器量，以及能承载的QPS，尽可能详细的描述此系统中的难点、解决方案。

Answer 1

歪个题，

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

Answer 2

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

大的原则问题是：

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

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

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

Answer 3

大概知道的！

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

• 请求问题：

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

Answer 4

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

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

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