mirror of
https://github.com/Vonng/ddia.git
synced 2025-09-26 23:09:18 +08:00
Compare commits
4 Commits
f570557601
...
4458823111
Author | SHA1 | Date | |
---|---|---|---|
![]() |
4458823111 | ||
![]() |
f972004e0f | ||
![]() |
f27a987508 | ||
![]() |
3a54466182 |
@ -13,8 +13,7 @@ breadcrumbs: false
|
||||
|
||||
如果你正在構建一個應用程式,你將會被一系列需求所驅動。在你的需求列表中,最重要的可能是應用程式必須提供的功能:需要哪些介面和按鈕,以及每個操作應該做什麼,以實現軟體的目的。這些是你的 ***功能性需求***。
|
||||
|
||||
此外,你可能還有一些 ***非功能性需求***:例如,應用程式應該快速、可靠、安全、合規,並且易於維護。
|
||||
這些需求可能沒有明確寫下來,因為它們看起來有些顯而易見,但它們與應用程式的功能同樣重要:一個慢得讓人無法忍受或不可靠的應用程式還不如不存在。
|
||||
此外,你可能還有一些 ***非功能性需求***:例如,應用程式應該快速、可靠、安全、合規,並且易於維護。這些需求可能沒有明確寫下來,因為它們看起來有些顯而易見,但它們與應用程式的功能同樣重要:一個慢得讓人無法忍受或不可靠的應用程式還不如不存在。
|
||||
|
||||
許多非功能性需求,比如安全性,超出了本書的範圍。但我們將考慮一些非功能性需求,本章將幫助你為自己的系統闡明它們:
|
||||
|
||||
@ -30,7 +29,7 @@ breadcrumbs: false
|
||||
|
||||
想象一下,你被賦予了實現一個類似 X(前身為 Twitter)風格的社交網路的任務,使用者可以釋出訊息並關注其他使用者。這將是對這種服務實際工作方式的巨大簡化 [^1] [^2] [^3],但它將有助於說明大規模系統中出現的一些問題。
|
||||
|
||||
假設使用者每天釋出 5 億條帖子,或平均每秒 5,700 條帖子。偶爾,速率可能飆升至每秒 150,000 條帖子 [^4]。我們還假設平均每個使用者關注 200 人並有 200 個粉絲(儘管範圍非常廣泛:大多數人只有少數粉絲,而少數名人如巴拉克・奧巴馬有超過 1 億粉絲)。
|
||||
假設使用者每天釋出 5 億條帖子,或平均每秒 5,700 條帖子。偶爾,速率可能飆升至每秒 150,000 條帖子 [^4]。我們還假設平均每個使用者關注 200 人並有 200 個粉絲(儘管實際的範圍要大得多:大多數人只有少數粉絲,而少數名人如巴拉克・奧巴馬有超過 1 億粉絲)。
|
||||
|
||||
### 表示使用者、帖子與關注關係 {#id20}
|
||||
|
||||
|
@ -171,8 +171,8 @@ breadcrumbs: false
|
||||
在驾驶汽车时,由于交通拥堵,道路交通网络的通行时间往往不尽相同。同样,计算机网络上数据包延迟的可变性通常是由于排队【25】:
|
||||
|
||||
* 如果多个不同的节点同时尝试将数据包发送到同一目的地,则网络交换机必须将它们排队并将它们逐个送入目标网络链路(如 [图 8-2](/v1/ddia_0802.png) 所示)。在繁忙的网络链路上,数据包可能需要等待一段时间才能获得一个插槽(这称为网络拥塞)。如果传入的数据太多,交换机队列填满,数据包将被丢弃,因此需要重新发送数据包 - 即使网络运行良好。
|
||||
* 当数据包到达目标机器时,如果所有 CPU 内核当前都处于繁忙状态,则来自网络的传入请求将被操作系统排队,直到应用程序准备好处理它为止。根据机器上的负载,这可能需要一段任意的时间。
|
||||
* 在虚拟化环境中,正在运行的操作系统经常暂停几十毫秒,因为另一个虚拟机正在使用 CPU 内核。在这段时间内,虚拟机不能从网络中消耗任何数据,所以传入的数据被虚拟机监视器 【26】排队(缓冲),进一步增加了网络延迟的可变性。
|
||||
* 当数据包到达目标机器时,如果所有 CPU 核心当前都处于繁忙状态,则来自网络的传入请求将被操作系统排队,直到应用程序准备好处理它为止。根据机器上的负载,这可能需要一段任意的时间。
|
||||
* 在虚拟化环境中,正在运行的操作系统经常暂停几十毫秒,因为另一个虚拟机正在使用 CPU 核心。在这段时间内,虚拟机不能从网络中消耗任何数据,所以传入的数据被虚拟机监视器 【26】排队(缓冲),进一步增加了网络延迟的可变性。
|
||||
* TCP 执行 **流量控制**(flow control,也称为 **拥塞避免**,即 congestion avoidance,或 **背压**,即 backpressure),其中节点会限制自己的发送速率以避免网络链路或接收节点过载【27】。这意味着甚至在数据进入网络之前,在发送者处就需要进行额外的排队。
|
||||
|
||||

|
||||
@ -234,7 +234,7 @@ breadcrumbs: false
|
||||
>
|
||||
> 相比之下,互联网动态分享网络带宽。发送者互相推挤和争夺,以让他们的数据包尽可能快地通过网络,并且网络交换机决定从一个时刻到另一个时刻发送哪个分组(即,带宽分配)。这种方法有排队的缺点,但其优点是它最大限度地利用了线路。线路固定成本,所以如果你更好地利用它,你通过线路发送的每个字节都会更便宜。
|
||||
>
|
||||
> CPU 也会出现类似的情况:如果你在多个线程间动态共享每个 CPU 内核,则一个线程有时必须在操作系统的运行队列里等待,而另一个线程正在运行,这样每个线程都有可能被暂停一个不定的时间长度。但是,与为每个线程分配静态数量的 CPU 周期相比,这会更好地利用硬件(请参阅 “[响应时间保证](#响应时间保证)”)。更好的硬件利用率也是使用虚拟机的重要动机。
|
||||
> CPU 也会出现类似的情况:如果你在多个线程间动态共享每个 CPU 核心,则一个线程有时必须在操作系统的运行队列里等待,而另一个线程正在运行,这样每个线程都有可能被暂停一个不定的时间长度。但是,与为每个线程分配静态数量的 CPU 周期相比,这会更好地利用硬件(请参阅 “[响应时间保证](#响应时间保证)”)。更好的硬件利用率也是使用虚拟机的重要动机。
|
||||
>
|
||||
> 如果资源是静态分区的(例如,专用硬件和专用带宽分配),则在某些环境中可以实现 **延迟保证**。但是,这是以降低利用率为代价的 —— 换句话说,它是更昂贵的。另一方面,动态资源分配的多租户提供了更好的利用率,所以它更便宜,但它具有可变延迟的缺点。
|
||||
>
|
||||
|
@ -801,7 +801,7 @@ WHERE room_id = 123 AND
|
||||
|
||||
當事務寫入資料庫時,它必須在索引中查詢最近曾讀取受影響資料的其他事務。這個過程類似於在受影響的鍵範圍上獲取寫鎖,但鎖並不會阻塞事務直到其他讀事務完成,而是像警戒線一樣只是簡單通知其他事務:你們讀過的資料可能不是最新的啦。
|
||||
|
||||
在 [圖 7-11](/v1/ddia_0711.png) 中,事務 43 通知事務 42 其先前讀已過時,反之亦然。事務 42 首先提交併成功,儘管事務 43 的寫影響了 42 ,但因為事務 43 尚未提交,所以寫入尚未生效。然而當事務 43 想要提交時,來自事務 42 的衝突寫入已經被提交,所以事務 43 必須中止。
|
||||
在 [圖 7-11](/v1/ddia_0711.png) 中,事務 42 通知事務 43 其先前讀已過時,反之亦然。事務 42 首先提交併成功,儘管事務 43 的寫影響了 42 ,但因為事務 43 尚未提交,所以寫入尚未生效。然而當事務 43 想要提交時,來自事務 42 的衝突寫入已經被提交,所以事務 43 必須中止。
|
||||
|
||||
#### 可序列化快照隔離的效能
|
||||
|
||||
|
@ -13,8 +13,7 @@ breadcrumbs: false
|
||||
|
||||
如果你正在构建一个应用程序,你将会被一系列需求所驱动。在你的需求列表中,最重要的可能是应用程序必须提供的功能:需要哪些界面和按钮,以及每个操作应该做什么,以实现软件的目的。这些是你的 ***功能性需求***。
|
||||
|
||||
此外,你可能还有一些 ***非功能性需求***:例如,应用程序应该快速、可靠、安全、合规,并且易于维护。
|
||||
这些需求可能没有明确写下来,因为它们看起来有些显而易见,但它们与应用程序的功能同样重要:一个慢得让人无法忍受或不可靠的应用程序还不如不存在。
|
||||
此外,你可能还有一些 ***非功能性需求***:例如,应用程序应该快速、可靠、安全、合规,并且易于维护。这些需求可能没有明确写下来,因为它们看起来有些显而易见,但它们与应用程序的功能同样重要:一个慢得让人无法忍受或不可靠的应用程序还不如不存在。
|
||||
|
||||
许多非功能性需求,比如安全性,超出了本书的范围。但我们将考虑一些非功能性需求,本章将帮助你为自己的系统阐明它们:
|
||||
|
||||
@ -30,7 +29,7 @@ breadcrumbs: false
|
||||
|
||||
想象一下,你被赋予了实现一个类似 X(前身为 Twitter)风格的社交网络的任务,用户可以发布消息并关注其他用户。这将是对这种服务实际工作方式的巨大简化 [^1] [^2] [^3],但它将有助于说明大规模系统中出现的一些问题。
|
||||
|
||||
假设用户每天发布 5 亿条帖子,或平均每秒 5,700 条帖子。偶尔,速率可能飙升至每秒 150,000 条帖子 [^4]。我们还假设平均每个用户关注 200 人并有 200 个粉丝(尽管范围非常广泛:大多数人只有少数粉丝,而少数名人如巴拉克・奥巴马有超过 1 亿粉丝)。
|
||||
假设用户每天发布 5 亿条帖子,或平均每秒 5,700 条帖子。偶尔,速率可能飙升至每秒 150,000 条帖子 [^4]。我们还假设平均每个用户关注 200 人并有 200 个粉丝(尽管实际的范围要大得多:大多数人只有少数粉丝,而少数名人如巴拉克・奥巴马有超过 1 亿粉丝)。
|
||||
|
||||
### 表示用户、帖子与关注关系 {#id20}
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user