印象/点击次数计算重负荷的设计

Question

我们有一个联盟系统，每天计算数百万张横幅展示次数/点击次数 目前，它会在每次请求时实时写入每次Impression / Click的SQL。

Web应用程序提供这些请求。

我们面临两个问题：

1. 如果我们每秒有很多并发请求，那么SQL就是 开始非常努力地插入Impressons / Clicks数据和 结果导致问题＃2。

2. 如果SQL此刻速度较慢，则会累积请求 正在Web服务器上的队列中等待。结果我们有一个 Web应用程序的速度缓慢，请求未被处理。

我们想到的高级设计：

  

我们现在正在考虑通过从Web应用程序中取出对SQL逻辑的写入来改变设计（将其写入某些本地存储）并创建一个独立的服务，该服务将从本地存储读取并最终写入聚合的Impressions /在后台单击数据（不是实时）到SQL。

我们的约束：

• 10台网络服务器（负载均衡）
• 1 SQL server

您对建议的设计有何看法？
您是否会将NoSQL用作每个Web服务器的本地存储？ 建议您的替代方案。

Answer 1

您的问题似乎是您的前端代码在等待后端代码更新数据库时同步阻塞。

去耦前端和后端，例如通过在前端可以以低延迟和高吞吐量写入队列的位置之间放置一个队列。然后，后端可以花时间将排队的数据处理到目的地。

可能需要或可能不需要使队列可重新启动（即在崩溃后不丢失数据）。根据这一点，您有多种选择：

• 内存中队列，快速但不防止崩溃。

• 数据库队列，将原始请求数据写入简单数据结构比将最终数据写入目标数据结构更快是有意义的。

• 重新排队队列，以应对崩溃。

Answer 2

我和Bernd在一起，但我不确定是否专门使用队列。

您需要的只是异步的东西，您可以调用;这样记录印象的行为几乎是多余的。