寫在前面的話：時間：2021.12.23 地點：陜西西安（居家辦公） 人物：冷妝,剛入行的java小菜雞事件起因:在哪吒社區得到《億級流量java高并發與網路編程實戰》 事件經過:西安因為疫情居家辦公，而我的電腦落在辦公區域,大型社4現場 |
續前文：高并發之概述
系統分析原則
在開發大型系統時，除了根據業務需求實作相應的模塊外，大型系統在設計時需要重點考慮的一些原則和設計要點來切實的掌控系統開發的思考
由高并發原則（高并發使用不當）->容錯原則->(實作高并發解決方案)CAP原則->冪等性原則->可擴展原則->可維護性原則->可監控原則???
高并發原則
為了保證專案在高并發環境下的正常運行，可以通過垂直擴展和水平擴展來實作
垂直擴展:通過軟體技識訓者升級硬體來提高單機的效率(吶呢，愚公移山嗎?)
水平擴展:通過增加服務器的節點個數來橫向擴展系統的性能（有點集群的意思）
最終的結果很明顯:分布式架構現成為了主流，高并發的最終解決方案認可了水平擴展
即使單機的性能是有限的，但不可否認的是垂直擴展更方便，更快，所以就可以根據實際專案酌情
考慮
容錯原則
未雨綢繆始終是正確的決定，高并發使用不當，防患于未然，系統具有一定的容錯性是必然的
通用場景用例子來說明：
SpringBoot+Redis實作分布式快取，使用MQ實作分布式場景下的事務一致性
使用MQ，PRG模式，Token令牌機制，資料庫唯一約束等解決重復提交問題
使用"去重表"實作操作的冪等性
使用集群或者zookeeper解決失敗遷移的問題
分布式系統中，網路延遲問題不可避免,那該采取什么策略來解決呢
通過session有效時長進行判斷(面試好像有遇到過這個問題)
心跳檢測機制判斷(感覺有點像JVM中判斷垃圾的可達化分析)：客戶每隔60s向服務器發送一次心跳，如果服務器能夠接收到就說明客戶端的狀態是正常的；如果服務器沒有收到，就再等待客戶端的下一次60s發來的心跳,如果連續N次都沒接收到某個客戶的心跳，就可以認定此客戶端已經斷線
預先隔離手段
像秒殺可預知時間的流量暴增情況，提前將秒殺服務器隔離成單獨的服務(對于這個隔離，筆者有心理恐懼，街上的救護車一直在響)，流量不大可以使用多級快取來解決
這里去查了一下PRG模式，Post/Redirect/Get 防止重復提交
CAP原則（這個還是比較熟悉的）
分布式系統中，多個節點資料同步以及該如何考慮呢？
C：Consistency一致性--》在同一時刻，所以節點的資料是相同的
A：Availability可用性--》在合理的時間范圍內，系統能提供正常的服務
P：Partition tolerance磁區容錯性--》當分布式系統中部分節點故障時，系統能正常運行
CAP原則：在任何一個分布式系統中，CAP三者不可兼得，最多同時滿足兩個，因為網路問題，所以以P為基礎選擇，然后對C,A根據實際業務來選擇
冪等性原則
提及冪等原則，自然離不開的就是分布式系統網路所帶的問題
冪等性原則是對呼叫服務器次數的一種限制，無論某個服務器提供的介面呼叫一次或多次結果是一樣的
對于分布式系統來說，冪等性的實作
1.可以在寫操作之前通過執行讀操作來實作
支付例子來說明的話：讀取當前的狀態來進行判斷（已支付或者未支付），然后做出寫的操作（支付成功或者支付失敗繼續支付）
2.”去重表“的方式來實作
通過第一次操作之前生成全域唯一ID-》去重表中查找判斷是否存在-》存在，回傳結果，不存在，存入去重表
3.CAS演算法
Compare And Swap，天然免疫死鎖狀態，操作保證了原子性
4.分布式鎖
在分布式環境下，鎖定全域唯一資源，使請求串行化，實際表現為互斥鎖，防止重復，解決冪等，
5.悲觀鎖
在獲取資料時加鎖，當同時有多個重復請求時其他請求都無法操作
可擴展原則
可擴展原則是必然考慮的因素，從專案架構，資料庫設計，技術選型和編碼規范等多個方面考慮
1.介面統一，方便集成
2.使用無狀態化的應用服務，避免開發后期遇到session共享等資料同步問題
3.使用HDFS等分布式系統，在存盤容量不足時迅速通過增加設備來擴容
4.合理設計資料庫的分庫分表策略，能快速進行資料擴容
5.使用分布式或微服務架構，快速開發并易于增加新的功能模塊
6.設計系統時考慮可擴展的各種手段，大幅度提高開發效率
7.通過橫向擴展MapReduce的方法，增加節點個數提升并行計算性能
可維護原則
字面理解開發系統方便改正修復系統存在的問題，從以下5個方面說起
1.專案的日志記錄功能完善，易于追溯，統計問題（日志是不可避免的）
2.有BugFree等Bug管理工具(名字比較專業，在軟體測驗課程中使用過，禪道)
3.有豐富的專案檔案和注釋(夸張的說法有代碼一行，注釋十行)
4.統一的開發規范(主要就是命名，見名知意，縮進規范)
5.使用模塊化的編程模式(微服務搭建就是模塊化開發的)
可監控原則
對系統中的流量，性能，服務例外等情況進行實時監控
對專案的關鍵技術做出性能監控，結合自己的實踐，測驗和監控情況進行具體的分析
個人總結
上面提及到的CAS演算法，以及冪等性原則和重復提交還需要再去理解
寫在后面的話：事件結果：現在的時間完全按照自己的規劃走下去，所以寫下了以上blog 碎碎念：歡迎大家指出blog中的問題，督促筆者進一步改善 |
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/393093.html
標籤：其他
上一篇：TCP/IP協議概論
下一篇：計算機導論期末總結