作者回复: 当然,环节越少越简单,出故障的概率就小,但是还是要看量级,因为体量决定架构。根据具体的体量大小,可以适当简化。 1. 可以通过采集网关(或者反向代理)的访问日志,来实现计数服务。 2. 通常原始访问日志也需要保存起来,中间一般引入kafka消息队列,主要考虑一个是流量消峰,另外一个是前后解耦合。
作者回复: ⛽️
作者回复: ⛽️
作者回复: 本课程主要面向中高级工程师和架构师,受众有一定限制
作者回复: 简单用一个ConcurrentHashMap,key是videoId,value是1分钟内的点击数量累加值。 弄个后台线程每分钟,新建一个ConcurrentHashMap,替换那个老的,然后把老的值打包写入本地MQ。
作者回复: 一般不直接写mq,前面放一个代理服务去写mq,这样客户端不耦合具体的mq技术。 kafka的auth,可以根据需要关闭,即使有auth也没有关系,客户端用官方方法做auth就好了。
作者回复: 可以,甚至还可以通过nginx或者网关的访问日志来收集。课程只是一个演示场景。
作者回复: ⛽️
作者回复: 如果通过内存做聚合并且要保证数据不丢,那么一般必须先写入磁盘文件。相当于在每台counting service的主机上要有磁盘queue(相当于write ahread log),然后在磁盘queue的一端写入数据,另外一端做消费聚合,同时在磁盘上记录queue的消费指针。后面如果计数服务crash了,重启服务后,从上次的消费指针重新消费即可,这样可以保证可靠性(但是可能重复消费)。
作者回复: 加油💪