1、基於時間戳
比如流水號規則如下：xx-yyyymmdd-n位隨機數，這也是企業級應用開發常用的規則。此流水號對人比較友好，可識別性高，但容量受後面隨機數的限制，且資料量越大，生成時難度越高。前三部分每天的流水號基本固定，後面的n位隨機數生成後，需要校驗此前不存在，可依賴redis的set機制，每天的隨機數都寫到乙個set集合中[set容易達42億之多，完全夠用]，重新生成後要與set集合作比對，以確保其唯一性。一天內不重複，再結合確定日期來保證其唯一性。
第一位為未使用，接下來的41位為毫秒級時間(41位的長度可以使用69年)，然後是5位datacenterid和5位workerid(10位的長度最多支援部署1024個節點） ，最後12位是毫秒內的計數（12位的計數順序號支援每個節點每毫秒產生4096個id序號）
一共加起來剛好64位，為乙個long型。(轉換成字串長度為18)
snowflake生成的id整體上按照時間自增排序，並且整個分布式系統內不會產生id碰撞（由datacenter和workerid作區分），並且效率較高。據說：snowflake每秒能夠產生26萬個id。
5、redis分布式id生成器
6、mongodb的objectid
公司情況，之前公司採用的是uuid,在業務發展的過程中，發現uuid相對於long型別來說更耗費效能，而且在範圍查詢的時候對索引的利用率效果不是很好。再加上公司有一些其他的語言，所以經過考慮公司採用vesta發號器。
-
唯一流水號的產生（分布式發號器）
在網際網路世界裡，產生唯 一流水號的服務系統俗稱發號器。1 uuid雖然能夠保證id的唯一性，但是無法滿足業務系統需要的很多其他特性，例如時間粗略有序性 可反解和可製造性。2 效能較差。uuid比較長 占用空間大，會間接導致資料庫效能下降 如使用資料庫的自增欄位，然而自增字段完全 依賴於資料庫，則在...
分布式 分布式鎖
本質是利用redis的setnx 方法的特性來加鎖，setnx 即key不存在則設定key，否則直接返回false，要求在分布式系統中使用同乙個redis服務，以下提供兩種解決方案 1 直接使用redistemplate 這其實並不能完全保證高併發下的安全問題，因為可能在鎖過期之後該執行緒尚未執行完...
分布式 分布式事務
是資料庫執行過程中的乙個邏輯單位，由乙個有限的資料庫操作序列構成。事務的acid四大特性 原子性 atomicity 事務作為乙個整體被執行。一致性 consistency 從乙個一致的狀態轉換到另乙個一致的狀態。隔離性 isolation 多個事務併發執行時，併發事務之間互相影響的程度。永續性 d...