我們先來回顧一下之前提到過的知識點，
1.在一台電腦上，使用非同步程式設計可以提高cpu的使用效率
2.使用actor模型，實現同一臺電腦上，在併發環境下的序列操作，保證事務執行的正確
3.在多伺服器環境下，actor模型配合zookeeper，可以實現在多伺服器環境下的序列操作，保證事務執行正確
4.對應用進行讀寫分離的設計，做到「寫服務」（有狀態）執行正確，同時又能方便地（增加伺服器）提高「讀服務」（無狀態）的效能
在這個場景下，步驟3最為耗時，有時需要超過1秒。對於步驟2，我們有很多方法來實現非同步操作，如果不能實現，那網頁伺服器被應用伺服器的響應所阻塞，吞吐量將急劇下降。
今天我們主要討論步驟1，使用者在下單，期望看到下單的結果，這是乙個典型的同步操作，隨著併發量上公升，伺服器的響應時間可能會超過30秒，最終造成瀏覽器的超時，使用者什麼也看不到，這是最壞的結果。我們來把這個同步呼叫，用非同步來模擬，
1.瀏覽器傳送下單請求到網頁伺服器（web server）
2.網頁伺服器傳送請求到應用伺服器
3.a)應用伺服器生成訂單號，把訂單號返回網頁伺服器
b)應用伺服器檢查庫存，鎖定庫存，把訂單狀態改成「下單成功」
4.瀏覽器收到訂單號，採用ajax方式，每隔2秒，請求網頁伺服器，查詢訂單狀態，直到獲得「下單成功」的狀態，跳轉到下單成功頁面
在這個非同步流程中，步驟3.b和步驟4在時間上是並行執行的，但是，還記得我們的「讀寫分離」設計嗎，步驟3訪問的是「寫」服務，步驟4訪問的是「讀」服務，這兩個服務可以獨立優化，不會成為對方的瓶頸。
使用瀏覽器的非同步訪問還帶來額外的好處，在非同步架構下，網頁伺服器和應用伺服器的響應都非常迅速。原先的耗時請求「請幫我下單，並告訴我下單結果」被拆分成不耗時的請求「幫我下單」（一次）和「剛才的下單成功了嗎」（一次或多次）。
如果使用了老式的網頁伺服器，不支援非同步請求應用伺服器，這樣還能一舉解決網頁伺服器訪問應用伺服器阻塞的問題。
在網際網路高併發的狀態改變（寫）操作，把業務流程設計成非同步是上策，比如大眾點評的退款操作，系統會告訴使用者「已收到您的退款請求，會在x個工作日能把錢退到您的賬戶」，這樣的非同步業務流程，對於系統毫無壓力。有時出於使用者體驗不得不採用同步流程，比如上面說的下單流程，如果一開始設計成用非同步流程來模擬，有兩個好處
1.不會因為併發量突然上公升而觸發瀏覽器超時
2.可以對「讀」，「寫」服務獨立優化
另外，在ajax非同步操作時，還可以在瀏覽器繪製動畫來安撫使用者焦躁的情緒，不要說我沒告訴你~
用非同步流程模擬同步流程的補充說明，在瀏覽器內使用ajax輪詢下單結果，是不得以。在伺服器可以主動訪問客戶端的環境下，應該總是優先考慮**的方式。瀏覽器是特殊的環境，伺服器訪問瀏覽器有時有困難，所以才使用比較保險的輪詢模式。
非同步客戶端和同步客戶端
先寫下我的理解，方便後邊閱讀資料校驗。一 同步客戶端 比如乙個連線有兩個請求，請求1 和 請求2，請求1 先發起請求，請求2後發起請求，則請求2 要等待請求1 響應完成才能接收到響應。舉個棗子，httpclient 傳送get請求，執行緒會一致阻塞，直到有響應結果。二 非同步客戶端 比如乙個連線有兩...
客戶端架構介紹
這篇文章寫得比較中坑 記錄下 整個客戶端大體上是分為frame和game兩大部分.frame為框架層,通用於所有專案.game是遊戲層,只能寫當前專案才會用到的 frame 說是通用於所有專案有點誇大了,畢竟遊戲型別太多了,商業遊戲引擎都不敢說通用於所有遊戲,但這確實是這部分設計的初衷.其實這部分就...
遊戲客戶端架構分析
用來進行ui管理 管理攝像機控制視野的移動和是否需要跟隨。當沒有角色時相機處於漫遊狀態，有角色時需要控制相機跟隨角色，由於是網路遊戲，需要通過cameramanager控制相機連線那個角色。負責角色的產生，當進入戰鬥場景時，要將角色生成到場景中。進行管理請求，所有請求繼承自baserequest，r...