雪花演算法的原理
第一位符號位固定為0，41位時間戳，10位workld，12位序列號，位數可以有不同實作
優點:
每個毫秒值包含的ID值很多，不夠可以變動位數來增加，性能佳 (依賴workld的實作)，.時間戳值在高位，中間是固定的機器碼，自增的序列在低位，整個ID是趨勢遞增的，0能夠根據業務場景資料庫節點布置靈活調整bit位劃分，靈活度高，
缺點:
強依賴于機器時鐘，如果時鐘回拔，會導致重復的ID生成，所以一般基于此的演算法發現時鐘回撥，都會拋例外.
處理，阻止ID生成，這可能導致服務不可用，
為什么Zookeeper可以用來作為注冊中心
可以利用Zookeeper的臨時節點和watch機制來實作注冊中心的自動注冊和發現，另外Zookeeper中的資料都是存在記憶體中的，并且Zookeeper底層采用了nio，多執行緒模型，所以Zokeeper的性能也是比較高的，所以可以用來作為注冊中心，但是如果考慮到注冊中心應該是注冊可用性的話，那么Zookeeper則不太合適，因為Zookeeper是CP的，它注重的是一致性，所以集群資料不-致時，集群將不可用，所以用Redis、Eureka、Nacos來作為注冊中心將更合適，
資料庫實作分布式鎖的問題及解決方案
利用唯一約束鍵存盤key，insert成功則代表獲取鎖成功，失敗則獲取失敗，操作完成需要洗掉鎖問題:
非阻塞，鎖獲取失敗后沒有排隊機制，需要自己編碼實作阻塞，可以使用自旋，直到獲取鎖；
不可重入，如果加鎖的方法需要遞回，則第二次插入會失敗，可以使用記錄執行緒標識解決重入問題；
死鎖，洗掉鎖失敗、則其他執行緒沒辦法獲取鎖，可以設定超時時間、使用定時任務檢查.
資料庫單點故障，資料庫高可用，
資料一致性模型有哪些
強一致性:當更新操作完成之后，任何多個后續行程的訪問都會回傳最新的更新過的值，這種是對用戶最友好的，就是用戶上一次寫什么，下一次就保證能讀到什么，根據 CAP 理論，這種實作需要犧牲可用性，
弱一致性: 系統在資料寫入成功之后，不承諾立即可以讀到最新寫入的值，也不會具體的承諾多久之后可以讀到，用戶讀到某一操作對系統資料的更新需要一段時間，我們稱這段時間為“不一致性視窗”，
最終一致性:最終一致性是弱一致性的特例，強調的是所有的資料副本，在經過一段時間的同步之后，最終都能夠達到一個一致的狀態，因此，最終一致性的本質是需要系統保證最終資料能夠達到一致，而不需要實時保證系統資料的強一致性，到達最終一致性的時間 ，就是不一致視窗時間，在沒有故障發生的前提下，不一致視窗的時間主要受通信延遲，系統負載和復制副本的個數影響
最終一致性模型根據其提供的不同保證可以劃分為更多的模型，包括因果一致性和會話一致性等，
因果一致性: 要求有因果關系的操作順序得到保證，非因果關系的操作順序則無所謂，
行程 A 在更新完某個資料項后通知了行程 B，那么行程 B 之后對該資料項的訪問都應該能夠獲取到行程A更新后的最新值，并且如果行程 B 要對該資料項進行更新操作的話，務必基于行程 A 更新后的最新值，
在微博或者微信進行評論的時候，比如你在朋友圈發了一張照片，朋友給你評論了，而你對朋友的評論進行了回復，這條朋友圈的顯示中，你的回復必須在朋友之后，這是一個因果關系，而其他沒有因果關系的資料，可以允許不一致，
會話一致性:將對系統資料的訪問程序框定在了一個會話當中，約定了系統能保證在同一個有效的會話中實作“讀己之所寫”"的一致性，就是在你的一次訪問中，執行更新操作之后，客戶端能夠在同一個會話中始終讀取到該資料項的最新值，實際開發中有分布式的 Session 一致性問題，可以認為是會話一致性的一個應用，
什么是分布式事務?有哪些實作方案?
在分布式系統中，一次業務處理可能需要多個應用來實作，比如用戶發送一次下單請求，就涉及到訂單系統創建訂單、庫存系統減庫存，而對于一次下單，訂單創與減庫存應該界要同時成功或同時失敗的，但在分布式系統中，如里不做處理，就很有可能出現訂單創建成功，但界減庫存失敗，那么解決這類問題，就需要用到分布式事務，常用解決方案有:
1.本地訊息表:創建訂單時，將減庫存訊息加入在本地事務中，一起提交到資料庫存入本地訊息表，然后呼叫庫存系統，如果呼叫成功則修改本地訊息狀態為成功，如果呼叫庫存系統失敗，則由后臺定時任務從本地訊息表中取出未成功的訊息，重試呼叫庫存系統
2.訊息佇列:目前RocketMQ中支持事務訊息，它的作業原理是:
a.生產者訂單系統先發送一條half訊息到Broker，half訊息對消費者而言是不可見的；
b.再創建單，根據創建訂單成功與否，向Broker發送commit或rollback；
c 并且生產者訂單系統還可以提供Broker回呼介面，當Broker發現一段時間half訊息沒有收到任何操作命令，則會主動調此介面來查詢訂單是否創建成功；
d.一旦half訊息commit了，消費者庫存系統就會來消費，如果消費成功，則訊息銷毀，分布式事務成功結束；
e.如果消費失敗，則根據重試策略進行重試，最后還失敗則進入死信佇列，等待進一步處理；
3.Seata:阿里開源的分布式事務框架，支持AT、TCC等多種模式，底層都是基于兩階段提交理論來實作的
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/543662.html
標籤：其他
上一篇：QA 不講武德！線上 1 億+ 資料亂分頁，讓我搞到半夜。。
下一篇：LeetCode_單周賽_332