現在流行混合云架構，先上圖
可能大家看著有點類似12306的
從這個架構圖里 ，我們可以把問題 分成 2 個問題來看 ： 1 海量請求的分流 ，2 數據的一致性 和 同步。
樂觀松耦合可能需要換一種售票和購票觀念。所謂新的售票觀念和購票觀念，比如預約，預約的方式。BookaTicket。
樂觀就是類似樂觀鎖定的那種方式，比如在12306這個場景上，樂觀可以是預定，BookaTicket。
我們現在是買票，買票就是看有沒有符合要求的票，有就買，如果有人比你先搶到，那你就后一個買，如果被搶完了，那你就買不到，只能再等。
這種“搶”的方式會造成大量的訪問在同一時間擁擠向服務器。
如果是預定的方式，你可以在任何時候做一個預定，系統可以隨時受理你的預定，系統受理預定，并不表示現在就購票成功，也不表示未來一定有票，但是系統會在一定的時間結算某一批預定，然后根據票況給予預定的結果。
如果符合你的要求有票，那么系統會回復消息給你“您預定的票已可購買，在1個小時內回復xxx確定購買”。
那么，你在1個小時內回復xxx的話（當然包括了支付錢），那么就購買成功了。
如果沒有符合要求的票，或者符合要求的票已經用完了（安排給在你之前預定的人們了），那么系統會回復你“沒有符合您的要求的票”或者“符合要求的票已預定完，請再次預定”。
你可以再次預定，然后等待系統通知，如此循環。
如果從架構的角度來解釋預定這種業務，可以這樣解釋，傳統的購買相當于同步，預定相當于異步，預定（異步）可以解決同一時間大量請求擁擠向服務器的問題。
同時可以解決數據一致性和同步的問題。
異步可以在一定的時間進行一次“結算”，就不需要像同步方式那樣為了數據一致性和數據同步而需要極致的服務器資源和網絡資源。
你把需求提給服務器，服務器不是即時（同步）答復，而是，“先考慮一下”，把很多用戶的需求都匯集一下，再統一答復一次。
消息隊列是“架構”里異步的代表，但在這里說的解決方案中，具體的技術可以是各種各樣。
輪詢redis，甚至輪詢數據庫也是可以的么。^^
事實上，用戶的需求會先持久化，所以，可能會輪詢數據庫。
因為是異步樂觀松耦合的架構，所以，輪詢數據庫也是很輕松的，不會給系統造成負擔。
我們再看上面的那個架構圖，圖的下方列出了余票查詢集群、用戶登錄集群、訂單分級查詢、票價計算集群、實名制身份確認集群5項。
我們可以看到圖的中央，紅色粗的箭頭“海量購票請求”，這個就是來自于全國的用戶的購票請求。這個請求是指向“鐵路總公司數據中心”。
中央還有一個藍色的比較細的箭頭，是“余票查詢請求分流”，指向阿里云公有云數據中心，也就是說，阿里云公有云數據中心可以來分擔“余票查詢”業務。
而左側有一個“主數據庫”，主數據庫的數據來自于18個路局的數據匯總，主數據庫同時向鐵路總公司數據中心和阿里云數據中心（負責余票查詢分流）提供數據（同步數據）。
從這個圖的架構中我們可以看到，核心交易是發生在“鐵路總公司數據中心”，就是說，這是一個實時的，中心化的數據庫支持的業務系統。
同時也可以判定，余票查詢不是實時的，是一個參考性的資料。具體能不能買這個票，在真正買票（在鐵路總公司數據中心中發生交易）時才能知道結果。而“鐵路總公司數據中心”這個中心數據庫，它的承載能力來自于一個分布式數據庫Gemfire。
