本作是"从一个用户到一百万"系列的第十部分,我们将通过遵循一个从一个用户增长到上百万的简单应用程序来构建对系统设计的理解.
而不是记忆性的技术, 我们会了解它们存在的原因, 通过解决它们看起来真正的问题。
在第九编中,我们解决了数据增长太大而无法建立单一数据库的问题。
我们把它分成多个硬块, 每一个硬块都握住, 这样就不需要任何一台机器来承担一切。
那时,这个建筑可以向几乎每一个方向发展, 我们试图推动它。
流量分布在应用程序服务器之间。
重复的数据库工作被缓存所吸收.
阅读流量被分散在复制品中.
数据本身被分割在了硬块上。
然则.
我们在结束第9部分时注意到了这些解决办法中没有任何一个涉及的问题。
一些用户请求触发了下游的大量工作.
保存订单是一回事。
但保存订单,发送确认邮件,生成发票,更新库存,解除通知,记录分析事件,触发推荐引擎:这是完全不同的对话.
现在,所有这一切发生在用户得到回应之前.
我们留下的问题是:如果他们不必等待这一切呢? —— 第1节:用户现在不需要一切,在我们研究任何解决方案之前,值得问一个简单的问题.
当用户发布命令时,他们需要知道什么才能继续前进?
他们需要知道订单收到 他们需要确认发生的重要事情:他们的钱被接受,他们的物品被保留,交易是真实的.
就是这样。
所等所取为相.
他们不需要等待确认的电子邮件 登陆他们的收件箱。
他们不需要等待发票的生成和存放到某个地方。
他们不需要等待分析系统来记录这次购买的发生.
他们当然不需要等待推荐引擎根据他们刚刚买来的东西更新其模型.
所有这一切都将发生。
应该发生 但是在用户获得确认屏之前,这些都无需发生.
这似乎很明显 当你直接说。
当然,用户不需要等待分析事件.
当然他们不需要在推荐系统重新计算时屏住呼吸.
但大多数应用最初的构建方式,正是如此. - 第2节:同步行事 典型的顺序流是这样的 当一切被连接在一起时 简单而明显的方式 用户点击了按钮并等待了近700毫秒的确认屏幕.
超过半秒, 对于一个反应 他们做了一个瞬间。
这就是假设没有出错 如果电子邮件服务慢了两秒钟而不是200毫秒呢?
用户等二分.
如果分析系统完全崩溃怎么办?
请求失败,用户会得到错误,即使命令本身被完美地保存.
该应用程序将其反应时间和可靠性与它从事的每一下游工作挂钩。
每个慢步都让用户等得更久.
每个失败的步骤都会使整个请求失败.
这不是硬件问题。
这不是一个数据库问题。
这是一个建筑问题。
应用程序正在按顺序进行工作,而大多数工作实际上并不取决于它之前的步骤.
确认邮件在发送前不需要生成发票.
分析事件在被录制之前不需要电子邮件成功.
这些任务都是独立的.
它们只是顺序的,因为这样它们才能被接通 因此,问题变成了:停止按顺序对待它们是什么样子的? -- 第3节:把工作放在一个队列中 我的观点