Routing data processing method, device and readable storage medium

Abstract

The present application discloses a routing data processing method, device, and readable storage medium, the method comprising: obtaining routing change information determined by service change data for a user device; in the process of updating the routing snapshot of the routing device from a first routing snapshot to a second routing snapshot based on the routing change information, querying the routing snapshot of the routing device; the first routing snapshot with a first committed state is a previous snapshot record of the second routing snapshot with a pending commit state; when the routing snapshot of the routing device is found to be the first routing snapshot pointed to by the second routing snapshot, changing the service state of the second routing snapshot from a pending commit state to a second committed state, and storing the second routing snapshot with the second committed state through a verification service device. By adopting the present application, routing reading and writing can be achieved without blocking, and the forwarding efficiency of service data can be improved.

Description

Technical Field

[0001] The present application relates to the field of communication technology, and in particular to a routing data processing method, device, and readable storage medium. Background Art

[0002] With the continuous development of communication technology, the demand for high-speed transmission networks by individuals and enterprises is also increasing. The fifth generation mobile communication technology (5G) is a new generation of broadband mobile communication technology with high speed, low latency and large connection characteristics. When facing services such as industrial control, smart grid, telemedicine, and autonomous driving, 5G networks need to provide 99.99% reliability, as well as millisecond-level latency and microsecond-level jitter. Therefore, the 5G core network (5G Core, referred to as 5GC) adopts a network architecture with CUPS (Control and User Plane Separation) that separates the control plane and the user plane. Among them, the user plane can also be called the forwarding plane, which is mainly responsible for routing and forwarding business data.

[0003] In the existing routing method, when a route changes, the routing device (such as the 5G core network gateway) needs to be notified in a timely manner. If the routing device is querying this route at this time, the route needs to be locked to ensure that the same route cannot be read and written at the same time, that is, to meet the read-write mutual exclusion requirement. In other words, locking will cause the route to be unable to be updated when the business queries the route, thereby affecting the business forwarding performance. Especially in the case of a large number of forwarding requests, locking will cause the forwarding efficiency of business data to be very low. Summary of the Invention

[0004] The embodiments of the present application provide a routing data processing method, device, and readable storage medium, which can achieve non-blocking routing reading and writing and improve the forwarding efficiency of business data.

[0005] An embodiment of the present application provides a method for processing routing data, the method being executed by a routing device, including:

[0006] Obtaining route change information determined by service change data for user equipment;

[0007] In a process of updating a routing snapshot of a routing device from a first routing snapshot to a second routing snapshot based on routing change information, querying the routing snapshot of the routing device; a service status of the first routing snapshot is a first committed status, a service status of the second routing snapshot is a pending commit status, and the first routing snapshot in the first committed status is a previous snapshot record of the second routing snapshot in the pending commit status;

[0008] When the routing snapshot of the routing device is found to be the first routing snapshot pointed to by the second routing snapshot, the service state of the second routing snapshot is changed from the pending state to the second submitted state, and the second routing snapshot with the second submitted state is stored through the verification service device.

[0009] In one aspect, an embodiment of the present application provides a method for processing routing data, which is executed by a verification service device and includes:

[0010] Based on the obtained second routing snapshot with a second committed state, a target routing snapshot is obtained, and the target routing snapshot is stored in a routing cache associated with the verification service device; the second routing snapshot with the second committed state is obtained by the routing device changing the service state of the second routing snapshot from a pending-commitment state to a second committed state when the found routing snapshot is the first routing snapshot pointed to by the second routing snapshot; the routing device is configured to query the routing snapshot of the routing device during the process of updating the routing snapshot of the routing device from the first routing snapshot to the second routing snapshot based on the routing change information; the service state of the first routing snapshot is a first committed state, the service state of the second routing snapshot is a pending-commitment state during the snapshot update process, and the first routing snapshot with the first committed state is a previous snapshot record of the second routing snapshot with the pending-commitment state;

[0011] When a route check request is received, a second route snapshot in a second committed state is obtained from the object storage indicated by the route check request as the original route snapshot, and a route check is performed on the original route snapshot based on the target route snapshot stored in the route cache.

[0012] In one aspect, an embodiment of the present application provides a routing data processing apparatus, which runs in a routing device and includes:

[0013] An acquisition module, configured to acquire route change information determined by service change data of a user device;

[0014] a query module configured to query a routing snapshot of a routing device during a process of updating the routing snapshot of the routing device from a first routing snapshot to a second routing snapshot based on routing change information; wherein the service status of the first routing snapshot is a first submitted status, the service status of the second routing snapshot is a pending submission status, and the first routing snapshot in the first submitted status is a previous snapshot record of the second routing snapshot in the pending submission status;

[0015] The changing module is used to change the service state of the second routing snapshot from a pending state to a second submitted state when finding that the routing snapshot of the routing device is the first routing snapshot pointed to by the second routing snapshot, and store the second routing snapshot in the second submitted state through the verification service device.

[0016] In one aspect, an embodiment of the present application provides a routing data processing device, which runs in a verification service device and includes:

[0017] The storage module is configured to obtain a target routing snapshot based on the acquired second routing snapshot having a second committed state, and store the target routing snapshot in a routing cache associated with the verification service device; the second routing snapshot having the second committed state is obtained by the routing device changing the service state of the second routing snapshot from a pending-commitment state to a second committed state when the found routing snapshot is the first routing snapshot pointed to by the second routing snapshot; the routing device is configured to query the routing snapshot of the routing device during the process of updating the routing snapshot of the routing device from the first routing snapshot to the second routing snapshot based on the routing change information; the service state of the first routing snapshot is a first committed state, the service state of the second routing snapshot is a pending-commitment state during the snapshot update process, and the first routing snapshot having the first committed state is a previous snapshot record of the second routing snapshot having the pending-commitment state;

[0018] The verification module is configured to, upon receiving a route verification request, obtain a second route snapshot having a second committed state from an object storage indicated by the route verification request as an original route snapshot, and perform route verification on the original route snapshot based on the target route snapshot stored in the route cache.

[0019] In one aspect, an embodiment of the present application provides a computer device, including: a processor and a memory;

[0020] The processor is connected to a memory, wherein the memory is used to store a computer program. When the computer program is executed by the processor, the computer device executes the method provided in the embodiment of the present application.

[0021] On the one hand, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. The computer program is suitable for being loaded and executed by a processor so that a computer device having the processor executes the method provided by the embodiment of the present application.

[0022] In one aspect, embodiments of the present application provide a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the method provided in the embodiments of the present application.

[0023] In an embodiment of the present application, a routing device can obtain routing change information determined by service change data for a user device. Further, based on the routing change information, the routing snapshot of the routing device can be updated from a first routing snapshot to a second routing snapshot. During the update process, the routing snapshot of the routing device can still be queried, wherein at this time, the service status of the first routing snapshot is a first submitted status, the service status of the second routing snapshot is a pending submission status, and the first routing snapshot with the first submitted status is the previous snapshot record of the second routing snapshot with the pending submission status. Further, when it is found that the routing snapshot of the routing device is the first routing snapshot pointed to by the second routing snapshot, the service status of the second routing snapshot can be changed from the pending submission status to the second submitted status, and the second routing snapshot with the second submitted status can be stored by the verification service device, so that the verification service device can subsequently perform offline routing verification on the second routing snapshot with the second submitted status. It can be seen that when the service data of the user device changes, the route used to forward the service data on the routing device will also change (for example, the first route is changed to the second route). To resolve read-write conflicts, the routing device can generate different versions of route snapshots based on the route change information. In the process of updating the first route snapshot to the second route snapshot, the second route snapshot is still in a pending state, indicating that the route update is not completed. Therefore, if the second route snapshot is queried at the same time, the previous snapshot record pointed to by the second route snapshot is queried, that is, the first route snapshot. This can achieve non-blocking route reading and writing, that is, route query will not be interrupted during route update, thereby improving the forwarding efficiency of service data. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1 This is a schematic diagram of a system architecture provided by an embodiment of the present application;

[0025] Figure 2 This is a schematic diagram of a scenario of routing data processing provided by an embodiment of the present application;

[0026] Figure 3 This is a flow chart of a routing data processing method provided in an embodiment of the present application;

[0027] Figure 4 This is a schematic diagram of a transaction processing scenario provided by an embodiment of the present application;

[0028] Figure 5 This is a schematic diagram of a routing query scenario provided by an embodiment of the present application;

[0029] Figure 6 This is a schematic diagram of a routing query process provided by an embodiment of the present application;

[0030] Figure 7This is a flow chart of a routing data processing method provided in an embodiment of the present application;

[0031] Figure 8 This is a schematic diagram of the structure of a routing snapshot provided in an embodiment of the present application;

[0032] Figure 9 This is a schematic diagram of the structure of a routing snapshot provided in an embodiment of the present application;

[0033] Figure 10 This is a flow chart of a routing data processing method provided in an embodiment of the present application;

[0034] Figure 11 This is a schematic diagram of a route verification scenario provided by an embodiment of the present application;

[0035] Figure 12 This is a schematic diagram of a route verification scenario provided by an embodiment of the present application;

[0036] Figure 13 This is a schematic diagram of the structure of a routing data processing device provided in an embodiment of the present application;

[0037] Figure 14 This is a schematic diagram of the structure of a routing data processing device provided in an embodiment of the present application;

[0038] Figure 15 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present application;

[0039] Figure 16 It is a structural diagram of a routing data processing system provided in an embodiment of the present application. DETAILED DESCRIPTION

[0040] The technical solutions in the embodiments of the present application will be described clearly and completely below in conjunction with the drawings in the embodiments of the present application.

[0041] The technical solutions of the embodiments of the present application can be applied to various communication systems, such as: Global System for Mobile communication (GSM), Code Division Multiple Access (CDMA) system, Wideband Code Division Multiple Access (WCDMA) system, General Packet Radio Service (GPRS), Long Term Evolution (LTE) system, LTE Frequency Division Duplex (FDD) system, LTE Time Division Duplex (TDD) system, Universal Mobile Telecommunications System (UMTS), Worldwide Interoperability for Microwave Access (WiMAX) communication system, future fifth generation (5G) mobile communication system or subsequently evolved mobile communication system, etc. The embodiments of the present application are mainly described by taking the fifth generation mobile communication system as an example.

[0042] See Figure 1 , Figure 1 This is a schematic diagram of a system architecture provided by an embodiment of the present application. Figure 1 As shown, the system architecture may include an application server cluster, a user device cluster, an access device 300a, and a routing device 300b. The application server cluster may include one or more application servers, and the number of application servers in the application server cluster is not limited here. For example, Figure 1 As shown, the multiple application servers may specifically include application server 100a, application server 100b, ..., application server 100m. It should be understood that a communication connection may exist between the application servers, for example, a communication connection exists between application server 100a and application server 100b. At the same time, any application server in the application server cluster may have a communication connection (for example, a dedicated line connection) with routing device 300b, so that each application server can exchange data with routing device 300b through the communication connection, for example, a communication connection exists between application server 100a and routing device 300b.

[0043] It can be understood that the application server in the embodiment of the present application can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud databases, cloud services, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, as well as big data and artificial intelligence platforms.

[0044] It is understood that the routing device in the embodiments of the present application is a hardware device that connects two or more networks and acts as a gateway between the networks. It is a dedicated intelligent network device that reads the destination address in each data packet and then determines how to transmit it. Therefore, the routing device can also be referred to as a gateway device. The routing device has routing functions and can be used to store and forward data packets between different networks. For example, the routing device may include a router, a server with a routing protocol enabled, a proxy server, etc. In a 5G mobile communication system, the routing device 300b may be a core network element ("network element" may also be referred to as "network function") in the 5G core network. For example, the routing device 300b here may be a UPF (User Plane Function, also referred to as a user plane network element) in the core network element. The UPF may be responsible for data routing and forwarding on the control plane (CP) and the user plane (DP), and interconnect with external data networks (such as carrier services, the Internet, or third-party services). Specifically, the routing device 300b may be a 5G gateway.

[0045] like Figure 1 In the system architecture shown, a user equipment cluster may include one or more user equipments, and the number of user equipments in the user equipment cluster is not limited here. Figure 1 As shown, the multiple user devices may specifically include user device 200a, user device 200b, ..., user device 200n. It should be understood that there may be a communication connection between user devices, for example, there is a communication connection between user device 200a and user device 200b. At the same time, any user device in the user device cluster may have a communication connection with access device 300a, for example, there is a communication connection between user device 200a and access device 300a. The above-mentioned communication connection does not limit the connection method, and may be through a 4G wireless access method or a 5G wireless access method, etc., and this application does not impose any restrictions on this.

[0046] It is understood that the user equipment (UE) in the embodiments of the present application may include a terminal device (e.g., a smartphone, a tablet computer, a laptop computer, a desktop computer, a PDA), an access terminal, a terminal in V2X (Vehicle to X) communication, a user unit, a user station, a mobile station, a mobile station, a remote station, a remote terminal, a mobile device, a user terminal, a wireless communication device, a user agent, or a user device. The terminal device may also be a cellular phone, a cordless phone, a Session Initiation Protocol (SIP) phone, a Wireless Local Loop (WLL) station, a Personal Digital Assistant (PDA), a handheld device with wireless communication capabilities, a computing device or other processing device connected to a wireless modem, an in-vehicle device, a wearable device (e.g., a smart watch, a smart bracelet, etc.), a smart computer, etc., a terminal device in a future 5G network, or a terminal device in a future evolved Public Land Mobile Network (PLMN), etc., and the embodiments of the present application are not limited thereto. The terminal device may also include a V2X device, such as a vehicle or an on-board unit (OBU) in a vehicle.

[0047] It can be understood that the access device 300a in the embodiment of the present application is an access device for the user equipment to access the mobile communication system wirelessly, for example, it can be a base station NodeB, an evolved base station eNodeB, a base station (gNodeB, gNB) in a 5G mobile communication system, a base station in a future mobile communication system, or an access node in a wireless fidelity (Wireless Fidelity, WiFi) system, etc. It can also be a wireless controller in a cloud radio access network (Cloud Radio Access Network, CRAN) scenario, or it can be a relay station, access point, vehicle-mounted equipment, wearable device, and network equipment in a future 5G network or a network equipment in a future evolved PLMN network (Public Land Mobile Network, Public Land Mobile Communication Network), etc. The embodiment of the present application does not limit the specific technology and specific device form adopted by the access device.

[0048] Among them, the number of access devices (such as base stations) corresponding to the access device 300a can be multiple, and multiple access devices can be jointly responsible for the access and management of the user device on the wireless side. Different user devices can correspond to different access devices, or different user devices can also correspond to the same access device. The access device corresponding to each user device is not limited here. The embodiment of the present application is explained by taking the access device corresponding to each user device as access device 300a as an example.

[0049] It should be understood that Figure 1 Each user device in the user device cluster shown can be integrated with an application client (i.e., an application program, which can be referred to as an application). When the application client runs in each user device, it can communicate with the above-mentioned access device 300a and the routing device 300b respectively. Figure 1 Data is exchanged between application servers in the application server cluster shown. Application clients may include, but are not limited to, in-vehicle clients, smart home clients, entertainment clients (e.g., game clients), multimedia clients (e.g., video clients), social clients, and information clients (e.g., news clients). Application clients may be standalone clients or embedded sub-clients integrated into a client (e.g., instant messaging clients, social clients, video clients, etc.).

[0050] It is understandable that if Figure 1 The system architecture shown can be applied to business scenarios that support edge computing (such as mobile edge computing, Mobile Edge Computing, MEC for short). The application servers in the above-mentioned application server cluster can be edge application servers (Edge Application Servers) in edge computing. Among them, edge computing refers to a platform that integrates network, computing storage, and application core capabilities at the edge of the network close to the source of objects or data, providing edge intelligent services nearby to meet the key needs of industry digitalization in agile connection, real-time business, data optimization, application intelligence security and privacy protection. Edge computing enables operators and third-party services to be hosted close to the access point of terminal devices, thereby achieving efficient service delivery by reducing end-to-end latency and load on the transmission network.

[0051] The fifth generation of mobile communication technology (abbreviated as 5G) is a new generation of broadband mobile communication technology with the characteristics of high speed, low latency and large connection. It is the network infrastructure for realizing the interconnection of people, machines and things. In 5G application scenarios, the peak rate of 5G services usually exceeds 10Gbps, and the bandwidth requirement is as high as tens of Gbps. Therefore, it will put tremendous pressure on wireless mid-haul and backhaul mobile networks. Therefore, 5G business needs require the business to be sunk to the edge of the network as much as possible to achieve local business diversion and reduce the network latency caused by network transmission and multi-level business forwarding. Among them, 5G cloud access can greatly improve network quality and transmission rate through end-side access to 5G and dedicated line capabilities in the cloud, meeting the business requirements of low latency and high reliability.

[0052] It is understandable that the access device 300a can establish a "control plane" connection (i.e., a control plane) between a user device (e.g., user device 200a) and a routing device 300b, and the control plane can be used to forward signaling messages between the two. These signaling messages include mobile phone identity authentication, registration, mobility management, etc. In addition, the access device 300a can also establish a "user plane" connection (i.e., a data plane) between the user device 200a and the routing device 300b, and the data plane can be used to forward the user's data traffic between the two. Among them, the control plane and the user plane are completely separated, and the routing device 300b can be distributedly deployed together with edge computing at the edge closer to the user side, thereby reducing network latency.

[0053] It should be understood that in a 5G network, assuming that a user device (for example, user device 200a) wishes to access a data network outside the mobile communication network (such as the Internet, corporate intranet, etc.), the user device 200a can initiate an access request and forward the access request to the access device 300a. The access device 300a can forward the service flow (also referred to as service data) requested by the user device 200a to the routing device 300b in the 5G core network, and then forward it through the routing device 300b and send it to the external data network.

[0054] Among them, in order to obtain more efficient service delivery, edge computing can be used to meet different business needs. It should be noted that in the edge computing scenario, an application service may be provided by multiple edge application servers (such as Figure 1The application servers 100a, 100b, and 100m in the network provide services. These multiple edge application servers that carry services may use a single IP address (Internet Protocol Address) or different IP addresses. Typically, the application server of an application client may be deployed in a central application server or in an edge application server. In order to route the service flow of the application client (for example, application client Y) to the edge application server, the user device needs to know the IP address of the edge application server that provides services to the application client. The user device can perform discovery to obtain the IP address (for example, IP address 1) of a suitable edge application server (for example, an edge application server closest to the user device, such as application server 100a) so that the traffic can be routed to the edge application server by the routing device 300b, and the service delay, traffic routing path, and user service experience can be optimized. Based on this, edge application server discovery is the process by which the user device uses the domain name system to find the IP address of a suitable edge application server. The domain name system (DNS) is an Internet service that acts as a distributed database that maps domain names and IP addresses to each other, enabling users to access the Internet more conveniently.

[0055] like Figure 1 As shown, after the user device discovers the IP address 1 of the application server 100a corresponding to the application client Y through the edge application server, the business data generated by running the application client Y (for example, business data transmitted in the form of data packets) will carry the IP address 1. The data packet will be forwarded to the routing device 300b. It should be noted that when the routing device 300b and the application server 100a are not in the same network or the distance is too far, the transmission of the data packet does not establish a long connection and needs to be forwarded hop by hop. In other words, there may be multiple routing devices (such as gateways, not shown in the figure) between the routing device 300 and the application server 100a. The data packet can be forwarded from one routing device to another routing device, and then continued to be forwarded by another routing device, and finally forwarded to the application server 100a. Therefore, after obtaining the data packet carrying IP address 1, the routing device 300b will select a suitable route based on the IP address 1 to route and forward the data packet, that is, forward the data packet to the next-hop routing device according to the next-hop routing device address contained in the route, and then the next-hop routing device will continue to select a suitable route based on IP address 1 and continue to route and forward the data packet, so that the data packet can eventually reach the application server 100a corresponding to the IP address 1.

[0056] It is understandable that the continuous changes in real-time business data on the user device side will lead to the continuous update of the forwarding route of the routing device. In order to improve the 5G transmission efficiency and allow route query and route update to run together, the embodiment of the present application provides a 5G cloud distributed routing read and write solution. Specifically, the routing device can obtain the route change information determined by the service change data of the user device. The route change information here is determined by changing the first route of the change record corresponding to the forwarding business change data to the second route, and the second route and the first route are both determined for the business change data. For example, the route change information can be configured by the 5G core network based on the business change data. Based on the route change information, the first route can be changed to the second route to adapt to the change of business data. Among them, the business change data here may include business data before and after the change, and the business data may include but is not limited to text data, voice data, video data, image data generated by the application client on the user device, or the location information of the user device, the type of network connected (such as mobile network type, wireless network type), etc. For example, if the real-time location of the user device 200a changes (such as moving from location A to location B), the application server connected to the application client (such as a video client) at a different location on the user device 200a may also change. For example, the connection changes from the application server 100a at location A to the application server 100b at location B. Therefore, the route used to forward the business data (such as video data) generated by the application client may also change accordingly.

[0057] Furthermore, based on the route change information, the route snapshot of the routing device can be updated from the first route snapshot of the first route to the second route snapshot of the second route, and during the update process, the route snapshot of the routing device can still be queried. At this time, the business status of the first routing snapshot is the first submitted state, the business status of the second routing snapshot is the pending submission state, and the first routing snapshot with the first submitted state is the previous snapshot record of the second routing snapshot with the pending submission state. It should be understood that the routing snapshot is a routing record stored by the routing device at a certain moment. Therefore, each time the route is successfully updated, the routing device can generate a corresponding routing snapshot and store it locally, that is, perform multi-version storage and read and write of the route. According to the generation timestamps corresponding to different routing snapshots, it can be known which routing snapshots are the latest snapshot records (such as the second routing snapshot) and which routing snapshots are historical snapshot records (such as the first routing snapshot). It can be understood that the business status of historical snapshot records are all submitted states, while the business status of snapshot records that have not yet been successfully updated is in a pending submission state. In the embodiment of the present application, in order to facilitate subsequent distinction, the business status of the first routing snapshot belonging to the historical snapshot record can be called the first submitted state, and the business status of the second routing snapshot obtained after a subsequent successful update can be called the second submitted state.

[0058] Furthermore, when it is found that the routing snapshot of the routing device is the first routing snapshot pointed to by the second routing snapshot, the service status of the second routing snapshot can be changed from the pending submission status to the second submitted status, indicating that the first route is successfully updated to the second route, and the second routing snapshot with the second submitted status can be stored through the verification service device, so that the verification service device can subsequently perform offline routing verification on the second routing snapshot with the second submitted status.

[0059] It can be seen that when the service data of the user device changes, the route used to forward the service data on the routing device will also change (for example, the first route is changed to the second route). In order to solve the read-write conflict problem in the existing routing solution, the routing device can generate different versions of routing snapshots based on the routing change information. In the process of updating the first routing snapshot to the second routing snapshot, the second routing snapshot is still in a pending state, indicating that the routing update is not completed. Therefore, if the second routing snapshot is queried at the same time, the previous snapshot record pointed to by the second routing snapshot is queried, that is, the first routing snapshot. In this way, routing reading and writing can be achieved without blocking, that is, routing queries will not be interrupted during routing updates, thereby improving the forwarding efficiency of service data.

[0060] For easier understanding, please refer to Figure 2 , Figure 2This is a schematic diagram of a routing data processing scenario provided by an embodiment of the present application. The routing data processing scenario mainly describes the data interaction between the user equipment and the routing device. Figure 2 The user equipment shown (including user equipment 20A, user equipment 20B, user equipment 20C, user equipment 20D) can be the above Figure 1 Any user equipment in the user equipment cluster in the corresponding embodiment, for example, user equipment 20A may be user equipment 200a; Figure 2 The routing device 21 shown may be a routing device (such as a 5G gateway) connected to the user equipment 20A to the user equipment 20D, that is, the service data of these user equipments can be sent to the routing device 21 for processing. The routing device 21 may be the above-mentioned Figure 1 The corresponding routing device 300b in the embodiment.

[0061] like Figure 2 As shown, assuming that routing device 21 inserts new routing data at a certain moment, such as route R0, a routing snapshot of route R0, namely route snapshot V0, can be generated. Therefore, at time T0, routing device 21 can store route snapshot V0 in its local storage. At this time, the service status of snapshot V0 is committed. It can be understood that route R0 at this time is the first initial routing data for this route.

[0062] Further, if Figure 2As shown, assume that the service data generated by an application client on user device 20A changes at time T1, thereby causing a change in route R0 used to forward the service data of the application client. For example, route R0 (equivalent to the first route) changes to route R1 (equivalent to the second route). Then, user device 20A may generate a route update request Rq1 based on route change information C1 generated by the change from route R0 to route R1, and send the route update request Rq1 to routing device 21. After receiving the route update request Rq1, routing device 21 may perform a route update based on route snapshot V0 based on the route change information C1 carried in the route update request Rq1, so as to update the route snapshot V0 of route R0 (equivalent to the first route snapshot) to the route snapshot V1 of route R1 (equivalent to the second route snapshot). That is, a write operation is performed on route snapshot V1. It should be understood that during this process, route snapshot V0 itself does not change, while route snapshot V1 is in a pending commit state. After the route update is completed, routing device 21 can change the service state of the finally generated route snapshot V1 from the previous pending state to the submitted state (equivalent to the second submitted state), associate the submitted route snapshot V1 with route snapshot V0 and store it, and return the route update result Rsp1 to user device 20A to notify user device 20A that the route update was successful. Conversely, if routing device 21 encounters an abnormal condition during the update process (for example, routing device 21 loses power) and the route update fails, routing device 21 also needs to return the corresponding route update result to user device 20A to notify user device 20A of the route update failure.

[0063] It should be understood that in actual business scenarios, application clients will continuously send route update requests to routing devices, and will also send a large number of route query requests. Therefore, it is very important to coordinate the query and update of the same route without affecting the business.

[0064] The interaction process between the user equipment 20A and the routing device 21 is similar to the above description. Figure 2As shown, assuming that the service data generated by the application client on user device 20A changes again at time T2, resulting in the need to change the route used to forward the service data of the application client from the previous route R1 (equivalent to the first route) to the new route R2 (equivalent to the second route). In this case, user device 20A may generate a route update request Rq2 based on the route change information C2 generated by the change from route R1 to route R2, and send the route update request Rq2 to routing device 21. After receiving the route update request Rq2, routing device 21 may perform a route update based on route snapshot V1 based on the route change information C2 carried in the route update request Rq2, so as to update the route snapshot V1 of route R1 (equivalent to the first route snapshot) to the route snapshot V2 of route R2 (equivalent to the second route snapshot). That is, a write operation is performed on route snapshot V2. It should be understood that during this process, route snapshots V0 and route snapshot V1 remain unchanged, while route snapshot V2 is in a pending commit state. Furthermore, if, during the process of updating route snapshot V1 to route snapshot V2, the application client on user device 20B sends a route query request Rq3 to routing device 21, routing device 21 can query its locally stored route snapshot based on route query request Rq3. Since route snapshot V2 is in the pending commit state at this time, the current route snapshot V2 is invisible to route query request Rq3. Routing device 21 then queries the previous snapshot record of route snapshot V2, namely route snapshot V1, performing a read operation on route snapshot V1. Ultimately, after the route update is complete, routing device 21 can change the service status of the resulting route snapshot V2 from the previous pending commit state to the committed state, associate the committed route snapshot V2 with route snapshot V1, and return the route update result Rsp2 to user device 20A. It is understood that routing device 21 can subsequently query the committed route snapshot V2. The user equipment 20A and the user equipment 20B may be the same user equipment, or may be different user equipment, which is not limited in the embodiment of the present application.

[0065] Similar, such as Figure 2As shown, assume that at time T3, user device 20A again generates a corresponding route update request Rq4 based on the route change information C3 generated by the change from route R2 (currently equivalent to the first route) to the new route R3 (currently equivalent to the second route), and sends this route update request Rq4 to routing device 21. Routing device 21 can then perform a route update based on route snapshot V2 based on the route change information C3 carried in this route update request Rq4, thereby updating route snapshot V2 of route R2 (currently equivalent to the first route snapshot) to route snapshot V3 of route R3 (currently equivalent to the second route snapshot), i.e., performing a write operation on route snapshot V3. Furthermore, if, during the process of updating route snapshot V2 to route snapshot V3, the application client on user device 20C sends a route query request Rq5 to routing device 21, routing device 21 can query the previous snapshot record of route snapshot V3, i.e., route snapshot V2, based on this route query request Rq5, i.e., perform a read operation on route snapshot V2. Similarly, if the application client on the user device 20D also sends a routing query request Rq6 to the routing device 21 at this time, the routing device 21 can also query the routing snapshot V2 based on the routing query request Rq6. Finally, after the routing update is completed, the routing device 21 can associate the final routing snapshot V3 with the submitted state with the routing snapshot V2 and store it, and return the routing update result Rsp3 to the user device 20A. Among them, the above-mentioned user device 20A, user device 20C, and user device 20D can be the same user device, or they can be different user devices. For example, when the user device 20C and the user device 20D are the same user device, different application clients running on the user device can simultaneously initiate routing query requests to the routing device 21. This embodiment of the present application does not limit this.

[0066] It should be noted that after each successful generation of a route snapshot with a committed state, the routing device 21 can also store these route snapshots through the verification service device, so that the verification service device can subsequently perform offline route verification on these route snapshots without occupying the resources of the routing device 21. The specific implementation method can be found in the subsequent Figure 10 The corresponding embodiment.

[0067] From the above, it can be seen that the method provided in the embodiment of the present application uses a snapshot method to copy the routing status, which can realize distributed routing reading and writing without blocking each other, that is, reading does not block writing, and writing does not block reading. Among them, the snapshot is an unlocked reading operation, which is also the operation method of 5G routing on the cloud. Compared with the locking operation (such as pessimistic lock reading), after the routing is organized through multiple versions, the data read using the snapshot is not necessarily the current latest routing, and may be the routing of the previous historical version. In the embodiment of the present application, if there is no update operation at present, the routing query is the current latest routing snapshot, for example, in Figure 2 The time T0 shown can query the routing snapshot V0; on the contrary, if there is an update operation, the routing query is the previous routing snapshot, and the current latest snapshot is updated. For example, Figure 2 That is, the embodiment of the present application optimizes the reading and writing methods of routes so that route queries do not affect route updates, and route updates do not affect route queries, thereby improving the service data transmission efficiency in 5G scenarios.

[0068] See Figure 3 , Figure 3 This is a flow chart of a method for processing routing data provided by an embodiment of the present application. The routing data processing method can be executed by a routing device, for example, Figure 1 The routing device 300b shown. Figure 3 As shown, the routing data processing method at least includes:

[0069] S101, obtaining route change information determined by service change data of a user equipment;

[0070] For example, in a 5G network, when the service data of a user device changes, the user device can record the change in the service data, obtain service change data, and feed the service change data back to the 5G core network. Then, the relevant core network elements in the 5G core network can configure appropriate route change information based on the service change data, and promptly notify the routing device (such as the 5G core network gateway) of the route change information. After the routing device receives the route change information determined for the service change data of the user device, it can subsequently perform route updates based on the route change information. For example, the first route used to forward the change record corresponding to the service change data is changed to a second route, and a corresponding route snapshot can be generated after the update is successful. It should be understood that both the second route and the first route are determined by the 5G core network for the service change data.

[0071] S102, in a process of updating a routing snapshot of a routing device from a first routing snapshot to a second routing snapshot based on routing change information, querying the routing snapshot of the routing device; the first routing snapshot in a first committed state is a previous snapshot record of the second routing snapshot in a pending committed state;

[0072] In an embodiment of the present application, optionally, the routing device can perform routing updates and routing queries in a transactional manner, wherein the transaction can include a series of operations requested by each application client on the user device, including but not limited to routing query operations and routing update operations, wherein the routing query operation not only needs to find a suitable forwarding path when forwarding business data, but also can find the routing data carried in the visible routing snapshot for the routing update operation to perform routing changes. The routing update operation can include routing modification operations, routing deletion operations, routing addition operations, etc. It should be understood that the operation data object of the transaction is routing data (also known as routing parameters), such as routing prefix (prefix), subnet mask, next hop address (nexthop, the next hop gateway address), etc., wherein a complete routing prefix is composed of the network address (i.e., IP address) + prefix length (prefix_length, or subnet mask), such as 192.168.1.0 / 24, the network address is 192.168.1.0, and its prefix length is 24. The subnet mask specifies which bits of an IP address identify the subnet where the host resides and which bits identify the host's bit mask. The longer the subnet mask, the more accurate the network segment address obtained by matching the IP address and subnet mask. When routing, the next-hop address corresponding to the available route with the longer subnet mask is closer to the destination network address.

[0073] It should be noted that a transaction may contain multiple routing update operations. If the transaction succeeds, a corresponding routing snapshot is generated. Conversely, if the transaction fails, all routing update operations are rolled back to the previous corresponding snapshot record. In other words, routing update operations executed in the same transaction will either all succeed or all fail. In other words, a transaction treats all the operations it contains as a whole atom, and there will be no situation where some operations succeed while others fail.

[0074] Optionally, the routing device may also perform routing updates and routing queries in a manner of executing separate operations (equivalent to including one operation in a transaction).

[0075] It should be noted that a snapshot is a record of the routing status at a certain moment in the data storage. When a transaction generates a snapshot, only the routing update results submitted by other transactions before this generation time point can be seen, but the routing update results submitted by other transactions after this generation time point cannot be seen. For easier understanding, please refer to Figure 4 , Figure 4 This is a scenario diagram of a transaction processing provided by an embodiment of the present application. Figure 4 The corresponding code.

[0076] Table 1

[0077]

[0078] It should be understood that the routing data seen by the same query action may be different before and after the snapshot is generated. Figure 4 As shown, transaction A is started at time T4 (before time T5). As can be seen from Table 1, transaction A searches the routing table (table) for the score (score) recorded in the routing snapshot with the name (name) Jackie. A routing update is performed at time T5, and a new version of the routing snapshot is generated. For example, as shown in Table 1, Jackie's score is updated to 78 at time T5 and then submitted. Transaction B is started at time T6 (after time T5). For example, it also searches the routing table for the score recorded in the routing snapshot with the name Jackie, and it can be seen that the score is 78 at this time. Therefore, the routing snapshot read by transaction A at time T4 is the version before the update at time T5, while the routing snapshot read by transaction B at time T6 is the version after the update at time T5. Among them, the names (name) and scores (score) exemplified in Table 1 above are both routing parameters in actual business scenarios.

[0079] It should be understood that for different versions of routing snapshots, the routing device needs to filter out the snapshot records visible to the current transaction when performing a query.

[0080] The embodiments of the present application are described using a transaction-based approach to perform routing updates and routing queries. For example, a routing device may generate a routing update transaction based on acquired routing change information, and may determine a target routing transaction during the process of updating the routing device's routing snapshot from a first routing snapshot of a first route to a second routing snapshot of a second route based on the routing update transaction. Since the scenario described herein primarily involves performing routing queries during a routing update, the target routing transaction may include a routing query transaction for querying the routing device's routing snapshot. Alternatively, the scenario of performing routing updates during a routing query includes a similar processing procedure, and the target routing transaction may include a routing update transaction for updating the routing device's routing snapshot. It should be understood that in the embodiments of the present application, transactions used for routing updates may be collectively referred to as routing update transactions. In addition to routing modification, deletion, and addition operations, routing update transactions may also generally include routing query operations. Similarly, transactions used for routing queries may be collectively referred to as routing query transactions, and the routing query transactions herein may only include routing query operations.

[0081] Furthermore, the routing device can obtain the first transaction identifier of the routing query transaction, the second transaction identifier of the routing update transaction, and the transaction identifier array corresponding to the pending transaction set. The pending transaction set may include one or more currently executing transactions (also referred to as uncommitted transactions). The transaction identifier array is used to record the transaction identifier of each transaction in the pending transaction set. It is understood that the pending transaction set at this time includes the routing query transaction. The transaction identifier, also known as the transaction ID (Identity document), is unique to each transaction. For routing update transactions, the transaction identifier can be used to record the ID of the most recent routing update transaction. Therefore, the routing snapshot generated after the successful execution of the routing update transaction will carry the transaction identifier of the routing update transaction.

[0082] Furthermore, the routing device may query the second transaction identifier corresponding to the second routing snapshot based on the first transaction identifier, the second transaction identifier, and the transaction identifier array, thereby obtaining a query result for the second transaction identifier. Specifically, the routing device may compare the second transaction identifier with the first transaction identifier to obtain a first comparison result, and may also compare the second transaction identifier with the minimum transaction identifier in the transaction identifier array to obtain a second comparison result. If the first comparison result indicates that the second transaction identifier is not equal to the first transaction identifier, and the second comparison result indicates that the second transaction identifier is greater than or equal to the minimum transaction identifier, the routing device may further determine a target transaction identifier based on the maximum transaction identifier in the transaction identifier array, and compare the second transaction identifier with the target transaction identifier to obtain a third comparison result. The target transaction identifier may be obtained by adding 1 to the maximum transaction identifier. Furthermore, based on the third comparison result, a query result for the second transaction identifier may be determined. If the query result obtained is an invisible result, the routing device may query the first routing snapshot in the first committed state, which is pointed to by the second routing snapshot in the pending state.

[0083] Optionally, if the third comparison result indicates that the second transaction identifier is greater than the target transaction identifier, it can be determined that the service status of the second routing snapshot is in an unexecuted state and pending submission state, and it can be determined that the query result for the second transaction identifier is an invisible result.

[0084] Optionally, if the third comparison result indicates that the second transaction identifier is less than or equal to the target transaction identifier, the second transaction identifier may be further searched in the transaction identifier array. If the second transaction identifier is found in the transaction identifier array, it may be determined that the business status of the second routing snapshot is in the pending submission state of the execution state, and it may be determined that the query result for the second transaction identifier is an invisible result.

[0085] It should be understood that before querying the first routing snapshot in the first committed state pointed to by the second routing snapshot in the pending state, the routing device may obtain the rollback pointer field carried by the second routing snapshot in the pending state. If the field value of the rollback pointer field is non-null, the routing device may obtain the third transaction identifier carried by the first routing snapshot pointed to by the rollback pointer field. The third transaction identifier is the transaction identifier corresponding to the transaction used to generate the first routing snapshot. The third transaction identifier may then be compared with the minimum transaction identifier in the transaction identifier array to obtain a fourth comparison result. If the fourth comparison result indicates that the third transaction identifier is less than the minimum transaction identifier, the service state of the first routing snapshot may be determined to be the first committed state. At this point, the first routing snapshot in the first committed state may be queried. Conversely, if the fourth comparison result indicates that the third transaction identifier is greater than or equal to the minimum transaction identifier, the routing device may continue to search for earlier routing snapshots using the rollback pointer field carried by the first routing snapshot.

[0086] For easier understanding, please refer to Figure 5 , Figure 5 This is a schematic diagram of a routing query scenario provided by an embodiment of the present application. The transaction identifier array (cur_tx_ids) refers to an array composed of transaction identifiers corresponding to all uncommitted transactions currently in progress. Assuming that the transaction identifier array initially includes transaction identifier 101, transaction identifier 102, transaction identifier 103, and transaction identifier 104, it can be understood that the minimum transaction identifier (min_tx_id) in the transaction identifier array is transaction identifier 101, and the maximum transaction identifier is transaction identifier 104. Then, the corresponding target transaction identifier (max_tx_id) at this time is transaction identifier 105 (i.e., 104+1). Among them, transaction identifier 101 corresponds to transaction 101, transaction identifier 102 corresponds to transaction 102, ..., transaction identifier 105 corresponds to transaction 105. As these transactions are gradually executed successfully and submitted, the transaction identifier array will also change accordingly.

[0087] like Figure 5 As shown, in the embodiment of the present application, a transaction with a transaction identifier less than the minimum transaction identifier (for example, transaction 100) can be called a committed transaction, and the business status of the routing snapshot corresponding to the committed transaction is the committed state. For example, for a routing snapshot X1, if the transaction identifier of the transaction corresponding to the routing snapshot X1 is less than the minimum transaction identifier, it means that the transaction has been committed before the current ongoing transaction (i.e., the uncommitted transaction) is started. Therefore, the routing snapshot X1 is visible to all transactions in the set of transactions to be committed.

[0088] Similarly, in the embodiments of the present application, a transaction whose transaction identifier is greater than the target transaction identifier (e.g., transaction 106) may be referred to as an unstarted transaction, and the business status of the routing snapshot corresponding to the unstarted transaction is in a pending-commit state. For example, for a routing snapshot X2, if the transaction identifier of the transaction corresponding to the routing snapshot X2 is greater than the target transaction identifier, it means that the transaction occurred after the currently ongoing transaction (i.e., the uncommitted transaction) was started. Since all transactions cannot read data that occurs in the future, the routing snapshot X2 is not visible to all transactions.

[0089] Similarly, in the embodiment of the present application, a transaction whose transaction identifier is in the transaction identifier array (for example, transaction 102) may be referred to as an uncommitted transaction (i.e., a transaction in the set of pending transactions), and the business state of the routing snapshot corresponding to the uncommitted transaction is a pending state in the execution state. As can be seen from the above, the pending state in the embodiment of the present application can be subdivided into two states, namely, a pending state in the unexecuted state and a pending state in the execution state, which correspond to an unstarted transaction and an uncommitted transaction, respectively.

[0090] Among them, for the routing snapshot corresponding to the uncommitted transaction, there are two situations:

[0091] (1) If it is the routing snapshot corresponding to an uncommitted transaction itself, or the routing snapshot corresponding to a currently committed transaction in the pending transaction set, then it is visible. For example, transaction 103 initially belongs to the same pending transaction set as transaction 101, but because transaction 103 executes faster, its corresponding routing snapshot is submitted before transaction 101 at some point. Therefore, transaction 101 can see both transaction 101's own data and the currently committed data of transaction 103 (i.e., the routing snapshot corresponding to transaction 103).

[0092] (2) If it is another transaction that is currently in the pending transaction set and has not been committed, it is not visible. For example, for transaction 101, the routing snapshot being updated by transaction 102 is not visible.

[0093] Further, please see Figure 6 , Figure 6 This is a flow chart of a route query provided by an embodiment of the present application. The route query process can be used as a specific implementation of step S102. Figure 6 As shown, the routing query process may include:

[0094] S1021. When a routing device performs a route query, it typically hopes to retrieve the latest version of the route. Therefore, the routing device can first obtain the transaction identifier tx_id (the transaction identifier carried by the second route snapshot, i.e., the second transaction identifier) carried by the latest snapshot record corresponding to the route to be queried (i.e., the second route snapshot described above, for example, route snapshot X3). Simultaneously, the transaction identifier cur_tx_id corresponding to the current transaction (i.e., the first transaction identifier of the route query transaction described above) can be obtained. Furthermore, the transaction identifier array cur_tx_ids corresponding to the ongoing transaction set (i.e., the pending transaction set) also needs to be obtained. It will be understood that at this point, the transaction identifier cur_tx_id belongs to the transaction identifier array cur_tx_ids.

[0095] S1022: The routing device may compare the transaction identifier tx_id with the transaction identifier cur_tx_id to obtain a first comparison result.

[0096] If the first comparison result indicates that the transaction identifier tx_id is equal to the transaction identifier cur_tx_id, it can be determined that the query result for the transaction identifier tx_id is a visible result, that is, the routing snapshot X3 is the routing snapshot of the current transaction itself, and the subsequent step S1028 can be executed.

[0097] If the first comparison result indicates that the transaction identifier tx_id is not equal to the transaction identifier cur_tx_id, the transaction identifier tx_id can be compared with the minimum transaction identifier min_tx_id in the transaction identifier array cur_tx_ids to obtain a second comparison result. If the second comparison result indicates that the transaction identifier tx_id is less than the minimum transaction identifier min_tx_id, the query result for the transaction identifier tx_id can be determined to be a visible result, and the service status of the routing snapshot X3 can be determined to be in the committed state, so step S1028 can be subsequently executed.

[0098] On the contrary, if the second comparison result indicates that the transaction identifier tx_id is not equal to the transaction identifier cur_tx_id, and the transaction identifier tx_id is greater than or equal to the minimum transaction identifier min_tx_id, step S1023 is executed.

[0099] At step S1023, the routing device may determine the target transaction identifier max_tx_id (i.e., the maximum transaction identifier plus 1) based on the maximum transaction identifier in the transaction identifier array cur_tx_ids, and then compare the transaction identifier tx_id with the target transaction identifier max_tx_id to obtain a third comparison result. If the third comparison result indicates that the transaction identifier tx_id is greater than the target transaction identifier max_tx_id, then the service status of routing snapshot X3 may be determined to be in the pending-commitment state (not executed), and the query result for the transaction identifier tx_id may be determined to be an invisible result, and step S1025 may be subsequently executed.

[0100] On the contrary, if the third comparison result indicates that the transaction identifier tx_id is less than or equal to the target transaction identifier max_tx_id, step S1024 is executed.

[0101] At step S1024, the routing device may search the transaction identifier array cur_tx_ids for the transaction identifier tx_id. If so, the routing device may determine that the service status of routing snapshot X3 is in the pending-commitment state and that the query result for the transaction identifier tx_id is an invisible result. Step S1025 may then be executed.

[0102] On the contrary, if it does not exist, it can be determined that the query result for the transaction identifier tx_id is a visible result, and it can be determined that the service status of the routing snapshot X3 is a submitted status, so step S1028 can be executed subsequently.

[0103] S1025: The routing device may obtain the rollback pointer field roll_ptr carried by the snapshot X3, and may search for the previous routing snapshot of the routing snapshot X3 through the rollback pointer roll_ptr.

[0104] At step S1026, the routing device checks the obtained rollback pointer field roll_ptr. If the rollback pointer field roll_ptr is detected to have a non-null value (i.e., the rollback pointer is a non-null pointer), it indicates that a previous routing snapshot (e.g., routing snapshot X4, i.e., the first routing snapshot) exists for routing snapshot X3, and step S1027 can be executed. Conversely, if the rollback pointer field roll_ptr is detected to have a null value (i.e., the rollback pointer is a null pointer), it indicates that a previous routing snapshot (i.e., routing snapshot X3) does not exist, and the routing query process ends.

[0105] At step S1027, the routing device may obtain the transaction identifier tx_id' (i.e., the third transaction identifier) of routing snapshot X4, as pointed to by the field value of the rollback pointer field roll_ptr, and then compare the transaction identifier tx_id' with the minimum transaction identifier min_tx_id to obtain a fourth comparison result. If the fourth comparison result indicates that the transaction identifier tx_id' is less than the minimum transaction identifier min_tx_id, then the query result for the transaction identifier tx_id' may be determined to be a visible result, and the service status of routing snapshot X4 may be determined to be committed, and therefore step S1028 may be subsequently executed.

[0106] On the contrary, if the fourth comparison result indicates that the transaction identifier tx_id' is greater than or equal to the minimum transaction identifier min_tx_id, it can be determined that the service status of the routing snapshot X4 is not yet committed, and the process returns to step S1025 to continue searching for an earlier version of the routing snapshot.

[0107] S1028: The routing device may return a corresponding routing snapshot (ie, routing snapshot X3 corresponding to transaction identifier tx_id or routing snapshot X4 corresponding to transaction identifier tx_id′) based on the visible result, and this routing query process ends.

[0108] It should be understood that a routing device may need to query multiple routing snapshots in a single transaction. The above process can be used to filter these routing snapshots to obtain the routing snapshots visible to the transaction. For example, if the current transaction requires reading routing snapshots 1, 2, and 3, the routing device will filter out the data visible to the transaction from these snapshots.

[0109] It should be understood that all routing snapshots returned by the above query method together constitute the routing list that can be read by the current transaction (i.e., the transaction corresponding to the transaction identifier cur_tx_id). This routing list is consistent across multiple queries within this transaction, regardless of how long it takes to execute or how the query conditions change. In other words, the data read by each transaction is highly consistent, and dirty reads (i.e., reading uncommitted data) and non-repeatable reads (i.e., reading data multiple times with inconsistent results) will not occur. Due to different start times, each transaction may see different data for the same routing table, but the data seen by the same transaction is always consistent and will not read data being updated by other transactions. This also ensures that routing reads and updates do not affect each other, allowing for unblocked business updates and improving business processing capabilities.

[0110] S103: When it is found that the routing snapshot of the routing device is the first routing snapshot pointed to by the second routing snapshot, the service state of the second routing snapshot is changed from a pending state to a second submitted state, and the second routing snapshot in the second submitted state is stored by the verification service device.

[0111] For example, when the routing snapshot of the routing device is found to be the first routing snapshot pointed to by the second routing snapshot, the routing device can turn to query the first routing snapshot in the first committed state, and after the routing update transaction successfully completes the routing update, the service state of the second routing snapshot is changed from the previous pending state to the second committed state. Finally, the second routing snapshot in the second committed state can be stored by the verification service device, and the subsequent verification service device can further verify the second routing in the second committed state. The specific implementation method can be found in the subsequent Figure 10 The corresponding embodiment.

[0112] Further, see Figure 7 , Figure 7 This is a flow chart of a method for processing routing data provided by an embodiment of the present application. The routing data processing method can be executed by a routing device, for example, Figure 1 The routing device 300b shown. Figure 7 As shown, the routing data processing method may at least include:

[0113] S201, obtaining route change information determined by service change data of a user equipment;

[0114] The specific process of this step can be found in the above Figure 3 Step S101 in the corresponding embodiment will not be described in detail here.

[0115] S202, when the route update transaction includes a route modification operation for changing a first route to a second route, generating a second route snapshot of the second route;

[0116] In an embodiment of the present application, each routing snapshot includes a routing key field and a routing parameter field. Among them, the routing key field may include at least three invisible fields and a deletion identification field. To resolve read-write conflicts, the multi-version routing snapshot principle of the embodiment of the present application mainly relies on these three invisible fields to be implemented, namely, the transaction identification field (tx_id, also known as the transaction ID, transaction primary key), the row auto-increment identification field (row_id, also known as the row primary key) and the rollback pointer field (roll_ptr), wherein the field value of the transaction identification field is the transaction identifier; the field value of the row auto-increment identification field is the unique identifier of each row of routing records, which can be an implicit auto-increment ID; the field value of the rollback pointer field is used to point to the routing snapshot of the previous version of the current route, for example, the storage address of the routing snapshot of the previous version can be used as the field value. The value of the delete flag field can be used to indicate whether the current route snapshot needs to be deleted. For example, when the value of the delete flag field carried by a route snapshot is a valid field value (for example, 1), it indicates that the route snapshot needs to be deleted; when the value of the delete flag field is an invalid field value (for example, 0), it indicates that the route snapshot does not need to be deleted. The value of the route parameter field includes the actual route parameters, such as the route prefix and next-hop address.

[0117] For easier understanding, please refer to Figure 8 , Figure 8 This is a schematic diagram of the structure of a routing snapshot provided by an embodiment of the present application. Figure 8 As shown, routing snapshot 800a, whose row auto-increment identifier field has a value of 100, carries a transaction identifier field value of 1001, and its rollback pointer field value points to routing snapshot 800b. Furthermore, routing snapshot 800a also includes routing parameters such as parameters 80A, 80B, ..., and 80N. Similarly, routing snapshot 800b, whose row auto-increment identifier field has a value of 96, carries a transaction identifier field value of 1000, and its rollback pointer field value points to routing snapshot 800c. Furthermore, routing snapshot 800b also includes routing parameters such as parameters 81A, 81B, ..., and 81N. Furthermore, routing snapshot 800c, whose row auto-increment identifier field has a value of 91, carries a transaction identifier field value of 999, and routing snapshot 800b also includes routing parameters such as parameters 82A, 82B, ..., and 82N. It can be understood that different versions of routing snapshots are connected in series through the rollback pointer fields they carry, which is equivalent to forming a chain of routing snapshots. If a routing update transaction fails, it can be rolled back to the previous routing snapshot in the corresponding chain.

[0118] Based on this, the embodiment of the present application may refer to the transaction corresponding to the route change information as a route update transaction. When the route update transaction includes a route modification operation (update), the routing device may change the first route to the second route based on the route modification operation, for example, Figure 8 The parameters 81A-81N are changed to parameters 80A-80N. Furthermore, a row auto-increment identification field and a rollback pointer field corresponding to the second route can be generated, and the transaction identification field (for example, 1001) whose field value is the second transaction identifier of the route update transaction, the row auto-increment identification field (for example, 100), and the rollback pointer field (for example, pointing to route snapshot 800b) are used as the route key fields associated with the second route, wherein the field value of the rollback pointer field is used to point to the first route snapshot (for example, pointing to route snapshot 800b). Finally, a second route snapshot (for example, route snapshot 800a) of the second route can be generated based on the second route and the route key field. Optionally, the route key field can also include a deletion identification field.

[0119] For easier understanding, please refer to Figure 9 , Figure 9 This is a schematic diagram of the structure of a routing snapshot provided by an embodiment of the present application. Figure 9 As shown, the routing snapshots in the embodiment of the present application can be organized and stored in the form of a routing table, which is equivalent to expanding the routing items in the traditional routing table. Multiple versions of routing snapshots can be stored. At this time, each row of routing records in the routing table is a routing snapshot. The latest version of the routing snapshot can be read from the routing table when forwarding business data. For example, suppose that the current routing table of the routing device includes routing snapshot 900a, routing snapshot 900b, routing snapshot 900c, routing snapshot 900d, routing snapshot 900e, and routing snapshot 900f. It should be noted that the routing parameters "Jackie", routing parameters: "80" and other data exemplified in the figure are all real routing parameters such as routing prefixes and masks in actual business scenarios. As Figure 9As shown, the routing device first executed the transaction with transaction ID 101, modified the routes of "Jackie" and "Tom", and obtained route snapshots 900a and 900b; then executed the transaction with transaction ID 102, inserted the route of "Sandy", and obtained route snapshot 900c; in the transaction with transaction ID 103, the score of "Jackie" was changed to 82, and obtained route snapshot 900d. At the same time, the rollback pointer of the latest route snapshot 900d of "Jackie" was set to 0. The field value points to routing snapshot 900a. In transaction 105, Jackie's score is changed to 85, resulting in routing snapshot 900e. Meanwhile, the field value of the rollback pointer of Jackie's latest routing snapshot 900e points to routing snapshot 900d. In transaction 106, Tom's score is changed to 56, resulting in routing snapshot 900f. Meanwhile, the field value of the rollback pointer of Tom's latest routing snapshot 900f points to routing snapshot 900b.

[0120] S203, when the routing update transaction includes a routing deletion operation, deleting the first routing snapshot based on the routing deletion operation;

[0121] Exemplarily, when the routing update transaction includes a routing deletion operation (delete), the routing device may set the field value of the deletion identification field carried in the first routing snapshot to a valid field value (for example, to 1) based on the routing deletion operation, and use the first routing snapshot carrying the valid field value as the routing snapshot to be deleted. Furthermore, when the routing snapshot to be deleted meets the deletion condition, the routing snapshot to be deleted may be deleted by the deletion thread. Optionally, the deletion thread may delete all routing snapshots carrying valid field values in order of version from low to high (for example, based on the generation timestamp, or based on the field value of the row auto-increment identification field). In this case, when the routing snapshot to be deleted belongs to the lowest version among all routing snapshots waiting to be deleted, or is in a certain version deletion interval, the deletion condition may be met.

[0122] Please see again Figure 9 For example, when a routing device wishes to delete routing snapshot 900d, it doesn't delete the snapshot directly. Instead, it first sets the deletion flag field in routing snapshot 900d to 1, waiting for the subsequent deletion thread to periodically clean up earlier routing snapshots. This approach allows the routing device to still retrieve the routing snapshot through rollback before it is actually deleted. Direct deletion, however, prevents rolling back recent routing snapshots.

[0123] S204, when the route update transaction includes a route adding operation, adding a third route to the route snapshot of the routing device based on the route adding operation;

[0124] Exemplarily, when a routing update transaction includes a routing addition operation (insert) for adding a third route to a routing snapshot of a routing device, the routing device can obtain the third route based on the routing addition operation, and generate a newly added row auto-increment identification field and a newly added rollback pointer field corresponding to the third route, and can use the newly added transaction identification field, the newly added row auto-increment identification field, and the newly added rollback pointer field, whose field values are the second transaction identifier of the routing update transaction, as newly added route key fields associated with the third route. The field value of the newly added rollback pointer field is a null value. Furthermore, a third routing snapshot of the third route can be generated based on the third route and the newly added route key field, and the third routing snapshot can be added to the routing snapshot of the routing device.

[0125] Please see again Figure 9 ,by Figure 9 Taking route snapshot 900c in the example, it adds a route "Sandy" that did not exist before, and there is no rollback of the previous version. Therefore, the field value of the rollback pointer field (that is, the newly added rollback pointer field) of route snapshot 900c is a null value, indicating that route snapshot 900c is the first version of the route "Sandy".

[0126] S205, querying the routing snapshot of the routing device in the process of updating the routing snapshot of the routing device from the first routing snapshot of the first route to the second routing snapshot of the second route based on the routing change information;

[0127] The specific process of this step can be found in the above Figure 3 Step S102 in the corresponding embodiment will not be described in detail here.

[0128] S206: When it is found that the routing snapshot of the routing device is the first routing snapshot pointed to by the second routing snapshot, the service state of the second routing snapshot is changed from a pending state to a second submitted state, and the second routing snapshot in the second submitted state is stored by the verification service device.

[0129] The specific process of this step can be found in the above Figure 3 Step S103 in the corresponding embodiment will not be described in detail here.

[0130] As can be seen from the above, when the service data of the user device changes, the route used to forward the service data on the routing device will also change (for example, the first route changes to the second route). To resolve read-write conflicts, the routing device can generate different versions of routing snapshots based on the route change information. In the process of updating the first routing snapshot of the first route to the second routing snapshot of the second route, the second routing snapshot is still in the pending submission state, indicating that the routing update has not ended. Therefore, if the second routing snapshot is queried at the same time, the query result is the previous snapshot record pointed to by the second routing snapshot, that is, the first routing snapshot. Using snapshots to copy routing status can achieve distributed routing reading and writing without blocking, that is, routing queries will not be interrupted when the route is updated, thereby improving the forwarding efficiency of service data.

[0131] Further, see Figure 10 , Figure 10 This is a flow chart of a routing data processing method provided by an embodiment of the present application. The routing data processing method can be executed by a verification service device, which is a computing resource independent of the routing device. Figure 10 As shown, the routing data processing method may at least include:

[0132] S301, obtaining a target route snapshot based on the acquired second route snapshot in the second committed state, and storing the target route snapshot in a route cache associated with the verification service device;

[0133] Exemplarily, the verification service device may obtain a second routing snapshot in a second committed state from a cloud message queue. The cloud message queue may be considered a basic cloud service with high reliability and performance, and may be used to transmit routing snapshots generated by the routing device to a regional controller associated with the routing device.

[0134] Furthermore, a version verification may be performed on the second routing snapshot in the second committed state to obtain a version verification result, and a target routing snapshot may be obtained based on the version verification result. The specific process may be as follows: the verification service device may request a global routing snapshot associated with the second routing snapshot in the second committed state from a global controller associated with the regional controller, and compare the second routing snapshot in the second committed state with the global routing snapshot to obtain a version verification result. If the version verification result indicates that the second routing snapshot in the second committed state is consistent with the global routing snapshot, the second routing snapshot in the second committed state is used as the target routing snapshot; conversely, if the version verification result indicates that the second routing snapshot in the second committed state is inconsistent with the global routing snapshot, the global routing snapshot is used as the target routing snapshot.

[0135] Finally, the obtained target route snapshot may be stored in a route cache associated with the verification service device.

[0136] The global controller is the top-level controller, capable of viewing all data (including data on regional controllers, routing devices, verification service devices, and other devices). For example, it can view the configuration of all regional controllers. When business needs arise, the global controller can also send user routing changes to regional controllers. Regional controllers, on the other hand, focus on forwarding and configuration for a region (such as East China or South China), and are associated with all routing devices in that region. Actual business forwarding is primarily performed by routing devices.

[0137] The verification service device belongs to a verification service device cluster. The verification service device cluster is an independent distributed computing resource that can provide route verification services, thereby reducing resource consumption of regions and routing devices and reducing latency. The route cache is associated with the verification service device cluster and can serve as a persistent layer to store route snapshots. The route cache can be a specific device in the verification service device cluster, or it can be a storage module in a verification service device. Every verification service device in the verification service device cluster can access the route cache.

[0138] It can be understood that the global controller, regional controller, verification service device, routing device and object storage involved in the embodiments of the present application can be deployed independently, or can be deployed in other ways according to actual needs, but different devices can communicate with each other.

[0139] The specific process of generating the second routing snapshot with the second committed state can be found in the above Figure 3 and Figure 7 The corresponding embodiments will not be described in detail here.

[0140] S302: Upon receiving a route check request, obtain a second route snapshot in a second committed state from the object storage indicated by the route check request as an original route snapshot, and perform route check on the original route snapshot based on the target route snapshot stored in the route cache.

[0141] It should be understood that distributed routing verification is the core content of 5G cloud computing, and the cloud message queue can be a queue stored in the cloud virtual space or cloud server, which is used to provide basic cloud services for the regional controller and the verification service device. For example, the cloud message queue in the embodiment of the present application can be used to cache the routing verification request sent by the regional controller. It should be understood that in the 5G network, the control plane needs to frequently perform parameter audits on the configuration of the forwarding plane, and routing is a very important data in the configuration of the routing device. Therefore, the routing verification request in the embodiment of the present application is used to request the verification service device to perform parameter audits on the routing data stored on the routing device, find the differences between the user configuration and the configuration on the routing device, and re-issue the configuration of the routing device, and delete the redundant configuration of the routing device.

[0142] It should be noted that distributed route verification is the core content of 5G cloud computing, and existing route verification solutions usually carry out verification work on routing devices, which also requires locking the verified route data. Since route verification is a time-consuming operation, the more route items stored in the routing device, the more impact the route verification will have on the business, resulting in the entire verification process occupying the computing resources of the routing device for a long time. The embodiment of the present application can support both automatic triggering and manual triggering to trigger route verification and error correction. When differences are found, erroneous route data can be repaired safely and reliably to achieve route synchronization on the 5G cloud. Optionally, the route verification request can be a request that the regional controller sends to the cloud message queue at regular intervals, or the route verification request can be a request that the regional controller sends to the cloud message queue after receiving a trigger instruction from the global controller associated with the regional controller. That is to say, when there is a routing change in the routing device, it will actively report it to the regional controller. The regional controller will regularly start the routing verification task and enable the routing verification action on other container resources (that is, the verification service device cluster) without affecting the current business of the routing device; when an emergency situation occurs and the routing verification needs to be started immediately, it can be manually triggered by the operation and maintenance personnel.

[0143] It should be understood that, based on a route verification request in a cloud message queue, the verification service device can read a second route snapshot in the second committed state from the object storage indicated by the route verification request as the original route snapshot. Furthermore, the target route snapshot can be read from the route cache and compared with the original route snapshot. Furthermore, if the target route snapshot is inconsistent with the original route snapshot, such as when the routing device is powered on again, restarted, powered off and then back online, or due to an abnormal network situation, the verification service device can generate a route correction request and return the route correction request to the routing device, so that the routing device corrects the second route snapshot in the second committed state based on the route correction request. It should be understood that the correction process here can also be performed in a transactional manner, so that the routing device updates the second route snapshot in the second committed state based on the route correction request. Optionally, if the target route snapshot is consistent with the original route snapshot, the verification service device can return a verification success result to the routing device.

[0144] Among them, the object storage here can be a storage resource independent of the routing device. In addition to the routing device as a forwarding plane needing to store routing snapshots locally to achieve fast routing reading, the object storage (i.e., object storage) can also store routing snapshots generated by the routing device and submitted by the regional controller. For example, the object storage can be an object storage Ceph system. In this way, when performing routing verification on the verification service device, the routing snapshot to be verified (i.e., the original routing snapshot) can be directly pulled from the object storage, and the routing snapshot can be compared with the corresponding version of the routing snapshot (i.e., the target routing snapshot) stored in the routing cache, so that the resources of the routing device will not be occupied during routing verification.

[0145] It should be understood that in an embodiment of the present application, the verification service device cluster may include one or more verification service devices, and all verification service devices in the verification service device cluster can verify the routing snapshots of all routing devices. In an embodiment of the present application, the verification service device used to perform a certain routing verification task can be any device in the verification service device cluster. For example, when a routing verification request is received, all verification service devices in the verification service device cluster will compete, and the verification service device that successfully competes can perform routing verification. In addition, the verification service device that successfully competes can also be recorded in Zookeeper (a distributed program coordination service), and the subsequent global controller can view it in Zookeeper. Among them, for different types of cloud message queues (such as RabbitMQ, Kafka, etc.), different same-group consumption algorithms can be used to select a suitable verification service device to carry out the verification work. The embodiment of the present application does not limit the specific type of cloud message queue. It can be understood that the use of multiple versions to achieve rapid verification in a distributed scenario can avoid affecting the normal business processing flow and improve the routing concurrent processing capability.

[0146] It is understandable that since the regional controller continuously sends the routing snapshots generated by the routing device to the verification service device cluster through the cloud message queue, the routing cache may store multiple versions of the routing snapshots of the same route, but generally the latest version of the routing snapshot will be verified without the need to verify other earlier versions.

[0147] Among them, route verification can include full verification and partial verification. Full verification refers to verifying the latest version of the route snapshot of all routes, while partial verification refers to verifying the route snapshot of a specified route. In this case, the version number of the route snapshot to be verified (or the row auto-increment identification field) can be carried in the route verification request.

[0148] Please also see Figure 11 , Figure 11 This is a schematic diagram of a route verification scenario provided by an embodiment of the present application. This scenario is an automatic triggering scenario. Figure 11As shown, the continuous changes in business data will cause the routing on the routing device to also continuously change, thereby generating different versions of routing snapshots. For example, when business data X is 3 and business data Y changes from 3 to 0, the routing device generates a routing snapshot with version number 101 (referred to as routing snapshot 101). When business data X changes from 3 to 0, the routing device generates a routing snapshot with version number 102 (referred to as routing snapshot 102). Similarly, when business data X changes from 0 to 2 and business data Y changes from 0 to 2, the routing device can generate a routing snapshot with version number 103 (referred to as routing snapshot 103). The routing device can actively report routing changes to the regional controller, that is, send the generated routing snapshot to the regional controller associated with the routing device. Upon receiving the routing snapshot, the regional controller can send the routing snapshot (e.g., routing snapshot 101, routing snapshot 102, routing snapshot 103, etc.) to the cloud message queue through the routing synchronization module in the regional controller. The routing snapshot can then be sent to the verification service device cluster for consumption through the cloud message queue. At the same time, the regional controller generates corresponding files based on these routing snapshots and stores them in the object storage. For example, the regional controller can obtain the corresponding file based on the routing snapshot generated by the routing device and the timestamp when the file was generated. Furthermore, the verification service device cluster continuously pulls routing snapshots from the cloud message queue and stores them in the associated routing cache. When the regional controller sends a route verification request to the cloud message queue regularly or periodically (for example, every 10 hours) through the route verification module (for example, check_point can be added to the cloud message queue as a route verification identifier), a verification service device in the verification service device cluster (for example, a verification service device that successfully competes) can obtain the route verification request from the cloud message queue, and based on the route verification request, pull the corresponding version of the file from the object storage to obtain the original route snapshot, and compare the original route snapshot with the target route snapshot in the route cache, for example, perform a diff calculation. When the comparison result indicates that the target route snapshot is inconsistent with the original route snapshot, the routing device is notified to trigger the correction behavior, that is, after the routing device receives the route correction request sent by the verification service device, it can request the global controller to update the difference route. For example, if the routing device restarts abnormally and the user updates the route in the global controller, the global controller needs to send the difference route to the routing device. It can be understood that no external intervention is required in the automatic triggering scenario.

[0149] Please also see Figure 12 , Figure 12 The present application embodiment provides a schematic diagram of a route verification scenario. This scenario is a manual trigger scenario. Figure 11The process described is similar. When the route verification is not triggered, the routing device can also report the generated route snapshots (such as route snapshot 101, route snapshot 102, route snapshot 103, etc.) to the regional controller. The route synchronization module in the regional controller then sends these route snapshots to the cloud message queue, and then sends them to the verification service device cluster through the cloud message queue for consumption. At the same time, the regional controller will also store these route snapshots in the object storage in the form of files. Figure 12 As shown, when operation and maintenance or business needs require, the global controller manually triggers the verification task to the regional controller. At this time, the global controller can send the routing snapshot (also generated by the routing device and visible to the global controller) to the regional controller, and then send the routing snapshot to the object storage and verification service device cluster through the process described above; at the same time, a trigger instruction is sent to the regional controller. After the regional controller receives the trigger instruction, it can also send a routing verification request to the cloud message queue through the routing verification module. Then, a verification service device in the verification service device cluster can obtain the routing verification request from the cloud message queue, and based on the routing verification request, pull the corresponding version of the file from the object storage to obtain the original routing snapshot, and compare the original routing snapshot with the target routing snapshot in the routing cache. When the comparison result indicates that the target routing snapshot is inconsistent with the original routing snapshot, the routing device is notified to trigger the corrective action. It can be understood that manual triggering requires human participation, such as manual triggering by operation and maintenance personnel.

[0150] As can be seen from the above, embodiments of the present application can support a verification service device to obtain a target route snapshot based on a second route snapshot obtained in a second committed state, and store the target route snapshot in a route cache associated with the verification service device. Furthermore, upon receiving a route verification request, the verification service device can obtain the second route snapshot in the second committed state from the object storage indicated by the route verification request as the original route snapshot, and then perform a route verification on the original route snapshot based on the target route snapshot stored in the route cache. Embodiments of the present application can support both automatic and manual triggering to enable route verification and error correction, enriching the route verification methods and enabling selection based on service needs, making route verification more flexible. Furthermore, since both the verification service device and the object storage are independent resources of the routing device, performing route verification does not affect the routing device's normal service forwarding, route query, and update operations, thereby reducing resource consumption on the routing device, reducing latency, and improving service data forwarding efficiency. Furthermore, secure and reliable data repair can be performed when discrepancies are discovered during route verification.

[0151] See Figure 13A schematic diagram of the structure of a routing data processing device provided in an embodiment of the present application. The routing data processing device can be a computer program (including program code) running on a computer device, for example, the routing data processing device is an application software; the device can run in a routing device, and the device can be used to execute the corresponding steps in the routing data processing method provided in an embodiment of the present application. Figure 13 , the routing data processing 1 may include: an acquisition module 11, a query module 12, a change module 13, a rollback module 14, a determination module 15, a modification module 16, a deletion module 17, and a new addition module 18;

[0152] An acquisition module 11 is configured to acquire route change information determined by service change data of a user equipment;

[0153] A query module 12 is configured to query a routing snapshot of a routing device during a process of updating the routing snapshot of the routing device from a first routing snapshot to a second routing snapshot based on routing change information; the service status of the first routing snapshot is a first committed state, the service status of the second routing snapshot is a pending commit state, and the first routing snapshot in the first committed state is a previous snapshot record of the second routing snapshot in the pending commit state;

[0154] The query module 12 may include: a transaction determination unit 121, an identification acquisition unit 122, an identification query unit 123, and a route query unit 124;

[0155] The transaction determining unit 121 is configured to generate a routing update transaction based on the routing change information, and to determine a target routing transaction in a process of updating a routing snapshot of a routing device from a first routing snapshot to a second routing snapshot based on the routing update transaction; the target routing transaction includes a routing query transaction for querying the routing snapshot of the routing device;

[0156] The identifier acquisition unit 122 is configured to acquire a first transaction identifier of a routing query transaction, a second transaction identifier of a routing update transaction, and a transaction identifier array corresponding to a pending transaction set included in the target routing transaction; the transaction identifier array is configured to record the transaction identifier of each transaction in the pending transaction set; the pending transaction set includes the routing query transaction;

[0157] The identifier query unit 123 is configured to query the second transaction identifier corresponding to the second routing snapshot based on the first transaction identifier, the second transaction identifier, and the transaction identifier array, and obtain a query result for the second transaction identifier;

[0158] The identification query unit 123 may include: a first comparison subunit 1231, a second comparison subunit 1232, and a result determination subunit 1233;

[0159] The first comparison subunit 1231 is configured to compare the second transaction identifier with the first transaction identifier to obtain a first comparison result; and compare the second transaction identifier with the minimum transaction identifier in the transaction identifier array to obtain a second comparison result;

[0160] a second comparing subunit 1232 configured to, if the first comparison result indicates that the second transaction identifier is not equal to the first transaction identifier and the second comparison result indicates that the second transaction identifier is greater than or equal to the minimum transaction identifier, determine a target transaction identifier based on a maximum transaction identifier in the transaction identifier array, and compare the second transaction identifier with the target transaction identifier to obtain a third comparison result;

[0161] A result determination subunit 1233 is configured to determine a query result for the second transaction identifier based on the third comparison result;

[0162] The result determination subunit 1233 is specifically configured to determine that the service status of the second routing snapshot is in a pending-commitment state (not executed) if the third comparison result indicates that the second transaction identifier is greater than the target transaction identifier, and determine that the query result for the second transaction identifier is an invisible result;

[0163] The result determination subunit 1233 is specifically configured to search for the second transaction identifier in the transaction identifier array if the third comparison result indicates that the second transaction identifier is less than or equal to the target transaction identifier; and is specifically configured to determine that the service status of the second routing snapshot is in the pending submission state of the execution state, and determine that the query result for the second transaction identifier is an invisible result if the second transaction identifier is found in the transaction identifier array.

[0164] The specific implementation of the first comparison subunit 1231, the second comparison subunit 1232, and the result determination subunit 1233 can be found in the above Figure 3 The description of step S102 in the corresponding embodiment will not be repeated here.

[0165] The routing query unit 124 is configured to query the first routing snapshot in the first committed state pointed to by the second routing snapshot in the pending committed state if the query result is an invisible result;

[0166] The specific implementation of the transaction determination unit 121, the identification acquisition unit 122, the identification query unit 123, and the route query unit 124 can be found in the above Figure 3 The description of step S102 in the corresponding embodiment will not be repeated here.

[0167] a changing module 13 configured to, when finding that the routing snapshot of the routing device is the first routing snapshot pointed to by the second routing snapshot, change the service state of the second routing snapshot from a pending state to a second committed state, and store the second routing snapshot in the second committed state through the verification service device;

[0168] The rollback module 14 is configured to obtain a rollback pointer field carried by the second routing snapshot in a pending commit state, and if the field value of the rollback pointer field is non-null, obtain a third transaction identifier carried by the first routing snapshot to which the field value of the rollback pointer field points; the third transaction identifier is a transaction identifier corresponding to the transaction used to generate the first routing snapshot;

[0169] a determination module 15 configured to compare the third transaction identifier with the minimum transaction identifier in the transaction identifier array to obtain a fourth comparison result; and if the fourth comparison result indicates that the third transaction identifier is less than the minimum transaction identifier, determining that the service state of the first routing snapshot is a first committed state;

[0170] The route change information is determined by changing the first route used to forward the change record corresponding to the service change data to a second route; both the second route and the first route are determined based on the service change data; the transaction corresponding to the route change information is a route update transaction, which includes a route modification operation for changing the first route to the second route:

[0171] Modification module 16 is configured to generate a row auto-increment identification field and a rollback pointer field corresponding to the second route, use the transaction identification field, the row auto-increment identification field, and the rollback pointer field, whose field values are the second transaction identification of the route update transaction, as route key fields associated with the second route; the field value of the rollback pointer field is used to point to the first route snapshot of the first route; and generate a second route snapshot of the second route based on the second route and the route key field.

[0172] The transaction corresponding to the route change information is a route update transaction, and the route update transaction includes a route deletion operation;

[0173] The deletion module 17 is configured to set the field value of the deletion identification field carried in the first route snapshot to a valid field value based on the route deletion operation, and use the first route snapshot carrying the valid field value as the route snapshot to be deleted; and when the route snapshot to be deleted meets the deletion condition, delete the route snapshot to be deleted through the deletion thread;

[0174] The transaction corresponding to the route change information is a route update transaction, and the route update transaction includes a route adding operation for adding a third route to the route snapshot of the routing device;

[0175] A new module 18 is added, which is used to obtain a third route based on a route addition operation, generate a new row auto-increment identification field and a new rollback pointer field corresponding to the third route, and use the new transaction identification field, the new row auto-increment identification field, and the new rollback pointer field whose field values are the second transaction identifier of the route update transaction as the new route key fields associated with the third route; the field value of the new rollback pointer field is a null value; generate a third route snapshot of the third route based on the third route and the new route key field, and add the third route snapshot to the route snapshot of the routing device.

[0176] The specific implementation of the acquisition module 11, the query module 12, the change module 13, the rollback module 14, the determination module 15, the modification module 16, the deletion module 17, and the addition module 18 can be found in the above Figure 3 The corresponding embodiment and the above Figure 7 The descriptions in the corresponding embodiments will not be repeated here. In addition, the descriptions of the beneficial effects of the same method will not be repeated here either.

[0177] See Figure 14 A schematic diagram of the structure of a routing data processing device provided in an embodiment of the present application. The routing data processing device can be a computer program (including program code) running on a computer device, for example, the routing data processing device is an application software; the device can run in a verification service device, and the device can be used to execute the corresponding steps in the routing data processing method provided in an embodiment of the present application. Figure 14 , the routing data processing 2 may include: a storage module 21, a verification module 22, and an error correction module 23;

[0178] The storage module 21 is configured to obtain a target routing snapshot based on the acquired second routing snapshot in the second committed state, and store the target routing snapshot in a routing cache associated with the verification service device; the second routing snapshot in the second committed state is obtained by the routing device changing the service state of the second routing snapshot from a pending-commitment state to a second committed state when the found routing snapshot is the first routing snapshot pointed to by the second routing snapshot; the routing device is configured to query the routing snapshot of the routing device during the process of updating the routing snapshot of the routing device from the first routing snapshot to the second routing snapshot based on the routing change information; the service state of the first routing snapshot is the first committed state, the service state of the second routing snapshot is the pending-commitment state during the snapshot update process, and the first routing snapshot in the first committed state is a previous snapshot record of the second routing snapshot in the pending-commitment state;

[0179] The storage module 21 may include: a route acquisition unit 211, a version verification unit 212, and a route storage unit 213;

[0180] The routing acquisition unit 211 is configured to acquire a second routing snapshot in a second committed state from a cloud message queue, wherein the cloud message queue is configured to transmit the routing snapshot generated by the routing device to a regional controller associated with the routing device.

[0181] A version verification unit 212 is configured to perform version verification on the second route snapshot in the second committed state to obtain a version verification result, and obtain a target route snapshot based on the version verification result;

[0182] The version verification unit 212 may include: a route comparison subunit 2121, a first route determination subunit 2122, and a second route determination subunit 2123;

[0183] The route comparison subunit 2121 is configured to request a global routing snapshot associated with the second routing snapshot in the second committed state from the global controller associated with the regional controller, compare the second routing snapshot in the second committed state with the global routing snapshot, and obtain a version verification result.

[0184] a first routing determination subunit 2122 configured to use the second routing snapshot in the second committed state as a target routing snapshot if the version verification result indicates that the second routing snapshot in the second committed state is consistent with the global routing snapshot;

[0185] The second route determination subunit 2123 is configured to use the global route snapshot as a target route snapshot if the version verification result indicates that the second route snapshot in the second committed state is inconsistent with the global route snapshot;

[0186] The specific implementation of the route comparison subunit 2121, the first route determination subunit 2122, and the second route determination subunit 2123 can be found in the above Figure 3 The description of step S102 in the corresponding embodiment will not be repeated here.

[0187] The route storage unit 213 is configured to store the target route snapshot in a route cache associated with the verification service device;

[0188] The specific implementation of the route acquisition unit 211, the version verification unit 212, and the route storage unit 213 can be found in the above Figure 10 As the description of step S301 in the embodiment has been completed, it will not be further described here.

[0189] a verification module 22 configured to, upon receiving a route verification request, obtain a second route snapshot in a second committed state from an object storage indicated by the route verification request as an original route snapshot, and perform route verification on the original route snapshot based on the target route snapshot stored in the route cache;

[0190] The cloud message queue is used to cache route verification requests sent by the regional controller; the route verification request is a request that the regional controller sends to the cloud message queue on a regular basis, or the route verification request is a request that the regional controller sends to the cloud message queue after receiving a trigger instruction from the global controller associated with the regional controller;

[0191] The verification module 22 may include: a route reading unit 221 and a route comparison unit 222;

[0192] The route reading unit 221 is configured to read, based on the route verification request in the cloud message queue, a second route snapshot in a second committed state from an object storage indicated by the route verification request as an original route snapshot; the object storage is independent of the routing device and is configured to store the route snapshot generated by the routing device and submitted by the regional controller;

[0193] The route comparison unit 222 is configured to read the target route snapshot from the route buffer and compare the target route snapshot with the original route snapshot;

[0194] The specific implementation of the route reading unit 221 and the route comparison unit 222 can be found in the above Figure 10 The description of step S302 in the corresponding embodiment will not be repeated here.

[0195] The error correction module 23 is configured to generate a routing error correction request if the target routing snapshot is inconsistent with the original routing snapshot, and return the routing error correction request to the routing device, so that the routing device performs error correction processing on the second routing snapshot in the second committed state based on the routing error correction request.

[0196] The specific implementation of the storage module 21, the verification module 22, and the error correction module 23 can be found in the above Figure 10 The description of steps S301 and S302 in the corresponding embodiment will not be repeated here. In addition, the description of the beneficial effects of the same method will not be repeated here either.

[0197] See Figure 15 , a schematic diagram of the structure of a computer device provided in an embodiment of the present application. Figure 15As shown, the computer device 1000 may include: a processor 1001, a network interface 1004 and a memory 1005. In addition, the above-mentioned computer device 1000 may also include: a user interface 1003, and at least one communication bus 1002. The communication bus 1002 is used to realize the connection and communication between these components. The user interface 1003 may include a display screen (Display), a keyboard (Keyboard), and the user interface 1003 may optionally include a standard wired interface and a wireless interface. The network interface 1004 may optionally include a standard wired interface and a wireless interface (such as a WI-FI interface). The memory 1004 may be a high-speed RAM memory, or a non-volatile memory (non-volatile memory), such as at least one disk memory. The memory 1005 may optionally be at least one storage device located away from the aforementioned processor 1001. As Figure 15 As shown, the memory 1005 as a computer-readable storage medium may include an operating system, a network communication module, a user interface module, and a device control application.

[0198] In such Figure 15 In the computer device 1000 shown, the network interface 1004 can provide network communication functions; the user interface 1003 is mainly used to provide an input interface for the user; and the processor 1001 can be used to call the device control application stored in the memory 1005 to execute the above Figure 3 、 Figure 7 、 Figure 10 The description of the routing data processing method in the corresponding embodiment will not be repeated here. In addition, the description of the beneficial effects of adopting the same method will not be repeated here either.

[0199] In addition, it should be noted that: the embodiment of the present application also provides a computer-readable storage medium, and the computer-readable storage medium stores a computer program executed by the routing data processing device 1 or the routing data processing device 2 mentioned above, and the computer program includes program instructions. When the processor executes the program instructions, it can execute the above-mentioned Figure 3 、 Figure 7 、 Figure 10 The description of the routing data processing method in any corresponding embodiment will not be repeated here. In addition, the description of the beneficial effects of using the same method will not be repeated here. For technical details not disclosed in the computer-readable storage medium embodiment involved in this application, please refer to the description of the method embodiment of this application.

[0200] The computer-readable storage medium may be the routing data processing device provided in any of the aforementioned embodiments or the internal storage unit of the computer device, such as the hard disk or memory of the computer device. The computer-readable storage medium may also be an external storage device of the computer device, such as a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. equipped on the computer device. Furthermore, the computer-readable storage medium may include both the internal storage unit of the computer device and an external storage device. The computer-readable storage medium is used to store the computer program and other programs and data required by the computer device. The computer-readable storage medium may also be used to temporarily store data that has been output or is to be output.

[0201] In addition, it should be noted that the present application also provides a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device performs the above-mentioned Figure 3 、 Figure 7 、 Figure 10 The method provided by any corresponding embodiment. In addition, the description of the beneficial effects of adopting the same method will not be repeated. For technical details not disclosed in the computer program product or computer program embodiment involved in this application, please refer to the description of the method embodiment of this application.

[0202] See Figure 16 , Figure 16 This is a schematic diagram of the structure of a routing data processing system provided by an embodiment of the present application. The routing data processing system 3 may include a routing data processing device 1a and a routing data processing device 2a. The routing data processing device 1a may be the above-mentioned Figure 13 In the corresponding embodiment, the routing data processing device 1 can be understood that the routing data processing device 1a can be integrated into the above Figure 2 The routing device 21 in the corresponding embodiment will not be described in detail here. Figure 14 In the corresponding embodiment, the routing data processing device 2a can be integrated into the above-mentioned Figure 11The verification service device in the corresponding embodiment will not be described in detail here. In addition, the description of the beneficial effects of adopting the same method will not be described in detail. For technical details not disclosed in the embodiment of the routing data processing system involved in this application, please refer to the description of the method embodiment of this application.

[0203] The terms "first", "second", etc. in the description, claims, and drawings of the embodiments of the present application are used to distinguish different objects, rather than to describe a specific order. In addition, the terms "comprising" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, apparatus, product, or device comprising a series of steps or units is not limited to the listed steps or modules, but may optionally include steps or modules not listed, or may optionally include other step units inherent to these processes, methods, apparatuses, products, or devices.

[0204] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in terms of function in the above description. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0205] The above disclosure is only a preferred embodiment of the present application, and certainly cannot be used to limit the scope of rights of the present application. Therefore, equivalent changes made according to the claims of the present application are still within the scope covered by the present application.

Claims

1. A routing data processing method, characterized in that: The method is performed by a routing device and includes: Obtaining route change information determined by service change data for user equipment; In a process of updating the routing snapshot of the routing device from a first routing snapshot to a second routing snapshot based on the routing change information, querying the routing snapshot of the routing device; the service status of the first routing snapshot is a first committed state, the service status of the second routing snapshot is a pending commit state, and the first routing snapshot in the first committed state is a previous snapshot record of the second routing snapshot in the pending commit state; When it is found that the routing snapshot of the routing device is the first routing snapshot pointed to by the second routing snapshot, the service state of the second routing snapshot is changed from the pending state to the second submitted state, and the second routing snapshot with the second submitted state is stored through the verification service device.

2. The method according to claim 1, characterized in that In the process of updating the routing snapshot of the routing device from the first routing snapshot to the second routing snapshot based on the routing change information, querying the routing snapshot of the routing device includes: generating a routing update transaction based on the routing change information, and determining a target routing transaction in a process of updating the routing snapshot of the routing device from a first routing snapshot to a second routing snapshot based on the routing update transaction; wherein the target routing transaction includes a routing query transaction for querying the routing snapshot of the routing device; Obtaining a first transaction identifier of the routing query transaction, a second transaction identifier of the routing update transaction, and a transaction identifier array corresponding to a pending transaction set contained in the target routing transaction; the transaction identifier array is used to record the transaction identifier of each transaction in the pending transaction set; the pending transaction set includes the routing query transaction; Based on the first transaction identifier, the second transaction identifier, and the transaction identifier array, query the second transaction identifier corresponding to the second routing snapshot to obtain a query result for the second transaction identifier; If the query result is an invisible result, query the first routing snapshot in the first submitted state pointed to by the second routing snapshot in the to-be-committed state.

3. The method according to claim 2, characterized in that The querying the second transaction identifier corresponding to the second routing snapshot based on the first transaction identifier, the second transaction identifier, and the transaction identifier array to obtain a query result for the second transaction identifier includes: Comparing the second transaction identifier with the first transaction identifier to obtain a first comparison result; Compare the second transaction identifier with the minimum transaction identifier in the transaction identifier array to obtain a second comparison result; If the first comparison result indicates that the second transaction identifier is not equal to the first transaction identifier, and the second comparison result indicates that the second transaction identifier is greater than or equal to the minimum transaction identifier, determining a target transaction identifier based on a maximum transaction identifier in the transaction identifier array, and comparing the second transaction identifier with the target transaction identifier to obtain a third comparison result; Based on the third comparison result, a query result for the second transaction identifier is determined.

4. The method according to claim 3, characterized in that The determining, based on the third comparison result, a query result for the second transaction identifier includes: If the third comparison result indicates that the second transaction identifier is greater than the target transaction identifier, the service state of the second routing snapshot is determined to be in a pending-commitment state that is not executed, and the query result for the second transaction identifier is determined to be an invisible result.

5. The method according to claim 3, characterized in that The determining, based on the third comparison result, a query result for the second transaction identifier includes: If the third comparison result indicates that the second transaction identifier is less than or equal to the target transaction identifier, searching for the second transaction identifier in the transaction identifier array; If the second transaction identifier is found in the transaction identifier array, it is determined that the service state of the second routing snapshot is in a pending submission state of the execution state, and the query result for the second transaction identifier is determined to be an invisible result.

6. The method according to claim 2, characterized in that Before querying the first routing snapshot in the first committed state pointed to by the second routing snapshot in the pending committed state, the method further includes: Obtaining a rollback pointer field carried by the second routing snapshot in the pending-commit state, and if the field value of the rollback pointer field is non-null, obtaining a third transaction identifier carried by the first routing snapshot pointed to by the field value of the rollback pointer field; the third transaction identifier is a transaction identifier corresponding to the transaction used to generate the first routing snapshot; Comparing the third transaction identifier with the minimum transaction identifier in the transaction identifier array to obtain a fourth comparison result; If the fourth comparison result indicates that the third transaction identifier is smaller than the minimum transaction identifier, it is determined that the service state of the first routing snapshot is the first committed state.

7. The method according to claim 1, characterized in that The route change information is determined by changing a first route used to forward a change record corresponding to the service change data to a second route; both the second route and the first route are determined for the service change data; The transaction corresponding to the route change information is a route update transaction, and the route update transaction includes a route modification operation for changing the first route to the second route; the method further includes: Generate a row auto-increment identification field and a rollback pointer field corresponding to the second route, and use the transaction identification field whose field values are the second transaction identification of the route update transaction, the row auto-increment identification field, and the rollback pointer field as route key fields associated with the second route; the field value of the rollback pointer field is used to point to the first route snapshot of the first route; A second route snapshot of the second route is generated based on the second route and the route key field.

8. The method according to claim 1, characterized in that The transaction corresponding to the routing change information is a routing update transaction, and the routing update transaction includes a routing deletion operation; the method further includes: Based on the route deletion operation, setting the field value of the deletion identification field carried in the first route snapshot to a valid field value, and using the first route snapshot carrying the valid field value as the route snapshot to be deleted; When the route snapshot to be deleted meets the deletion condition, the route snapshot to be deleted is deleted through a deletion thread.

9. The method according to claim 1, characterized in that The transaction corresponding to the routing change information is a routing update transaction, and the routing update transaction includes a routing addition operation for adding a third route to the routing snapshot of the routing device; The method further comprises: Based on the route adding operation, the third route is obtained, a new row auto-increment identification field and a new rollback pointer field corresponding to the third route are generated, and the new transaction identification field, whose field values are the second transaction identifier of the route update transaction, the new row auto-increment identification field, and the new rollback pointer field are used as the new route key fields associated with the third route; the field value of the new rollback pointer field is a null value; A third route snapshot of the third route is generated based on the third route and the newly added route key field, and the third route snapshot is added to the route snapshot of the routing device.

10. A routing data processing method, characterized in that: The method is performed by a verification service device and includes: A target routing snapshot is obtained based on the acquired second routing snapshot having a second committed state, and the target routing snapshot is stored in a routing cache associated with the verification service device; the second routing snapshot having the second committed state is obtained by the routing device changing the service state of the second routing snapshot from a pending-commitment state to a second committed state when the found routing snapshot is the first routing snapshot pointed to by the second routing snapshot; the routing device is configured to query the routing snapshot of the routing device during the process of updating the routing snapshot of the routing device from the first routing snapshot to the second routing snapshot based on the routing change information; the service state of the first routing snapshot is a first committed state, the service state of the second routing snapshot is a pending-commitment state during the snapshot update process, and the first routing snapshot having the first committed state is a previous snapshot record of the second routing snapshot having the pending-commitment state; Upon receiving a route check request, obtaining a second route snapshot in the second committed state from the object storage indicated by the route check request as an original route snapshot, and performing a route check on the original route snapshot based on the target route snapshot stored in the route cache.

11. The method according to claim 10, characterized in that The obtaining of a target route snapshot based on the acquired second route snapshot in the second committed state, and storing the target route snapshot in a route cache associated with the verification service device, includes: Obtaining a second routing snapshot in a second committed state from a cloud message queue, wherein the cloud message queue is used to transmit the routing snapshot generated by the routing device to a regional controller associated with the routing device; performing version verification on the second routing snapshot in the second committed state to obtain a version verification result, and obtaining a target routing snapshot based on the version verification result; The target route snapshot is stored in a route cache associated with the verification service device.

12. The method according to claim 11, characterized in that The performing version verification on the second routing snapshot in the second committed state to obtain a version verification result, and obtaining a target routing snapshot based on the version verification result, includes: requesting a global routing snapshot associated with the second routing snapshot in the second committed state from a global controller associated with the regional controller, and comparing the second routing snapshot in the second committed state with the global routing snapshot to obtain a version verification result; If the version verification result indicates that the second routing snapshot in the second committed state is consistent with the global routing snapshot, taking the second routing snapshot in the second committed state as the target routing snapshot; If the version verification result indicates that the second routing snapshot in the second committed state is inconsistent with the global routing snapshot, the global routing snapshot is used as the target routing snapshot.

13. The method according to claim 11, characterized in that The cloud message queue is used to cache route verification requests sent by the regional controller; the route verification request is a request that the regional controller sends to the cloud message queue on a regular basis, or the route verification request is a request that the regional controller sends to the cloud message queue after receiving a trigger instruction from a global controller associated with the regional controller; The method of claim 10 further comprising: upon receiving a route check request, obtaining a second route snapshot having the second committed state from the object storage indicated by the route check request as an original route snapshot, and performing route check on the original route snapshot based on the target route snapshot stored in the route cache. Based on the route verification request in the cloud message queue, read a second route snapshot in the second submitted state from an object storage indicated by the route verification request as an original route snapshot; the object storage is independent of the routing device and is used to store the route snapshot generated by the routing device and submitted by the regional controller; The target route snapshot is read from the route cache, and the target route snapshot is compared with the original route snapshot.

14. The method according to claim 13, characterized in that Also includes: If the target routing snapshot is inconsistent with the original routing snapshot, a routing error correction request is generated and returned to the routing device, so that the routing device performs error correction processing on the second routing snapshot in the second committed state based on the routing error correction request.

15. A routing data processing device, characterized in that: The apparatus runs in a routing device and includes: an acquisition module, configured to acquire routing change information determined by service change data for a user device; a query module, configured to query a routing snapshot of the routing device during a process of updating the routing snapshot of the routing device from a first routing snapshot to a second routing snapshot based on the routing change information; the service status of the first routing snapshot being a first committed state, the service status of the second routing snapshot being a pending commit state, and the first routing snapshot having the first committed state being a previous snapshot record of the second routing snapshot having the pending commit state; a changing module, configured to, when finding that the routing snapshot of the routing device is the first routing snapshot pointed to by the second routing snapshot, change the service status of the second routing snapshot from the pending-commitment status to a second committed status, and store the second routing snapshot in the second committed status through the verification service device.

16. A routing data processing device, characterized in that: The device operates in a verification service device and includes: a storage module configured to obtain a target routing snapshot based on the acquired second routing snapshot in a second committed state, and store the target routing snapshot in a routing cache associated with the verification service device; the second routing snapshot in the second committed state is obtained by the routing device changing the service state of the second routing snapshot from a pending-commitment state to a second committed state when the found routing snapshot is the first routing snapshot pointed to by the second routing snapshot; the routing device is configured to query the routing snapshot of the routing device during the process of updating the routing snapshot of the routing device from the first routing snapshot to the second routing snapshot based on routing change information; the service state of the first routing snapshot is a first committed state, the service state of the second routing snapshot is a pending-commitment state during the snapshot update process, and the first routing snapshot in the first committed state is a previous snapshot record of the second routing snapshot in the pending-commitment state; a verification module configured to, upon receiving a route verification request, obtain, from the object storage indicated by the route verification request, a second route snapshot having the second committed state as an original route snapshot, and perform route verification on the original route snapshot based on the target route snapshot stored in the route cache.

17. A computer device, characterized in that: include: processor and memory; The processor is connected to the memory, wherein the memory is used to store a computer program, and the processor is used to call the computer program to enable the computer device to execute the method according to any one of claims 1 to 14.

18. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, which is suitable for being loaded and executed by a processor, so that a computer device having the processor executes the method according to any one of claims 1 to 14.

19. A computer program product, characterized in that The computer program product includes computer instructions, which are stored in a computer-readable storage medium. The computer instructions are suitable for being read and executed by a processor, so as to enable a computer device having the processor to perform the method according to any one of claims 1 to 14.

Images