什么時候需要分布式鎖？首先，我們需要知道在非分布式環(huán)境中，什么可以用鎖來解決？多線程環(huán)境，共享資源線程安全問題！此時，共享資源通常在一臺機(jī)器的多線程中競爭。從JAVA內(nèi)存模型的角度來看，我們可以通過鎖

什么時候需要分布式鎖？

首先，我們需要知道在非分布式環(huán)境中，什么可以用鎖來解決？

多線程環(huán)境，共享資源線程安全問題！此時，共享資源通常在一臺機(jī)器的多線程中競爭。從JAVA內(nèi)存模型的角度來看，我們可以通過鎖定對象、方法和代碼塊來避免共享資源的競爭

！1，生成全局ID；

2，修改全局配置文件；

3，分布式服務(wù)中的seckill；

4，分布式環(huán)境中的重復(fù)提交；

1，使用數(shù)據(jù)庫的唯一主鍵實現(xiàn)鎖定

！2、使用redis指令：通常使用setnx方法，incr方法實現(xiàn)

3、使用zookeeper：使用API生成臨時節(jié)點實現(xiàn)鎖定

MySQL分庫分表之后，id主鍵如何處理？

我將從存在的問題和如何做中回答這個問題。。

沒有辦法避免這個問題，通常拆分SQL，使用多個查詢，然后使用結(jié)果分別檢查結(jié)果

！我們可以使用TCC編程模型來確保兩個事務(wù)可以正確提交，但這種代碼入侵方式相對較重！您還可以使用基于消息的數(shù)據(jù)一致性保證

！1. 使用多線程分別查詢多個節(jié)點，然后匯總

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

現(xiàn)在分布式很流行。由于數(shù)據(jù)庫分布在不同的服務(wù)器上，如果采用傳統(tǒng)的自增長方式生成Id，很難保證不同數(shù)據(jù)庫上的Id不重復(fù)，存在業(yè)務(wù)影響的風(fēng)險

！可以說，唯一的標(biāo)識碼是分布式數(shù)據(jù)庫的第一個障礙

！我與distributed接觸多年，我遇到了許多生成唯一標(biāo)識碼的方法

！1，UUID：有很多算法，使用同一臺機(jī)器上生成的時間字節(jié)來區(qū)分同一臺機(jī)器上的不同id，使用IEEE機(jī)器識別號或IP地址來區(qū)分不同機(jī)器上的id，從而區(qū)分不同機(jī)器和同一臺機(jī)器，確保生成的UUID是全局唯一的

！Java有自己的UUID隨機(jī)UUID（）算法實現(xiàn)

！限制：生成的ID沒有序列

JAVA面試如何保證消息不被重復(fù)消費？如何保證消息消費的冪等性？

我沒事，來這里玩，開始在各種網(wǎng)絡(luò)上尋找技術(shù)信息，之后以“頭條”為主。從尋找信息到交朋友。因為我覺得事情落后于時代，有人認(rèn)為，是因為自己水平不高。只是在心里想，無法實現(xiàn)現(xiàn)實

請問對于數(shù)據(jù)庫的主鍵究竟要不要用自增id呢？

感謝您的邀請！此問題與特定的業(yè)務(wù)場景和技術(shù)實現(xiàn)有關(guān)：

1。業(yè)務(wù)場景：如訂單、付款單等敏感字段不能自動添加。它們是具有高安全級別的字段，需要一個唯一的ID作為主鍵。

2. 技術(shù)實現(xiàn)：在實際開發(fā)過程中，批量導(dǎo)入或處理數(shù)據(jù)時，需要考慮技術(shù)實現(xiàn)的性能，因此需要從多方面驗證是使用自增主鍵還是非自增主鍵。

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

兩種常用的分布式ID方法是UUID和snowflake算法。

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

該算法的核心思想是一個長ID：1位標(biāo)識符（始終為0）、41位時間戳毫秒、10位機(jī)器識別碼和12位序列號（毫秒）。從理論上講，該算法可以在一臺機(jī)器上每秒生成1000*（2^12）個ID，具有高性能、增長趨勢和高靈活性。然而，算法依賴于機(jī)器的操作時鐘。如果服務(wù)器倒計時，將生成重復(fù)的ID。