MySQL分庫(kù)分表之后，id主鍵如何處理？我從分庫(kù)分表存在的問(wèn)題和怎么做來(lái)回答一下這個(gè)問(wèn)題。。一，分庫(kù)分表的ID主鍵不能依賴(lài)于數(shù)據(jù)庫(kù)的自增，因?yàn)槎鄮?kù)中會(huì)重復(fù)！通常使用外接的數(shù)據(jù)組件獲取全局唯一的ID：

MySQL分庫(kù)分表之后，id主鍵如何處理？

我從分庫(kù)分表存在的問(wèn)題和怎么做來(lái)回答一下這個(gè)問(wèn)題。。

一，分庫(kù)分表的ID主鍵不能依賴(lài)于數(shù)據(jù)庫(kù)的自增，因?yàn)槎鄮?kù)中會(huì)重復(fù)！

通常使用外接的數(shù)據(jù)組件獲取全局唯一的ID：比如加強(qiáng)型UUID（根據(jù)Ip，時(shí)間戳等得到）和使用Redis(RedisAtomicLong)和zookeeper的API獲取，Twitter的雪花算法等等！

二，分庫(kù)分表之后的連接查詢比較困難！

問(wèn)題沒(méi)法避免，通常拆分SQL，使用多次查詢，用查到的結(jié)果再分別查別的結(jié)果！

三，分布式事務(wù)的數(shù)據(jù)一致性很難保證！

可以使用TCC編程模型保證兩處的事務(wù)都能正確提交，但是這種方式對(duì)代碼的侵入比較重！也可以使用基于消息的數(shù)據(jù)一致性保證！

四，多數(shù)據(jù)的排序，分組，統(tǒng)計(jì)會(huì)比較困難！

1，用多線程，對(duì)多個(gè)節(jié)點(diǎn)分別查詢，然后匯總！

2，也可以提前冗余查詢表，將所有的經(jīng)常查詢的重點(diǎn)數(shù)據(jù)提前統(tǒng)一到個(gè)庫(kù)表里！

分庫(kù)分表涉及到的知識(shí)點(diǎn)比較多，建議使用專(zhuān)門(mén)的分庫(kù)分表組件！本人有mycat使用經(jīng)驗(yàn)，如果您有相關(guān)問(wèn)題，歡迎前來(lái)探討！

在分布式系統(tǒng)中，如何生成分布式ID？

分布式ID常見(jiàn)的兩種方法就是UUID和snowflake算法（雪花算法）。

UUID是一種本地生成ID的方法，不需要遠(yuǎn)程調(diào)用，高性能、低延時(shí)、擴(kuò)展性好，但是UUID不支持遞增。

snowflake算法是twitter開(kāi)源的分布式ID生成算法，其核心思想是一個(gè)long型的ID：1位標(biāo)識(shí)符（始終是0）、41位時(shí)間戳毫秒數(shù)、10位機(jī)器標(biāo)識(shí)碼、12位毫秒內(nèi)序列號(hào)，該算法單機(jī)每秒內(nèi)理論上最多可以生成1000*(2^12)的ID，性能高、趨勢(shì)遞增、靈活度高，但snowflake依賴(lài)機(jī)器的時(shí)鐘，如果服務(wù)器時(shí)鐘回?fù)軙?huì)導(dǎo)致生成重復(fù)的ID。

圖像視頻雪花噪點(diǎn)的檢測(cè)算法實(shí)現(xiàn)，有大神有代碼的嗎？

主要還是像素檢測(cè)。閾值指定。1：對(duì)于一個(gè)像素獲取其周?chē)南袼?，均值加?quán)之后和現(xiàn)有的像素值進(jìn)行比較，2：計(jì)算百分比差異，也可以直接用色差。閾值指定可以通過(guò)define全局變量指定值，修改define達(dá)到修改閾值的效果。這個(gè)閾值肯定是要你自己指定，視情況修改就好了?；蛘呓y(tǒng)計(jì)出全像素的色差值和，算出平均之后取差異大的。