流量暴涨十倍后的遇到了哪些问题

广告引擎工程的挑战

广告引擎工程的目标
1、快速接入不同流量场景
2、快速实验
3、稳定性要求高
4、性能要好
5、可观测、可解释，完善的日志系统
7、降级、容灾

流量暴涨了十倍后遇到了哪些问题？

延迟上报的问题

这个问题要挖掘MQ，引导面试官去聊MQ，曝光rabbitMq, kafka和rocketMq的选型等方面。有没有什么办法让mq更快。
1、普通的日志上报
普通日志重要性不高，少量丢失对问题影响不大。
2、曝光/点击日志上报
这个涉及到结算/钱，日志是不能丢的，因此MQ选型时除了考虑吞吐量，还要保证日志不丢。RabbitMq吞吐偏小，不适合这种吞吐量大的场景。
Kafka和RocketMq的吞吐都能到10万+，满足吞吐的要求。RocketMq在保证消息不丢的表现更好，因为他单个broker的多个queue实现的日志是一起写的在同一个commitLog里，使用的是追加写，写的性能非常块。
Kafka保证消息不丢是通过partition同步到slave partition实现的，即使配置等到slave partition写完后返回ACK，由于slave不是真正意义上的写磁盘，而是写page cache，page cache异步刷磁盘的，因此得到ACK并不表示真的不丢。如果配置fsync=true强制page cache每次刷盘，Kafka的吞吐会严重下降。这是因为Kafka的每个broker有多个partition，每个partition对应一个独立的segment log文件，这个虽然每个segment是顺序写，但是多个segment分别顺序写是多不到的，会反复寻址，就退化随机写了。那为什么Kafka不像rocketMq一样同一个broker上的多个queue公用一个log文件呢？
Kafka一个partition对应一个segment带来的如下几个好处：
1、简单的offset维护策略
2、为某个partition维护独立的文件策略也简单，比如压缩、删除等。
3、Kafka是一个partition对应一个消费者，一个broker上不同的partition被不同的consumer消费时，由于segment不同有可能会存在随机读，但是他通过pagecache机制和批量拉取机制大大缓解了这个问题。如果消费明显之后，确实会存在随机读。
RocketMQ一个broker不同topic共享一个commitLog就没有随机读的问题吗？
由于共享一个commitLog，rocketMq的offset维护就比Kafka复杂不少。RocketMq维护了一个consueQueue来存储同一个queue的偏移量，一个broker上有N个queue就会维护N个consumeQueue。consumeQueue通过mmap映射到内存用于读取消息的偏移量，然后去pagecache里读取消息。这样就避免了随机读的问题。

广告超投的问题

1、曝光表积压，导致GD广告数据回流延迟严重，疯狂超投。
2、数据分钟级别延迟，导致最后账户没钱了还在投，店铺小的话量不大，如果是连锁店，量很大，一天下来资损积累不少。

HA3数据延迟

HA3数据延迟带来的问题是计划、店铺状态、预算等决定广告是否能被曝光关键信息的不能及时同步。新增的广告无法及时被召回等问题。

比如店铺已经下线、账户已经没预算，引擎还在召回、曝光。在结算的时候扣费失败。今儿导致平台损失。