分布式id：用在分布式系統中
在我們的業務需求中通常有需要一些唯一的id，來記錄我們某個資料的標識:
1.如果id我們使用的是資料庫的自增長型別，在分布式系統中需要分庫和分表，會有兩個相同的表，有可能產生主鍵衝突
根據資料庫的儲存結構來定，mysql底層用的是innodb引擎,底層儲存結構是b+樹,大家可以去
用b+tree插入string型別資料，從插入第四個字串開始看
第四個字串是從樹的右邊插入的
第五個字串是從樹中間插入的
第六個字串是從樹的左邊插入的
當往b+樹中插入字串，不確定會往樹的哪個地方插，這樣會破壞這顆樹，
結論：
所以我們選用數值型別作為分布式id
那麼數值型別中又應該如何篩選呢
我在裡面插入的數值是越來越大的，而且每次都是往樹的右節點插入的
而最後，我插入小值時，就不確定它往樹的哪邊插入，這樣就會像插入字串一樣，破壞樹的結構
數值越來越大時，就會一直往樹的最右節點插入
最終結論
雪花：自然界中不存在兩片一毛一樣的雪花，唯一，與時間有關，遞增
簡單原理：
第一部分：備用
第二部分：時間戳：由於是二進位制，所以是2的41次方得到毫秒值，再計算是年份69年，41位為毫秒級時間(41位的長度可以使用69年) 如果大於69年，就會使用第一部分，時間戳只會越來越大
第三部分：用來記錄機器id，一般用前5位代表資料中心，後面5位是某個資料中心的機器id(10位的長度最多支援部署1024個節點【集群】）
第四部分：序列號：支援併發，逐漸遞增 ，2的12次方=4096，也就是一毫秒內支援產生4096個id，一秒4096*100=4096000，所以一台機器每秒的併發可以支援4096000，但是經測試snowflake每秒能夠產生26萬個id。
snowflake生成的id整體上按照時間自增排序，並且整個分布式系統內不會產生id碰撞（由datacenter和workerid作區分），並且效率較高。經測試snowflake每秒能夠產生26萬個id。
分布式技術之分布式ID和分布式事務
mycat不支援只能使用在sharding jdbc中 public class mysharding implements preciseshardingalgorithm spring.shardingsphere.sharding.tables.t order.actual data node...
甜甜的分布式ID
生活太苦了，只能把技術變甜了。id是資料的唯一標識，傳統的做法是利用 uuid 和資料庫的自增 id，在網際網路企業中，大部分公司使用的都是 mysql，並且因為需要支援事務，所以通常會使用 innodb 儲存引擎，uuid太長以及無序，所以並不適合在 innodb 中來作為主鍵，自增 id 比較合...
分布式ID生成器
一 需求緣起 幾乎所有的業務系統，都有生成乙個唯一記錄標識的需求，例如 這個記錄標識往往就是資料庫中的主鍵，資料庫上會建立聚集索引 cluster index 即在物理儲存上以這個字段排序。這個記錄標識上的查詢，往往又有分頁或者排序的業務需求，例如 所以往往要有乙個time欄位，並且在time欄位上...