處理用戶請求的方法和裝置的制造方法
【專利摘要】本公開是關于一種處理用戶請求的方法，應用于服務器，所述方法包括：在所述服務器的可用服務進程列表中，存在有占用所述服務器的內存超過預定的內存閾值的服務進程時，將所述服務進程從所述可用服務進程列表中刪除；將所述服務進程結束；創(chuàng)建新的服務進程，并將所述新的服務進程添加到所述可用服務進程列表中；根據(jù)當前的可用服務進程列表，處理所述服務器接收的用戶請求。這樣，減少了垃圾收集的運行，減少了服務響應時間，從而提高了響應的即時性，保證了服務的高可用性，提升了用戶體驗。
【專利說明】
處理用戶請求的方法和裝置
技術領域
[0001]本發(fā)明涉及服務器進程運行領域，具體地，涉及一種處理用戶請求的方法和裝置。
【背景技術】
[0002]目前，越來越多的服務器中都采用了帶垃圾收集器的語言(例如Go，Java)進行開發(fā)，以提高開發(fā)效率，降低維護成本。使用垃圾收集器，運行垃圾收集都需要停止程序響應(Stop the world)，由于垃圾收集運行的時機存在不確定性，往往程序負荷較大的時候會頻繁的觸發(fā)，從而影響業(yè)務響應的實時性。對于很多服務器平臺，都會影響響應的實時性，將會降低用戶體驗。例如，對于電商平臺來說，會影響成單的數(shù)量。
[0003]上述問題可以通過使服務器盡量擴大物理內存、優(yōu)化程序的內存使用、或者使程序盡量降低內存占用來解決，以減少GC(Gabage Collect1n)阻塞時間。但是，擴大物理內存會導致成本上升，如果考慮如何減少內存占用問題的話，開發(fā)周期變長，小內存開發(fā)會影響業(yè)務的擴展。

【發(fā)明內容】

[0004]本發(fā)明的目的是提供一種對用戶請求能夠快速響應的、處理用戶請求的方法和裝置。
[0005]根據(jù)本公開實施例的第一方面，提供一種處理用戶請求的方法，應用于服務器。所述方法包括:在所述服務器的可用服務進程列表中，存在有占用所述服務器的內存超過預定的內存閾值的服務進程時，將所述服務進程從所述可用服務進程列表中刪除;將所述服務進程結束;創(chuàng)建新的服務進程，并將所述新的服務進程添加到所述可用服務進程列表中；根據(jù)當前的可用服務進程列表，處理所述服務器接收的用戶請求。
[0006]可選地，所述將所述服務進程結束的步驟包括:在刪除所述服務進程預定時長之后，將所述服務進程結束。
[0007]可選地，所述根據(jù)當前的可用服務進程列表，處理所述服務器接收的用戶請求的步驟包括:按照負載均衡策略，將所述服務器接收的用戶請求分配到當前的可用服務進程列表中的一個或多個服務進程中進行處理。
[0008]可選地，所述方法還包括:停止垃圾收集機制的運行。
[0009]可選地，所述內存閾值小于垃圾收集閾值，所述垃圾收集閾值為能夠觸發(fā)垃圾收集機制運行的、服務進程所占用的最小內存值。
[0010]根據(jù)本公開實施例的第二方面，提供一種處理用戶請求的裝置，應用于服務器。所述裝置包括:刪除模塊，用于在所述服務器的可用服務進程列表中，存在有占用所述服務器的內存超過預定的內存閾值的服務進程時，將所述服務進程從所述可用服務進程列表中刪除;結束模塊，用于將所述服務進程結束;創(chuàng)建添加模塊，用于創(chuàng)建新的服務進程，并將所述新的服務進程添加到所述可用服務進程列表中；處理模塊，用于根據(jù)當前的可用服務進程列表，處理所述服務器接收的用戶請求。[0011 ]通過上述技術方案，將超過預定的內存閾值的服務進程結束，并創(chuàng)建新的服務進程，這樣，減少了垃圾收集的運行，減少了服務響應時間，從而提高了響應的即時性，保證了服務的高可用性，提升了用戶體驗。
[0012]本發(fā)明的其他特征和優(yōu)點將在隨后的【具體實施方式】部分予以詳細說明。
【附圖說明】
[0013]此處的附圖被并入說明書中并構成本說明書的一部分，示出了符合本公開的實施例，并與說明書一起用于解釋本公開的原理。
[0014]圖1是根據(jù)一示例性實施例示出的處理用戶請求的方法的流程圖；
[0015]圖2是根據(jù)另一示例性實施例示出的處理用戶請求的方法的流程圖；
[0016]圖3是根據(jù)又一示例性實施例示出的處理用戶請求的方法的流程圖；
[0017]圖4是根據(jù)又一示例性實施例示出的處理用戶請求的方法的流程圖；
[0018]圖5是根據(jù)一示例性實施例示出的處理用戶請求的裝置的框圖；
[0019]圖6是根據(jù)另一示例性實施例示出的處理用戶請求的裝置的框圖；
[0020]圖7是根據(jù)又一示例性實施例示出的處理用戶請求的裝置的框圖；
[0021]圖8是根據(jù)又一示例性實施例示出的處理用戶請求的裝置的框圖；以及
[0022]圖9是根據(jù)一示例性實施例示出的處理用戶請求的裝置的框圖。
【具體實施方式】
[0023]這里將詳細地對示例性實施例進行說明，其示例表示在附圖中。下面的描述涉及附圖時，除非另有表示，不同附圖中的相同數(shù)字表示相同或相似的要素。以下示例性實施例中所描述的實施方式并不代表與本公開相一致的所有實施方式。相反，它們僅是與如所附權利要求書中所詳述的、本公開的一些方面相一致的裝置和方法的例子。
[0024]圖1是根據(jù)一示例性實施例示出的處理用戶請求的方法的流程圖，如圖1所示，所述方法用于服務器中，包括以下步驟。
[0025]在步驟Sll中，在所述服務器的可用服務進程列表中，存在有占用所述服務器的內存超過預定的內存閾值的服務進程時，將所述服務進程從所述可用服務進程列表中刪除。
[0026]在步驟S12中，將所述服務進程結束。
[0027]在步驟S13中，創(chuàng)建新的服務進程，并將所述新的服務進程添加到所述可用服務進程列表中。
[0028]在步驟S14中，根據(jù)當前的可用服務進程列表，處理所述服務器接收的用戶請求。
[0029]通過上述技術方案，將超過預定的內存閾值的服務進程結束，并創(chuàng)建新的服務進程，這樣，減少了垃圾收集的運行，減少了服務響應時間，從而提高了響應的即時性，保證了服務的高可用性，提升了用戶體驗。
[0030]具體地，服務器中通常設置有多個服務進程，這些服務進程可以同時對用戶的多個請求進行處理。并且，在服務器中可以配置有可用服務進程列表。所述可用服務進程列表為當前可以接收任務的服務進程的列表。當服務器接收到用戶請求時，從可用服務進程列表中選取一些服務進程，并指示其來處理。
[0031]根據(jù)本公開的實施例，在步驟Sll中，可以對每個服務進程所占用的內存進行實時監(jiān)控，當監(jiān)控到有服務進程占用的內存超過預定的內存閾值時，將所述服務進程從可用服務進程列表中刪除。此時，如果接收到新的用戶請求，則被刪除出可用服務進程列表的服務進程，將不會接收到新的任務。
[0032]在步驟S12中，將所述服務進程結束。其中，結束為強制結束。結束進程即殺死(kill)進程。由于被刪除出可用服務進程列表的服務進程將不會被指派給新的任務，因此，可以直接將其結束。之后可以創(chuàng)建新的服務進程，以保證服務的高可用性。
[0033]由于被刪除的服務進程可能還需要一定的時間來處理之前的用戶請求，因此，可以在所述服務進程處理完之前接收的用戶請求之后，再將其結束。圖2是根據(jù)另一示例性實施例示出的處理用戶請求的方法的流程圖。如圖2所示，在圖1的基礎上，將所述服務進程結束的步驟(步驟S12)可以包括步驟S121。
[0034]在步驟S121中，在刪除所述服務進程預定時長之后，將所述服務進程結束。
[0035]其中，所述預定時長可以設置為保證所述服務進程能夠在預定時長內完成之前分配的用戶請求。例如預定時長可以為一分鐘。這樣，在所述服務進程被結束之前，能夠執(zhí)行完被分配的全部任務，保證了服務器處理用戶請求的完整性，避免出現(xiàn)一些用戶請求得不到響應的情況。
[0036]返回圖1，在步驟S13中，創(chuàng)建新的服務進程，并將所述新的服務進程添加到所述可用服務進程列表中。
[0037]雖然步驟S13和步驟S14以數(shù)字的順序表示，但是，并不表示它們具有先后順序，也可以同時進行。也就是，可以在結束所述服務進程后再創(chuàng)建新的服務進程，也可以在結束所述服務進程的同時創(chuàng)建新的服務進程。新的服務進程被創(chuàng)建以后就可以被添加到可用服務進程列表中，這樣，新的服務進程就可以隨時準備接收用戶請求。對于可用服務進程列表的存儲、維護、以及對用戶請求的分配，例如可以通過反向代理服務器來運行。
[0038]在步驟S14中，根據(jù)當前的可用服務進程列表，處理服務器接收的用戶請求。
[0039]如前所述，服務器可以將接收到的用戶請求分配到當前可用服務進程列表中的一個或多個服務進程中，由服務進程來處理接收到的用戶請求。根據(jù)本公開的實施例，可用服務進程列表是可以更新的，所述更新包括將占用內存超過預定的內存閾值的服務進程刪除，以及添加新創(chuàng)建的服務進程。可以理解的是，只要沒有停止程序響應，服務器隨時可以接收用戶請求，因此，該步驟S14可以是在以上步驟Sll?步驟S13中的任意位置。也就是，月艮務器在接收到用戶請求時，可以根據(jù)當時的可用服務進程列表分配任務。
[0040]為了將用戶請求盡量平均地分配到各個服務進程中，可以按照負載均衡策略進行分配。圖3是根據(jù)又一示例性實施例示出的處理用戶請求的方法的流程圖。如圖3所示，在圖1的基礎上，根據(jù)當前的可用服務進程列表，處理服務器接收的用戶請求的步驟(步驟S14)可以包括步驟SI 41。
[0041]在步驟S141中，按照負載均衡策略，將服務器接收的用戶請求分配到當前的可用服務進程列表中的一個或多個服務進程中進行處理。
[0042]所述負載均衡策略可以采用相關技術中常用的均衡策略。在該實施例中，根據(jù)負載均衡策略分配任務，避免了服務進程之間工作量差異過大的情況，并且減少了服務器執(zhí)行上述結束和創(chuàng)建服務進程的動作，減少了服務器的工作量。
[0043]如前所述，在相關技術中，服務器通常運行垃圾收集來應對負荷較大的狀況。在垃圾收集的運行當中，當服務進程占用的內存大于垃圾收集閾值時，會觸發(fā)垃圾收集的運行。通過上述實施例，能夠有效地應對服務器負荷較大的狀況，因此，在本公開的一實施例中，可以停止垃圾收集機制的運行。
[0044]圖4是根據(jù)又一示例性實施例示出的處理用戶請求的方法的流程圖。如圖4所示，在圖1的基礎上，所述方法還可以包括步驟S15。
[0045]在步驟S15中，停止垃圾收集機制的運行。
[0046]可以理解的是，雖然圖4中，步驟S15排在最后，但是，停止垃圾收集機制的運行可以不受上述步驟Sll?步驟S14的順序的限制，S卩，可以與上述步驟具有任意的順序關系。在該實施例中，停止垃圾收集機制，能夠減小服務器的工作量，從而加快服務器的運行速度。
[0047]另外，服務器中的垃圾收集機制也可以不被停止，而將所述垃圾收集閾值設置得高于所述內存閾值，這樣將停止絕大部分垃圾收集的運行。因此，在本公開的又一實施例中，服務器中可以設置內存閾值小于垃圾收集閾值，其中，所述垃圾收集閾值為能夠觸發(fā)垃圾收集機制運行的、服務進程所占用的最小內存值。這樣，一方面，在通常狀況下，步驟Sll?步驟S14能夠處理大部分的服務器負荷較大的狀況。另一方面，必要的時候，服務器還能夠應用垃圾收集機制來應付負荷較大的狀況。
[0048]通過上述技術方案，將超過預定的內存閾值的服務進程結束，并創(chuàng)建新的服務進程，這樣，減少了垃圾收集的運行，減少了服務響應時間，從而提高了響應的即時性，保證了服務的高可用性，提升了用戶體驗。
[0049]本公開還提供一種處理用戶請求的裝置，應用于服務器。圖5是根據(jù)一示例性實施例示出的處理用戶請求的裝置的框圖。如圖5所示，所述裝置包括刪除模塊11、結束模塊12、創(chuàng)建添加模塊13和處理模塊14。
[0050]所述刪除模塊11用于在所述服務器的可用服務進程列表中，存在有占用所述服務器的內存超過預定的內存閾值的服務進程時，將所述服務進程從所述可用服務進程列表中刪除。
[0051 ]所述結束模塊12用于將所述服務進程結束。
[0052]所述創(chuàng)建添加模塊13用于創(chuàng)建新的服務進程，并將所述新的服務進程添加到所述可用服務進程列表中。
[0053]所述處理模塊14用于根據(jù)當前的可用服務進程列表，處理所述服務器接收的用戶請求。
[0054]圖6是根據(jù)另一示例性實施例示出的處理用戶請求的裝置的框圖。如圖6所示，在圖5的基礎上，所述結束模塊12包括結束子模塊121。
[0055]所述結束子模塊121用于在刪除所述服務進程預定時長之后，將所述服務進程結束。
[0056]圖7是根據(jù)又一示例性實施例示出的處理用戶請求的裝置的框圖。如圖7所示，在圖5的基礎上，所述處理模塊14包括分配子模塊141。
[0057]所述分配子模塊141用于按照負載均衡策略，將所述服務器接收的用戶請求分配到當前的可用服務進程列表中的一個或多個服務進程中進行處理。
[0058]圖8是根據(jù)又一示例性實施例示出的處理用戶請求的裝置的框圖。如圖8所示，在圖5的基礎上，所述裝置還包括停止模塊15。
[0059]所述停止模塊15用于停止垃圾收集機制的運行。
[0060]可選地，所述內存閾值小于垃圾收集閾值，所述垃圾收集閾值為能夠觸發(fā)垃圾收集機制運行的、服務進程所占用的最小內存值。
[0061]關于上述實施例中的裝置，其中各個模塊執(zhí)行操作的具體方式已經在有關該方法的實施例中進行了詳細描述，此處將不做詳細闡述說明。
[0062]通過上述技術方案，將超過預定的內存閾值的服務進程結束，并創(chuàng)建新的服務進程，這樣，減少了垃圾收集的運行，減少了服務響應時間，從而提高了響應的即時性，保證了服務的高可用性，提升了用戶體驗。
[0063]圖9是根據(jù)一示例性實施例示出的處理用戶請求的裝置900的框圖。例如，裝置900可以被提供為一服務器。參照圖9，裝置900包括處理組件922，其進一步包括一個或多個處理器，以及由存儲器932所代表的存儲器資源，用于存儲可由處理組件922的執(zhí)行的指令，例如應用程序。存儲器932中存儲的應用程序可以包括一個或一個以上的每一個對應于一組指令的模塊。此外，處理組件922被配置為執(zhí)行指令，以執(zhí)行上述處理用戶請求的方法。
[0064]裝置900還可以包括一個電源組件926被配置為執(zhí)行裝置900的電源管理，一個有線或無線網(wǎng)絡接口 950被配置為將裝置900連接到網(wǎng)絡，和一個輸入輸出(I/O)接口 958。裝置900可以操作基于存儲在存儲器932的操作系統(tǒng)，例如Windows ServerTM,Mac OS XTM,UnixTM，LinuxTM，F(xiàn)reeBSDTM 或類似。
[0065]在示例性實施例中，還提供了一種包括指令的非臨時性計算機可讀存儲介質，例如包括指令的存儲器，上述指令可由裝置900的處理器執(zhí)行以完成上述處理用戶請求的方法。例如，所述非臨時性計算機可讀存儲介質可以是ROM、隨機存取存儲器(RAM)、⑶-ROM、磁帶、軟盤和光數(shù)據(jù)存儲設備等。
[0066]本領域技術人員在考慮說明書及實踐本公開后，將容易想到本公開的其它實施方案。本申請旨在涵蓋本公開的任何變型、用途或者適應性變化，這些變型、用途或者適應性變化遵循本公開的一般性原理并包括本公開未公開的本技術領域中的公知常識或慣用技術手段。說明書和實施例僅被視為示例性的，本公開的真正范圍和精神由下面的權利要求指出。
[0067]應當理解的是，本公開并不局限于上面已經描述并在附圖中示出的精確結構，并且可以在不脫離其范圍進行各種修改和改變。本公開的范圍僅由所附的權利要求來限制。
【主權項】
1.一種處理用戶請求的方法，應用于服務器，其特征在于，所述方法包括: 在所述服務器的可用服務進程列表中，存在有占用所述服務器的內存超過預定的內存閾值的服務進程時，將所述服務進程從所述可用服務進程列表中刪除； 將所述服務進程結束； 創(chuàng)建新的服務進程，并將所述新的服務進程添加到所述可用服務進程列表中； 根據(jù)當前的可用服務進程列表，處理所述服務器接收的用戶請求。2.根據(jù)權利要求1所述的方法，其特征在于，所述將所述服務進程結束的步驟包括: 在刪除所述服務進程預定時長之后，將所述服務進程結束。3.根據(jù)權利要求1所述的方法，其特征在于，所述根據(jù)當前的可用服務進程列表，處理所述服務器接收的用戶請求的步驟包括: 按照負載均衡策略，將所述服務器接收的用戶請求分配到當前的可用服務進程列表中的一個或多個服務進程中進行處理。4.根據(jù)權利要求1所述的方法，其特征在于，所述方法還包括: 停止垃圾收集機制的運行。5.根據(jù)權利要求1所述的方法，其特征在于，所述內存閾值小于垃圾收集閾值，所述垃圾收集閾值為能夠觸發(fā)垃圾收集機制運行的、服務進程所占用的最小內存值。6.一種處理用戶請求的裝置，應用于服務器，其特征在于，所述裝置包括: 刪除模塊，用于在所述服務器的可用服務進程列表中，存在有占用所述服務器的內存超過預定的內存閾值的服務進程時，將所述服務進程從所述可用服務進程列表中刪除； 結束模塊，用于將所述服務進程結束； 創(chuàng)建添加模塊，用于創(chuàng)建新的服務進程，并將所述新的服務進程添加到所述可用服務進程列表中； 處理模塊，用于根據(jù)當前的可用服務進程列表，處理所述服務器接收的用戶請求。7.根據(jù)權利要求6所述的裝置，其特征在于，所述結束模塊包括: 結束子模塊，用于在刪除所述服務進程預定時長之后，將所述服務進程結束。8.根據(jù)權利要求6所述的裝置，其特征在于，所述處理模塊包括: 分配子模塊，用于按照負載均衡策略，將所述服務器接收的用戶請求分配到當前的可用服務進程列表中的一個或多個服務進程中進行處理。9.根據(jù)權利要求6所述的裝置，其特征在于，所述裝置還包括: 停止模塊，用于停止垃圾收集機制的運行。10.根據(jù)權利要求6所述的裝置，其特征在于，所述內存閾值小于垃圾收集閾值，所述垃圾收集閾值為能夠觸發(fā)垃圾收集機制運行的、服務進程所占用的最小內存值。11.一種處理用戶請求的裝置，其特征在于，所述裝置包括: 處理器； 用于存儲處理器可執(zhí)行指令的存儲器； 其中，所述處理器被配置為: 在所述服務器的可用服務進程列表中，存在有占用所述服務器的內存超過預定的內存閾值的服務進程時，將所述服務進程從所述可用服務進程列表中刪除； 將所述服務進程結束；創(chuàng)建新的服務進程，并將所述新的服務進程添加到所述可用服務進程列表中；根據(jù)當前的可用服務進程列表，處理所述服務器接收的用戶請求。
【文檔編號】G06F9/50GK105868012SQ201610195430
【公開日】2016年8月17日
【申請日】2016年3月30日
【發(fā)明人】馬鑫, 李偉, 金帥
【申請人】北京小米移動軟件有限公司