--- tags: 學習筆記 --- 演算法 ============== ### 雪花演算法 **世界上沒有完全相同的兩片雪花** 資料庫索引很常會使用ID作為該筆資料的Key, 這類Key常見的取得方式有 * 資料庫自增(auto increment) * 方便易用 * 依賴資料庫實現 * 需考慮多併發或是分庫分表時的管理方式 * 多併發時可能會出現重號或跳號等問題(而且會有效能瓶頸問題) * 分庫分表時ID會重號,需另尋解法 * 自建ID Contoler表(每次新增資料自此表取Key) * 透過自行撰寫邏輯實現,不依賴資料庫 * 效能瓶頸問題仍然存在 * 透過此表可輕鬆了解DB中各張資料表的KEY值情況(分析資料量,做分庫分表或是資料移轉也可了解當前序號到多少) * GUID * 不易發生重號 * 無時序性 * 效能瓶頸問題仍然存在 而雪花演算法的優勢就在於它可以解決多伺服器同時寫入時的效能瓶頸問題(DB只有一台,但有多台伺服器連線),且產生的ID依然具備時序性。 * 時間戳:41位毫秒級的時間 * 保證序號的時序性 * 配合12位的流水號,可保證即使同一毫秒也能有2^12筆獨立序號 * 2^41毫秒約可保證69年的持續使用 * 給定一起始時間,時間戳為產生序號的當下與起始時間的時間差(距離系統上線時間越近越好) * 設下後即不可改變(才能保證不會重號) * 工作機ID:透過此ID達成分散式主機產生的ID不會重號的目的每台工作機都有獨立的一組ID,因此即使同時A主機與B主機都要寫入新序號,也必然不會重號。 
×
Sign in
Email
Password
Forgot password
or
By clicking below, you agree to our
terms of service
.
Sign in via Facebook
Sign in via Twitter
Sign in via GitHub
Sign in via Dropbox
Sign in with Wallet
Wallet (
)
Connect another wallet
New to HackMD?
Sign up