數(shù)據(jù)更新的加鎖方法和設備的制作方法
【專利摘要】本申請涉及一種多線程的數(shù)據(jù)更新的加鎖方法和設備，其中，該方法可以包括：確定對InnoDB存儲引擎中要更新的線程進行加鎖的請求是否成功；如果所述加鎖請求失敗，則判斷所述等待鎖數(shù)是否超過預定閾值；如果所述等待鎖數(shù)沒有超過預定閾值，則創(chuàng)建針對所述失敗線程的鎖并等待加鎖；如果所述等待鎖數(shù)超過預定閾值，則將所述加鎖失敗線程調(diào)度出InnoDB存儲引擎并將其哈希到各個桶中；將相同桶中的加鎖失敗線程以輪詢的方式傳送到InnoDB存儲引擎以請求加鎖。采用本申請，通過利用鎖競爭的情況來識別并發(fā)更新的熱點數(shù)據(jù)，從而對并發(fā)更新熱點數(shù)據(jù)的線程進行調(diào)度控制，進而優(yōu)化了高并發(fā)熱點數(shù)據(jù)更新的處理能力。
【專利說明】數(shù)據(jù)更新的加鎖方法和設備

【技術(shù)領域】
[0001]本申請涉及數(shù)據(jù)處理領域，更具體地涉及一種針對多線程的數(shù)據(jù)更新進行處理的方法和設備。

【背景技術(shù)】
[0002]在計算領域中，InnoDB存儲引擎是MySQL的數(shù)據(jù)庫引擎之一，是其中使用最頻繁的一種引擎，InnoDB存儲引擎由Innobase Oy公司所開發(fā)。InnoDB支持回滾、崩潰恢復能力、多版本并發(fā)控制、ACID事務，支持行級鎖定等功能，已經(jīng)成為MySQL的默認存儲引擎。InnoDB存儲引擎作為MySQL的一個可插拔的引擎，其支持事務，并且采用多版本并發(fā)控制的方式來提高并發(fā)度。MySQL的InnoDB存儲引擎是基于行記錄鎖粒度，在對單條記錄并發(fā)更新時，并發(fā)的線程變?yōu)榇谢?。由于IrmoDB的鎖設計問題，導致每個請求的事務在InnoDB存儲引擎做創(chuàng)建一個行記錄鎖。當有大量并發(fā)的線程更新記錄時，會導致InnoDB存儲引擎的鎖對象非常多，巨大的鎖操作的額外開銷導致性能下降非常嚴重。因此，例如，在高并發(fā)的熱點行記錄變更時，MySQL數(shù)據(jù)庫的InnoDB存儲引擎性能非常差。例如，2K并發(fā)更新16條記錄性能有1k TPS，但是2K并發(fā)更新20條記錄性能只有250的TPS。
[0003]對于這種熱點行記錄并發(fā)更新的場景，通常的做法為:
[0004]1.在業(yè)務方識別熱點行記錄加以控制，這要求業(yè)務邏輯中對更新的行能夠識別。這種做法對業(yè)務的侵入較大，并且不通用。另外，在集群環(huán)境下，即使業(yè)務方做控制，也有可能在某個數(shù)據(jù)庫服務器上的并發(fā)訪問量非常大。
[0005]2.在數(shù)據(jù)庫層識別熱點行記錄加以控制，這要求數(shù)據(jù)庫本身能識別熱點行的功能。類似典型的KV (鍵值)存儲系統(tǒng)，每個操作都帶有當前行記錄的標記。類似系統(tǒng)能夠?qū)⒉l(fā)的行記錄訪問加以控制，將相同行的記錄放在相同的隊列中，從而避免熱點行記錄并發(fā)量過大的問題。但是該方法對于非KV存儲系統(tǒng)而言是無能為力的。
[0006]因此，需要一種針對多線程的數(shù)據(jù)更新尤其是數(shù)據(jù)并發(fā)更新的加鎖方法和設備。通過該加鎖方法和設備，能夠在InnoDB存儲引擎識別并發(fā)更新的熱點數(shù)據(jù)并對其線程進行調(diào)度控制從而實現(xiàn)改善的加鎖過程，提高InnoDB存儲引擎的性能。


【發(fā)明內(nèi)容】

[0007]因此，本申請的目的在于提供一種針對多線程的數(shù)據(jù)并發(fā)更新的加鎖技術(shù)，以克服上述缺陷。
[0008]根據(jù)本申請一個方面的實施例，提供一種多線程的數(shù)據(jù)更新的加鎖方法，其特征在于，包括:確定對InnoDB存儲引擎中要更新的線程進行加鎖的請求是否成功；如果所述加鎖請求失敗，則判斷所述等待鎖數(shù)是否超過預定閾值；如果所述等待鎖數(shù)沒有超過預定閾值，則創(chuàng)建針對所述失敗線程的鎖并等待加鎖；如果所述等待鎖數(shù)超過預定閾值，則將所述加鎖失敗線程調(diào)度出InnoDB存儲引擎并將其哈希到各個桶中；將相同桶中的加鎖失敗線程以輪詢的方式傳送到InnoDB存儲引擎以請求加鎖。
[0009]根據(jù)本申請的實施例，該方法可以進一步包括:如果所述加鎖請求成功，則創(chuàng)建針對成功線程的鎖并執(zhí)行加鎖。
[0010]根據(jù)本申請的實施例，該方法可以進一步包括:在執(zhí)行加鎖并對加鎖的線程執(zhí)行事務后，釋放鎖。
[0011]根據(jù)本申請的實施例，該方法可以進一步包括:通過基于所述鎖的釋放從而等待加鎖的加鎖失敗線程轉(zhuǎn)換成加鎖狀態(tài)，更新等待鎖數(shù)。
[0012]根據(jù)本申請的實施例，在該方法中，創(chuàng)建針對所述失敗線程的鎖并等待加鎖的步驟還可以包括:基于創(chuàng)建針對所述失敗線程的鎖并等待加鎖，更新等待鎖數(shù)。
[0013]根據(jù)本申請的實施例，在該方法中，將所述加鎖失敗線程調(diào)度出InnoDB存儲引擎并將其哈希到各個桶中的步驟進一步包括:基于所述失敗線程的鎖信息的哈希值哈希到各個桶中，其中相同記錄的失敗線程的鎖信息的哈希值相同，從而哈希到相同的桶中。
[0014]根據(jù)本申請的實施例，該方法進一步包括:將不同桶中的加鎖失敗線程以并行的方式傳送到InnoDB存儲引擎以請求加鎖。
[0015]根據(jù)本申請另一方面的實施例，提供一種多線程的數(shù)據(jù)更新的加鎖設備，其特征在于，包括:請求確定模塊，用于確定對InnoDB存儲引擎中要更新的線程進行加鎖的請求是否成功；判斷模塊，用于如果所述加鎖請求失敗，則判斷所述等待鎖數(shù)是否超過預定閾值；鎖創(chuàng)建模塊，用于如果所述等待鎖數(shù)沒有超過預定閾值，則創(chuàng)建針對所述失敗線程的鎖并等待加鎖；調(diào)度模塊，用于如果所述等待鎖數(shù)超過預定閾值，則將所述加鎖失敗線程調(diào)度出InnoDB存儲引擎并將其哈希到各個桶中；傳送模塊，用于將不同桶中的加鎖失敗線程以并行的方式傳送到InnoDB存儲引擎并且將相同桶中的加鎖失敗線程以輪詢的方式傳送到InnoDB存儲引擎以請求加鎖。
[0016]與現(xiàn)有技術(shù)相比，根據(jù)本申請的技術(shù)方案，通過利用鎖競爭的情況來識別并發(fā)更新的熱點數(shù)據(jù)，從而對并發(fā)更新熱點數(shù)據(jù)的線程進行調(diào)度控制，進而優(yōu)化了高并發(fā)熱點數(shù)據(jù)更新的處理能力。

【專利附圖】

【附圖說明】
[0017]此處所說明的附圖用來提供對本申請的進一步理解，構(gòu)成本申請的一部分，本申請的示意性實施例及其說明用于解釋本申請，并不構(gòu)成對本申請的不當限定。在附圖中:
[0018]圖1示出了根據(jù)本申請實施例的多線程的數(shù)據(jù)并發(fā)更新的加鎖方法的流程圖；以及
[0019]圖2示出了根據(jù)本申請實施例的多線程的數(shù)據(jù)并發(fā)更新的加鎖設備的框圖。

【具體實施方式】
[0020]為使本申請的目的、技術(shù)方案和優(yōu)點更加清楚,下面將結(jié)合本申請具體實施例及相應的附圖對本申請技術(shù)方案進行清楚、完整地描述。顯然，所描述的實施例僅是本申請一部分實施例，而不是全部的實施例?；诒旧暾堉械膶嵤├?，本領域普通技術(shù)人員在沒有做出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都屬于本申請保護的范圍。
[0021]參考圖1，圖1示出了根據(jù)本申請實施例的多線程的數(shù)據(jù)并發(fā)更新的加鎖方法的流程圖。
[0022]在步驟SllO處，確定對InnoDB存儲引擎中要更新的線程進行加鎖的請求是否成功。
[0023]具體而言，例如，多個線程對于同一數(shù)據(jù)(例如，同一熱點行記錄)進行并發(fā)更新，則該多個線程進入InnoDB存儲引擎，請求加鎖。因此，在InnoDB存儲引擎中，確定該多個線程進行加鎖請求是否成功。
[0024]在步驟S120處，如果所述加鎖請求失敗，則判斷所述等待鎖數(shù)是否超過預定閾值。
[0025]具體而言，在InnoDB存儲引擎中，由于加鎖是單行的，假如多個線程對于同一熱點行記錄進行并發(fā)更新，則多個線程中的大部分線程的加鎖請求將失敗。因此，如果加鎖請求失敗，則在該方法中，將判斷等待鎖數(shù)是否超過預定閾值。
[0026]在步驟S130處，如果所述等待鎖數(shù)沒有超過預定閾值，則創(chuàng)建針對所述失敗線程的鎖并等待加鎖。也即是說，創(chuàng)建該鎖，并且等待持有鎖的事務完成后授予該所于當前事務。
[0027]例如，假設預訂閾值為N，并且假設有一個線程請求成功，該線程處于加鎖中，并且另外有M個線程處于等待加鎖狀態(tài)，則等待鎖數(shù)為M，且M小于等于N，而此時有一個線程請求加鎖失敗，這時候判斷等待鎖數(shù)沒有超過預定閾值，因此針對該加鎖失敗線程創(chuàng)建鎖并且等待加鎖。
[0028]在步驟S130處，還可以進一步包括步驟:基于創(chuàng)建針對所述加鎖請求失敗線程的鎖并等待加鎖，更新等待鎖數(shù)。也即是說，每創(chuàng)建一個針對所述加鎖請求失敗線程的鎖并等待時，等待鎖數(shù)就加一。
[0029]繼續(xù)上面的例子，在步驟S130處請求加鎖失敗的線程處于等待加鎖狀態(tài)，因此將該加鎖失敗線程掛起，并且等待鎖數(shù)加1，從而更新后的等待鎖數(shù)為M+1。
[0030]在步驟S140處，如果所述等待鎖數(shù)超過預定閾值，則將所述加鎖失敗線程調(diào)度出InnoDB存儲引擎并將其哈希到各個桶(bucket)中。
[0031]具體而言，例如，繼續(xù)上面的例子，例如再有一個線程請求加鎖，并且由于已經(jīng)有線程加鎖成功并且事務在執(zhí)行中，因此該線程的加鎖請求失敗，判斷等待鎖數(shù)是否超過預定閾值。而此時等待鎖數(shù)為M+1，假設M+1大于N，則判斷出來等待鎖數(shù)超過預定閾值N，因此將該加鎖失敗線程調(diào)度出InnoDB存儲引擎。接著，基于該加鎖失敗線程的鎖信息將其哈希到各個桶中。
[0032]在步驟S150處，將相同桶中的加鎖失敗線程以輪詢的方式傳送到InnoDB存儲引擎以請求加鎖。
[0033]具體而言，基于所述失敗線程的鎖信息的哈希值哈希到各個桶中，其中相同記錄的失敗線程的鎖信息的哈希值相同，從而哈希到相同的桶中。不同記錄的失敗線程由于鎖信息的哈希值不同，從而將會被哈希到不同的桶中。因此，對于哈希到相同桶中的失敗線程，例如針對相同熱點記錄的線程，該方法將采用輪詢的方式將其再傳送到InnoDB存儲引擎以請求加鎖。從而，解決了 IrmoDB存儲引擎性能下降的問題。此外，在該步驟中，還可以將不同桶中的加鎖失敗線程以并行的方式傳送到InnoDB存儲引擎以請求加鎖。
[0034]在步驟S160處，如果所述加鎖請求成功，則創(chuàng)建針對加鎖成功線程的鎖。
[0035]具體而言，當線程請求加鎖時，沒有線程處于加鎖成功狀態(tài)，則加鎖請求成功，從而針對該成功加鎖線程創(chuàng)建鎖，然后執(zhí)行加鎖。
[0036]在步驟S160處，還可以進一步對加鎖的線程執(zhí)行事務，在事務執(zhí)行完成之后，釋放鎖。也即是說，加鎖的線程在事務完成之后，將把鎖進行釋放。接著還可以通過基于所述鎖的釋放從而等待加鎖的加鎖失敗線程轉(zhuǎn)換成加鎖狀態(tài)，更新等待鎖數(shù)。也即是說，每釋放一個針對所述加鎖請求成功線程的鎖并且等待加鎖的加鎖請求失敗線程轉(zhuǎn)換成加鎖時，從而處于等待加鎖狀態(tài)的線程將變成加鎖成功，從而等待加鎖的線程將減少一個，將等待鎖數(shù)減一。
[0037]為了更好地理解本申請的方法，下面我們舉一個具體的實施例以使更清楚地描述本申請的加鎖方法。
[0038]例如，有1000個線程并發(fā)更新同一條記錄。1000個線程進入InnoDB存儲引擎中請求加鎖。例如，設置預定的等待鎖數(shù)的閾值為4。
[0039]例如，假設線程I請求加鎖，而此時沒有任何線程在加鎖，因此，線程I的加鎖請求成功，則針對線程I創(chuàng)建鎖，并且完成加鎖，事務在執(zhí)行中。
[0040]假設在這個時候線程2請求加鎖，由于加鎖是串行的，而此時線程I的狀態(tài)是鎖被占用并且事務執(zhí)行中的狀態(tài)，所以線程2的加鎖請求失敗，因此流程進入步驟120進行等待鎖數(shù)的判斷。由于閾值為4，目前等待鎖數(shù)為0，等待鎖數(shù)未超過閾值，因此，針對失敗線程(線程2)創(chuàng)建鎖，并且等待加鎖，同時更新等待鎖數(shù)。也即是說，等待鎖數(shù)加1，從而等待鎖數(shù)變成I。
[0041]假設線程3、線程4、線程5、線程6也與線程2 —樣請求加鎖，也由于線程I加鎖請求成功，從而線程3-6的請求也失敗，并且閾值沒有超過4，因此針對線程3-6也創(chuàng)建鎖，并且等待加鎖，同時等待鎖數(shù)也被更新為4。
[0042]假設這時線程7請求加鎖，同樣由于加鎖失敗，因此判斷等待鎖數(shù)是否超過閾值，現(xiàn)在等待鎖數(shù)為4，已經(jīng)等于閾值，因此不會針對失敗線程(線程6)創(chuàng)建鎖并等待。而是將線程6調(diào)度出InnoDB存儲引擎。并且根據(jù)線程6的鎖信息的哈希值將其哈希到桶中。
[0043]同理，例如，線程7-10請求加鎖并且請求加鎖失敗，并且由于等待鎖數(shù)等于或大于閾值，因此線程7-10也都被調(diào)度出InnoDB存儲引擎。并且，由于線程7_10與線程6都是針對相同的記錄請求加鎖，因此它們的鎖信息的哈希值相同，從而它們將會被哈希到相同的桶中。
[0044]對于在桶中的線程6-10，會再次回到InnoDB存儲引擎進行加鎖。為了防止熱點記錄并發(fā)更新導致加鎖失敗的問題，這時，規(guī)定相同桶中的線程采取輪詢方式傳送到InnoDB存儲引擎。具體而言，假設線程6-10依次在同一個桶中排隊，首先將線程6傳送回InnoDB存儲引擎，進行加鎖請求，如果請求失敗并且等待鎖數(shù)仍然大于或等于閾值，則它重新被調(diào)度出InnoDB存儲引擎并回到線程7_10的桶中，此時，線程6將排隊在線程10之后，順次等待再次進入InnoDB存儲引擎。按照排列順序，則下一次將線程7傳送回InnoDB存儲引擎，進入加鎖請求，如果請求失敗但是等待鎖數(shù)小于閾值，則針對線程7創(chuàng)建鎖，并且等待加鎖。按照排列順序，下一次將線程8傳回InnoDB存儲引擎，重復同樣的操作。如果輪詢的過程超過一個預定的周期，例如所有線程都輪詢過10次之后，則將桶內(nèi)的所有線程強制全部發(fā)送回InnoDB存儲引擎進行加鎖請求。
[0045]以上各個段落中關(guān)于多個線程針對同一熱點數(shù)據(jù)并發(fā)更新僅為本申請的可選示例，本申請不限于此，而是還可以適用于任何數(shù)據(jù)并發(fā)更新。
[0046]至此，已經(jīng)描述了本申請實施例的多線程的數(shù)據(jù)并發(fā)更新的加鎖方法的流程圖。
[0047]根據(jù)本申請的實施例，還提供一種多線程的數(shù)據(jù)并發(fā)更新的加鎖設備200，如圖2所示，圖2為根據(jù)本申請實施例的多線程的數(shù)據(jù)更新的加鎖設備的結(jié)構(gòu)框圖。該設備可以包括:請求確定模塊210、判斷模塊220、鎖創(chuàng)建模塊230、調(diào)度模塊240、以及傳送模塊250。
[0048]根據(jù)本申請實施例的設備，請求接收模塊可以用于接收對InnoDB存儲引擎中要更新的線程進行加鎖的請求。判斷模塊可以用于如果所述加鎖請求失敗，則判斷所述等待鎖數(shù)是否超過預定閾值。第一鎖創(chuàng)建模塊可以用于如果所述等待鎖數(shù)沒有超過預定閾值，則創(chuàng)建針對所述失敗線程的鎖并等待加鎖。調(diào)度模塊可以用于如果所述等待鎖數(shù)超過預定閾值，則將所述加鎖失敗線程調(diào)度出InnoDB存儲引擎并將其哈希到各個桶中。傳送模塊可以用于將相同桶中的加鎖失敗線程以輪詢的方式傳送到IrmoDB存儲引擎以請求加鎖。
[0049]根據(jù)本申請實施例的設備，鎖創(chuàng)建模塊230可以進一步用于:如果所述加鎖請求成功，則創(chuàng)建針對成功線程的鎖并執(zhí)行加鎖。
[0050]根據(jù)本申請實施例的設備，鎖創(chuàng)建模塊230可以進一步包括鎖釋放子模塊261，其可以用于在執(zhí)行加鎖并對加鎖的線程執(zhí)行事務后，釋放鎖。
[0051]根據(jù)本申請實施例的設備，所述鎖創(chuàng)建模塊230可以進一步包括更新子模塊，用于通過基于所述鎖的釋放從而等待加鎖的加鎖失敗線程轉(zhuǎn)換成加鎖狀態(tài)，更新等待鎖數(shù)。也即是說，每釋放一個針對所述加鎖請求成功線程的鎖并且等待加鎖的加鎖請求失敗線程轉(zhuǎn)換成加鎖時，等待鎖數(shù)就減一。
[0052]根據(jù)本申請實施例的設備，鎖創(chuàng)建模塊230還可以包括:更新子模塊231，用于基于創(chuàng)建針對所述加鎖請求失敗線程的鎖并等待加鎖，更新等待鎖數(shù)，也即是說，每創(chuàng)建一個針對所述加鎖請求失敗線程的鎖并等待時，等待鎖數(shù)就加一。
[0053]根據(jù)本申請實施例的設備，調(diào)度模塊240可以進一步包括哈希子模塊232，用于基于所述失敗線程的鎖信息的哈希值哈希到各個桶中，其中相同記錄的失敗線程的鎖信息的哈希值相同，從而哈希到相同的桶中。
[0054]根據(jù)本申請實施例的設備，傳送模塊250可以進一步被配置成將不同桶中的加鎖失敗線程以并行的方式傳送到IrmoDB存儲引擎以請求加鎖。
[0055]由于本實施例的設備所實現(xiàn)的功能基本相應于前述圖1所示的方法實施例，故本實施例的描述中未詳盡之處，可以參見前述實施例中的相關(guān)說明，在此不做贅述。
[0056]在一個典型的配置中，計算設備包括一個或多個處理器(CPU)、輸入/輸出接口、網(wǎng)絡接口和內(nèi)存。
[0057]內(nèi)存可能包括計算機可讀介質(zhì)中的非永久性存儲器，隨機存取存儲器(RAM)和/或非易失性內(nèi)存等形式，如只讀存儲器(ROM)或閃存(flash RAM)。內(nèi)存是計算機可讀介質(zhì)的示例。
[0058]計算機可讀介質(zhì)包括永久性和非永久性、可移動和非可移動媒體可以由任何方法或技術(shù)來實現(xiàn)信息存儲。信息可以是計算機可讀指令、數(shù)據(jù)結(jié)構(gòu)、程序的模塊或其他數(shù)據(jù)。計算機的存儲介質(zhì)的例子包括，但不限于相變內(nèi)存(PRAM)、靜態(tài)隨機存取存儲器(SRAM)、動態(tài)隨機存取存儲器(DRAM)、其他類型的隨機存取存儲器(RAM)、只讀存儲器(ROM)、電可擦除可編程只讀存儲器(EEPROM)、快閃記憶體或其他內(nèi)存技術(shù)、只讀光盤只讀存儲器(CD-ROM)、數(shù)字多功能光盤(DVD)或其他光學存儲、磁盒式磁帶，磁帶磁磁盤存儲或其他磁性存儲設備或任何其他非傳輸介質(zhì)，可用于存儲可以被計算設備訪問的信息。按照本文中的界定，計算機可讀介質(zhì)不包括暫存電腦可讀媒體(transitory media),如調(diào)制的數(shù)據(jù)信號和載波。
[0059]還需要說明的是，術(shù)語“包括”、“包含”或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、商品或者設備不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、商品或者設備所固有的要素。在沒有更多限制的情況下，由語句“包括一個……”限定的要素，并不排除在包括所述要素的過程、方法、商品或者設備中還存在另外的相同要素。
[0060]本領域技術(shù)人員應明白，本申請的實施例可提供為方法、系統(tǒng)或計算機程序產(chǎn)品。因此，本申請可采用完全硬件實施例、完全軟件實施例或結(jié)合軟件和硬件方面的實施例的形式。而且，本申請可采用在一個或多個其中包含有計算機可用程序代碼的計算機可用存儲介質(zhì)(包括但不限于磁盤存儲器、CD-ROM、光學存儲器等)上實施的計算機程序產(chǎn)品的形式。
[0061]以上所述僅為本申請的實施例而已，并不用于限制本申請。對于本領域技術(shù)人員來說，本申請可以有各種更改和變化。凡在本申請的精神和原理之內(nèi)所作的任何修改、等同替換、改進等，均應包含在本申請的權(quán)利要求范圍之內(nèi)。
【權(quán)利要求】
1.一種多線程的數(shù)據(jù)更新的加鎖方法，其特征在于，包括: 確定對Inn0DB存儲引擎中要更新的線程進行加鎖的請求是否成功； 如果所述加鎖請求失敗，則判斷所述等待鎖數(shù)是否超過預定閾值； 如果所述等待鎖數(shù)沒有超過預定閾值，則創(chuàng)建針對所述失敗線程的鎖并等待加鎖； 如果所述等待鎖數(shù)超過預定閾值，則將所述加鎖失敗線程調(diào)度出InnoDB存儲引擎并將其哈希到各個桶中； 將相同桶中的加鎖失敗線程以輪詢的方式傳送到IrmoDB存儲引擎以請求加鎖。
2.根據(jù)權(quán)利要求1所述的方法，其特征在于，進一步包括: 如果所述加鎖請求成功，則創(chuàng)建針對成功線程的鎖并執(zhí)行加鎖。
3.根據(jù)權(quán)利要求2所述的方法，其特征在于，進一步包括:在執(zhí)行加鎖并對加鎖的線程執(zhí)行事務后，釋放鎖。
4.根據(jù)權(quán)利要求3所述的方法，其特征在于，還包括:通過基于所述鎖的釋放從而等待加鎖的加鎖失敗線程轉(zhuǎn)換成加鎖狀態(tài)，更新等待鎖數(shù)。
5.根據(jù)權(quán)利要求1-4任一項所述的方法，其特征在于，創(chuàng)建針對所述失敗線程的鎖并等待加鎖的步驟還包括:基于創(chuàng)建針對所述失敗線程的鎖并等待加鎖，更新等待鎖數(shù)。
6.根據(jù)權(quán)利要求1-4任一項所述的方法，其特征在于，將所述加鎖失敗線程調(diào)度出InnoDB存儲引擎并將其哈希到各個桶中的步驟進一步包括: 基于所述失敗線程的鎖信息的哈希值哈希到各個桶中，其中相同記錄的失敗線程的鎖信息的哈希值相同，從而哈希到相同的桶中。
7.根據(jù)權(quán)利要求1-4任一項所述的方法，其特征在于，進一步包括: 將不同桶中的加鎖失敗線程以并行的方式傳送到InnoDB存儲引擎以請求加鎖。
8.一種多線程的數(shù)據(jù)更新的加鎖設備，其特征在于，包括: 請求確定模塊，用于確定對InnoDB存儲引擎中要更新的線程進行加鎖的請求是否成功； 判斷模塊，用于如果所述加鎖請求失敗，則判斷所述等待鎖數(shù)是否超過預定閾值； 鎖創(chuàng)建模塊，用于如果所述等待鎖數(shù)沒有超過預定閾值，則創(chuàng)建針對所述失敗線程的鎖并等待加鎖； 調(diào)度模塊，用于如果所述等待鎖數(shù)超過預定閾值，則將所述加鎖失敗線程調(diào)度出InnoDB存儲引擎并將其哈希到各個桶中； 傳送模塊，用于將不同桶中的加鎖失敗線程以并行的方式傳送到InnoDB存儲引擎并且將相同桶中的加鎖失敗線程以輪詢的方式傳送到IrmoDB存儲引擎以請求加鎖。
9.根據(jù)權(quán)利要求8所述的設備，其特征在于，所述鎖創(chuàng)建模塊進一步用于如果所述加鎖請求成功，則創(chuàng)建針對成功線程的鎖并執(zhí)行加鎖。
10.根據(jù)權(quán)利要求9所述的設備，其特征在于，所述鎖創(chuàng)建模塊進一步包括:鎖釋放子模塊，用于在執(zhí)行加鎖并對加鎖的線程執(zhí)行事務后，釋放鎖。
11.根據(jù)權(quán)利要求10所述的設備，其特征在于，所述鎖創(chuàng)建模塊還包括更新子模塊，用于通過基于所述鎖的釋放從而等待加鎖的加鎖失敗線程轉(zhuǎn)換成加鎖狀態(tài)，更新等待鎖數(shù)。
12.根據(jù)權(quán)利要求8-11任一項所述的設備，其特征在于，所述鎖創(chuàng)建模塊還包括更新子模塊，用于基于創(chuàng)建針對所述失敗線程的鎖并等待加鎖，更新等待鎖數(shù)。
13.根據(jù)權(quán)利要求8-11任一項所述的設備，其特征在于，調(diào)度模塊進一步包括: 哈希子模塊，用于基于所述失敗線程的鎖信息的哈希值哈希到各個桶中，其中相同記錄的失敗線程的鎖信息的哈希值相同，從而哈希到相同的桶中。
14.根據(jù)權(quán)利要求8-11任一項所述的設備，其特征在于，傳送模塊進一步被配置成:將不同桶中的加鎖失敗線程以并行的方式傳送到InnoDB存儲引擎以請求加鎖。
【文檔編號】G06F9/48GK104252386SQ201310259869
【公開日】2014年12月31日 申請日期:2013年6月26日 優(yōu)先權(quán)日:2013年6月26日
【發(fā)明者】劉輝 申請人:阿里巴巴集團控股有限公司