生活中的程序員思維（二）
在生活中的程序員思維（一）中，講到了並行、併發、防禦式編程等思維，下面繼續講另外三種思維。
同步/異步
公司樓下開了一個飲品店，頗受歡迎。有些公司會大批量購買，作爲員工的下午茶。一開始，顧客需要親自到店、點單、等待飲品做好，最後取走飲品。時間長了，無論是店家還是顧客，都覺得很不方便。對店家來說，突然來了大批訂單，然而店裏人手有限，此時別的顧客就只能長時間等待了，這導致了顧客體驗變差，甚至客源流失。對於顧客來說，需要親自到店，就地等待飲品加工完成，買的越多，等待時間越長，顧客的時間成本變高了。
這家店主頭腦很靈活，很快想到了辦法，在店裏貼出微信二維碼，可以微信下單、送貨上門。這麼一來，有大批量訂單時，店家不必火急火燎地加工，可以優先響應到店的顧客，比以前淡定、從容多了，生意也越來越好。
解讀
同步/異步應站在服務者（場景中的飲品店）的角度看，一開始，飲品店同一時間只能接待一個顧客，無論是大批量購買，或少量購買。在服務好一位顧客前，店家不會服務另一位顧客，這就是同步方式：訂單處理完成前，不返回結果，也不能處理其它訂單。
經過改進，飲品店支持在線下單了。大客戶通過微信下單，店家收到訂單後立即回覆：收到，請耐心等待送貨上門。此時如果有別的顧客進店，店家可以優先接待。對於店家來說，在大客戶的訂單還沒完成前，還可以接待其他顧客，這就是異步方式：接收到請求後，立即返回（微信回覆），通過回調（送貨上門）將結果傳遞給客戶。
常見的第三方支付接口通常都是異步的。支付接口接收的參數中有一個回調地址，支付完成後，將結果通過回調地址通知請求方。除了回調，支付服務通常還會提供查詢接口，請求方可以主動查詢支付結果。
總結
- 同步/異步是站在服務方角度的概念
- 同步：在請求處理完成前不返回結果，請求方通常需要等待
- 異步：接收到請求後立即返回，服務方通過回調將結果傳遞給請求方，或由請求方主動查詢獲取結果
解耦
想象一下你來到一個大型商場，恰逢週末，商場人很多。你走進一家服裝店，打算給即將到來的冬季準備一些衣物，經過挑選、試穿，最終選定了一件黑色羽絨服，在帶走衣服之前，還差最後一步：結賬。導購員指引你去商場專門的收銀臺，發現那裏有不少人在排隊，這讓你有些皺眉頭。大約等了10分鐘，到你了，收銀員笑臉相迎，熟練地開好單據，讓本人簽字。因爲消費額度較高，收銀員提醒你可以領取優惠券或停車券，你選擇了停車券（因爲開車了）。還需要打開手機掃描二維碼，輸入車牌號等，這大概花了3分鐘時間。你好像知道爲什麼有那麼多人在排隊等待了。
上面的場景中，顧客結賬是一個獨立的過程，但在此過程中插入了“送停車券”、”送優惠券“兩個過程。稍微想一下，就會發現存在幾個問題
- 不是每個顧客都開車
- 不是每個顧客都想要優惠券
- 結賬速度變慢了
繼續想象你是這家商場的管理人員，看到結賬的顧客大排長龍，你有些擔心。怎麼才能改善結賬的用戶體驗？你決定這麼做：在收銀臺位置張貼告示：消費滿200送停車券，滿500送優惠券，至1樓服務檯領取；在商場1樓設立服務檯，發放此類優惠券。
解讀
從上面的例子中，我們看到”結賬“過程耦合了”送停車券“、”送優惠券“的過程，這明顯增加了結賬的時間成本、溝通成本。經過改進，將”送停車券“和”送優惠券“獨立出來，不再影響”結賬“，顧客憑”收銀單“按需領取。
耦合這個詞的涵義很廣泛，例如代碼耦合、過程耦合，這裏特指在主要流程中插入了附屬流程，並影響了主流程的行進。場景中的”結賬“是主流程，”送優惠券“、”送停車券“是附屬流程，它們是可有可無的，它們是否存在、結果如何並不影響主流程的完整性。
想象一個業務場景：用戶登錄，考慮到賬戶安全，我們需要記錄用戶的登錄地點，發現異地登錄及時向用戶發送安全提醒。
最簡單粗暴的做法，在登錄完成前根據用戶IP獲取到地點，並做記錄。根據上面的解讀，很明顯用戶登錄是主流程，記錄登錄地點是附屬流程，且附屬流程並不影響主流程的完整性。假定獲取IP所在地的API異常了、或超時了，不應該影響用戶正常登錄。
更合理的做法，在用戶登錄時發送一條消息（對應場景中的收銀單據），消息中包含用戶ID、用戶IP，在另外一個過程中（對應場景中的服務檯）讀取消息、計算IP所在地，並做記錄。
總結
- 耦合是在主流程中插入了附屬流程，且附屬流程影響了主流程的行進
- 附屬流程是否存在、結果如何並不影響主流程的完整性
- 解耦是將附屬流程獨立出去，主流程發佈消息，附屬流程訂閱消息
冷熱分離
想象一下現在正是春夏交替的季節，但天氣有些變換莫測，時冷時熱，棉服、長褲時不時還用得上。對於不拘小節的朋友們來說，衣櫃裏塞滿了各個季節的衣服，顯得很凌亂，找衣服也很花時間。
再過一些日子，就完全進入夏天了，棉服顯然已經派不上用場，有必要對衣櫃做一次“冷熱分離”，把厚衣服打包另存，把夏天的衣服放在衣櫃最顯眼的位置。
解讀
在程序員的世界裏，冷和熱通常用於形容數據，也就是冷數據、熱數據。顧名思義，熱數據就是那些經常被訪問的數據，冷數據正好相反。我們都知道，數據通常存儲於數據庫中，對於一張數據表來說，數據量越大，獲取數據的成本越高。
想象你在管理一個博客系統，數據表中存了數百萬文章，檢索文章列表花費的時間很長。有一點你很清楚，文章列表展示的是最近發佈的、最近評論的或閱讀量較大的文章，統稱爲熱門文章。受到分離冷熱季節衣物的啓發，你決定將熱門文章和冷門文章分開處理，獲取列表時，只檢索熱門文章。經過優化，速度提升明顯。
總結
- 冷熱指冷數據和熱數據
- 熱數據是經常被訪問的數據，冷數據相反
- 冷熱分離是將熱數據獲取和冷數據獲取分開處理
由於作者水平有限，不準確之處在所難免，歡迎批評指正。