mysql分庫如何查詢，分布式系統(tǒng)中？

分布式系統(tǒng)中的“身份證”即分布式Id且唯一。如何生成分布式系統(tǒng)中的唯一Id？考慮這個(gè)問題的時(shí)候，我覺得可以從“帶著問題去找方案”這個(gè)思路去聊聊，也就是說我要生成的這個(gè)分布式Id需要滿足哪些條件呢？

分布式Id生成需要滿足的條件全局唯一：這個(gè)不用多說了，不然還有什么分布式“身份證”？高可用：不能有單點(diǎn)故障，小心引起雪崩；安全：這個(gè)Id不能是連續(xù)的，否則讓非友好人士發(fā)現(xiàn)規(guī)則，數(shù)據(jù)爬去、數(shù)據(jù)預(yù)測都會有一定的安全風(fēng)險(xiǎn)；保證順序遞增：MySQL的Innodb引擎采用B+樹算法存儲索引數(shù)據(jù)，為了提高性能，就得要求索引的主鍵在一定程度上是有序的，這樣不管是寫入還是查詢效率都很好的；分片支持：可以根據(jù)分布式Id得到具體的業(yè)務(wù)shardingId，方便業(yè)務(wù)查詢；不要太長：64位存儲最佳？大家覺得還有哪些場景或者條件需要考慮？歡迎評論區(qū)留言討論~那么基于以上需要考慮的條件，我們?nèi)粘Ｖ卸加心男┓植际絀d生成方案呢？數(shù)據(jù)庫生成

優(yōu)點(diǎn)：簡單粗暴，自增Id順序遞增

缺點(diǎn)：只有主庫才能生成，容易造成單點(diǎn)故障；性能不足時(shí)候，無法擴(kuò)展；分庫分表會有很多麻煩。

UUID

優(yōu)點(diǎn)：簡單直接，無性能問題，真正的全球唯一

缺點(diǎn)：無規(guī)則；UUID是字符串，IO傳輸數(shù)據(jù)量大，存儲空間大，查詢效率低；基于UUID分庫分表更難。

redis生成

優(yōu)點(diǎn)：基于內(nèi)存操作的reids性能比數(shù)據(jù)庫好；可以基于集群做有序的數(shù)字Id生成；利于分庫分表；

缺點(diǎn)：需要搭建一套高可用redis集群；需要基于集群編寫生成Id的方案；

zookeeper生成和redis類似業(yè)務(wù)規(guī)則生成舉例訂單號的生成：10_2298765801_1565283246399_781.業(yè)務(wù)字段用于區(qū)分具體的業(yè)務(wù)，采用2-4位，可以根據(jù)不同的系統(tǒng)或者業(yè)務(wù)自由決定；2.用戶Id，最長10位夠了吧3.毫秒級時(shí)間戳：13位4.隨機(jī)數(shù)：2-4位

個(gè)人還是喜歡采用業(yè)務(wù)規(guī)則生成的方案，性能肯定沒的說，基于內(nèi)存計(jì)算即可得到，也不存在什么單點(diǎn)故障，哪臺機(jī)器都可以自己生成，不依賴第三方服務(wù)或者應(yīng)用，也能保證順序遞增。

這樣的設(shè)計(jì)能達(dá)到真正的分布式唯一Id嗎？能滿足上面所說的那些條件嗎？大家還有什么好的生成方案？歡迎評論交流，批評指正~