（本文作者溫少，首發(fā)于博客園，轉(zhuǎn)載請注明）
ID生成算法，其中一種就是使用GUID（又稱UUID），使用128位存儲。UUID的一個問題是太長，可讀性太差，人腦無法記憶。
替代方案之一，就是使用關(guān)系數(shù)據(jù)庫的自增長字段，自增長字段的一個問題是，無法預(yù)先創(chuàng)建一個ID，只能夠在保存的時候才能生成ID，這對于批量關(guān)聯(lián)插入數(shù)據(jù)來說，不滿足需求。
替
代方案之二，就是使用一個記錄ID的表，每次加一，在事務(wù)中使用Select FOR UPDATE來讀取然后UPDATE SET FVALUE =
FVALUE + 1，或者使用我之前文章中所提到的CAS算法。 這樣做，會導(dǎo)致性能低下，每生成一個ID的成本都很高。
替代方案之
三，就是把ID分成兩部分，Seed和IncrementID。Seed采用上面的方案二或者其他辦法生成，IncrementID使用一個
AtomicInteger來每次遞增生成。SEED轉(zhuǎn)化為九進(jìn)制數(shù)字，這樣SEED就不會包含9，于是使用9作為分隔符，把SEED和
IncrementID隔開。這樣做，就可以做高性能產(chǎn)生ID，而且確保不重復(fù)。甚至可以更進(jìn)一步，SEED由一個中心服務(wù)器生成。使用9個分隔符號隔開
SEED和IncrementID，好處是SEED是變長，而不是使用固定位數(shù)來保存SEED，這樣產(chǎn)生的ID會更短，可讀性更好。
舉例，34915，其中34時SEED，15是IncrementID，9是分隔符，SEED部分采用九進(jìn)制表示法，確保不出現(xiàn)9，第一個9之后的內(nèi)容屬于IncrementID。
我已經(jīng)做了一個實現(xiàn)，用于實際開發(fā)中，思路采用方案三，有很多實作的細(xì)節(jié)，但是總體設(shè)計思路就是如此。
（本文作者溫少，首發(fā)于博客園，轉(zhuǎn)載請注明）