分布式和集群

分布式一定是集群，但是集群不一定是分布式（可能是復制的）

集群是多個實例一起工作，分布式將一個系統(tǒng)拆分之后那就是多個實例

分布式應用結構：

Hash算法

適用于在加密，數(shù)據(jù)存儲和查找方面有hash表，效率高，最理想的時間復雜度接近O(1)

例如：

直接尋址法：存儲的數(shù)據(jù)和數(shù)組下標綁定到一起 H(key)=a*key + b(a,b是常量)

除留余數(shù)法：存儲的數(shù)據(jù)對空間長度求模確定存儲位置

普通Hash算法存在問題：擴容縮容都需要影響全局重新計算，因此引入一致性Hash

一致性Hash算法

一致性Hash算法將整個Hash空間組織成一個虛擬的圓環(huán)，Hash函數(shù)的值空間為0 - 2^32 -1 整形，如圖所示

一致性Hash算法對于節(jié)點的增減都只需重定位環(huán)空間中的一小部分數(shù)據(jù)，具有較好的容錯性和可擴展性。

在節(jié)點少時容易出現(xiàn)資源傾斜，解決這種問題使用虛擬節(jié)點機制，每個節(jié)點對應多個hash，通過虛擬節(jié)點映射真實節(jié)點

集群時鐘同步方案

如果所有服務器都能聯(lián)網(wǎng)，可以分別同步國家時間服務器

使用命令：ntpdate -u ntp.api.bz

如果存在不能聯(lián)網(wǎng)的的機器，定時同步局域網(wǎng)內(nèi)能聯(lián)網(wǎng)的其他服務器時間（如果全部不能聯(lián)網(wǎng)就指定設置一臺同步）

分布式ID生成方案

UUID 重復概率低

獨立數(shù)據(jù)庫自增id 性能和可靠性都低

SnowFlake 雪花算法 ：二進制 由41位時間戳 + 10位機器碼 + 12位序列號組成

Redis incr

分布式調(diào)度

1.運行在分布式集群環(huán)境下的調(diào)度任務(同一個定時任務程序部署多份，只應該有一個定時任務在執(zhí)行)

2.分布式調(diào)度—>定時任務的分布式—>定時任務的拆分(即為把一個大的作業(yè)任務拆分為多個小的作業(yè)任務，同時執(zhí)行)

定時任務與消息隊列的區(qū)別

共同點

異步處理

2. 應用解耦

3. 流量削峰

不同點

定時任務作業(yè)是時間驅(qū)動，而MQ是事件驅(qū)動

2. 定時任務作業(yè)更傾向于批處理，MQ傾向于逐條處理

分布式調(diào)度框架Elastic-Job

分布式調(diào)度協(xié)調(diào) 基于 Zookeeper 實現(xiàn)

在分布式環(huán)境中，任務能夠按指定的調(diào)度策略執(zhí)行，并且能夠避免同一任務多實例重復執(zhí)行

豐富的調(diào)度策略 基于成熟的定時任務作業(yè)框架Quartz cron表達式執(zhí)行定時任務

彈性擴容縮容 當集群中增加某一個實例，它應當也能夠被選舉并執(zhí)行任務;當集群減少一個實例 時，它所執(zhí)行的任務能被轉(zhuǎn)移到別的實例來執(zhí)行。

失效轉(zhuǎn)移 某實例在任務執(zhí)行失敗后，會被轉(zhuǎn)移到其他實例執(zhí)行

錯過執(zhí)行作業(yè)重觸發(fā) 若因某種原因?qū)е伦鳂I(yè)錯過執(zhí)行，自動記錄錯過執(zhí)行的作業(yè)，并在上次作業(yè) 完成后自動觸發(fā)。

支持并行調(diào)度 支持任務分片，任務分片是指將一個任務分為多個小任務項在多個實例同時執(zhí)行。 作業(yè)分片一致性 當任務被分片后，保證同一分片在分布式環(huán)境中僅一個執(zhí)行實例。

Leader節(jié)點選舉機制

每個Elastic-Job的任務執(zhí)行實例App作為Zookeeper的客戶端來操作ZooKeeper的znode

1.多個實例同時創(chuàng)建leader節(jié)點

2.leader節(jié)點只能創(chuàng)建一個，后創(chuàng)建的會失敗，創(chuàng)建成功的實例會被選為leader節(jié)點， 執(zhí)行任務

任務分片：

處理數(shù)據(jù)量過大時，ElasticJob可以把作業(yè)分為多個的task(每一個task就是一個任務分片)，每一個task交給具體的一個機器實例去處理(一個機器實例是可以處理多個task的)，但是具體每個task 執(zhí)行什么邏輯由我們自己來指定。

當擴容或者縮容時，Zookeeper或通知Elastic-Job 重新分片

Session共享（一致性）

解決方案：

Nginx的 IP_Hash 策略 ：同一個客戶端IP的請求都會被路由到同一個目標服務器

缺陷：服務器重啟Session丟失，存在單點負載高的?險，單點故障問題

2. Session復制：Tomcat修改配置文件，達到Session之間的復制

缺陷：性能低，延遲

3. Session共享，使用緩存中間件

Spring Session 使用僅需要引入依賴，配置redis，開啟注解

原理如下圖：

作業(yè)：

基于SpringBoot實現(xiàn)一個登陸功能，含有攔截驗證，使用Spring session保持session一致性，打成war包，將war包部署到tomcat集群中，要求1個Nginx節(jié)點、2個Tomcat節(jié)點，使用Nginx輪詢訪問兩個tomcat

主要代碼及配置：

登錄Controller

攔截器：此處簡易實現(xiàn)

配置攔截登錄之外的請求

Nginx配置

總結

以上是生活随笔為你收集整理的springsession分布式登录被覆盖_拉勾 分布式 学习小结的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。