細(xì)觀分布式事務(wù)的出現(xiàn)和演變過程是什么？分布式事務(wù)是指事務(wù)的參與者、支持什么事務(wù)的服務(wù)器、資源服務(wù)器以及事務(wù)管理器共有坐落相同的分布式系統(tǒng)的不同節(jié)點之上。目的是實現(xiàn)方法分布式事務(wù)，需要使用下面將能介紹的

細(xì)觀分布式事務(wù)的出現(xiàn)和演變過程是什么？

分布式事務(wù)是指事務(wù)的參與者、支持什么事務(wù)的服務(wù)器、資源服務(wù)器以及事務(wù)管理器共有坐落相同的分布式系統(tǒng)的不同節(jié)點之上。目的是實現(xiàn)方法分布式事務(wù)，需要使用下面將能介紹的兩階段再提交協(xié)議。*階段一:結(jié)束向事務(wù)牽涉到到的全部資源發(fā)送中再提交前信息。此時，事務(wù)牽涉到的資源還有最后四次機會來異樣結(jié)束了事務(wù)。要是正二十邊形一個資源做出決定極其都結(jié)束了事務(wù)，則整個事務(wù)已取消，肯定不會并且資源的更新。要不然，事務(wù)將都正常負(fù)責(zé)執(zhí)行，就算發(fā)生了什么災(zāi)難性的失敗。目的是以免會發(fā)生災(zāi)難性的失敗，所有資源的更新都會寫入到日志中。這些日志是可以修復(fù)的，但，這些日志會無法幸免罹難因此在失敗的話之后這個可以原先對所有資源并且沒更新。*階段二:只在階段一沒有十分結(jié)束后的時候才會突然發(fā)生。此時，所有能被定位和另操縱的資源管理器都將又開始先執(zhí)行完全的數(shù)據(jù)更新。在分布式事務(wù)兩階段并提交協(xié)議中，有一個主事務(wù)管理器負(fù)責(zé)作為分布式事務(wù)協(xié)調(diào)器的角色。事務(wù)協(xié)調(diào)器共同負(fù)責(zé)整個事務(wù)并使之與網(wǎng)絡(luò)中的其他事務(wù)管理器協(xié)同工作。替基于分布式事務(wù)，可以使用一種協(xié)議在分布式事務(wù)的各個參與者之間訊息傳遞事務(wù)上下文信息，IIOP便是這種協(xié)議。這就特別要求相同開發(fā)商開發(fā)的事務(wù)參與者可以允許一種標(biāo)準(zhǔn)協(xié)議，才能實現(xiàn)方法分布式的事務(wù)。分布式事務(wù)處理(TP)系統(tǒng)旨在搭建全力協(xié)助在分布式環(huán)境中跨異類的事務(wù)識別資源的事務(wù)。在分布式TP系統(tǒng)的支持下，應(yīng)用程序也可以將完全不同的活動擴展為一個事務(wù)性單元，這些活動除開從消息隊列隊列數(shù)據(jù)庫檢索消息、將消息儲存在Microsoft SQL Server數(shù)據(jù)庫中、將所有超過的消息語句從Oracle Server數(shù)據(jù)庫中移除，等等。畢竟分布式事務(wù)跨多個數(shù)據(jù)庫資源，故滿ACID屬性維護所有資源上的數(shù)據(jù)一致性是很重要的是的。

適用于分布式唯一標(biāo)識碼的生成算法有哪些？

謝邀~

關(guān)與這個問題，有幾個方案和大家分享分享一下。

利用數(shù)據(jù)庫生成氣體先說最笨的方法，利用數(shù)據(jù)庫的自增長序列化合，數(shù)據(jù)庫內(nèi)唯一。

優(yōu)點：理解出聲最容易，用起來也最容易。

缺點：也太明顯了，每種數(shù)據(jù)庫的實現(xiàn)完全不同，要是數(shù)據(jù)庫是需要遷移到的話比較好各位；比較大的問題是性能問題，不太好擴展，假如并發(fā)大的時候，數(shù)據(jù)庫很可能會頂不住。

利用Redis/MongoDB/zookeeper化合Redis的單線程的，利用incr和increby；MongoDB的ObjectId；ZK是從znode數(shù)據(jù)版本；都可以生成全局的真正標(biāo)識碼。

優(yōu)點：性能不考慮數(shù)據(jù)庫；這個可以建議使用集群部署。

缺點：是需要化入不對應(yīng)的組件，增加系統(tǒng)的古怪度。

UUID這個是分布式架構(gòu)中，生成沉淀僅有標(biāo)識碼最常用的算法。

UUID有基于MAC地址的，再加時間和時鐘序列的，也有實現(xiàn)偽隨機數(shù)的，基于加密哈希的。

優(yōu)點：本地生成氣體，不要第三方組件，生成沉淀比較很簡單，性能好。

缺點：長度長，利于存儲，而且沒有排序，是個字符串，不利于查詢。解決雜亂無序問題，可做個參考Comb算法（combinedguid/timestamp）。

SnowflakeTwitter開源，基于組件zk，41位時間戳（10ms數(shù)）10位機器的ID12位1毫秒內(nèi)的流水號1位符號位（永遠(yuǎn)不會是0）。

優(yōu)點：性能還好，單機內(nèi)遞增。

缺點：感情依賴zk；感情依賴于機器時鐘，分布式環(huán)境內(nèi)很有可能會又不是全局趨近于。

UidGenerator百度開放源代碼，基于組件snowflake算法。

Leaf美團開源代碼。

優(yōu)點：能保證全局唯一性、高可用、趨勢遞增（不太不會有危險，.例如泄露公司訂單數(shù)量）、單調(diào)單調(diào)遞增等。

缺點：依然會依賴感第三方組件，zk或數(shù)據(jù)庫。

我將堅持了多多分享Java開發(fā)、架構(gòu)設(shè)計、程序員職業(yè)發(fā)展等方面的見解，希望能能得到你的關(guān)注。