同步架構與異步架構
背景
把智能系統比喻成KFC營業廳，處理器是窗口和窗口后面的服務員（把一個窗口當作一個核心），指令集是后面排隊的人，窗口是數據吞吐量。 當中午就餐人多的時候，一個窗口肯定忙不過來， 這時候就需要增加窗口
解決方案
1.在窗口后面增加多個服務員，分擔一下工作
2.新增多個窗口
分析
方案一就是異步架構，方案二同步架構
一個窗口是不可能比上多個窗口的工作效率
對比結論
優點：異步架構設計簡單，實現方便。
缺點：性能低，吞吐量差。
總結：如果對處理並發量不高的系統。優先選擇異步架構！！！
異步能夠給架構帶來什么
優化前端，主動把控與用戶的會話，讓用戶體驗更好。
高並發處理，能夠比較簡單實現負載均，案例：12306
提供架構容錯能力。高可用
系統代碼更加安全，不用使用多線程，所以也會碰到線程死鎖等問題，對信息同步也更加方便。
異步--高並發場景
異步編程—給我們帶來什么
async/await
非阻塞I/O可以使CPU與I/O並不依賴，可以更大程度的利用資源
對於網絡應用，並行帶來的優勢更大，利於分布式和雲的應用
異步，自動多線程，主動處理軟件架構問題，如：高並發，高可用。
異步—高可用場景
高可用實現
反向代理/負載均衡，實現網站的高可用
Processor，通過重復Worker實現高可用的架構
微服務-高並發/高可用實現
前端MQ訂閱，后端Processer調用微服務實現
高並發，利用網關，很方便的進行服務分流，eg：Docker
高可用，MQ防止數據丟失，結合線程池/反向代理網關[k8s]插件,實現微服務的高可用
緩存—給我們帶來什么
提高數據使用性能和安全…..
高可用，實現內存數據的高可用，結合nginx等，可以很方便的實現軟件高可用
高並發，Redis數據多節點異地存儲，可以實現多節點分流
微服務-高並發/高可用場景
前端MQ訂閱，后端Processer調用微服務實現
高並發，利用網關，很方便的進行服務分流，eg：Docker
高可用，MQ防止數據丟失，結合線程池/反向代理網關[k8s]插件,實現微服務的高可用
MQ--高可用/高並發
高可用
高可用，服務的持續響應
解耦，MQ的消息生產者和消費者互相不關心對方是否存在
並發，MQ有生產者集群和消費者集群，所以客戶端是億級用戶時，他們都是並行的。從而大大提升響應速度。
削峰，因為MQ能存儲的消息量很大，所以他可以把大量的消息請求先存下了，然后再並發的方式慢慢處理。
CQRS（讀寫分離）—高並發場景
1. 分工明確，可以負責不同的部分
2. 將業務上的命令和查詢的職責分離能夠提高系統的性能、可擴展性和安全性。並且在系統的演化中能夠保持高度的靈活性，能夠防止出現CRUD模式中，對查詢或者修改中的某一方進行改動，導致另一方出現問題的情況。
3. 邏輯清晰，能夠看到系統中的那些行為或者操作導致了系統的狀態變化。
4. 可以從數據驅動(Data-Driven) 轉到任務驅動(Task-Driven)以及事件驅動(Event-Driven) 】
Kafka—阿里雲PAAS產品
消息隊列Kafka版是阿里雲提供的分布式、高吞吐、可擴展的消息隊列服務。消息隊列Kafka版廣泛用於日志收集、監控數據聚合、流式數據處理、在線和離線分析等大數據領域，已成為大數據生態中不可或缺的部分。 https://help.aliyun.com/document_detail/68151.html?spm=5176.167616.1288903.btn3.537a5a1cQ3KmhQ
高容量存儲：能在商業硬件上存儲高容量的數據，實現可橫向擴展的分布式系統。
一對多消費模型：“發布/訂閱”模型，支持同份數據集能同時被消費多次。
同時支持實時和批處理：支持本地數據持久化和Page Cache，在無性能損耗的情況下能同時傳送消息到實時和批處理的消費者
數據庫—高可用/並發
數據庫：數據持續化，把內存數據保存為文件【系列化持久化】 保存數據，保障數據安全，傳輸
高並發給它帶來那些調整：資源【磁盤/cpu/內存】，I/O Buffer 解決方案：讀寫分離【發布訂閱】分庫分表【入門級】，
高可用給它帶來什么問題：數據庫宕機危機 解決方案：主從熱備，定時BackUp【入門們】 周全量備份，周一對數據庫做一個全面備份，存儲到其他OSS 日增量備份，每天相對於前天，對比數據做一個增量備份。存儲到其他OSS
異步架構常見的坑
1.復雜度變高，程序之間來回回調，工程師剛入手時，調試或解決問題很不方便 比較合適的方法，多用中間件，Redis/MQ/Kafla/DB，少用多線程/程序回調
2.時間成本 對實時性比較強的程序，有很大時間消耗。不建議使用異步編程
3.比較推薦：缺點，異步的代碼同步化，可能會導致性能上的問題(降低性能)
