Bill2020-09-05可以更简单一些，流量直接打到网关上记录日志，然后起个普通的统计聚合服务，面向写的场景写入DB就了。 简化掉中间很多环节，可用性提升。作者回复: 当然，环节越少越简单，出故障的概率就小，但是还是要看量级，因为体量决定架构。根据具体的体量大小，可以适当简化。 1. 可以通过采集网关(或者反向代理)的访问日志，来实现计数服务。 2. 通常原始访问日志也需要保存起来，中间一般引入kafka消息队列，主要考虑一个是流量消峰，另外一个是前后解耦合。
3
jhren2020-06-17感谢杨老师核心名词都提供了英文翻译作者回复: ⛽️
3
静水流深2020-06-16这节课，让我感受到了，知识储备的重要性！！需要不断地去深入学习。作者回复: ⛽️
3
杰2020-10-12波波老师讲的很精彩，可惜报名的人数那么少，可能大部分学员看到标题就没太大兴趣了。作者回复: 本课程主要面向中高级工程师和架构师，受众有一定限制
2
G小调2020-06-24有个疑问，计算服务，怎么计算一个窗口期时间内的请求聚合，再推送到数据库存储作者回复: 简单用一个ConcurrentHashMap，key是videoId，value是1分钟内的点击数量累加值。 弄个后台线程每分钟，新建一个ConcurrentHashMap，替换那个老的，然后把老的值打包写入本地MQ。
2
何凌2020-06-20有没有可能直接写MQ？Kafka会有auth的问题，如果是带auth的MQ呢？作者回复: 一般不直接写mq，前面放一个代理服务去写mq，这样客户端不耦合具体的mq技术。 kafka的auth，可以根据需要关闭，即使有auth也没有关系，客户端用官方方法做auth就好了。
2
不忘初心2020-06-19观看事件的产生，老说讲的是浏览器主动发送，是否可以在api网关里用过滤器来产生观看事件？作者回复: 可以，甚至还可以通过nginx或者网关的访问日志来收集。课程只是一个演示场景。
1
tt2020-06-18看得真过瘾作者回复: ⛽️
1- Sky2021-04-25计数服务如果是一个窗口期时间内的请求聚合，再推送到数据库存储， 在还没推送前，计数服务器crash，那存储与concurren hashmap中的计数就丢失了。如果为了放丢失，写入硬盘又慢，这个有什么好的办法解决？
作者回复: 如果通过内存做聚合并且要保证数据不丢，那么一般必须先写入磁盘文件。相当于在每台counting service的主机上要有磁盘queue(相当于write ahread log)，然后在磁盘queue的一端写入数据，另外一端做消费聚合，同时在磁盘上记录queue的消费指针。后面如果计数服务crash了，重启服务后，从上次的消费指针重新消费即可，这样可以保证可靠性(但是可能重复消费)。
瞌睡的李先生2021-04-23作为一个0年经验的实习生，感觉波波老师讲的东西为我打开了一扇新世界的大门作者回复: 加油💪