本發(fā)明屬于互聯(lián)網(wǎng)領(lǐng)域，具體而言，涉及一種購買操作共享方法及裝置。

背景技術(shù)：

隨著互聯(lián)網(wǎng)的普及，網(wǎng)購在人們生活中的使用越來越普遍化?，F(xiàn)有的網(wǎng)購方式大多為每一個用戶對應(yīng)于一個購物車，即不同用戶的購買操作是相互獨立存在的，無法實現(xiàn)多個用戶共享同一個購買操作。例如，網(wǎng)上點餐時，由于不同用戶的購買操作是相互獨立存在的，無法實現(xiàn)多個用戶共享同一個購買操作，當(dāng)相互認識的多個人想要在同一個商家一起點餐時，大多會事先根據(jù)該商家所包括的菜品商量出需要點的菜品以及相應(yīng)的數(shù)量，然后再由其中一個人根據(jù)商量結(jié)果構(gòu)建購買操作并下單?；蛘撸扔善渲幸粋€人單獨構(gòu)建購買操作后，將其構(gòu)建的購買操作分享給其他人，其他人按照事先商量好的順序依次基于已存在的購買操作構(gòu)建新的購買操作，并也將各自構(gòu)建的購買操作分享給其他人，當(dāng)每一個人對其他人的購買操作均無異議時，分別對自己構(gòu)建的購買操作下單。

技術(shù)實現(xiàn)要素：

本發(fā)明的目的在于提供一種購買操作共享方法及裝置，能夠?qū)崿F(xiàn)多個客戶端共享一個購買操作。

第一方面，本發(fā)明實施例提供了一種購買操作共享方法，所述方法包括：獲取多個客戶端發(fā)送的購買訂單，其中，每個所述客戶端均與當(dāng)前購買操作綁定；根據(jù)所獲取的多個所述購買訂單生成一個購買總訂單。

第二方面，本發(fā)明實施例還提供了一種購買操作共享裝置，所述裝置包括：訂單獲取模塊及總訂單生成模塊。訂單獲取模塊用于獲取多個客戶端發(fā)送的購買訂單，其中，每個客戶端均與當(dāng)前購買操作綁定?？傆唵紊赡K用于根據(jù)所獲取的多個所述購買訂單生成一個購買總訂單。

本發(fā)明實施例提供的購買操作共享方法及裝置通過獲取多個客戶端發(fā)送的購買訂單，其中，每個客戶端均與當(dāng)前購買操作綁定，根據(jù)所獲取的多個所述購買訂單生成一個購買總訂單，有效地實現(xiàn)了多個客戶端共享同一個購買操作，即可以實現(xiàn)多個用戶共享同一個購物操作。

附圖說明

為了更清楚地說明本發(fā)明實施例或現(xiàn)有技術(shù)中的技術(shù)方案，下面將對實施例中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本發(fā)明的一些實施例，對于本領(lǐng)域普通技術(shù)人員來講，在不付出創(chuàng)造性勞動的前提下，還可以根據(jù)這些附圖獲得其他的附圖。通過附圖所示，本發(fā)明的上述及其它目的、特征和優(yōu)勢將更加清晰。在全部附圖中相同的附圖標(biāo)記指示相同的部分。并未刻意按實際尺寸等比例縮放繪制附圖，重點在于示出本發(fā)明的主旨。

圖1為本發(fā)明一實施例提供的一種購買操作共享系統(tǒng)的交互示意圖；

圖2為本發(fā)明一實施例提供的服務(wù)器的結(jié)構(gòu)框圖；

圖3為本發(fā)明一實施例提供的一種購買操作共享方法的方法流程圖；

圖4為本發(fā)明另一實施例提供的一種購買操作共享方法的方法流程圖；

圖5為本發(fā)明另一實施例提供的一種購買操作共享方法的方法流程圖；

圖6為本發(fā)明另一實施例提供的一種購買操作共享方法的方法流程圖；

圖7為本發(fā)明另一實施例提供的一種購買操作共享方法的方法流程圖；

圖8為本發(fā)明另一實施例提供的一種購買操作共享系統(tǒng)的交互示意圖；

圖9為本發(fā)明另一實施例提供的一種購買操作共享方法的方法流程圖；

圖10為本發(fā)明一實施例提供的一種購買操作共享裝置的結(jié)構(gòu)框圖；

圖11為本發(fā)明另一實施例提供的一種購買操作共享裝置的結(jié)構(gòu)框圖；

圖12為本發(fā)明另一實施例提供的一種購買操作共享裝置的結(jié)構(gòu)框圖；

圖13為本發(fā)明另一實施例提供的一種購買操作共享裝置的結(jié)構(gòu)框圖；

圖14為本發(fā)明另一實施例提供的一種購買操作共享裝置的結(jié)構(gòu)框圖；

圖15為本發(fā)明另一實施例提供的一種購買操作共享裝置的結(jié)構(gòu)框圖。

具體實施方式

下面將結(jié)合本發(fā)明實施例中附圖，對本發(fā)明實施例中的技術(shù)方案進行清楚、完整地描述，顯然，所描述的實施例僅僅是本發(fā)明一部分實施例，而不是全部的實施例。通常在此處附圖中描述和示出的本發(fā)明實施例的組件可以以各種不同的配置來布置和設(shè)計。因此，以下對在附圖中提供的本發(fā)明的實施例的詳細描述并非旨在限制要求保護的本發(fā)明的范圍，而是僅僅表示本發(fā)明的選定實施例。基于本發(fā)明的實施例，本領(lǐng)域技術(shù)人員在沒有做出創(chuàng)造性勞動的前提下所獲得的所有其他實施例，都屬于本發(fā)明保護的范圍。

應(yīng)注意到：相似的標(biāo)號和字母在下面的附圖中表示類似項，因此，一旦某一項在一個附圖中被定義，則在隨后的附圖中不需要對其進行進一步定義和解釋。同時，在本發(fā)明的描述中，術(shù)語“第一”、“第二”等僅用于區(qū)分描述，而不能理解為指示或暗示相對重要性。

請參閱圖1，示出了一種購買操作共享系統(tǒng)。購買操作共享系統(tǒng)包括服務(wù)器100及多個客戶端200。其中，客戶端200可以是網(wǎng)頁客戶端，也可以是應(yīng)用程序客戶端。當(dāng)多個客戶端200均與服務(wù)器100之間的正常網(wǎng)絡(luò)連接時，多個客戶端200均能夠與服務(wù)器100進行數(shù)據(jù)交互。

如圖2所示，是所述服務(wù)器100的方框示意圖。所述服務(wù)器100包括購買操作共享裝置110、存儲器120、存儲控制器130、處理器140及外設(shè)接口150。

所述存儲器120、存儲控制器130、處理器140、外設(shè)接口150各元件相互之間直接或間接地電性連接，以實現(xiàn)數(shù)據(jù)的傳輸或交互。例如，這些元件相互之間可通過一條或多條通訊總線或信號線實現(xiàn)電性連接。所述購買操作共享裝置110包括至少一個可以軟件或固件(firmware)的形式存儲于所述存儲器120中或固化在所述服務(wù)器的操作系統(tǒng)(operating system，OS)中的軟件功能模塊。所述處理器140用于執(zhí)行存儲器中存儲的可執(zhí)行模塊，例如所述購買操作共享裝置110包括的軟件功能模塊或計算機程序。

其中，存儲器120可以是，但不限于，隨機存取存儲器(Random Access Memory，RAM)，只讀存儲器(Read Only Memory，ROM)，可編程只讀存儲器(Programmable Read-Only Memory，PROM)，可擦除只讀存儲器(Erasable Programmable Read-Only Memory，EPROM)，電可擦除只讀存儲器(Electric Erasable Programmable Read-Only Memory，EEPROM)等。其中，存儲器用于存儲程序，所述處理器140在接收到執(zhí)行指令后，執(zhí)行所述程序，前述本發(fā)明實施例任一實施例揭示的流過程定義的服務(wù)器所執(zhí)行的方法可以應(yīng)用于處理器140中，或者由處理器140實現(xiàn)。

處理器140可能是一種集成電路芯片，具有信號的處理能力。上述的處理器140可以是通用處理器，包括中央處理器140(Central Processing Unit，簡稱CPU)、網(wǎng)絡(luò)處理器140(Network Processor，簡稱NP)等；還可以是數(shù)字信號處理器140(DSP)、專用集成電路(ASIC)、現(xiàn)成可編程門陣列(FPGA)或者其他可編程邏輯器件、分立門或者晶體管邏輯器件、分立硬件組件。可以實現(xiàn)或者執(zhí)行本發(fā)明實施例中的公開的各方法、步驟及邏輯框圖。通用處理器可以是微處理器或者該處理器也可以是任何常規(guī)的處理器等。

所述外設(shè)接口150將各種輸入/輸出裝置耦合至處理器140以及存儲器120。在一些實施例中，外設(shè)接口150，處理器140以及存儲控制器130可以在單個芯片中實現(xiàn)。在其他一些實例中，他們可以分別由獨立的芯片實現(xiàn)。

圖3示出了本發(fā)明實施例提供的一種購買操作共享方法，該方法應(yīng)用于上述購買操作共享系統(tǒng)。如圖3所示，購買操作共享方法至少包括：步驟S301和步驟S302。下面將以服務(wù)器為執(zhí)行主體對本實施例的方法所包含的步驟進行詳細說明。

步驟S301：獲取多個客戶端發(fā)送的購買訂單，每個客戶端均與當(dāng)前購買操作綁定。

其中，購買操作是指多人共同參與的一次購買行為。例如，多人參與某某飯店的網(wǎng)上訂餐。當(dāng)前購買操作綁定有多個客戶端，其中，每個客戶端對應(yīng)一個購買行為的參與者。

其中，客戶端能夠接收用戶的修改操作。根據(jù)所接收的用戶的修改操作生成購買訂單，并將生成的購買訂單發(fā)送到服務(wù)器。例如，用戶在參與購買操作之后，用戶能夠在用戶對應(yīng)的客戶端上看到商品列表，其中，商品列表對應(yīng)商品的數(shù)量和種類。用戶修改感興趣的商品種類之后，客戶端將所選的商品種類以及對應(yīng)的數(shù)量生成購買訂單。因此，每個客戶端對應(yīng)一個購買訂單，每個購買訂單都與當(dāng)前購買操作綁定。

于本實施例中，服務(wù)器獲取多個客戶端發(fā)送的購買訂單的方式可以為：多個客戶端以預(yù)設(shè)時間間隔向服務(wù)器發(fā)送購買訂單，此時，所述購買訂單包括對應(yīng)有更新操作的訂單和無更新操作的訂單。也就是說，無論客戶端所對應(yīng)的用戶是否做出更新操作，即增加某種商品的數(shù)量或減少某種商品的數(shù)量，與當(dāng)前購買操作綁定的所有客戶端均固定以預(yù)設(shè)時間間隔向服務(wù)器發(fā)送購買訂單。此外，服務(wù)器獲取多個客戶端發(fā)送的購買訂單的方式也可以為：當(dāng)且僅當(dāng)客戶端對應(yīng)的用戶做出更新操作時，客戶端生成購買訂單，并將生成的購買訂單發(fā)送到服務(wù)器。

步驟S302：根據(jù)所獲取的多個所述購買訂單生成一個購買總訂單。

每一個購買訂單中包括商品的種類及數(shù)量。服務(wù)器根據(jù)每一個購買訂單中的商品種類及數(shù)量生成一個購買總訂單。例如，客戶端a發(fā)送的購買訂單中商品A的數(shù)量為1，客戶端b發(fā)送的購買訂單中商品B的數(shù)量為2，客戶端c發(fā)送的購買訂單中商品C的數(shù)量為1，則此時，服務(wù)器先后獲取到上述購買訂單后所生成的購買總訂單為：商品A：1件，商品B：2件，商品C：1件。

為了保證上述與當(dāng)前購買操作綁定的多個客戶端中，每一個客戶端均能實時獲得當(dāng)前時刻其他客戶端已提交的購買訂單，實現(xiàn)上述多個客戶端之間購買訂單的實時共享，需要將服務(wù)器根據(jù)所獲取到的購買訂單得到的更新數(shù)據(jù)實時發(fā)送到與當(dāng)前購買操作綁定的所有客戶端。

如圖4所示，本發(fā)明實施例提供的一種購買操作共享方法，至少包括步驟S401至步驟S404。

步驟S401：根據(jù)當(dāng)前購買操作創(chuàng)建初始訂單，將所述初始訂單發(fā)送至與所述當(dāng)前購買操作綁定的所有客戶端。

參與當(dāng)前購買操作的每個客戶端所顯示的初始訂單均與服務(wù)器中的初始訂單一致，即商品種類一致，且每個種類的商品數(shù)量也一致。初始狀態(tài)下，即所有客戶端均未發(fā)送購買訂單時，初始訂單中沒有商品記錄。

步驟S402：獲取多個客戶端基于所接收的初始訂單而生成的購買訂單。

與當(dāng)前購買操作綁定的客戶端接收到服務(wù)器發(fā)送的初始訂單后，可以基于該初始訂單對初始訂單中商品的數(shù)量進行修改操作?？梢岳斫獾氖?，上述修改操作包括增加操作或刪減操作。當(dāng)然，當(dāng)初始訂單中無商品記錄時，只能進行增加操作。客戶端根據(jù)所接收的用戶對初始訂單中商品數(shù)量的修改操作生成購買訂單，并將生成的購買訂單發(fā)送至服務(wù)器。

步驟S403：根據(jù)所獲取的購買訂單更新初始訂單，并將更新后的初始訂單發(fā)送至與當(dāng)前購買操作綁定的所有客戶端。

參與當(dāng)前購買操作的每個客戶端發(fā)送的購買訂單，都是基于在步驟S401獲得的初始訂單的基礎(chǔ)上而生成的，即客戶端對應(yīng)的用戶所選擇的種類的商品數(shù)量為大于零的數(shù)，而沒選擇的種類的商品數(shù)為0。服務(wù)器根據(jù)所獲取的參與當(dāng)前購買操作的客戶端發(fā)送的購買訂單所包含的商品種類和數(shù)量，修改初始訂單。服務(wù)器將更新后的初始訂單發(fā)送至與當(dāng)前購買操作綁定的所有客戶端，使得每個客戶端均可以實時顯示當(dāng)前的初始訂單，便于參與當(dāng)前購買操作的用戶可以及時獲知當(dāng)前已購買的商品種類及數(shù)量，以進一步對初始訂單中的商品種類或數(shù)量進行更新，例如追加購買商品或者修改商品數(shù)量。

此時，與所述當(dāng)前購買操作綁定的所有客戶端中所記錄的每一種商品的數(shù)量與當(dāng)前服務(wù)器中所存儲的初始訂單中對應(yīng)的商品數(shù)量一致。

例如，客戶端a、客戶端b及客戶端c均與當(dāng)前購買操作綁定。服務(wù)器執(zhí)行步驟S401，根據(jù)當(dāng)前購買操作創(chuàng)建一個初始訂單，并將該初始訂單發(fā)送到客戶端a、客戶端b及客戶端c。初始訂單中的商品包括：商品A、商品B及商品C。且商品A、商品B及商品C的數(shù)量均為0。此時，假設(shè)用戶A通過客戶端a對商品A的數(shù)量做了“+1”操作，客戶端a根據(jù)所記錄的用戶A的操作生成將商品A的數(shù)量加一的購買訂單，并將該購買訂單發(fā)送到服務(wù)器。服務(wù)器接收到該購買訂單后，根據(jù)該購買訂單對初始訂單進行更新，更新后的初始訂單中商品A的數(shù)量變?yōu)?，服務(wù)器將更新后的初始訂單發(fā)送給客戶端a、客戶端b及客戶端c，即此時客戶端a、客戶端b及客戶端c中所顯示的商品A的數(shù)量均為1。

步驟S404：根據(jù)更新后的初始訂單生成購買總訂單。

當(dāng)服務(wù)器接收到當(dāng)前購買操作所對應(yīng)的任意一個客戶端所發(fā)送的購買完成指令之前，可以根據(jù)所接收到的與當(dāng)前購買操作對應(yīng)的任意客戶端發(fā)送的購買訂單多次對當(dāng)前購買操作對應(yīng)的初始訂單進行更新，并將更新結(jié)果反饋給與當(dāng)前購買操作綁定的所有客戶端。當(dāng)服務(wù)器接收到當(dāng)前購買操作所對應(yīng)的任意一個客戶端所發(fā)送的購買完成指令時，服務(wù)器根據(jù)當(dāng)前的初始訂單生成購買總訂單。

或者，服務(wù)器可以設(shè)定一個預(yù)設(shè)時間值，服務(wù)器從初始訂單創(chuàng)建完成時開始計時。在計時時間達到預(yù)設(shè)時間值之前，服務(wù)器可以根據(jù)所接收到的與當(dāng)前購買操作對應(yīng)的任意客戶端發(fā)送的購買訂單多次對當(dāng)前購買操作對應(yīng)的初始訂單進行更新，并將更新結(jié)果反饋給與當(dāng)前購買操作綁定的所有客戶端。當(dāng)計時時間達到該預(yù)設(shè)時間值時，則根據(jù)當(dāng)前的初始訂單生成購買總訂單。

其中，購買總訂單包含了初始訂單中數(shù)量大于零的商品的種類和數(shù)量、當(dāng)前支付狀態(tài)、收貨人信息等。

如圖5所示，本發(fā)明實施例提供的一種購買操作共享方法，至少包括以下步驟S501至步驟S508。

步驟S501：根據(jù)當(dāng)前購買操作創(chuàng)建多個子訂單，將所述多個子訂單發(fā)送至與所述當(dāng)前購買操作綁定的所有客戶端。

其中，每一個子訂單與一個客戶端綁定，用于記錄對應(yīng)的客戶端所購買的商品種類以及數(shù)量。初始狀態(tài)下，即所有客戶端均未發(fā)送購買訂單時，所有子訂單中均沒有商品數(shù)據(jù)。每個客戶端均可以顯示所有的子訂單，以便于參與當(dāng)前購買操作的每個用戶均可以及時了解自己和其他用戶的購買情況。

步驟S502：獲取多個客戶端基于所接收的子訂單而生成的購買訂單。

每個客戶端發(fā)送的購買訂單均基于所接收到的與該客戶端綁定的子訂單生成。也就是說，本實施例中，每個客戶端只能修改與其對應(yīng)的子訂單。

步驟S503：查找與當(dāng)前購買訂單對應(yīng)的子訂單。

按照服務(wù)器接收到多個客戶端發(fā)送的購買訂單的時間順序，將每一個購買訂單作為當(dāng)前購買訂單。本實施例中，購買訂單為客戶端接收到用戶的修改操作后基于與客戶端綁定的當(dāng)前子訂單生成的。此時，查找與當(dāng)前購買訂單對應(yīng)的子訂單的具體實施方式可以為：服務(wù)器中設(shè)置有第一對應(yīng)表，該第一對應(yīng)表中包括每一個子訂單與相應(yīng)的客戶端的身份信息的對應(yīng)關(guān)系。當(dāng)前購買訂單包括有身份信息，根據(jù)當(dāng)前購買訂單的身份信息即可以查找與當(dāng)前購買訂單對應(yīng)的子訂單。本實施例中，當(dāng)前購買訂單的身份信息可以為發(fā)送該購買訂單的客戶端的MAC地址等地址信息或該客戶端的登錄信息等。

步驟S504：獲取所查找到的子訂單中與當(dāng)前購買訂單所包括的欲更新商品種類一致的商品的數(shù)量。

除了包括身份信息外，當(dāng)前購買訂單還包括欲更新商品的種類、數(shù)量變化起點和數(shù)量變化終點。需要說明的是，當(dāng)在對應(yīng)的子訂單中查找不到與欲更新商品種類一致的商品時，所獲取到的商品的數(shù)量為0。

步驟S505：判斷欲更新商品的數(shù)量變化起點與所獲取的商品數(shù)量是否一致。

當(dāng)欲更新商品的數(shù)量變化起點與所獲取的商品數(shù)量一致時，執(zhí)行步驟S506。當(dāng)欲更新商品的數(shù)量變化起點與所獲取的商品數(shù)量不一致時，丟棄當(dāng)前購買訂單，執(zhí)行步驟S507。例如，當(dāng)前購買訂單中欲更新商品的種類為商品A，數(shù)量變化起點為1，數(shù)量變化終點為2。當(dāng)所查找到的子訂單中商品A的數(shù)量為1時，則判定欲更新商品的數(shù)量變化起點與所獲取的商品數(shù)量一致，當(dāng)所查找到的子訂單中商品A的數(shù)量不為1時，則判定欲更新商品的數(shù)量變化起點與所獲取的商品數(shù)量不一致。

步驟S506：根據(jù)當(dāng)前購買訂單更新對應(yīng)的子訂單，將更新后的子訂單發(fā)送到每個客戶端。

具體的，根據(jù)當(dāng)前購買訂單更新對應(yīng)的子訂單的具體實施方式可以為：當(dāng)對應(yīng)的子訂單中存在與欲更新商品的種類一致的商品時，將對應(yīng)的子訂單中欲更新商品的數(shù)量更新為當(dāng)前購買訂單中欲更新商品的數(shù)量變化終點；當(dāng)對應(yīng)的子訂單中不存在與欲更新商品的種類一致的商品時，將當(dāng)前購買訂單中欲更新商品添加到對應(yīng)的子訂單中，且數(shù)量為當(dāng)前購買訂單中欲更新商品的數(shù)量變化終點。

例如，當(dāng)前客戶端a的所接收的多個子訂單中，對應(yīng)于客戶端a的子訂單中商品A的數(shù)量為1。假設(shè)客戶端a接收到的用戶的修改操作為將商品A的數(shù)量由1增加到2。此時，客戶端a基于對應(yīng)的子訂單所生成的購買訂單為：欲更新商品為商品A，商品A數(shù)量變化起點為1，數(shù)量變化終點為2。服務(wù)器獲取到該購買訂單后，執(zhí)行步驟S504，獲取服務(wù)器中存儲的與客戶端a綁定的子訂單中商品A的數(shù)量。繼續(xù)執(zhí)行步驟S505，若獲取到的商品A的數(shù)量為1時，執(zhí)行步驟S506，將服務(wù)器中與客戶端a綁定的子訂單中商品A的數(shù)量更新為2，并更新后的子訂單發(fā)送至所有客戶端；若獲取到的商品A的數(shù)量不為1時，說明當(dāng)前購買訂單無效，丟棄當(dāng)前購買訂單，服務(wù)器中與客戶端a綁定的子訂單中商品A的數(shù)量仍為1。

步驟S507：是否接收到購買完成指令？

購買完成指令可以由與當(dāng)前購買操作綁定的任意一個客戶端發(fā)送。若服務(wù)器接收到購買完成指令時，執(zhí)行步驟S508。若服務(wù)器未接收到購買完成指令，重復(fù)執(zhí)行步驟S503至步驟S507，直至獲取到購買完成指令。

步驟S508：根據(jù)多個更新后的子訂單生成購買總訂單。

此時，根據(jù)上述步驟S502至步驟S506以對初始創(chuàng)建的多個子訂單中的至少一個進行了一次或多次更新操作。當(dāng)獲取到購買完成指令時，即多個子訂單的更新截止，服務(wù)器不再接收購買訂單，根據(jù)當(dāng)前所存儲的子訂單生成購買總訂單。具體為：獲取與當(dāng)前購買操作綁定的所有客戶端對應(yīng)的子訂單中商品的種類及每種商品的數(shù)量，并將相同種類的商品的數(shù)量進行累加，從而得到購買總訂單。

需要說明的是，該買總訂單中除了包括商品的種類及每種商品的數(shù)量之外，還可以包括當(dāng)前支付狀態(tài)、收貨人信息等。

本實施例在實現(xiàn)多個客戶端共享一個購買操作的基礎(chǔ)上，通過加入步驟S503至步驟S505可以有效地保證同步數(shù)據(jù)的冪等性，保證了在客戶端與服務(wù)器之間的網(wǎng)絡(luò)連接狀況較差服務(wù)器沒有響應(yīng)時，服務(wù)器將不對由于客戶端無法及時獲得服務(wù)器的最新更新數(shù)據(jù)所導(dǎo)致的誤操作進行處理。

例如，當(dāng)前客戶端a所接收到的服務(wù)器發(fā)送的對應(yīng)于客戶端a的子訂單a中商品A的數(shù)量為1。此時，用戶A基于上述子訂單a將商品A的數(shù)量由1增加到2，客戶端a接收到用戶A的修改操作后生成購買訂單Ⅰ發(fā)送到服務(wù)器。然而，由于網(wǎng)絡(luò)狀況較差的原因，服務(wù)器沒有及時響應(yīng)，客戶端a上所顯示的子訂單a中商品A的數(shù)量仍為1，即服務(wù)器沒有及時將子訂單a的更新結(jié)果發(fā)送到客戶端a。若此時，用戶A再次在客戶端a上執(zhí)行將商品A的數(shù)量由1增加到2的操作則可以理解為一次誤操作。

在具體的應(yīng)用中，可以在購買訂單中加入From和To的數(shù)據(jù)結(jié)構(gòu)實現(xiàn)上述步驟S503至步驟S505。例如，客戶端a發(fā)送的購買訂單中包括數(shù)據(jù)結(jié)構(gòu){skuId:A,from:1,to:2}，表示將種類為A的商品的數(shù)量由1更改為2。

基于上述實施方式，本發(fā)明實施例還提供了另一種實施方式，不僅可以防止客戶端與服務(wù)器之間的網(wǎng)絡(luò)連接狀況較差或服務(wù)器沒有響應(yīng)時，客戶端無法及時獲得服務(wù)器中與當(dāng)前購買操作對應(yīng)的初始訂單的最新更新數(shù)據(jù)所導(dǎo)致的誤操作，還可以防止兩個或兩個以上的客戶端針對于同一子訂單下的同一商品的修改操作發(fā)生沖突。

如圖6所示，本發(fā)明實施例提供的一種購買操作共享方法，至少包括以下步驟S601至步驟S611。

步驟S601：根據(jù)當(dāng)前購買操作創(chuàng)建多個子訂單，將多個子訂單發(fā)送至與所述當(dāng)前購買操作綁定的所有客戶端。

其中，每一個子訂單分別與一個客戶端綁定，用于記錄對應(yīng)的客戶端所購買的商品種類以及數(shù)量。初始狀態(tài)下，即所有客戶端均未發(fā)送購買訂單時，所有子訂單中均沒有商品數(shù)據(jù)。每個客戶端均可以顯示所有的子訂單，以便于參與當(dāng)前購買操作的每個用戶均可以及時了解自己或其他用戶的購買情況。

此外，每一個子訂單中的每一種商品均對應(yīng)有版本號。需要說明的是，子訂單中不存在的商品對應(yīng)的版本號為0。

步驟S602：獲取多個客戶端基于所接收的子訂單而生成的購買訂單。

每一個客戶端均可以顯示所有子訂單。每一個客戶端可以基于自身對應(yīng)的子訂單生成購買訂單并發(fā)送到服務(wù)器，也可以基于其他客戶端所對應(yīng)的子訂單生成購買訂單，即每一個客戶端可以修改自身對應(yīng)的子訂單，也可以修改其他客戶端所對應(yīng)的子訂單。此時，服務(wù)器所接收到的每一個購買訂單均為基于一個子訂單生成的，即每一個購買訂單均對應(yīng)于一個子訂單。

步驟S603：查找與當(dāng)前購買訂單對應(yīng)的子訂單，獲取所查找到的子訂單中與當(dāng)前購買訂單所包括的欲更新商品種類一致的商品的版本號作為第一版本號；

服務(wù)器按照接收到多個客戶端發(fā)送的購買訂單的時間順序，將每一個購買訂單作為當(dāng)前購買訂單。

其中，獲取與當(dāng)前購買訂單對應(yīng)的子訂單的實施方式可以為：服務(wù)器中可以設(shè)置有第二對應(yīng)表，該第二對應(yīng)表中包括每一個子訂單與其標(biāo)識信息的對應(yīng)關(guān)系。每一個購買訂單均是基于子訂單生成，因此，購買訂單中包括所對應(yīng)的子訂單的標(biāo)識信息。此時，根據(jù)當(dāng)前購買訂單所包括的標(biāo)識信息即可以查找到對應(yīng)的子訂單。當(dāng)然，需要說明的是，所查找到的子訂單可以是與發(fā)送當(dāng)前購買訂單的客戶端對應(yīng)的子訂單，也可以與其他客戶端對應(yīng)的子訂單。

此外，當(dāng)前購買訂單還包括：欲更新商品的種類、數(shù)量變化起點和數(shù)量變化終點。獲取所查找到的子訂單中與當(dāng)前購買訂單所包括的欲更新商品種類一致的商品的版本號作為第一版本號的具體實施方式可以為：獲取當(dāng)前購買訂單所包括的欲更新商品的種類，在所查找到的子訂單中查找種類與所獲取的欲更新商品的種類一致的商品，獲取所找到的商品對應(yīng)的版本號作為第一版本號。

需要說明的是，當(dāng)所查找到的子訂單中不存在與當(dāng)前購買訂單所包括的欲更新商品種類一致的商品時，所獲取到的第一版本號為0。

步驟S604：獲取所查找到的子訂單中與當(dāng)前購買訂單所包括的欲更新商品種類一致的商品的數(shù)量。

需要說明的是，當(dāng)在對應(yīng)的子訂單中查找不到與欲更新商品種類一致的商品時，所獲取到的商品的數(shù)量為0。

步驟S605：判斷欲更新商品的數(shù)量變化起點與所獲取的商品數(shù)量是否一致。

當(dāng)欲更新商品的數(shù)量變化起點與所找到的商品對應(yīng)的數(shù)量一致時，執(zhí)行步驟S606。當(dāng)欲更新商品的數(shù)量變化起點與所找到的商品對應(yīng)的數(shù)量不一致時，執(zhí)行步驟S610。步驟S605的具體實施方式可以參照上述實施例中的步驟S505，在此不再贅述。

步驟S606：再次獲取所查找到的子訂單中與當(dāng)前購買訂單所包括的欲更新商品種類一致的商品的版本號作為第二版本號；

步驟S607：判斷第二版本號是否等于第一版本號？

當(dāng)?shù)诙姹咎柕扔诘谝话姹咎枙r，執(zhí)行步驟S608。當(dāng)?shù)诙姹咎柌坏扔诘谝话姹咎枙r，表示當(dāng)前購買訂單為過期數(shù)據(jù)，丟棄當(dāng)前購買訂單，執(zhí)行步驟S610。

當(dāng)步驟S605中判定欲更新商品的數(shù)量變化起點與所找到的商品對應(yīng)的數(shù)量一致之后，為了避免此時與當(dāng)前購買訂單對應(yīng)的子訂單中與欲更新商品種類一致的商品的數(shù)量發(fā)生變化，導(dǎo)致更新的數(shù)據(jù)與步驟S604所獲取的數(shù)據(jù)不一致的情況，需要在進行更新操作之前步驟S606及步驟S607，以保證更新的數(shù)據(jù)與步驟S604所獲取的數(shù)據(jù)一致，確保更新的準(zhǔn)確性。

例如，服務(wù)器接收到對應(yīng)于某個子訂單中商品A的購買訂單包括客戶端a發(fā)送的第一購買訂單和客戶端b發(fā)送的第二購買訂單。其中，第一購買訂單為將該子訂單中商品A的數(shù)量由1增加到2，而第二訂單為將該子訂單中商品A的數(shù)量由1減到0。這種情況即為兩個客戶端針對于同一子訂單下的同一商品的修改操作發(fā)生沖突的情況。根據(jù)上述步驟S603、步驟S606及步驟S607可以有效地避免上述沖突情況發(fā)生時影響更新結(jié)果的準(zhǔn)確性。

假設(shè)上述沖突情況發(fā)生時，服務(wù)器對第一購買訂單執(zhí)行步驟S603時，所得到的第一版本號為1，對第二購買訂單執(zhí)行步驟S603時，所得到的第一版本號也為1。然而，相比于客戶端a發(fā)送的第一購買訂單，服務(wù)器先對客戶端b發(fā)送的第二購買訂單執(zhí)行了步驟S604至S608，且根據(jù)第二購買訂單對上述子訂單中的上述某商品的數(shù)量進行了更新，使得上述子訂單中某商品對應(yīng)的版本號加1。因此，當(dāng)服務(wù)器對第一購買訂單執(zhí)行步驟S606時，所獲取到的第二版本號為2，不滿足步驟S607的條件，此時，服務(wù)器丟棄第一購買訂單，有效地保證了在步驟S604中所獲取的數(shù)據(jù)與步驟S608中所更新的數(shù)據(jù)的一致性，從而保證了更新結(jié)果的準(zhǔn)確性。

步驟S608：將所找到的子訂單中對應(yīng)商品的數(shù)量更新為與欲更新商品的數(shù)量變化終點一致，將所述對應(yīng)商品的版本號加一。

當(dāng)確保所獲取到的第二版本號等于第一版本號時，根據(jù)當(dāng)前購買訂單對所找到的子訂單進行更新操作。具體為，將所找到的子訂單中與欲更新商品的種類一致的商品的數(shù)量更新為當(dāng)前購買訂單所包括的數(shù)量變化終點，且將所找到的子訂單中與欲更新商品的種類一致的商品的版本號加一。例如，當(dāng)前購買訂單中欲更新商品的種類為商品A，數(shù)量變化起點為1，數(shù)量變化終點為2；所找到的子訂單中商品A的數(shù)量為1，版本號為1。則將所找到的子訂單中商品A的數(shù)量更新為2，版本號更新為2。

步驟S609：將更新后的子訂單發(fā)送至與當(dāng)前購買操作綁定的所有客戶端。

將更新后的子訂單發(fā)送到與當(dāng)前購買操作所綁定的所有客戶端，以便于各個客戶端能夠獲取到最新的更新數(shù)據(jù)。具體的，服務(wù)器將更新后的子訂單發(fā)送至與所述當(dāng)前購買操作綁定的所有客戶端的發(fā)送方式可以為：http輪詢的方式，也可以采用push方式。

步驟S610：是否接收到購買完成指令？

購買完成指令可以由與當(dāng)前購買操作綁定的任意一個客戶端發(fā)送。若服務(wù)器接收到購買完成指令時，執(zhí)行步驟S611。若服務(wù)器未接收到購買完成指令，重復(fù)執(zhí)行步驟S603至步驟S610，直至獲取到購買完成指令。

步驟S611：根據(jù)多個更新后的子訂單生成購買總訂單。

步驟S610至步驟S611的具體實施方式可以參考前述實施例的步驟S507至步驟S508，在此不再贅述。

在上述幾個實施例中，將多個客戶端與當(dāng)前購買操作綁定的具體實施方式可以為：根據(jù)預(yù)設(shè)規(guī)則將多個客戶端與一個購買操作綁定。

在本發(fā)明實施例的一種實施方式中，購買操作可以是服務(wù)器針對于每一個商家預(yù)先創(chuàng)建的。此時，根據(jù)預(yù)設(shè)規(guī)則將多個客戶端與一個購買操作綁定的方式可以為：服務(wù)器針對于每一個商家預(yù)先創(chuàng)建多個購買操作。將當(dāng)前商家的每一個購買操作與所有客戶端中該當(dāng)前商家頁面上的一個購買操作入口關(guān)聯(lián)。其中，每一個購買操作入口均具有不同的特定標(biāo)識，不同的特定標(biāo)識對應(yīng)于不同的購買操作。用戶通過點擊客戶端中當(dāng)前商家頁面上的一個購買操作入口生成綁定請求并發(fā)送給服務(wù)器。其中，綁定請求包括該購買操作入口的特定標(biāo)識。當(dāng)服務(wù)器接收到該綁定請求時，根據(jù)該綁定請求包括的特定標(biāo)識，將發(fā)送該綁定請求的客戶端與該特定標(biāo)識對應(yīng)的購買操作綁定，并發(fā)送一個標(biāo)記信息到所有客戶端以對該購買操作入口進行標(biāo)記，表示該購買操作入口對應(yīng)的購買操作已綁定有客戶端。例如，當(dāng)用戶A、用戶B和用戶C分別通過所對應(yīng)的客戶端點擊同一個購買操作入口時，服務(wù)器可以獲取到相應(yīng)的三個客戶端分別發(fā)送的綁定請求，將發(fā)送綁定請求的三個客戶端均與該購買操作入口所對應(yīng)的購買操作綁定。

或者，根據(jù)預(yù)設(shè)規(guī)則可以將多個客戶端與該商家對應(yīng)的一個購買操作綁定的實施方式還可以為：服務(wù)器針對于每一個商家預(yù)先創(chuàng)建多個購買操作，并為每一個購買操作關(guān)聯(lián)一個標(biāo)識序列?？蛻舳酥械拿恳粋€商家頁面上均設(shè)置有“獲取標(biāo)識序列”圖標(biāo)和“一起點”圖標(biāo)，當(dāng)用戶點擊“獲取標(biāo)識序列”圖標(biāo)時，可以獲取到服務(wù)器發(fā)送的一個未綁定有客戶端的購買操作所關(guān)聯(lián)的標(biāo)識序列。用戶點擊商家頁面上的“一起點”圖標(biāo)，可以開啟輸入標(biāo)識序列界面。進一步在輸入標(biāo)識序列界面中輸入所獲取到的標(biāo)識序列生成綁定請求并發(fā)送服務(wù)器。其中，綁定請求包括用戶端獲取到的用戶輸入的標(biāo)識序列。服務(wù)器根據(jù)獲取到的綁定請求所包括的標(biāo)識序列將發(fā)送該綁定請求的客戶端與對應(yīng)的購買操作綁定。

例如，當(dāng)用戶A通過客戶端a點擊“獲取標(biāo)識序列”圖標(biāo)時，客戶端a可以獲取到服務(wù)器發(fā)送的一個未綁定有客戶端的購買操作所關(guān)聯(lián)的標(biāo)識序列，用戶B和用戶C可以從用戶A處獲知該標(biāo)識序列。用戶A通過客戶端a點擊“一起點”圖標(biāo)，在開啟的輸入標(biāo)識序列界面上輸入該標(biāo)識序列，服務(wù)器獲取到客戶端a發(fā)送的綁定請求后將客戶端a與該標(biāo)識序列對應(yīng)的購買操作綁定。同理，用戶B通過客戶端b點擊“一起點”圖標(biāo)，也在開啟的輸入標(biāo)識序列界面上輸入該標(biāo)識序列，用戶C通過客戶端c點擊“一起點”圖標(biāo)，也在開啟的輸入標(biāo)識序列界面上輸入該標(biāo)識序列圖標(biāo)，服務(wù)器獲取到客戶端b和客戶端c發(fā)送的綁定請求后將客戶端a與客戶端b也與該標(biāo)識序列對應(yīng)的購買操作綁定。

在本發(fā)明實施例的另一種實施方式中，購買操作還可以是服務(wù)器根據(jù)客戶端發(fā)送的創(chuàng)建請求實時創(chuàng)建。為了避免服務(wù)器資源的浪費，降低后期維護難度，本發(fā)明實施例中，購買操作的創(chuàng)建方式可以優(yōu)選為服務(wù)器根據(jù)用戶的需要實時創(chuàng)建購買操作。

本實施例中，多個客戶端包括一個群主客戶端和多個成員客戶端。其中，群主客戶端為創(chuàng)建該購買操作的客戶端，成員客戶端為除了群主客戶端以外加入該購買操作的客戶端。如圖7所示，本發(fā)明實施例提供的一種購買操作共享方法，至少包括步驟S701至步驟S715。

其中，步驟S701及步驟S702為群主客戶端創(chuàng)建當(dāng)前購買操作的步驟。

步驟S701：獲取群主客戶端發(fā)送的創(chuàng)建請求。

其中，所述創(chuàng)建請求包括第一標(biāo)號。第一標(biāo)號可以是用戶在群主客戶端中輸入的口令信息，例如，該口令信息可以為1234?？梢岳斫獾氖?，為了提高對應(yīng)于該創(chuàng)建請求的購買操作創(chuàng)建成功的概率，口令信息可以設(shè)置的盡量復(fù)雜。

步驟S702：根據(jù)所述創(chuàng)建請求創(chuàng)建當(dāng)前購買操作。

具體的，步驟S702為服務(wù)器根據(jù)群主客戶端發(fā)送的創(chuàng)建請求創(chuàng)建當(dāng)前購買操作的方法。所述方法包括：判斷創(chuàng)建請求的第一標(biāo)號是否與所存儲的所有購買操作的身份標(biāo)識匹配；當(dāng)所述第一標(biāo)號與所存儲的所有購買操作的身份標(biāo)識均不匹配時，創(chuàng)建與所述創(chuàng)建請求對應(yīng)的購買操作，將群主客戶端與當(dāng)前購買操作綁定，將所述第一標(biāo)號作為所述當(dāng)前購買操作的身份標(biāo)識和驗證密碼。

例如，服務(wù)器中存儲有購買操作的身份標(biāo)識與購買操作的第三對應(yīng)表。因此，可以在第三對應(yīng)表中查找與創(chuàng)建請求包括的第一標(biāo)號匹配的身份標(biāo)識。當(dāng)未查找到與第一標(biāo)號匹配的身份標(biāo)識時，服務(wù)器創(chuàng)建與所述創(chuàng)建請求對應(yīng)的購買操作。進一步，將群主客戶端與當(dāng)前購買操作綁定，將所述第一標(biāo)號作為當(dāng)前購買操作的身份標(biāo)識和驗證密碼。當(dāng)查找到與第一標(biāo)號匹配的身份標(biāo)識時，可以發(fā)送創(chuàng)建失敗信息到該群主客戶端顯示，以提示用戶購買操作創(chuàng)建失敗，已存在該創(chuàng)建請求對應(yīng)的購買操作，需要更換創(chuàng)建請求，也就是更換創(chuàng)建請求所包括的第一標(biāo)號。當(dāng)然，當(dāng)查找到與第一標(biāo)號匹配的身份標(biāo)識時，也可以是將該群主客戶端加入已存在的購買操作成為該購買操作的一個成員客戶端。

為了避免相同的創(chuàng)建請求對應(yīng)有兩個購買操作的情況，執(zhí)行根據(jù)所述創(chuàng)建請求創(chuàng)建當(dāng)前購買操作的過程中，當(dāng)在預(yù)設(shè)時間之內(nèi)接收到的創(chuàng)建請求與創(chuàng)建當(dāng)前購買操作所對應(yīng)的創(chuàng)建請求一致時，不執(zhí)行該預(yù)設(shè)時間之內(nèi)接收到的創(chuàng)建請求。其中，預(yù)設(shè)時間為接收到與當(dāng)前購買操作所對應(yīng)的創(chuàng)建請求之后，以及獲取到當(dāng)前購買操作創(chuàng)建完成時生成的創(chuàng)建完成指令之前的時間段。

其中，當(dāng)前購買操作創(chuàng)建完成包括了當(dāng)前購買操作創(chuàng)建成功的情況及當(dāng)前購買操作創(chuàng)建失敗情況，即服務(wù)器在當(dāng)前購買操作創(chuàng)建成功或當(dāng)前購買操作創(chuàng)建失敗時均會生成創(chuàng)建完成指令。

具體的，服務(wù)器創(chuàng)建當(dāng)前購買操作的過程中，可以通過緩存鎖技術(shù)鎖定當(dāng)前購買操作，直至當(dāng)前購買操作創(chuàng)建成功或當(dāng)前購買操作創(chuàng)建失敗。

在本發(fā)明的一種實施例中，服務(wù)器根據(jù)群主客戶端發(fā)送的創(chuàng)建請求完成該創(chuàng)建請求的第一標(biāo)號對應(yīng)的當(dāng)前購買操作的創(chuàng)建后，可以對上述群主客戶端的身份信息進行標(biāo)記。

進一步，步驟S703及步驟S704為成員客戶端加入該購買操作的步驟。

步驟S703：獲取多個成員客戶端發(fā)送的購買請求。

其中，購買請求對應(yīng)于當(dāng)前購買操作。也就是說，基于服務(wù)器已根據(jù)成員客戶端發(fā)送的創(chuàng)建請求成功創(chuàng)建了當(dāng)前購買操作的情況下，當(dāng)多個成員客戶端需要與群主客戶端共享同一個購買操作時，多個成員客戶端分別需要發(fā)送一個購買請求至服務(wù)器。

步驟S704：根據(jù)購買請求將每個成員客戶端與當(dāng)前購買操作綁定。

其中，購買請求可以包括輸入密碼。具體的，根據(jù)所述購買請求將每個所述成員客戶端與所述當(dāng)前購買操作綁定的方式可以為：查找所輸入的輸入密碼與驗證密碼匹配的所有成員客戶端，將所查找到的所有成員客戶端與當(dāng)前購買操作綁定?？梢岳斫獾氖牵?dāng)群主客戶端對應(yīng)的用戶與多個成員客戶端分別對應(yīng)的用戶已約定好共享同一個購物操作時，多個成員客戶端對應(yīng)的用戶可以從群主客戶端對應(yīng)的用戶處獲知當(dāng)前購買操作的驗證密碼，即第一標(biāo)號，以保證多個成員客戶端所發(fā)送的購買請求的輸入密碼與當(dāng)前購買操作的驗證密碼匹配。

步驟S705：根據(jù)當(dāng)前購買操作創(chuàng)建多個子訂單，將所述多個子訂單發(fā)送至與所述當(dāng)前購買操作綁定的群主客戶端及所有成員客戶端。

步驟S705的具體實施方式可以參考前述實施例中的步驟S602，在此不再贅述。

步驟S706：獲取群主客戶端和成員客戶端基于所接收的子訂單而生成的購買訂單。

本實施例中，為了更好的管理當(dāng)前購買操作，群主客戶端可以基于群主客戶端所對應(yīng)的子訂單發(fā)送購買訂單，也可以基于任意成員客戶端對應(yīng)的子訂單發(fā)送購買訂單，而成員客戶端只能基于自身對應(yīng)的子訂單發(fā)送購買訂單。也就是說，本實施例中，群主客戶端與成員客戶端具有不同的權(quán)限。表現(xiàn)為：成員客戶端只能修改自己購買的商品，而群主客戶端可以修改與當(dāng)前購買操作綁定的所有客戶端的商品。

步驟S707：查找與當(dāng)前購買訂單對應(yīng)的子訂單，獲取所查找到的子訂單中與當(dāng)前購買訂單所包括的欲更新商品種類一致的商品的版本號作為第一版本號；

步驟S708：獲取所查找到的子訂單中與當(dāng)前購買訂單所包括的欲更新商品種類一致的商品的數(shù)量。

步驟S709：判斷欲更新商品的數(shù)量變化起點與所獲取的商品數(shù)量是否一致。

當(dāng)欲更新商品的數(shù)量變化起點與所獲取的商品數(shù)量一致時，執(zhí)行步驟S710。當(dāng)欲更新商品的數(shù)量變化起點與所獲取的商品數(shù)量不一致時，丟棄當(dāng)前購買訂單，執(zhí)行步驟S714。

步驟S710：再次獲取所查找到的子訂單中與當(dāng)前購買訂單所包括的欲更新商品種類一致的商品的版本號作為第二版本號。

步驟S711：判斷第二版本號是否等于第一版本號？

當(dāng)?shù)诙姹咎柕扔诘谝话姹咎枙r，執(zhí)行步驟S712。當(dāng)?shù)诙姹咎柌坏扔诘谝话姹咎枙r，表示當(dāng)前購買訂單為過期數(shù)據(jù)，丟棄當(dāng)前購買訂單，執(zhí)行步驟S714。

步驟S712：將所找到的子訂單中對應(yīng)商品的數(shù)量更新為與欲更新商品的數(shù)量變化終點一致，將所述對應(yīng)商品的版本號加一。

步驟S713：將更新后的子訂單發(fā)送至與當(dāng)前購買操作綁定的群主客戶端和所有成員客戶端。

步驟S714：是否接收到購買完成指令？

本實施例中，為了便于當(dāng)前購買操作的有效管理，當(dāng)且僅當(dāng)服務(wù)器接收到群主客戶端發(fā)送的購買完成指令時，根據(jù)當(dāng)前的初始訂單生成購買總訂單。也就是說，僅群主客戶端具有發(fā)送購買完成指令的權(quán)限，即下單的權(quán)限，成員客戶端沒有下單的權(quán)限。購買完成指令中包括群主客戶端的身份信息，可以在上述步驟S702中預(yù)先對群主客戶端的身份信息進行標(biāo)記，以便于服務(wù)器識別群主客戶端的身份信息。若服務(wù)器接收到群主客戶端發(fā)送的購買完成指令時，執(zhí)行步驟S715。若服務(wù)器未接收到群主客戶端發(fā)送的購買完成指令，重復(fù)執(zhí)行步驟S707至步驟S714，直至獲取到購買完成指令。

步驟S715：根據(jù)多個更新后的子訂單生成購買總訂單。

本實施例中，步驟S707至步驟S713及步驟S715至步驟S715的具體實施方式均可以參照前述實施例中的步驟S603至步驟S609及步驟S611至步驟S611，在此不再贅述。

另外，當(dāng)多個客戶端200包括群主客戶端210和多個成員客戶端220時，在本發(fā)明實施例還提供了另一種購買操作共享系統(tǒng)。如圖8所示，在另一種購買操作共享系統(tǒng)中，多個成員客戶端220與群主客戶端210通過網(wǎng)絡(luò)進行數(shù)據(jù)交互，群主客戶端210與服務(wù)器100之間通過網(wǎng)絡(luò)進行數(shù)據(jù)交互。多個成員客戶端220將生成的購買請求發(fā)送至群主客戶端210。群主客戶端210根據(jù)自身生成的購買請求以及所接收到的購買請求生成一個購買總訂單。此后，群主客戶端210再將所生成的購買總訂單發(fā)送到服務(wù)器100。

另外，基于圖8所示的購買操作共享系統(tǒng)，本發(fā)明實施例還提供了另一種購買操作共享方法。如圖9所示，該方法包括：

步驟S901：多個成員客戶端發(fā)送購買訂單至群主客戶端；

其中，群主客戶端及每一個成員客戶端均與當(dāng)前購買操作綁定。具體的綁定方法，請參照上述實施例中的步驟S701至步驟S704，在此不再贅述。

步驟S902：群主客戶端根據(jù)所獲取的多個購買訂單生成購買總訂單；

步驟S902的具體實施方式可以參照上述實施例中的步驟302，在此不再贅述。

步驟S903：群主客戶端將生成的購買總訂單發(fā)送至服務(wù)器。

群主客戶端將生成的購買總訂單發(fā)送給服務(wù)器，由服務(wù)器將購買總訂單發(fā)送至當(dāng)前購買操作對應(yīng)的商家，以便商家根據(jù)收貨人信息將購買總訂單對應(yīng)的商品的種類和數(shù)量送至收貨人。其中，服務(wù)器可以在購買總訂單的當(dāng)前支付狀態(tài)為支付完成時，將購買總訂單發(fā)送至當(dāng)前購買操作對應(yīng)的商家。服務(wù)器內(nèi)存儲有多個商家以及與商家對應(yīng)的商家客戶端的身份信息。其中，商家客戶端的身份信息可以是商家客戶端的MAC地址等地址信息或商家客戶端的登錄信息等。

另外，本發(fā)明實施例還提供了一種購買操作共享裝置110，如圖10所示，所述裝置包括：訂單獲取模塊412和總訂單生成模塊413。

其中，訂單獲取模塊412獲取多個客戶端發(fā)送的購買訂單，其中，每個客戶端均與當(dāng)前購買操作綁定；

總訂單生成模塊413用于根據(jù)所獲取的多個所述購買訂單生成一個購買總訂單。

如圖11所示，在本發(fā)明的一種實施例中，購買操作共享裝置110除了包括訂單獲取模塊412及總訂單生成模塊413之外，還包括初始訂單創(chuàng)建模塊410。初始訂單創(chuàng)建模塊410用于根據(jù)當(dāng)前購買操作創(chuàng)建初始訂單，將所述初始訂單發(fā)送至與所述當(dāng)前購買操作綁定的所有客戶端。此時，所述訂單獲取模塊412具體用于獲取多個客戶端基于所接收的初始訂單而生成的購買訂單。所述總訂單生成模塊413包括初始訂單更新單元511和第一生成單元512。其中，初始訂單更新單元511用于根據(jù)所獲取的購買訂單更新所述初始訂單，并將所更新的初始訂單發(fā)送至與所述當(dāng)前購買操作綁定的所有客戶端。第一生成單元512用于根據(jù)更新后的初始訂單生成所述購買總訂單。

如圖12所示，在本發(fā)明的另一種實施例中，購買操作共享裝置110除了包括訂單獲取模塊412及總訂單生成模塊413之外，還包括子訂單創(chuàng)建模塊411。子訂單創(chuàng)建模塊411用于根據(jù)當(dāng)前購買操作創(chuàng)建多個子訂單，將所述多個子訂單發(fā)送至與所述當(dāng)前購買操作綁定的所有客戶端。此時，所述訂單獲取模塊412具體用于獲取多個所述客戶端基于所接收的子訂單而生成的購買訂單。所述總訂單生成模塊413包括：子訂單更新單元521、發(fā)送單元522和第二生成單元523。其中，子訂單更新單元521用于根據(jù)所獲取的每個所述購買訂單更新所對應(yīng)的子訂單。發(fā)送單元522用于將所有更新后的子訂單均發(fā)送到每個所述客戶端。第二生成單元523用于根據(jù)多個更新后的子訂單生成購買總訂單。

在本發(fā)明的另一種實施例的一種具體實施方式中，所述購買訂單包括欲更新商品的數(shù)量變化起點和數(shù)量變化終點，如圖13所示，所述子訂單更新單元521包括：第一查找子單元611、第一獲取子單元612及第一判斷子單元613。其中，第一查找子單元611用于查找與當(dāng)前購買訂單對應(yīng)的子訂單。第一獲取子單元612用于獲取所查找到的子訂單中與當(dāng)前購買訂單所包括的欲更新商品種類一致的商品的數(shù)量。第一判斷子單元613用于判斷欲更新商品的數(shù)量變化起點與所獲取的商品數(shù)量是否一致，當(dāng)欲更新商品的數(shù)量變化起點與所獲取的商品數(shù)量一致時，根據(jù)當(dāng)前購買訂單更新對應(yīng)的子訂單。

在本發(fā)明的另一種實施例的另一種具體實施方式中，所述購買訂單包括欲更新商品的數(shù)量變化起點和數(shù)量變化終點，每一個所述子訂單中的每一種商品均對應(yīng)有版本號。如圖14所示，所述子訂單更新單元521包括：第二獲取子單元621、第三獲取子單元622、第二判斷子單元623及第三判斷子單元624。其中，第二獲取子單元621用于查找與當(dāng)前購買訂單對應(yīng)的子訂單，獲取所查找到的子訂單中與當(dāng)前購買訂單所包括的欲更新商品種類一致的商品的版本號作為第一版本號。第三獲取子單元622用于獲取所查找到的子訂單中與當(dāng)前購買訂單所包括的欲更新商品種類一致的商品的數(shù)量。第二判斷子單元623用于判斷欲更新商品的數(shù)量變化起點與所獲取的商品數(shù)量是否一致，當(dāng)欲更新商品的數(shù)量變化起點與所找到的商品對應(yīng)的數(shù)量一致時，再次獲取所查找到的子訂單中與當(dāng)前購買訂單所包括的欲更新商品種類一致的商品的版本號作為第二版本號。第三判斷子單元624用于判斷第二版本號是否等于第一版本號，當(dāng)?shù)诙姹咎柕扔诘谝话姹咎枙r，將所找到的子訂單中對應(yīng)商品的數(shù)量更新為與欲更新商品的數(shù)量變化終點一致，將所述對應(yīng)商品的版本號加一。

進一步的，所述多個客戶端包括一個群主客戶端和多個成員客戶端。如圖15所示，本發(fā)明實施例還提供了另一種購買操作共享裝置110。該購買操作共享裝置110包括：創(chuàng)建請求獲取模塊406、購買操作創(chuàng)建模塊407、購買請求獲取模塊408、綁定模塊409、子訂單創(chuàng)建模塊411、訂單獲取模塊412及總訂單生成模塊413。所述總訂單生成模塊413包括子訂單更新單元521、發(fā)送單元522和第二生成單元523。所述子訂單更新單元521包括：第二獲取子單元621、第三獲取子單元622、第二判斷子單元623及第三判斷子單元624。

其中，創(chuàng)建請求獲取模塊406用于獲取群主客戶端發(fā)送的創(chuàng)建請求，所述創(chuàng)建請求包括第一標(biāo)號；

購買操作創(chuàng)建模塊407用于根據(jù)所述創(chuàng)建請求創(chuàng)建所述當(dāng)前購買操作，將所述群主客戶端與所述當(dāng)前購買操作綁定，將所述第一標(biāo)號作為所述當(dāng)前購買操作的身份標(biāo)識和驗證密碼；

購買請求獲取模塊408用于獲取多個成員客戶端發(fā)送的購買請求，其中，所述購買請求對應(yīng)所述當(dāng)前購買操作；

綁定模塊409用于根據(jù)所述購買請求將每個所述成員客戶端與所述當(dāng)前購買操作綁定。

進一步的，所述購買操作創(chuàng)建模塊407具體用于當(dāng)所述第一標(biāo)號與所存儲的所有購買操作的身份標(biāo)識均不匹配時，根據(jù)所述創(chuàng)建請求創(chuàng)建購買操作。

進一步的，所述購買請求包括輸入密碼，所述綁定模塊409具體用于查找所輸入的輸入密碼與所述驗證密碼匹配的所有成員客戶端，將所查找到的所有成員客戶端與所述當(dāng)前購買操作綁定。

為了避免相同的創(chuàng)建請求對應(yīng)有兩個購買操作的情況，該購買操作共享裝置還包括鎖定模塊。所述鎖定模塊用于當(dāng)在預(yù)設(shè)時間之內(nèi)接收到的創(chuàng)建請求與創(chuàng)建所述當(dāng)前購買操作所對應(yīng)的創(chuàng)建請求一致時，不執(zhí)行該預(yù)設(shè)時間之內(nèi)接收到的創(chuàng)建請求，其中，所述預(yù)設(shè)時間為接收到與所述當(dāng)前購買操作所對應(yīng)的創(chuàng)建請求之后，以及獲取到所述當(dāng)前購買操作創(chuàng)建完成時生成的創(chuàng)建完成指令之前的時間段。

所屬領(lǐng)域的技術(shù)人員可以清楚地了解到，為描述的方便和簡潔，上述描述的系統(tǒng)、裝置和單元的具體工作過程，可以參考前述方法實施例中的對應(yīng)過程，在此不再贅述。

在本申請所提供的幾個實施例中，應(yīng)該理解到，所揭露的裝置和方法，也可以通過其它的方式實現(xiàn)。以上所描述的裝置實施例僅僅是示意性的，例如，附圖中的流程圖和框圖顯示了根據(jù)本發(fā)明的多個實施例的裝置、方法和計算機程序產(chǎn)品的可能實現(xiàn)的體系架構(gòu)、功能和操作。在這點上，流程圖或框圖中的每個方框可以代表一個模塊、程序段或代碼的一部分，所述模塊、程序段或代碼的一部分包含一個或多個用于實現(xiàn)規(guī)定的邏輯功能的可執(zhí)行指令。也應(yīng)當(dāng)注意，在有些作為替換的實現(xiàn)方式中，方框中所標(biāo)注的功能也可以以不同于附圖中所標(biāo)注的順序發(fā)生。例如，兩個連續(xù)的方框?qū)嶋H上可以基本并行地執(zhí)行，它們有時也可以按相反的順序執(zhí)行，這依所涉及的功能而定。也要注意的是，框圖和/或流程圖中的每個方框、以及框圖和/或流程圖中的方框的組合，可以用執(zhí)行規(guī)定的功能或動作的專用的基于硬件的系統(tǒng)來實現(xiàn)，或者可以用專用硬件與計算機指令的組合來實現(xiàn)。

另外，在本發(fā)明各個實施例中的各功能模塊可以集成在一起形成一個獨立的部分，也可以是各個模塊單獨存在，也可以兩個或兩個以上模塊集成形成一個獨立的部分。

所述功能如果以軟件功能模塊的形式實現(xiàn)并作為獨立的產(chǎn)品銷售或使用時，可以存儲在一個計算機可讀取存儲介質(zhì)中?；谶@樣的理解，本發(fā)明的技術(shù)方案本質(zhì)上或者說對現(xiàn)有技術(shù)做出貢獻的部分或者該技術(shù)方案的部分可以以軟件產(chǎn)品的形式體現(xiàn)出來，該計算機軟件產(chǎn)品存儲在一個存儲介質(zhì)中，包括若干指令用以使得一臺計算機設(shè)備(可以是個人計算機，服務(wù)器，或者網(wǎng)絡(luò)設(shè)備等)執(zhí)行本發(fā)明各個實施例所述方法的全部或部分步驟。而前述的存儲介質(zhì)包括：U盤、移動硬盤、只讀存儲器(ROM，Read-Only Memory)、隨機存取存儲器(RAM，Random Access Memory)、磁碟或者光盤等各種可以存儲程序代碼的介質(zhì)。需要說明的是，在本文中，諸如第一和第二等之類的關(guān)系術(shù)語僅僅用來將一個實體或者操作與另一個實體或操作區(qū)分開來，而不一定要求或者暗示這些實體或操作之間存在任何這種實際的關(guān)系或者順序。而且，術(shù)語“包括”、“包含”或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、物品或者設(shè)備不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、物品或者設(shè)備所固有的要素。在沒有更多限制的情況下，由語句“包括一個……”限定的要素，并不排除在包括所述要素的過程、方法、物品或者設(shè)備中還存在另外的相同要素。

以上所述僅為本發(fā)明的優(yōu)選實施例而已，并不用于限制本發(fā)明，對于本領(lǐng)域的技術(shù)人員來說，本發(fā)明可以有各種更改和變化。凡在本發(fā)明的精神和原則之內(nèi)，所作的任何修改、等同替換、改進等，均應(yīng)包含在本發(fā)明的保護范圍之內(nèi)。