[發(fā)明專利]一種基于tooz的信號(hào)量的實(shí)現(xiàn)方法及裝置

在審

• 申請(qǐng)?zhí)枺?/td>: 202211257205.9
• 申請(qǐng)日: 2022-10-14
• 公開(kāi)（公告）號(hào): CN115599560A
• 公開(kāi)（公告）日: 2023-01-13
• 發(fā)明（設(shè)計(jì)）人: 申嘉童;宋偉;謝濤濤
• 申請(qǐng)（專利權(quán)）人: 浪潮云信息技術(shù)股份公司
• 主分類號(hào): G06F9/52
• 分類號(hào): G06F9/52;G06F9/54
• 代理公司: 濟(jì)南信達(dá)專利事務(wù)所有限公司 37100
• 代理人: 姜麗潔

本發(fā)明涉及云計(jì)算領(lǐng)域和計(jì)算機(jī)網(wǎng)絡(luò)領(lǐng)域，具體提供了一種基于tooz的信號(hào)量的實(shí)現(xiàn)方法，具有如下步驟：S1、對(duì)tooz的接口進(jìn)行改造，增加一個(gè)Semaphore類；S2、加鎖的方法acquire若加鎖成功則返回鎖對(duì)象L；S3、釋放鎖的方法release是將已經(jīng)成功獲取到的鎖進(jìn)行釋放的操作；S4、針對(duì)步驟s3中提到的acquire方法，獲取鎖的具體方法；S5、為防止加鎖的操作過(guò)于頻繁導(dǎo)致鎖服務(wù)的壓力過(guò)大，設(shè)置加鎖失敗的超時(shí)時(shí)間；S6、使用__exit__和__enter__方法，簡(jiǎn)化用戶的使用；S7、修改Agent端的RPC API的代碼，并調(diào)用使用信號(hào)量鎖加鎖。與現(xiàn)有技術(shù)相比，本發(fā)明通過(guò)tooz實(shí)現(xiàn)了一個(gè)信號(hào)量鎖，支持配置最大的并發(fā)量M，解決了tooz僅支持互斥鎖的缺陷。

技術(shù)領(lǐng)域

本發(fā)明涉及云計(jì)算領(lǐng)域和計(jì)算機(jī)網(wǎng)絡(luò)領(lǐng)域，具體提供一種基于tooz的信號(hào)量的實(shí)現(xiàn)方法及裝置。

背景技術(shù)

云計(jì)算技術(shù)因其原生的高擴(kuò)展性和高可用性，吸引了越來(lái)越多的企業(yè)選擇將自己的業(yè)務(wù)從線下機(jī)房的物理機(jī)上遷移到云數(shù)據(jù)中心上。OpenStack是一種開(kāi)源的云計(jì)算平臺(tái)的管理軟件。對(duì)于一個(gè)常見(jiàn)的OpenStack集群的部署，其集群中的節(jié)點(diǎn)根據(jù)功能不同一般分為控制節(jié)點(diǎn)、計(jì)算節(jié)點(diǎn)和網(wǎng)絡(luò)節(jié)點(diǎn)，其中控制節(jié)點(diǎn)運(yùn)行著管理服務(wù)，如：neutron-server、MySQL等；計(jì)算節(jié)點(diǎn)運(yùn)行著虛擬機(jī)和虛擬網(wǎng)絡(luò)的管理Agent，如網(wǎng)絡(luò)Agent、nova-computeAgent等；網(wǎng)絡(luò)節(jié)點(diǎn)一般運(yùn)行著NAT網(wǎng)關(guān)等網(wǎng)絡(luò)Agent。隨著技術(shù)的不斷成熟，OpenStack所管理的集群的容量已經(jīng)達(dá)到了1000以上。

集群規(guī)模的擴(kuò)張，對(duì)集群的管理帶來(lái)了更大的挑戰(zhàn)，其中一個(gè)是多網(wǎng)絡(luò)Agent的重啟對(duì)服務(wù)端neutron-server的壓力，當(dāng)前多Agent重啟的情況下，Agent之間并沒(méi)有進(jìn)行同步和并發(fā)量的限制，一般的思路是在neutron-server和其所在的控制節(jié)點(diǎn)進(jìn)行網(wǎng)絡(luò)限速、限制并發(fā)連接數(shù)等方案，這種方法雖然能夠限速，但是對(duì)Agent端不優(yōu)化，且Agent仍然會(huì)由于訪問(wèn)超時(shí)進(jìn)行重試，最終導(dǎo)致控制端的負(fù)載長(zhǎng)時(shí)間的飆高。

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

本發(fā)明是針對(duì)上述現(xiàn)有技術(shù)的不足，提供一種實(shí)用性強(qiáng)的基于tooz的信號(hào)量的實(shí)現(xiàn)方法。

本發(fā)明進(jìn)一步的技術(shù)任務(wù)是提供一種設(shè)計(jì)合理，安全適用的基于tooz的信號(hào)量的實(shí)現(xiàn)裝置。

本發(fā)明解決其技術(shù)問(wèn)題所采用的技術(shù)方案是：

一種基于tooz的信號(hào)量的實(shí)現(xiàn)方法，在已有tooz的基礎(chǔ)上，實(shí)現(xiàn)一個(gè)信號(hào)鎖；

具有如下步驟：

S1、對(duì)tooz的接口進(jìn)行改造，增加一個(gè)Semaphore類，所述Semaphore類至少實(shí)現(xiàn)兩個(gè)節(jié)點(diǎn)acquire和release，acquire實(shí)現(xiàn)一個(gè)加鎖的過(guò)程，所述release則是將當(dāng)前持有的鎖釋放；

S2、加鎖的方法acquire若加鎖成功則返回鎖對(duì)象L；

S3、釋放鎖的方法release是將已經(jīng)成功獲取到的鎖進(jìn)行釋放的操作；

S4、針對(duì)步驟s3中提到的acquire方法，獲取鎖的具體方法；

S5、為防止加鎖的操作過(guò)于頻繁導(dǎo)致鎖服務(wù)的壓力過(guò)大，設(shè)置加鎖失敗的超時(shí)時(shí)間；

S6、使用__exit__和__enter__方法，簡(jiǎn)化用戶的使用；

S7、修改Agent端的RPC API的代碼，并調(diào)用使用信號(hào)量鎖加鎖。

進(jìn)一步的，在步驟S1中，在通過(guò)類初始化實(shí)例時(shí)傳入鎖名稱和鎖的最大并發(fā)訪問(wèn)數(shù)M,所述M必須是一個(gè)正整數(shù)。

進(jìn)一步的，在步驟S2中，所述鎖對(duì)象L是復(fù)用tooz已有的鎖，入?yún)⒅袔в幸粋€(gè)可選的超時(shí)參數(shù)timeout，默認(rèn)配置為無(wú)限，即在沒(méi)有獲取鎖的情況下，進(jìn)行無(wú)限期的等待；