springsession分布式登录被覆盖_拉勾 分布式 学习小结
分布式和集群
分布式一定是集群，但是集群不一定是分布式（可能是復制的）
集群是多個實例一起工作，分布式將一個系統拆分之后那就是多個實例
分布式應用結構：
Hash算法
適用于在加密，數據存儲和查找方面有hash表，效率高，最理想的時間復雜度接近O(1)
例如：
直接尋址法：存儲的數據和數組下標綁定到一起 H(key)=a*key + b(a,b是常量)
除留余數法：存儲的數據對空間長度求模確定存儲位置
普通Hash算法存在問題：擴容縮容都需要影響全局重新計算，因此引入一致性Hash
一致性Hash算法
一致性Hash算法將整個Hash空間組織成一個虛擬的圓環，Hash函數的值空間為0 - 2^32 -1 整形，如圖所示
一致性Hash算法對于節點的增減都只需重定位環空間中的一小部分數據，具有較好的容錯性和可擴展性。
在節點少時容易出現資源傾斜，解決這種問題使用虛擬節點機制，每個節點對應多個hash，通過虛擬節點映射真實節點
集群時鐘同步方案
如果所有服務器都能聯網，可以分別同步國家時間服務器
使用命令：ntpdate -u ntp.api.bz
如果存在不能聯網的的機器，定時同步局域網內能聯網的其他服務器時間（如果全部不能聯網就指定設置一臺同步）
分布式ID生成方案
UUID 重復概率低
獨立數據庫自增id 性能和可靠性都低
SnowFlake 雪花算法 ：二進制 由41位時間戳 + 10位機器碼 + 12位序列號組成
Redis incr
分布式調度
1.運行在分布式集群環境下的調度任務(同一個定時任務程序部署多份，只應該有一個定時任務在執行)
2.分布式調度—>定時任務的分布式—>定時任務的拆分(即為把一個大的作業任務拆分為多個小的作業任務，同時執行)
定時任務與消息隊列的區別
共同點
2. 應用解耦
3. 流量削峰
不同點
2. 定時任務作業更傾向于批處理，MQ傾向于逐條處理
分布式調度框架Elastic-Job
分布式調度協調 基于 Zookeeper 實現
在分布式環境中，任務能夠按指定的調度策略執行，并且能夠避免同一任務多實例重復執行
豐富的調度策略 基于成熟的定時任務作業框架Quartz cron表達式執行定時任務
彈性擴容縮容 當集群中增加某一個實例，它應當也能夠被選舉并執行任務;當集群減少一個實例 時，它所執行的任務能被轉移到別的實例來執行。
失效轉移 某實例在任務執行失敗后，會被轉移到其他實例執行
錯過執行作業重觸發 若因某種原因導致作業錯過執行，自動記錄錯過執行的作業，并在上次作業 完成后自動觸發。
支持并行調度 支持任務分片，任務分片是指將一個任務分為多個小任務項在多個實例同時執行。 作業分片一致性 當任務被分片后，保證同一分片在分布式環境中僅一個執行實例。
Leader節點選舉機制
每個Elastic-Job的任務執行實例App作為Zookeeper的客戶端來操作ZooKeeper的znode
1.多個實例同時創建leader節點
2.leader節點只能創建一個，后創建的會失敗，創建成功的實例會被選為leader節點， 執行任務
任務分片：
處理數據量過大時，ElasticJob可以把作業分為多個的task(每一個task就是一個任務分片)，每一個task交給具體的一個機器實例去處理(一個機器實例是可以處理多個task的)，但是具體每個task 執行什么邏輯由我們自己來指定。
當擴容或者縮容時，Zookeeper或通知Elastic-Job 重新分片
Session共享（一致性）
解決方案：
缺陷：服務器重啟Session丟失，存在單點負載高的?險，單點故障問題
2. Session復制：Tomcat修改配置文件，達到Session之間的復制
缺陷：性能低，延遲
3. Session共享，使用緩存中間件
Spring Session 使用僅需要引入依賴，配置redis，開啟注解
原理如下圖：
作業：
基于SpringBoot實現一個登陸功能，含有攔截驗證，使用Spring session保持session一致性，打成war包，將war包部署到tomcat集群中，要求1個Nginx節點、2個Tomcat節點，使用Nginx輪詢訪問兩個tomcat
主要代碼及配置：
登錄Controller
攔截器：此處簡易實現
配置攔截登錄之外的請求
Nginx配置
總結
以上是生活随笔為你收集整理的springsession分布式登录被覆盖_拉勾 分布式 学习小结的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： oracle 重建em失败,11gr2
- 下一篇： oracle中国授权机构查询,oracl