CN117097801A - Access method and system, CDN node, electronic equipment and storage medium - Google Patents

Abstract

The embodiments of this application relate to the field of communication technology and disclose an access method and system, CDN node, electronic device and storage medium. The access method is applied to the CDN node, including: receiving an access request sent by the client carrying user information and target URL; when the access request is determined to be in a waiting state based on the user information and target URL, sending a locally cached waiting room page to the client Data for the client to present the waiting room page based on the waiting room page data; when the access request is determined to be in the allowed connection status based on the user information and the target URL, the access request is forwarded to the origin site pointed to by the target URL for the origin site to access Request a response. At least it is helpful to ensure the timeliness of access requests at the same time.

Description

Access methods and systems, CDN nodes, electronic devices and storage media

Technical field

The embodiments of this application relate to the field of communication technology, and in particular to an access method and system, CDN node, electronic device and storage medium.

Background technique

A sudden surge in incoming traffic to a website may cause the website to crash or severely degrade website performance, such as slow loading of the website. This in turn results in a poor user experience, which results in lost sales for the retailer. In order to solve the above problems, virtual waiting room technology came into being. When the traffic of the website is about to reach the bottleneck, the virtual waiting room technology diverts redundant users to the waiting room page, so that user requests are processed and responded to by the target website in an orderly manner. .

However, the current access to the website based on virtual waiting room technology has low timeliness, resulting in poor user experience.

Contents of the invention

The embodiments of the present application provide an access method and system, a CDN node, an electronic device, and a storage medium, which are at least conducive to improving the timeliness of access requests, thereby improving user experience.

According to some embodiments of the present application, on the one hand, the embodiments of the present application provide an access method, which is applied to a CDN node. The method includes: receiving an access request sent by a client, where the access request carries user information and a target URL; When it is determined that the access request is in a waiting state according to the user information and the target URL, the locally cached waiting room page data is sent to the client for the client to present the wait according to the waiting room page data. Room page; when it is determined that the access request is in the allowed connection state based on the user information and the target URL, the access request is forwarded to the origin site pointed to by the target URL for the origin site to Respond to the above access request.

According to some embodiments of the present application, on the other hand, the embodiments of the present application also provide a CDN node, including: an edge application module and a waiting room page module; the edge application module is connected to the waiting room page module; the edge The application module is used to implement the access method as described in any one of the above; the waiting room page module is used to maintain the locally cached waiting room page data of the CDN node to provide the locally cached waiting room page data to the edge application module. Waiting room page data.

According to some embodiments of the present application, on the other hand, the embodiments of the present application also provide an access system, including: several CDN nodes as described above.

According to some embodiments of the present application, another aspect of the embodiment of the present application further provides an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores Instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the access method as described in any of the above embodiments.

According to some embodiments of the present application, on the other hand, the embodiments of the present application also provide a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, the access method as described in any of the above embodiments is implemented. .

The technical solutions provided by the embodiments of this application have at least the following advantages:

When an access request is received and the access request is determined to be in a waiting state based on the user information and target URL carried in the access request, the CDN node sends the locally cached waiting room page data to the client instead of returning to the origin or accessing the third page. The waiting room page data obtained by third-party websites enables the rendering of the waiting room page to be accelerated based on the local cache of the CDN node, ensuring timeliness. Moreover, the processing of access requests by each CDN node shares the pressure of processing access requests on the origin site, which is conducive to improving the carrying capacity of access requests, and can reduce load imbalance and even service unavailability problems, reducing The above-mentioned problems have an adverse impact on the processing of access requests, further improving the timeliness of access requests.

Description of the drawings

One or more embodiments are exemplified by the pictures in the corresponding drawings. These illustrative illustrations do not constitute limitations to the embodiments. Elements with the same reference numerals in the drawings are represented as similar elements. Unless otherwise stated, the figures in the drawings are not intended to be limited to scale.

Figure 1 is a flow chart of an access method provided in an embodiment of the present application;

Figure 2 is another flow chart of an access method provided in an embodiment of the present application;

Figure 3 is another flow chart of the access method provided in an embodiment of the present application;

Figure 4 is another flow chart of the access method provided in an embodiment of the present application;

Figure 5 is another flow chart of the access method provided in an embodiment of the present application;

Figure 6 is another flow chart of the access method provided in an embodiment of the present application;

Figure 7 is another flow chart of the access method provided in an embodiment of the present application;

Figure 8 is another flow chart of the access method provided in an embodiment of the present application;

Figure 9 is another flow chart of the access method provided in an embodiment of the present application;

Figure 10 is a schematic structural diagram of a CDN node provided in an embodiment of the present application;

Figure 11 is another schematic structural diagram of a CDN node provided in an embodiment of the present application;

Figure 12 is a schematic structural diagram of an access system provided in an embodiment of the present application;

Figure 13 is a schematic structural diagram of an electronic device provided in an embodiment of the present application.

Detailed ways

It can be seen from the background technology that currently it is difficult to ensure the timeliness of access requests when accessing websites based on virtual waiting room technology, which affects the user experience.

After analysis, it was found that the reason for the above problems is at least that: the current access to the website based on virtual waiting room technology mainly involves the virtual waiting room technology based on the centralized bill center, which usually first takes the number from the bill center based on the access initiated by the user. Then, after obtaining the number, the access request is allowed to access the website. However, the processing capacity of the ticket center is relatively limited, and it is difficult to process all the requests received in a timely manner. It may even cause overflow due to too many requests, seriously affecting the efficiency of number retrieval and website access, resulting in a delay in requests. Poor timeliness. And regardless of whether there is a sudden increase in traffic, it will bring serious access delays and lead to poor request timeliness.

In order to solve the above problems, embodiments of the present application provide an access method and system, a CDN node, an electronic device and a storage medium. The CDN node processes the user's access request, so that the processing of the access request can be accelerated based on the CDN architecture. , in particular, the CDN node locally caches the waiting room page data, so that the process of entering the waiting room can be accelerated, further reducing the response delay, improving the read and write timeliness, and by allocating the load-bearing pressure and processing pressure of the origin site to each CDN nodes can help reduce the access pressure on waiting room pages, improve the carrying capacity of access requests, process access requests in a timely manner, and improve the timeliness of access requests.

In order to make the purpose, technical solutions and advantages of the embodiments of the present application clearer, each embodiment of the present application will be described in detail below with reference to the accompanying drawings. However, those of ordinary skill in the art can understand that in each embodiment of the present application, many technical details are provided to enable readers to better understand the present application. However, even without these technical details and various changes and modifications based on the following embodiments, the technical solution claimed in this application can also be implemented.

The division of the following embodiments is for the convenience of description and should not constitute any limitation on the specific implementation of the present application. The various embodiments can be combined with each other and referenced with each other on the premise that there is no contradiction.

On the one hand, embodiments of the present application provide an access method, which is applied to content delivery network (ContentDelivery Network, CDN) nodes. In some cases, it is specifically applied to edge application modules in CDN nodes. In this way, the access method provided by the embodiments of the present application can be deployed to CDN nodes through edge applications without the need to modify the CDN node equipment, which is conducive to saving costs and reducing implementation difficulty. At the same time, it can also realize method upgrades more efficiently and conveniently. Iterate.

In some embodiments, the flow of the access method is shown in Figure 1, which at least includes the following steps:

Step 101: Receive an access request sent by the client. The access request carries user information and target URL.

In the embodiment of this application, the user information may be any or some information that can uniquely identify a user, such as user account name, client device identification, etc. The target Uniform Resource Locator (URL) is the URL that the access request wants to access, where the URL is the address pointing to the website that you want to access.

In some cases, the target URL can be the URL of any website that provides a waiting room page. That is, there is no need to determine whether the website to be accessed by the received access request provides a waiting mechanism, which is more efficient. In some cases, it can be any URL without limiting the website pointed to by the URL. At this time, you can determine whether to perform corresponding processing by judging whether the website that the received access request needs to access provides a waiting mechanism. In this way, whether it is a website that provides a waiting room service room or a website that does not provide a waiting room service, the CDN node All can be received and processed uniformly, without the need to set up another process dedicated to processing access requests initiated to websites that do not provide waiting room services, realizing the unification of the processing processes for requests to access different types of websites.

It can be understood that when the target URL is any URL, the origin site it points to may be a website that provides waiting room services, or it may be a website that does not provide waiting room services. At this time, the CDN node can be configured according to actual needs, so that the CDN node can determine which type of URL needs to perform the subsequent steps 102 and so on to provide the waiting room service, and which type of URL does not need to perform the subsequent steps. 102, etc., can directly follow the general response process of the CDN node, that is, determine whether to return to the origin by judging whether the access request hits the cache.

That is to say, in some embodiments, after step 101, the access method also includes: receiving a request sent by the client, parsing the target URL carried in the request, and detecting whether the source site pointed to by the target URL is a website that provides waiting room services, When it is detected that the source site pointed by the target URL is a website that provides waiting room services, perform step 102 or step 103; when it is detected that the source site pointed by the target URL is a website that does not provide waiting room services, detect access Whether the request hits the cache to determine whether to forward the access request to the upper-level CDN node or origin site.

The embodiment of this application does not limit the form of the access request. It can be any form of request for initiating access to a URL, such as a Hyper Text Transfer Protocol (Hyper Text Transfer Protocol, HTTP) request, etc., which will not be discussed here. Described one by one.

Among them, since the access method is applied to the CDN node, the access request initiated by the client can be accelerated and load balanced based on the CDN node. Compared with the centralized ticket center, its processing efficiency will be improved. The origin site pointed by the target URL Part of the processing pressure will be borne by the CDN node, which will help reduce the processing pressure of the origin site, improve the access request carrying capacity as a whole, avoid access delays caused by poor carrying capacity, and thus improve the timeliness of access requests.

Step 102: When it is determined that the access request is in a waiting state based on the user information and the target URL, locally cached waiting room page data is sent to the client for the client to present the waiting room page based on the waiting room page data.

In this embodiment, the waiting state represents a state in which the access request cannot be immediately responded to by the origin station. That is, the access request needs to enter the waiting room and wait for a period of time before it can be responded to by the origin station.

This embodiment does not limit the waiting room page data, which can be any page data that can be perceived by the user as being in a waiting state after being presented.

In some embodiments, the waiting room page may be shared by different users, that is, the waiting room page data of different users are the same. This can reduce the amount of waiting room page data that needs to be maintained in CDN nodes, simplify the processing process, and improve processing efficiency.

In some embodiments, the waiting room page may also vary with different users, or with different characteristics of the group to which the user belongs. In this way, different waiting room pages are presented to different users on the client. That is, a customized waiting room page, that is to say, it can provide users with differentiated waiting room services, which is conducive to improving service diversity and service quality, and improving user experience.

Based on this, in some embodiments, as shown in Figure 2, when the result of the query is that the access request is in a waiting state, the access method also includes the following steps:

Step 104: Determine customized page data based on customized reference information, which includes at least one of the following information: user information and connection status of the access request.

This embodiment does not limit the customized page data. It can be any page data related to the current access request, and the page customized data corresponding to at least part of the access requests is different.

Accordingly, while sending the locally cached waiting room page data to the client, the access method also includes the following steps: sending customized page data to the client.

This way, at the client, it will be able to render the customized waiting room page based on the waiting room page data and the custom page data. At the same time, because the waiting room page data is stored separately instead of repeatedly storing the waiting room page data based on different users, it is helpful to reduce the occupation of the CDN cache by the waiting room page data.

In some examples, the page customization data can be specific information about the connection status of the access request. After being presented, it can display the current waiting number of the target URL, which waiting position this access request is at, etc.

In this way, by buffering the waiting room page data locally on the CDN node, the waiting room page data can be obtained without going back to the source or accessing a third party, achieving CDN node-based acceleration and improving the timeliness of access requests.

Step 103: When it is determined that the access request is in the allowed connection state based on the user information and the target URL, the access request is forwarded to the origin site pointed to by the target URL so that the origin site can respond to the access request.

In this embodiment, the allowed connection state represents a state in which the access request can be immediately responded to by the origin station, that is, the access request does not need to enter the waiting room to wait, but can be immediately responded to by the origin station.

It should be noted that this embodiment does not limit the implementation of determining the status of the access request based on the user information and the target URL.

In some embodiments, as shown in Figure 3, after forwarding the access request to the origin site pointed to by the target URL, the access method further includes the following steps:

Step 105: After ending the access to the target URL based on the access request, trigger the step of determining the target client; among the other clients currently rendering the waiting room page based on the access to the target URL, the target client requested access the earliest .

In order to facilitate those skilled in the art to better understand the target client described in the above embodiments, examples are provided below.

Assume that there are k+1 access requests in a short period of time that successively initiate access to the origin site pointed by the target URL, and after the kth access request accesses the origin site pointed by the target URL, the request accessed by the origin site pointed by the target URL The number reaches the maximum number of requests that can be carried, then when the response to the request appears in the request currently accessed by the origin site pointed to by the target URL, since there is the k+1th access request that is still pointed to the target URL The source site requests the earliest access request. Therefore, the step of using the client that initiated the k+1th access request as the corresponding target client will be triggered at this time.

The embodiments of this application do not limit the method of determining the earliest time of access request and how to record the time of requested access.

In some embodiments, a data table can be set up to record the access time requested by each access request. Specifically, the recorded time can be the writing time of the relevant information of the access request, etc., so that the source site pointed to by the target URL When a request for response completion occurs, the target client is determined based on the recorded time.

In some embodiments, the access requests can also be assigned sequence numbers according to the access time of each access request. The request for access earlier has a smaller number, and the request for access later has a larger number, so that the number pointed to by the target URL can be When the origin site responds to a completed request, it determines the target client based on the sequence number, etc., so I won’t go into details here.

Among them, information such as the access time requested by each access request can be saved in a database, such as the local database of the CDN node, or an external database that can be accessed by calling relevant services.

Step 106: Forward the target client's request to the origin site pointed to by the target URL.

In other words, earlier requests will be responded to first, and access requests will be responded to in the order of requests, ensuring fairness of the service and improving user experience.

It can be understood that if the responses to N access requests are completed at the same time or close to the same time, at this time, the resources of the origin site corresponding to these N access requests are freed and can be used to respond to another N access requests. This additional The N access requests are still determined according to the method provided in the above embodiment, so that the N access requests that previously requested access will be forwarded to the origin site pointed to by the target URL first, and the previous requests will be responded to first, ensuring that The fairness of services is conducive to improving user experience.

Of course, the above is only a specific example. In some embodiments, the user information may also carry a priority identifier. In this case, the target client may also be determined based on the priority indicated by the priority identifier. It is understandable that in order to better provide services to users, differentiated services can also be provided to different users, such as setting priorities for them, thereby helping to meet the higher timeliness requirements of specific users for access requests.

In some embodiments, the waiting room page data carries data used to regularly trigger a request to access the target URL, so that after receiving the waiting room page data, the client will regularly trigger an access request to the target URL based on the data it carries. Based on this, as shown in Figure 4, after sending the locally cached waiting room page data to the client, the access method also includes the following steps:

Step 107: Receive the access periodically initiated by the client based on the waiting room page data to determine the status of the access request again and perform corresponding steps according to the status of the access request until the access request is forwarded to the origin site.

That is to say, in the waiting state, it also provides a scheduled refresh function. Through multiple queries, the state of the access request can be discovered in a timely manner from the waiting state to the allowed connection state, thereby realizing the origin site's response to the access request in a timely manner. , to avoid excessive waiting time. This enables access requests to be responded to in a timely manner, which is beneficial to improving user experience.

It should be noted that the client periodically initiates access based on the waiting room page data. Since it is related data carried in the waiting room page data (it is understandable that in general, this data is program code data), therefore, it will automatically trigger again. The action of initiating access is implemented, so that the response to the access request can be realized in time without the user being aware of it, and there is no need to modify the client, which is conducive to improving the user experience and reducing implementation costs and difficulty.

Of course, the above is just an example. The action of triggering re-initiation of access can also be implemented when there is no relevant data carried in the waiting room page data. At this time, the client can regularly initiate access to the target URL through its own deployed program. Implementing related functions will help reduce the amount of waiting room page data that the CDN node needs to maintain locally, and reduce the occupation of the storage space of the CDN node.

It should also be noted that in the process of regularly determining the status of the access request and performing corresponding steps according to the status of the access request, if the access request is still in the waiting state, it can also be detected whether the page data that needs to be presented changes. If it changes, Then send the changed page data to the client. If no change occurs, no data will be generated. For example, when a change in the connection status of the target URL is detected, the page data corresponding to the changed connection status is sent to the client, otherwise no action is taken. In other words, the waiting situation is synchronized to the client in real time, so that the user can understand the waiting situation in real time, which is beneficial to improving the user experience.

In some embodiments, after sending the locally cached waiting room page data to the client, the access method further includes the following steps: monitoring whether the client initiates access regularly based on the waiting room page data; not monitoring within the first preset time period. When the client periodically initiates access based on the waiting room page data, the record corresponding to the access request is updated to delete the record corresponding to the access request.

It is understandable that users may give up access to the target URL while waiting. Among them, when the user gives up access, he can click the give up access button provided on the waiting room page, and then the client notifies the CDN node to give up the request, etc. At this time, if the CDN node is still refreshed regularly, it will cause a waste of resources. Therefore, the above embodiment can promptly detect the user's action of abandoning the access by monitoring whether the access is initiated again and delete it, which is conducive to accurately adjusting the redundancy of the waiting room and ensuring whether the queued users are still waiting to access the origin site pointed to by the target URL. .

It should be noted that the above embodiment does not limit the value of the first preset duration, which may be determined based on the user's waiting requirements, the number of waiting connections allowed by the origin station, etc. Of course, in addition to monitoring whether access is initiated again, you can also monitor whether the client interrupts the connection, whether the client sends related messages to give up the access, etc., so as to make relevant processing in a timely manner and avoid resource waste, which will not be discussed here. Described one by one.

In some embodiments, as shown in Figure 5, after forwarding the access request to the origin site pointed to by the target URL, the access method further includes the following steps:

Step 108: If it is not detected that the client initiates access based on the user information and the target URL within the second preset time period, update the record corresponding to the access request to delete the record corresponding to the access request.

That is to say, after the connection is realized, a valid time is defined for the connection, that is, the second preset time period. When access is initiated again within the valid time, the connection can still be used to continue to access the origin site pointed to by the target URL. During the effective time, the connection is no longer maintained, and the resources occupied by the connection are provided to other connections, so that the connection can be efficiently utilized, and the adverse impact on other connections can be reduced, and the time occupied by a single connection on the origin site resources can be avoided. Too long to facilitate the establishment of other connections. This improves user experience and reduces the pressure of requesting information records.

It should be noted that this embodiment does not limit the specific value of the second preset duration, which can be determined based on the processing pressure of the origin station, the number of requests currently in the waiting state, etc., and will not be described again here.

According to the access method provided in the above embodiment, when an access request is received and the access request is determined to be in a waiting state based on the user information and target URL carried in the access request, the CDN node sends the locally cached waiting room page data to the client. Instead of obtaining the waiting room page data by going back to the source or visiting a third-party website, the rendering of the waiting room page can be accelerated based on the local cache of the CDN node, ensuring timeliness. In addition, the processing of access requests by each CDN node shares the pressure of processing access requests on the origin site, which is conducive to improving the carrying capacity of access requests, and can reduce load imbalance and even service unavailability problems, further improving ensure the timeliness of access requests.

In addition, compared with the currently provided virtual waiting room technology based on a centralized bill center, the access method implemented on the CDN node mentioned above can actually be regarded as the function of the bill center being moved down from the bill center to each CDN node close to the user side. Among them, relative to the bill center, CDN nodes can be regarded as edges. In other words, the access method provided by the embodiment of this application actually deploys the functions of the ticket center to the CDN node located at the user edge through the edge application. In this way, the access request can be received by the CDN node on the CDN. The driver on the node processes the access request locally, which reduces the delay of the access request, improves the timeliness of the access request, and also reduces the processing pressure.

In addition to the aforementioned virtual waiting room technology based on a centralized ticket center, there is also a virtual waiting room technology based on a regional ticket center. When accessing the website, first the access initiated by the user will get a number from the ticket service provider in the region to which it belongs. Different regional ticket service providers independently maintain their own ticket queues, and then when the number is obtained Access requests are allowed to the website only if required. At this time, data consistency cannot be guaranteed, resulting in the inability to turn on or off the waiting room function synchronously, which may lead to unbalanced load on the website or even service unavailability.

In order to solve the above problem, in some embodiments, the CDN node is deployed with a local database, and the local database of the CDN node maintains data synchronization with the local databases of other CDN nodes. Among them, the local database is a database deployed locally on the CDN node.

Correspondingly, as shown in Figure 6, after receiving the access request sent by the client, the access method also includes:

Step 109: Query the local database according to the user information and the target URL to determine whether the access request is in a waiting state.

In this embodiment, the local database stores user information, target URL, and connection status related to the target URL, such as user identification, whether the user has currently established a connection with the target URL, the maximum number of connections currently allowed by the target URL, and the current number of connections of the target URL. The number of connections, the maximum number of waiting connections currently allowed by the target URL, etc. will not be described one by one here.

In this way, each CDN node achieves global consistency of user information, target URL and related information through data synchronization between their respective local databases, without the number being used (that is, which number is the current access request waiting for)? There are idle and unused numbers among the requested sequence numbers) or problems such as access errors caused by different requests being assigned the same number.

In some embodiments, querying in the local database based on the user information and the target URL can be implemented in the following manner: based on the user information and the target URL, querying in the local database whether the client corresponding to the user information is in an established state with the target URL. The status of the connection; when the client corresponding to the user information is not in the state of establishing a connection with the target URL, query the connection status of the target URL in the local database based on the target URL. Correspondingly, after querying the local database according to the user information and the target URL, the access method also includes: determining whether the access request is in a waiting state according to the connection status of the target URL.

It should be noted that the client may initiate access to different URLs within a short period of time, that is, the local database may have the same user information regarding the connection status of multiple URLs. When the client initiates access to the target URL, that is, sends an access request carrying the target URL, the same user information exists in the local database regarding whether a connection between multiple URLs is established between the client and the corresponding URL. This When querying, whether the client corresponding to the user information is in the established connection state with the target URL, not other URLs. Based on this, in some embodiments, the same user information in the local database is only relevant information about whether a specific URL establishes a connection between the client and the URL. At this time, there is no interference from multiple URLs, and there is no need to use Query the target URL, so I won’t go into details here.

In some embodiments, determining whether the access request is in the waiting state according to the connection status of the target URL can be implemented in the following manner: when the connection to the target URL is not full, determine that the access request is in the allowed connection status; When the connection is full, the access request is determined to be in a waiting state.

In order to facilitate those skilled in the art to better understand the above embodiments, examples of querying and determining the status of an access request will be described below.

First, based on the user information and the target URL, it is determined whether the client corresponding to the user information has established a connection with the origin site pointed to by the target URL. If yes, it means that the access initiated by the client can be responded directly without waiting, that is, the access request is in the running connection state; if not, you need to further confirm whether the origin site pointed to by the target URL can access the access request. Specifically, we first need to query the number of requests currently connected to the origin site pointed by the target URL based on the target URL, that is, the connection status of the target URL; and then determine the number of requests currently connected to the origin site pointed to by the target URL based on the query. Whether the upper limit of the number of requests that the origin site pointed to by the target URL can handle has been reached, that is, determine whether the connection to the target URL is full. If yes, the access request is determined to be in the waiting state; if not, the access request is determined to be in the running connection state.

That is to say, the above embodiment uses the upper limit of the number of requests that the origin site pointed to by the target URL can handle, so that the requests that the origin site pointed to by the target URL needs to process will not exceed its carrying capacity, ensuring that it can use sufficient resources to handle already processed requests. Respond to connection requests to avoid users waiting for too long or invalid waiting, improve response quality, and thus improve user experience. Of course, the above is only an example of querying and determining the status of the access request based on the query results. In other embodiments or examples, it can also be implemented in other ways, and the details will not be described here.

It should be noted that when there are too many access requests in the waiting state, the waiting time for subsequent access requests that enter the waiting state may be too long. At this time, in order to further prevent users from waiting too long, you can also set a rejection status for access requests. Specifically, the number of requests accessed by the origin site pointed to by the target URL reaches the upper limit, and the requests in the waiting state also reach the upper limit before receiving them again. Incoming access requests are no longer in a waiting state, but will be in a denied state.

In some embodiments, the data in the local database of the CDN node is stored in the form of key-value (KV), that is, the local database is a KV database, so that the query can be completed more efficiently and is beneficial to the local database and data Central data maintenance.

Based on this, in some embodiments, as shown in Figure 7, querying the local database according to user information and target URL may include the following steps:

Step 1091: Generate a user ID based on the user information. The user ID is used to uniquely identify the user information.

This embodiment does not limit the user identification, which may be a string or a label, etc., which will not be described in detail here.

Step 1092: Query in the local database according to the user ID and target URL.

Correspondingly, access methods also include:

Step 1010: If the query based on the user ID fails, query the connection status of the target URL in the local database and update the user ID, target URL, and connection status of the target URL to the local database in the form of KV.

In this embodiment, the target URL is an address pointing to the website you want to visit. The connection status of the target URL can be one or more of the number of connections of the target URL, the number of waiting connections, the upper limit of the number of connections, etc. It can also be a state used to indicate whether the upper limit of the number of connections has been reached or whether the upper limit of the number of waiting connections has been reached. Flag bits, etc. will not be described one by one here.

It is understandable that user information may include a variety of information, and the efficiency of querying through multiple types of information will be relatively low. Converting it into a user ID that uniquely identifies the user information and then writing it to the local database in KV form can simplify the query. It is helpful to improve query efficiency, reduce maintenance difficulty, and reduce the probability of errors.

Of course, the fact that the local database is a KV database is only an example of the local database. In some embodiments, the local database can also be an online transaction processing (On-Line Transaction Processing, OLTP) database, etc.

In some embodiments, data synchronization between the local databases of each CDN node is implemented through the same data center to which they are commonly connected. That is, the local database of each CDN node can be regarded as multiple edge databases centered on the data center, but these databases are distributed on different CDN nodes. In this way, data synchronization between the local databases of each CDN node is achieved through the push mechanism and subscription mechanism of the data center.

In some embodiments, as shown in Figure 8, the access method also includes:

Step 1011: When data update occurs in the local database, the updated data is sent to the data center, so that the data center can push the received updated data to the local databases of other CDN nodes that subscribe to the updated data.

That is, allowing data synchronization from the local database to the data center and back to the local database.

It should be noted that this embodiment does not limit the situation of sending updates to the local database. It can be any corresponding data sending in the local database caused by related changes in access requests on the CDN node where the local database is located. Updates due to changes. For example, newly writing information related to an access request, deleting information related to an access request, changing an access request from the waiting state to the allowed connection state, etc. can all be cases where the local database sends updates.

For example, since the process of forwarding the target client's request to the origin site pointed to by the target URL in step 106 provided in the foregoing embodiment is essentially the target client transitioning from the waiting state to the connection allowed state, therefore, the target client needs to be transferred to the target client in a timely manner. The corresponding waiting status is updated to the allowed connection status. At this time, if the user's corresponding status information is saved based on the local database, it will appear that data update has occurred in the local database.

It is understandable that in addition to the situation where the local database changes actively, there may also be situations where the local database changes passively, that is, the data in the data center changes first. At this time, the data center actively delivers data to each local database to achieve data synchronization. If the connection status of the target URL changes, the origin site will notify the data center of the change. At this time, the data center will also notify each local database of the change.

Based on this, in some embodiments, as shown in Figure 9, the access method also includes:

Step 1012: When the connection status of the target URL changes, the synchronization data pushed by the data center is received through the local database and synchronized to the local database. The synchronization data is data obtained by the data center according to the change in the connection status of the target URL.

That is, data synchronization is allowed from the data center to the local database of each CDN node.

In some embodiments, data synchronization between the local database of a CDN node and the local databases of other CDN nodes is allowed, and data synchronization between the data center and the local database of each CDN node is allowed.

It should be noted that the above is only an example of the data push and subscription process between the data center and each local database. In some embodiments, it can also be implemented in other ways, such as timing data synchronization, etc., which will not be discussed here. Described one by one.

The steps of the various methods above are divided just for the purpose of clear description. During implementation, they can be combined into one step or some steps can be split into multiple steps. As long as they include the same logical relationship, they are all within the scope of protection of this patent. ; Adding insignificant modifications or introducing insignificant designs to the algorithm or process without changing the core design of the algorithm and process are within the scope of protection of this patent.

On the other hand, the embodiment of the present application also provides a CDN node. As shown in Figure 10, the CDN node 1000 includes: an edge application module 1001 and a waiting room page module 1003; the edge application module 1001 and the waiting room page module 1003 are connected respectively.

Among them, the edge application module 1001 is used to implement the access method provided by any of the above embodiments;

The waiting room page module 1003 is configured to maintain locally cached waiting room page data of the CDN node 1000 to provide the locally cached waiting room page data to the edge application module 1001 .

It should be noted that the above embodiment deploys the edge application module 1001 on the CDN node 1000, so that when the CDN node receives an access request, it can drive itself and the waiting room page module 1003 to implement corresponding actions based on the edge application module 1001, thereby Cooperate with each other to complete the access method provided by any of the above method embodiments.

In other words, the CDN node provided by the embodiment of this application is actually formed by deploying the functions of the bill center to the CDN node located on the user side (ie, the edge) in the form of an edge application. At this time, the access request can be processed through Receive and drive the CDN node to process the access request locally, which reduces the delay of the access request, improves the timeliness of the access request, and also reduces the processing pressure.

In some embodiments, as shown in Figure 11, the CDN node 1000 also includes an edge database service module 1002.

Among them, a local database 1004 is deployed in the edge database service module 1002, and data is synchronized between the local database 1004 deployed within the edge database service module 1002 and the local database 1004 deployed within the edge database service module 1002 of other CDN nodes 1000;

The edge database service module 1002 is connected to the edge application module 1001 and is used to maintain the local database of the CDN node 1000 to provide database services to the edge application module 1001.

In this way, through data synchronization of local databases between each CDN node 1000, strong consistency of information such as global request status is ensured, which is conducive to providing access accuracy and avoiding long waiting times caused by number retrieval errors, number hopping, etc. question.

In some embodiments, as shown in Figure 12, the edge database service module of a CDN node 1000 and the edge database service modules 1002 of other CDN nodes 1000 are connected to the same data center 2000 through an internally deployed local database 1004.

It should be noted that when the local database is deployed outside the edge database service module 1002, the local database can only subscribe to the data center 2000 for the relevant data of the access request described in the above embodiment to efficiently synchronize and alleviate local Database processing pressure.

In this way, through the data center 2000, each CDN node 1000 can achieve data synchronization with simple deployment and low difficulty, which is conducive to the wide application of various access scenarios and reduced costs.

It is not difficult to find that this embodiment is a node embodiment corresponding to the method embodiment, and this embodiment can be implemented in cooperation with the method embodiment. The relevant technical details mentioned in the method embodiment are still valid in this embodiment. In order to reduce duplication, they will not be described again here. Correspondingly, the relevant technical details mentioned in this embodiment can also be applied to the method embodiment.

On the other hand, the embodiment of the present application also provides an access system. As shown in Figure 11, the access system includes: a plurality of CDN nodes 1000 as described in any of the previous embodiments.

It should be noted that, in order to facilitate the presentation of the relationship between each CDN node 1000 in the system, Figure 12 illustrates that each CDN node 1000 is deployed with an edge database service module 1002, and the edge database service module 1002 is deployed internally through the respective The local database 1004 is connected to the same data center 2000 to maintain data synchronization. Among them, the database 2000 can be regarded as a part of the access system, or can be regarded as another structure independent of the access system, which will not be described in detail here.

However, in some embodiments, the access system can also achieve data synchronization without going through the data center 2000. At this time, the edge database service module 1002 of each CDN node 1000 no longer needs to connect to the data center 2000 through its respective local database 1004.

It is not difficult to find that this embodiment is a system embodiment corresponding to the node embodiment, and this embodiment can be implemented in cooperation with the method embodiment. The relevant technical details mentioned in the method embodiment are still valid in this embodiment. In order to reduce duplication, they will not be described again here. Correspondingly, the relevant technical details mentioned in this embodiment can also be applied to the method embodiment.

In order to facilitate those skilled in the art to better understand the above embodiments, examples will be provided below.

When the client 3000 needs to access the target URL, it generates a corresponding access request. The edge application module 1001 receives the access request sent by the client 3000 and parses out the target URL it carries. Then the edge application module 1001 executes the request according to the preconfigured The information detects whether the origin site pointed to by the target URL provides a waiting room service.

When the origin site pointed to by the target URL provides a waiting room service, the edge application module 1001 forwards the access request to the edge database service module 1002. The edge database service module 1002 generates a user ID based on the user information and based on the user ID in the deployed Query is performed in the local database 1004 and the data obtained by the query is returned to the edge application module 1001.

After receiving the query result, the edge application module 1001 first determines whether the query failed.

If the query fails, it means that there is no record of the access request. The edge application module 1001 further makes a judgment based on the connection status of the target URL, that is, the number of connections and the number of waiting connections of the target URL. specifically:

When the number of connections to the target URL and the number of waiting connections both reach the upper limit, the access request is determined to be in the denied state and the access request is rejected; when the number of connections to the target URL reaches the upper limit and the number of waiting connections does not reach the upper limit, the access request is determined The request is in the waiting state, and the waiting room page data is obtained from the waiting room page module 1003 and returned to the client 3000; when the number of connections to the target URL and the number of waiting connections have not reached the upper limit, it is determined that the access request is in the allowed connection state. , forward the access request to the origin site 4000 pointed by the target URL, so that the origin site 4000 responds to the access request.

Among them, if the query fails, the user information, target URL and the connection status of the queried target URL can also be written in the local database 1004, and synchronized to other CDN nodes 1000 through the subscription and push functions of the data center.

If the query is successful, it means that the access request is recorded, and the edge application module 1001 further makes a judgment based on whether the access request is in a connected state. specifically:

If it is in the connected state, the edge application module 1001 determines that the access request is in the allowed connection state, and forwards the access request to the origin site 4000 pointed to by the target URL, so that the origin site 4000 responds to the access request. If it is not in the connected state, the edge application module 1001 further makes a judgment based on the connection status of the target URL, that is, the number of connections to the target URL. specifically:

When the number of connections to the target URL reaches the upper limit, the edge application module 1001 determines that the access request is in a waiting state, and forwards the access request to the waiting room page module 1003; when the number of connections to the target URL does not reach the upper limit, determines The access request is in the allowed connection state, and the access request is forwarded to the origin site 4000 pointed to by the target URL, so that the origin site 4000 responds to the access request.

Wherein, when there is no record of the access request, after determining the status of the access request, the edge application module 1001 also notifies the edge database service module 1002 to write the user ID, the status of the access request and other information into the local database 1004 in the form of KV. middle. When it is queried that the access request is in the waiting state and it is determined that the access request is currently in the allowed connection state, the edge application module 1001 notifies the edge database service module 1002 to update the status of the access request in the local database 1004.

When the data in the local database 1004 is updated, the edge database service module 1002 will report the updated data to the data center 2000, so the data center 2000 will deliver the updated data to the edge database service modules 1002 of other CDN nodes 1000. Thus, the local database 1004 of other CDN nodes is updated.

After receiving the waiting room page data returned by the waiting room page module 1003, the client 3000 will periodically initiate an access request again, and the edge application module 1001 will perform the above steps again until the access request is forwarded to the origin site pointed to by the target URL. 4000. At the same time, the edge application module 1001 will also set a timeout for the access request after returning the waiting room page data to the client 300 - the first preset duration. Once it is not refreshed within the timeout period, the user is considered to have exited the waiting period.

In addition, the edge application module 1001 will also set a timeout for the access request after the access request changes from the waiting state to the allowed connection state - the second preset time period. Once the access request carrying user information and target URL is received within the timeout period, request, the edge database service module 1002 will be notified to delete the information related to the access request in the local database 1004.

After the current access request completes the response, it is determined that the client 3000 corresponding to the earliest recorded time among the requests waiting to access the target URL recorded in the local database 1004 is the target client, and the edge application module 1001 determines the access request corresponding to the target client. Forward to the origin site 4000 pointed by the target URL, and notify the edge database service module 1002 to modify the status of the access request corresponding to the target client in the local database 1004 to the allowed connection status. And as mentioned above, the status of the access request corresponding to the target client is the allowed connection status and is synchronized to the local database 1004 of other CDN nodes.

Of course, the above examples do not involve all the above-mentioned embodiments, and the above-mentioned embodiments can also be combined into the above-mentioned examples if no contradiction occurs, so the details will not be described one by one here.

It is worth mentioning that each module involved in this embodiment is a logical module. In practical applications, a logical unit can be a physical unit, or a part of a physical unit, or it can be multiple physical units. The combination of units is realized. In addition, in order to highlight the innovative part of this application, units that are not closely related to solving the technical problems raised in this application are not introduced in this embodiment, but this does not mean that other units do not exist in this embodiment.

On the other hand, the embodiment of the present application also provides an electronic device, as shown in Figure 13, including: at least one processor 1301; and a memory 1302 communicatively connected to the at least one processor 1301; wherein the memory 1302 stores data that can Instructions executed by at least one processor 1301, instructions are executed by at least one processor 1301, so that at least one processor 1301 can execute the access method described in any of the above method embodiments.

The memory 1302 and the processor 1301 are connected using a bus. The bus may include any number of interconnected buses and bridges. The bus connects various circuits of one or more processors 1301 and the memory 1302 together. The bus may also connect various other circuits together such as peripherals, voltage regulators, and power management circuits, which are all well known in the art and therefore will not be described further herein. The bus interface provides the interface between the bus and the transceiver. A transceiver may be one element or may be multiple elements, such as multiple receivers and transmitters, providing a unit for communicating with various other devices over a transmission medium. The data processed by the processor 1301 is transmitted on the wireless medium through the antenna. Further, the antenna also receives the data and transmits the data to the processor 1301.

Processor 1301 is responsible for managing the bus and general processing, and can also provide various functions, including timing, peripheral interfaces, voltage regulation, power management, and other control functions. The memory 1302 may be used to store data used by the processor 1301 when performing operations.

Another aspect of the embodiment of the present application also provides a computer-readable storage medium storing a computer program. The above method embodiments are implemented when the computer program is executed by the processor.

That is, those skilled in the art can understand that all or part of the steps in implementing the methods of the above embodiments can be completed by instructing relevant hardware through a program. The program is stored in a storage medium and includes several instructions to make a device (can It is a microcontroller, chip, etc.) or processor that executes all or part of the steps of the methods described in various embodiments of this application. The aforementioned storage media include: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), magnetic disk or optical disk and other media that can store program code.

Those of ordinary skill in the art can understand that the above-mentioned embodiments are specific embodiments for implementing the present application, and in actual applications, various changes can be made in form and details without departing from the spirit and spirit of the present application. scope.

Claims (19)

1. An access method, characterized in that it is applied to CDN nodes, and the method includes: Receive an access request sent by the client, where the access request carries user information and target URL; When it is determined that the access request is in a waiting state based on the user information and the target URL, locally cached waiting room page data is sent to the client for presentation by the client based on the waiting room page data. Waiting room page; When it is determined that the access request is in the allowed connection state based on the user information and the target URL, the access request is forwarded to the origin site pointed to by the target URL for the origin site to respond to the access request. to respond. 2. The access method according to claim 1, characterized in that the CDN node is deployed with a local database, and the local database of the CDN node maintains data synchronization with the local databases of other CDN nodes; After receiving the access request sent by the client, the method further includes: According to the user information and the target URL, a query is performed in a local database to determine whether the access request is in a waiting state. 3. The access method according to claim 2, characterized in that the local database of the CDN node and the local databases of other CDN nodes are connected to the same data center; The method also includes: When data update occurs in the local database, the updated data is sent to the data center, so that the data center can push the received updated data to the other CDN nodes that subscribe to the updated data. local database. 4. The access method according to claim 3, characterized in that the method further includes: When the connection status of the target URL changes, the synchronization data pushed by the data center is received through the local database and synchronized to the local database. The synchronization data is the data generated by the data center according to the connection status of the target URL. Change the data obtained. 5. The access method according to claim 2, characterized in that the data in the local database of the CDN node is stored in the form of key values, and according to the user information and the target URL, in the local database Make inquiries including: Generate a user identification according to the user information, and the user identification is used to uniquely identify the user information; Query in the local database according to the user ID and the target URL; The method also includes: If the query based on the user ID fails, query the connection status of the target URL in the local database and update the user ID, the target URL, and the connection status of the target URL in the form of key values to in the local database. 6. The access method according to claim 2, characterized in that querying in a local database according to the user information and the target URL includes: According to the user information and the target URL, query in a local database whether the client corresponding to the user information is in a state of establishing a connection with the target URL; When the client corresponding to the user information is not in a state of establishing a connection with the target URL, query the connection status of the target URL in the local database according to the target URL; After querying the local database according to the user information and the target URL, the method further includes: According to the connection status of the target URL, it is determined whether the access request is in a waiting state. 7. The access method according to claim 6, wherein determining whether the access request is in a waiting state according to the connection status of the target URL includes: When the connection to the target URL is not full, determine that the access request is in the allowed connection state; When the connection to the target URL is full, it is determined that the access request is in a waiting state. 8. The access method according to any one of claims 1 to 7, characterized in that, when it is determined that the access request is in a waiting state according to the user information and the target URL, the method further includes : Determine customized page data based on customized reference information, which includes at least one of the following information: the connection status of the user information and the access request; While sending the locally cached waiting room page data to the client, the method also includes: Send the customized page data to the client. 9. The access method according to any one of claims 1 to 7, characterized in that after forwarding the access request to the origin site pointed by the target URL, the method further includes: After the access to the target URL based on the access request is completed, the step of determining the target client is triggered; among other clients currently presenting the waiting room page based on the access to the target URL, the target The earliest time the client requests access; Forward the request of the target client to the origin site pointed by the target URL. 10. The access method according to claim 9, characterized in that after triggering the step of determining the target client, the method further includes: Update the waiting status corresponding to the target client to the allowed connection status. 11. The access method according to any one of claims 1 to 7, characterized in that the waiting room page data carries data used to regularly trigger a request to access the target URL, and the data sent to the client After locally caching the waiting room page data, the method further includes: Receive the access initiated by the client based on the waiting room page data regularly to determine the status of the access request again and perform corresponding steps according to the status of the access request until the access request is forwarded to the source stand. 12. The access method according to claim 11, wherein after sending the locally cached waiting room page data to the client, the method further includes: Monitor whether the client regularly initiates access based on the waiting room page data; If the access initiated regularly by the client based on the waiting room page data is not detected within the first preset time period, the record corresponding to the access request is updated to delete the record corresponding to the access request. 13. The access method according to any one of claims 1 to 7, characterized in that after forwarding the access request to the origin site pointed by the target URL, the method further includes: If it is not detected that the client initiates access based on the user information and the target URL within the second preset time period, update the record corresponding to the access request to delete the record corresponding to the access request. . 14. A CDN node, characterized in that it includes: an edge application module and a waiting room page module; the edge application module is connected to the waiting room page module; The edge application module is used to implement the access method as described in any one of claims 1 to 13; The waiting room page module is configured to maintain the locally cached waiting room page data of the CDN node, so as to provide the locally cached waiting room page data to the edge application module. 15. The CDN node according to claim 14, further comprising an edge database service module; A local database is deployed in the edge database service module, and data is synchronized between the local database deployed within the edge database service module and the local database deployed within the edge database service module of other CDN nodes; The edge database service module is connected to the edge application module and is used to maintain an internally deployed local database to provide database services to the edge application module. 16. The CDN node according to claim 15, wherein the edge database service module of the CDN node and the edge database service modules of other CDN nodes are connected to the same data center through an internally deployed local database. 17. An access system, characterized by comprising: a plurality of CDN nodes according to any one of claims 14 to 16. 18. An electronic device, characterized in that it includes: at least one processor; and, a memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor, so that the at least one processor can perform as claimed in any one of claims 1 to 13 access method described above. 19. A computer-readable storage medium storing a computer program, characterized in that when the computer program is executed by a processor, the access method according to any one of claims 1 to 13 is implemented.