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

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

回答

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

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

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

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

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

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

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

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

歪个题,

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

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

大的原则问题是:

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

详细单说日志业务的话,反正采用http协议,服务是基于swoole httpserver开发的,整体大概如下图所示:
【php】最近参加高级php面试,笔记题最后一题必答题老是下面这个日志系统设计问题,有没有高手能够给出完美答案?

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

大概知道的!

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

  • 请求问题:

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

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

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

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

以上是 【php】最近参加高级php面试,笔记题最后一题必答题老是下面这个日志系统设计问题,有没有高手能够给出完美答案? 的全部内容, 来源链接: utcz.com/a/98480.html

回到顶部