有趣的問題。
我們用HTTP做下單的請求舉例子。一個下單請求完整包括：
前4個構成了一個完整網路連線。你的瀏覽器和某臺伺服器連起來了。但是那個直接連線的伺服器很可能就是個反向代理/負載均衡器。代理/均衡器後邊才是真正得伺服器，他會把請求傳送給某個後臺“真·伺服器"。
而伺服器第一件事，就要做認證，就是把你的請求中的token/session id翻出來，並去資料庫裡查一下你是誰，然後拿到你的賬戶，做一些交易檢查，比如
如果一切滿足，就給你在資料庫裡建立一條交易記錄（順便扣庫存），然後返回給你“麼麼噠，等著快遞小哥“。
這裡，資料庫可能你和別人使用的是同一臺DB，也可能是不同的。這要看系統設計裡怎麼做的“分片”。比如，你可以規定所有人都用一臺資料庫伺服器；也可能說，因為壓力太大了，所以我要準備10臺數據庫伺服器。使用者ID尾號為0的放在第一臺機器上，為1的放在第二臺機器上……
但無論怎麼區分，你會發現，
但你說，不同請求使用同一根光纜發的啦。資料都混一起了。但是整個網路協議，應用協議決定了，混在一起的資料還能很乾淨的拆開。這就好像，你坐火車去上海，出火車時，你還是你，你的腦袋不會因為你們曾經坐一起就接在別人身子上。
但是，特別要注意，如果你和別人訪問的是同一個資源，你們的確會相互影響。比如一個可以共同編輯的文件系統。你和你的同事可以同時編寫同一份文件。這個場景下，系統要做的事情是讓這個相互影響是確定性的，並且儘量符合直覺。比如，系統可以說“你的朋友小明在編輯，你不可以，要等他編輯完“；也可以說，”你的朋友小明在編輯這個段落/行，你能編輯其他地方，但不能和小明編輯同一個地方“。做的越好系統，越能讓你覺得舒服自然。
有趣的問題。
我們用HTTP做下單的請求舉例子。一個下單請求完整包括：
請求伺服器的URL——就是你說的網址。網址會透過DNS解析到伺服器IP。有可能同一個URL會總解析到同一個IP；但如果開啟了DNS load balancer，就可能解析到不同IP請求伺服器的埠——但一般公開用的伺服器埠就是80（http）或者443（https）。我們可以假設沒有這個條目客戶端的IP——當你上網時一般會透過DHCP自動分配一個客戶端的埠——會自動隨機生成一個。請求Method——GET POST PUT等。這裡說下單，那麼基本上必然是POST請求Header/Cookie —— 其中最關鍵的就是認證的token或者session id，那個讓伺服器能認出你就是你的東西請求體 —— 包括這次請求的資訊，比如買的什麼，多少錢，用了什麼券，交易密碼是啥，下單流水號是什麼等等。前4個構成了一個完整網路連線。你的瀏覽器和某臺伺服器連起來了。但是那個直接連線的伺服器很可能就是個反向代理/負載均衡器。代理/均衡器後邊才是真正得伺服器，他會把請求傳送給某個後臺“真·伺服器"。
而伺服器第一件事，就要做認證，就是把你的請求中的token/session id翻出來，並去資料庫裡查一下你是誰，然後拿到你的賬戶，做一些交易檢查，比如
你能不能買這個東西你使用的優惠券真的屬於你嗎你的交易密碼對嗎……如果一切滿足，就給你在資料庫裡建立一條交易記錄（順便扣庫存），然後返回給你“麼麼噠，等著快遞小哥“。
這裡，資料庫可能你和別人使用的是同一臺DB，也可能是不同的。這要看系統設計裡怎麼做的“分片”。比如，你可以規定所有人都用一臺資料庫伺服器；也可能說，因為壓力太大了，所以我要準備10臺數據庫伺服器。使用者ID尾號為0的放在第一臺機器上，為1的放在第二臺機器上……
但無論怎麼區分，你會發現，
在網路層面，你和其他人是相互不影響的，因為使用的不同的連線在應用層面，你和其他人是相互不影響的，因為你們的認證資訊不一樣。後臺伺服器要保證，你的資訊不會寫在別人名下，反之亦然但你說，不同請求使用同一根光纜發的啦。資料都混一起了。但是整個網路協議，應用協議決定了，混在一起的資料還能很乾淨的拆開。這就好像，你坐火車去上海，出火車時，你還是你，你的腦袋不會因為你們曾經坐一起就接在別人身子上。
但是，特別要注意，如果你和別人訪問的是同一個資源，你們的確會相互影響。比如一個可以共同編輯的文件系統。你和你的同事可以同時編寫同一份文件。這個場景下，系統要做的事情是讓這個相互影響是確定性的，並且儘量符合直覺。比如，系統可以說“你的朋友小明在編輯，你不可以，要等他編輯完“；也可以說，”你的朋友小明在編輯這個段落/行，你能編輯其他地方，但不能和小明編輯同一個地方“。做的越好系統，越能讓你覺得舒服自然。