又有個新朋友問我分布式，我表示了一下自己的看法， 也與大家分享一下。
一、要點
負載均衡(集群)： 部署多個單應用(每台伺服器部署的應用相同)，然後通過nginx或其他軟體對客戶端的請求進行分發分工。即使其中某乙個或者多個壞了，剩下的仍在工作仍可請求通完成任務。相比單應用伺服器，能有效的解決高併發和伺服器壓力。
分布式：將整個系統的功能進行拆解，根據業務功能模組分別部署到不同的伺服器上，各個業務模組之間通過介面進行資料互動。分布式如果掛了乙個伺服器則這個伺服器上對應的功能就用不了，其他的能用。比如充值提現伺服器掛了則僅充值提現業務受到影響，其他如註冊下單等等均可正常使用。
微服務：與分布式差不多，但是拆分的更細。
二、效率比較
假如10個請求，每個請求處理需10s。
三、注意點：
1 負載均衡
1.1 需做好共享,如 session ，公共資料夾 等等
1.2 更新**每台伺服器都要更新一下。最好是先全部關閉，每台更新完畢後在逐個重啟。盡量不要更新完一台就重啟然後接著下一台，因為更新完了的是最新**，還沒更新的是老**，如果在這個過程中分發交差了新老**的伺服器難免出問題。
1.3 如有定時任務只需要一台伺服器執行就好，不要每台都執行一遍。(可以給定時任務做個開關標誌寫配置檔案裡面僅一台伺服器配上標誌)
2 分布式&微服務
2.1 需注意事務管理，不要最後交易失敗了出現有些事務提交了有些回滾了。
2.2 修改了不在服務註冊監控中心的東西，需要重啟中介軟體才能生效。
2.3 若集群，根據業務決定集群數量，一般1-4臺即可，多了也要成本。重點業務、請求併發大的子系統集群數量可以多幾台，反之可以少幾台或單台
2.4 缺點：需要的硬體、人力成本多，排查問題牽扯的太多服務和對應的負責人，大多人只知自己負責的這塊，調到別人那裡面是什麼個情況完全不知情。
簡介分布式系統會有乙個對外提供服務的閘道器api，客戶端請求到（負載均衡然後到）閘道器api，閘道器api根據路由規則會給到對應的應用服務去處理以及傳送非同步處理。在此之前，每個應用服務都要註冊登記到服務註冊監控中心，服務註冊監控中心會把自己掌握的資訊提供給閘道器api。至於應用服務，也就是業務實現的地方，主要的開發工作在此。不同的需求寫不同的服務和業務邏輯**，部分需求業務可能會用到快取(redis)和訊息佇列(rabbitmq)。每個功能模組下一般都寫了***，有興趣的話可以去看看***裡面寫了什麼。
整個系統還應該會用到日誌管理（方便整個請求鏈路的日誌追查，一般是在閘道器的時候就生成日誌號id， 層層往下傳遞）和效能監控（監測系統效能）模組。
認識分布式系統
多個系統一起組成分布式系統，各個系統之間互相呼叫。系統不做拆分，量會很大，很多人一起維護 難以維護，上線複雜。拆分之後，每個人只維護自己的系統和服務，大大減少了 衝突，上線也只需要測試自己的部分即可，想用新技術也不怕影響其他 根據系統功能進行拆分，比如風控系統，拆成了交易系統，授信系統，審核系統，催...
分布式 分布式鎖
本質是利用redis的setnx 方法的特性來加鎖，setnx 即key不存在則設定key，否則直接返回false，要求在分布式系統中使用同乙個redis服務，以下提供兩種解決方案 1 直接使用redistemplate 這其實並不能完全保證高併發下的安全問題，因為可能在鎖過期之後該執行緒尚未執行完...
分布式 分布式事務
是資料庫執行過程中的乙個邏輯單位，由乙個有限的資料庫操作序列構成。事務的acid四大特性 原子性 atomicity 事務作為乙個整體被執行。一致性 consistency 從乙個一致的狀態轉換到另乙個一致的狀態。隔離性 isolation 多個事務併發執行時，併發事務之間互相影響的程度。永續性 d...