CN109729060B - Processing method, device and equipment for policy issuing request - Google Patents
Processing method, device and equipment for policy issuing request Download PDFInfo
- Publication number
- CN109729060B CN109729060B CN201810173299.9A CN201810173299A CN109729060B CN 109729060 B CN109729060 B CN 109729060B CN 201810173299 A CN201810173299 A CN 201810173299A CN 109729060 B CN109729060 B CN 109729060B
- Authority
- CN
- China
- Prior art keywords
- insurance
- policy
- server
- request
- request data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Abstract
The application discloses a method, a device and equipment for processing a policy issuing request, and relates to the technical field of insurance, so that a server can avoid the condition of centralized processing when processing the request, and can support high-concurrency large-batch policy issuing. The method comprises the following steps: when a server receives a policy issuing request sent by a client, acquiring insurance application request data carried in the policy issuing request; verifying the insurance request data; if the verification is successful, storing the insurance request data into a preset message cache queue, wherein the insurance request data carried by different insurance policy order-out requests to be processed by the server are stored in the preset message cache queue; and pushing the insurance application request data corresponding to each insurance policy order output request in the preset message cache queue to a server for processing so as to generate a corresponding insurance policy according to a preset pushing rule. The method and the device are suitable for processing the policy issuing request.
Description
Technical Field
The present application relates to the field of insurance technologies, and in particular, to a method, an apparatus, and a device for processing policy issuing requests.
Background
With the rapid development of internet technology, the cooperation of internet companies and insurance industry is also deepened continuously. The internet insurance application is more and more a popular trend, and the user can apply insurance on line through the network without the user going to an insurance company to handle business in person, so that the time is saved, and great convenience is brought to the user. The remarkable characteristics of Internet application are large output amount and high concurrence number.
At present, a user can purchase a policy on line through a client application, the client sends a policy output request carrying user application request data to an insurance company server, the insurance company server immediately processes the policy output request after receiving the policy output request, and the policy is generated according to the user application request data and fed back to the user client.
However, because the number of the servers of the insurance company is fixed, the request processing capacity of each server is limited, and if a large number of scattered households simultaneously perform online insurance application, huge pressure is brought to the insurance company to issue a single system, even the servers are down, and then the situation that the users fail in insurance application in the down stage is caused, so that the use experience of the users is influenced.
Disclosure of Invention
In view of this, the present application provides a method, an apparatus, and a device for processing a policy issuing request, and mainly aims to solve the problem that a current insurance company server immediately processes a policy issuing request to generate a policy after receiving the policy issuing request, and if a large number of scattered households simultaneously perform online insurance application, huge pressure is brought to the policy issuing system of the insurance company, even a server is down, and further a user fails to apply insurance at the down stage.
According to one aspect of the application, a method for processing a policy issuing request is provided, and the method comprises the following steps:
when a server receives a policy issuing request sent by a client, acquiring insurance application request data carried in the policy issuing request;
verifying the application request data;
if the verification is successful, storing the insurance request data into a preset message cache queue, wherein the insurance request data carried by different insurance policy order-out requests to be processed by the server are stored in the preset message cache queue;
and pushing the insurance application request data corresponding to each insurance policy order output request in the preset message cache queue to a server for processing so as to generate a corresponding insurance policy according to a preset pushing rule.
According to another aspect of the present application, there is provided a processing apparatus for policy issuance request, the apparatus including:
the system comprises an acquisition unit, a processing unit and a processing unit, wherein the acquisition unit is used for acquiring insurance application request data carried in an insurance policy issuing request when a server receives the insurance policy issuing request sent by a client;
the verification unit is used for verifying the insurance application request data;
the storage unit is used for storing the insurance request data into a preset message cache queue if the verification of the verification unit is successful, wherein the insurance request data carried by different insurance policy issuing requests to be processed by the server are stored in the preset message cache queue;
and the pushing unit is used for pushing the insurance application request data corresponding to each insurance policy order output request in the preset message cache queue to a server for processing so as to generate a corresponding insurance policy.
According to yet another aspect of the present application, there is provided a storage medium having stored thereon a computer program which, when executed by a processor, implements the method of processing a policy issuance request described above.
According to still another aspect of the present application, there is provided a device for processing a policy issuing request, including a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, where the processor implements the method for processing the policy issuing request when executing the computer program.
By the technical scheme, the application provides a processing method, a device and equipment for policy issuing request, compared with the mode that the insurance company server immediately processes and generates the insurance policy after receiving the policy issuing request at present, the method adopts the buffer mechanism of the message buffer queue, when the server receives a policy issuing request sent by the client, the server firstly carries out simple verification processing according to the insurance application request data carried in the request, if the verification is successful, the insurance request data is stored in a preset message buffer queue to wait for being pushed to the server for processing, so that the server can avoid the condition of centralized processing when processing the request, when a large number of scattered households simultaneously carry out online insurance, pressure cannot be brought to issuing of single systems of insurance companies, the occurrence of the condition that a server is down is reduced, and high-concurrency large-batch single issuing can be supported by the method.
The foregoing description is only an overview of the technical solutions of the present application, and the present application can be implemented according to the content of the description in order to make the technical means of the present application more clearly understood, and the following detailed description of the present application is given in order to make the above and other objects, features, and advantages of the present application more clearly understandable.
Drawings
The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this application, illustrate embodiment(s) of the application and together with the description serve to explain the application and not to limit the application. In the drawings:
fig. 1 is a schematic flowchart illustrating a method for processing a policy issuing request according to an embodiment of the present application;
FIG. 2 is a flow chart illustrating another policy issuing request processing method according to an embodiment of the present disclosure;
fig. 3 is a schematic structural diagram illustrating a processing apparatus for policy issuing request according to an embodiment of the present application;
fig. 4 is a schematic structural diagram illustrating another processing apparatus for policy issuing request according to an embodiment of the present application.
Detailed Description
The present application will be described in detail below with reference to the accompanying drawings in conjunction with embodiments. It should be noted that the embodiments and features of the embodiments in the present application may be combined with each other without conflict.
In this embodiment, a method for processing policy form issue requests is provided, where a buffering mechanism of a message buffer queue is adopted, so that a server can avoid a centralized processing situation when processing requests, and can support high-concurrency large-batch policy form issue, as shown in fig. 1, the method includes:
101. and when the server receives the policy issuing request sent by the client, acquiring insurance application request data carried in the policy issuing request.
The application request data may include: order data (such as the time of the order, the payment amount of the insurance product, a coupon used for payment, a payment account, insurance product information purchased by the user who made the order, etc.), insurance application data (such as the applicant information, the insured person information, the amount of the application, the year of the application, etc. filled in by the user who made the order), etc.; the applicant information may include name, age, identification number, home address, contact information, etc. of the applicant, the insured information may also include name, age, identification number, etc. of the insured, and the insurance product information purchased by the ordering user may include, for example, name or number (ID) of the insurance product, insurance policy information, insurance policy type information, etc.
The execution main body of this embodiment may be a policy issuing request processing device based on a message buffer queue buffer mechanism, which may be run on an insurance company server, or may be an independent device connected to the insurance company server, such as a front-end server, and the like, and is configured to monitor a policy issuing request received by the insurance company server, specifically, buffer a policy issuing request received by the insurance company server and sent by a client, and wait for being pushed to the insurance company server to process and generate a policy.
102. And carrying out verification processing according to the acquired insurance application request data.
For the embodiment, simple verification processing can be performed according to the insurance policy request data, and whether the insurance policy issuing request meets the preset basic requirements of some insurance policy issuing requests or not is judged, namely, preliminary filtering and screening processing is performed. The specific implementation content of the preliminary verification processing can be configured in advance according to actual requirements.
For example, according to the order data in the insurance request data, it is determined whether the insurance product that the ordering user needs to purchase exists on the insurance company side, that is, whether the insurance company side is selling the insurance product online, if the insurance product that the ordering user purchases does not exist on the insurance company side, the verification may be determined to fail, if it is determined that the insurance company side is actually selling the insurance product online, it may be further determined whether the inventory of the insurance product is sufficient, and if the inventory is insufficient, the verification may also be determined to fail.
For another example, according to order data in the insurance application request data, it is determined that the ordering user is an insurance product a which is successfully ordered and purchased in the time period 1, but the insurance product a can be successfully purchased only in the time period 2 through inquiry, that is, the insurance product a is a limited time rush-purchase product, so that the ordering user can be determined to be in violation of operation, and the verification fails; and then, or detecting that the coupon used by the order-placing user is not in compliance, and judging that the verification fails.
103. And if the verification is successful, storing the application request data into a preset message buffer queue.
The insurance policy issuing request data is stored in the preset message cache queue, wherein the insurance policy issuing request data are respectively carried by different insurance policy issuing requests to be processed by the insurance company server.
For this embodiment, after the primary filtering and screening of the basic requirements of each policy output order, if the final verification is successful, the insurance request data carried by the policy output order request received this time may be stored in the predetermined message buffer queue to wait for a suitable time and be pushed to the insurance company server for processing to generate the policy, so that the insurance company server avoids the centralized processing.
104. And pushing the insurance application request data corresponding to each insurance policy order output request in the preset message cache queue to a server for processing so as to generate a corresponding insurance policy according to a preset pushing rule.
The predetermined pushing rule can be preset according to the actual requirement of the insurance business.
For example, according to the actual request processing situation of the insurance company server, avoiding the situation of centralized processing of the server, the insurance request data corresponding to each policy issuing request in the predetermined message cache queue is dispersedly pushed to the server for processing, so that the server does not process a large amount of request data at the same time, and the server can gradually digest and process the request data at different time periods, so as to reduce the load pressure of the server.
It should be noted that, the method for processing a policy issuing request provided in this embodiment may be applied to a scenario in which a server processes a policy issuing request, and may also be applied to other scenarios in which a request is processed, for example, an application request and a merchandise purchase request that implement an application function may all adopt the message cache queue buffer mechanism, so as to avoid a situation of centralized processing by the server, and reduce a situation of server crash or downtime.
By applying the technical scheme of the embodiment, when the server receives a policy issuing request sent by the client, simple verification processing is firstly carried out according to insurance application request data carried in the request, if the verification is successful, the insurance application request data is stored in the preset message cache queue to wait for being pushed to the server for processing, so that the server can avoid the condition of centralized processing when processing the request, and when a large number of scattered households simultaneously carry out online insurance, pressure can not be brought to an insurance company policy issuing system, the occurrence of the condition of server crash is reduced, and high-concurrency large-batch policy issuing can be supported by the method.
Further, as a refinement and an extension of the specific implementation of the foregoing embodiment, in order to fully describe the specific implementation process of the present embodiment, another method for processing a policy issuing request is provided, as shown in fig. 2, the method includes:
201. a message buffer queue is created in advance.
For this embodiment, an Application Programming Interface (API) order issuing architecture may be pre-established in an isolation Zone (DMZ) of an insurance company order issuing system, and used as an execution main device of the method, so that an insurance policy order issuing request sent by a client received by an insurance company server first enters the API order issuing architecture for processing, and specifically, simple verification may be performed according to insurance Application request data in the insurance policy order issuing request, and a message cache queue is used to buffer the request, and the like. The isolation area can be regarded as a buffer area between the non-safety system and the safety system, the isolation area is located in a network area between the insurance company single-system network and the external network, and the insurance company single-system safety can be effectively protected through the isolation area.
The message buffer queue is pre-established as a data buffer area between the API order-issuing framework and the insurance company server, and the length of the queue can be set according to actual requirements, for example, the queue can be set according to the maximum number of requests simultaneously undertaken and processed by each server, or according to the download amount of the insurance client, or can be correspondingly increased according to the number of requests received in real time, so as to ensure that the message buffer queue is normally usable (i.e., a message buffer queue with variable length). And the created message buffer queue is used for receiving the insurance application request data carried in the request sent by the API form-out architecture according to a certain sequence and storing the insurance application request data in sequence when the API form-out architecture successfully verifies the insurance policy form-out request.
In order to continue to implement the request buffering mechanism in this embodiment when the message cache queue is abnormal and cannot store newly received application request data, further, in an optional manner of this embodiment, a Redis cache server may be deployed in advance to implement a cache compensation mechanism. For example, when the application request data stored in the message cache queue is full and cannot be stored in the newly received application request data, the newly received application request data may be stored by the Redis cache server and then wait to be pushed to the insurance company server at an appropriate time for processing.
In order to speed up the processing efficiency of the insurance company server for policy issuing requests, further, in another optional manner of this embodiment, a plurality of message cache queues of different categories may be created in advance according to the actual insurance business requirements, for example, different categories, including message cache queues of categories such as life insurance, car insurance, child insurance, and traffic insurance, may be divided according to the insurance product information, and each category of message cache queue corresponds to a server dedicated to processing policy issuing requests of its respective category, for example, a message cache queue of a life insurance category may correspond to a server dedicated to processing life insurance policy issuing requests, and a message cache queue of a traffic insurance category may correspond to a server dedicated to processing traffic insurance policy issuing requests.
Therefore, when insurance application request data need to be stored in the message buffer queue, the insurance application request data can be stored in the message buffer queue of the corresponding category according to the category of insurance products which need to be purchased by the order-issuing user, and then the insurance application request data are waited to be pushed to a server specially processing the category for processing. For the optional mode, because the policy issuing processes of different categories are possibly different, each server specially processes the policy issuing processes of a few categories through the targeted processing, the complexity calculation of the policy issuing process is reduced, and the request processing efficiency and accuracy can be improved.
It should be noted that the process in step 201 may be regarded as a pre-equipped process in this embodiment, and the following processes shown in steps 202 to 205b are processes for specifically processing policy issuing requests in this embodiment.
202. And when the server receives the policy issuing request sent by the client, acquiring insurance application request data carried in the policy issuing request.
In this embodiment, a user who needs online insurance application can place an order and apply insurance through an insurance client, and the user needs to log in his account number, then selects an insurance product that he needs to purchase to place an order and purchase, and fills in corresponding insurance application data, such as insurance applicant information, insured person information, and insurance application amount. After the user successfully pays, the client sends a policy issuing request carrying policy issuing request data including policy issuing data, order data and the like to the insurance company server. Correspondingly, when the insurance company server receives the policy issuing request sent by the client, the API issuing framework pre-established in step 201 intercepts the policy issuing request, temporarily does not send the policy issuing request to the insurance company server for processing, obtains insurance application request data carried in the policy issuing request, and performs simple verification processing, as shown in step 203.
203. And carrying out verification processing according to the acquired insurance application request data.
For example, to illustrate the specific implementation process of step 203, in an optional manner of this embodiment, step 203 may specifically include: detecting whether insurance products required to be purchased by an order placing user exist according to order data in the insurance application request data; if yes, detecting whether the stock of the insurance product is sufficient; and/or detecting whether the insurance product is paid successfully; if the payment is successful, detecting whether the corresponding purchase amount of the ordering user conforms to the purchase amount requirement of the insurance product; and/or inquiring the insurance product corresponding insurance application qualification, and detecting whether the policy issuing request conforms to the policy issuing request of the insurance product or not by combining the information of the insurance applicant and the insured person filled by the ordering user in the insurance application request data.
Correspondingly, when detecting that the insurance product does not exist, and/or the inventory of the insurance product is insufficient, and/or the payment of the insurance product is unsuccessful, and/or the purchase amount of the ordering user does not accord with the purchase amount requirement of the insurance product, and/or detecting that the policy issuing request does not accord with the issuing requirement of the insurance product, determining that the verification fails; and when the insurance product exists, the inventory of the insurance product is sufficient, the payment of the insurance product is successful, the purchase amount of the ordering user accords with the purchase amount requirement of the insurance product, and the order issuing request of the current insurance order accords with the order issuing requirement of the insurance product, the verification is determined to be successful.
For example, the name or product number of the insurance product a that the ordering user needs to purchase may be queried from the order data, and then the name or product number and the like are utilized to query whether the insurance product a exists in each insurance product sold by the insurance company side, if the insurance product a does not exist, the verification may be determined to fail, if the insurance product a exists, whether the corresponding stock is sufficient may be further determined, if the stock is insufficient, it is indicated that the insurance product a has been sold, the purchase is invalid, and the verification is determined to fail.
For another example, whether the order placing user successfully pays or not can be inquired from the order data, if the system is abnormal, the client sends the order data which is not successfully paid, and the verification failure can be determined; if the ordering user is inquired that the payment is successful, whether the corresponding ordering user purchase amount meets the purchase amount requirement of the insurance product or not can be further detected, namely whether the amount actually paid by the ordering user (which can comprise coupons, point redemption and the like) can purchase the insurance product or not, and if the ordering user purchase amount is detected not to meet the purchase amount requirement of the insurance product, the verification can be judged to be failed.
For another example, the name or product number of the insurance product that the ordering user needs to purchase may be used to query the insurance application qualification of the insurance product, that is, the condition that the applicant or the insured person must have, to judge whether the information of the applicant and the insured person filled by the ordering user in the application request data meets the condition, and if not, the verification may be determined to fail.
The verification processing is carried out through the verification rules, whether the policy issuing request meets the basic regulation requirements of some policies can be judged quickly, the insurance company server is helped to filter and screen quickly, some requests which do not meet the requirements are filtered, and the condition that the server processes invalid requests is further reduced, so that the request quantity of the server is reduced to a certain extent, and the load pressure of the server is reduced.
In order to ensure the security of the insurance policy issuing system and reduce the potential safety hazard of the insurance service, as another optional mode, the policy issuing request further carries the client information, and correspondingly, step 203 may further include: detecting whether the age of the ordering user meets the preset purchasing age condition or not according to the ordering user account information contained in the client information; and/or inquiring credit information of the order placing user according to the account information of the order placing user, and detecting whether the credit of the order placing user meets the preset credit requirement or not according to the credit information; and/or according to the equipment identification (such as equipment name, IMEI number and the like) of the order issuing terminal equipment and the user identification (such as user name, identity card number and the like) of the order issuing user, which are contained in the client information, the safety verification is carried out by combining a preset white list and a preset black list; and/or counting whether the number of requests sent by the order-placing terminal equipment or the order-placing user received by the server in a preset time period is larger than a preset number threshold or not according to the equipment identification and the user identification.
Accordingly, when the age of the order placing user is detected not to meet the predetermined purchasing age condition, and/or the credit of the order placing user does not meet the preset credit requirement, and/or the security verification fails, and/or the request number is larger than the preset number threshold value, the verification is determined to be failed.
The predetermined purchasing age condition, the predetermined credit requirement, the white list and the black list, the predetermined time period, the predetermined quantity threshold value and the like can be preset according to actual requirements, the white list comprises terminal equipment identifications and/or user identifications which can pass the security verification, and the black list comprises terminal equipment identifications and/or user identifications which can not pass the security verification. For example, the age information filled by the order placing user when the order placing user initially registers can be inquired from the account information of the order placing user, so that the age of the order placing user can be determined, if the age is less than 12 years old, namely in the stage of children, the condition that the predetermined purchasing age condition is not met can be judged, and the condition that the verification fails is determined to avoid economic loss to the user because the children are probably misoperated.
For another example, the information such as the name, identification number and the like filled by the order user when the order user initially registers can be inquired from the account information of the order user, then the credit information of the user, such as credit value, credit score and the like, can be inquired through a third-party platform by using the information, if the credit value is lower than a certain threshold value, the credit of the user is poor and is likely to be a fraud user, and the verification failure can be judged to avoid economic loss brought to an insurance company.
For another example, screening is performed through a white list and a black list to realize security verification, if a user a has a record which is frequently cheated for protection, the identifier of the user a can be added into the black list in advance, and when the security verification is performed on a policy issuing request sent by the user a, the verification failure can be determined, so that the user a fails to purchase the policy issuing request and does not successfully issue the policy, and the economic loss of an insurance company is reduced.
For another example, it may also count whether the number of requests sent by the ordering user or the terminal within a certain period of time is greater than a certain number, if so, add the requests to a blacklist or directly determine that the verification fails, and output alarm information.
Through the verification rules for ensuring the safety, the safety of an insurance policy issuing system can be ensured, the potential safety hazard of insurance business is reduced, unnecessary property loss brought to users and insurance companies is avoided, it needs to be explained that the verification rules can not be limited to the above, other verification rules for ensuring the safety can be provided, and the actual requirements for ensuring the safety of the insurance business can be determined.
204a, if the verification fails, sending insurance application failure response information to the client.
Furthermore, the client outputs prompt information related to the insurance application failure according to the received insurance application failure response information. The prompt information can be text prompt information, picture prompt information, audio prompt information, video prompt information, light prompt information, vibration prompt information and the like.
In order to enable the user to know the reason of the insurance application failure, in an optional manner of this embodiment, insurance application failure response information may be further sent to the client in combination with the non-compliant verification rule according to the verification result, so that the client may output prompt information including the reason of the insurance application failure in combination with the non-compliant verification rule, for example, insurance application failure caused by insufficient inventory of insurance products, insurance application failure caused by a purchase amount not being compliant with requirements, and the like.
And a step 204b parallel to the step 204a, if the verification is successful, storing the insurance request data into a preset message buffer queue, and sending insurance success response information to the client.
Furthermore, the client outputs prompt information related to the success of the insurance application according to the received response information of the success of the insurance application.
In this embodiment, if the check rules in step 203 are passed, a response message indicating that the application is successful is returned to the client before the server actually processes the application, and if one or more check rules are failed in the check rules, a response message indicating that the application is failed is also fed back to the client before the server actually processes the application.
For this embodiment, corresponding application request data may be stored in the message buffer queue according to the time sequence of the requests received by the server, and the time stamps of the application request data stored in the message buffer queue are recorded at the same time, so that when the application request data is subsequently pushed from the message buffer queue to the server, the pushing process is sequentially performed according to the time stamps from the morning to evening of the storage time.
Here, before storing the insurance policy request data in the message cache queue, it is necessary to perform exception detection on the message cache queue, and if the message cache queue is abnormal, the insurance policy request data may be stored in the Redis cache server pre-deployed in step 201 to replace the message cache queue, so as to ensure that the policy issuing request processing process in this embodiment can be normally implemented.
In order to ensure that the storage space of the message buffer queue is not occupied by invalid data, in an optional manner of this embodiment, expired data in the message buffer queue may also be cleaned regularly or irregularly, so as to save the storage space of the message buffer queue.
205b, according to a predetermined pushing rule, pushing the insurance application request data corresponding to each policy issuing request in the predetermined message buffer queue to the server for processing so as to generate a corresponding policy.
Wherein, the preset push rule can be set according to the actual request processing condition of the insurance company server.
For example, to illustrate the specific implementation process of step 205b, in an optional manner of this embodiment, step 205b may specifically include: monitoring the load condition of the server in real time, and determining whether the server is in an idle time stage according to the load condition; if the server is in an idle stage, sequentially pushing insurance application request data corresponding to each insurance policy order output request in a preset message cache queue to the server according to a preset sequence for processing so as to generate corresponding insurance policies; and if the server is in the busy period, stopping pushing the insurance application request data in the preset message buffer queue to the server for processing.
For example, according to the real-time request processing condition of the server of the insurance company, if the load pressure of the server at the moment is monitored to be large, the insurance application request data can be temporarily not pushed to the server, if the load pressure of the server is monitored to be small, a large amount of request data can be processed, the insurance application request data can be pushed to the server for processing, and therefore the request processing is carried out when the relative load pressure of the server is small, the pressure of the server is relieved, and the occurrence of the crash of the server is reduced.
In another optional manner of this embodiment, step 205b may further include: and pushing the insurance request data corresponding to each insurance policy order output request stored in the preset message buffer queue within the preset period to the server for processing according to the preset period to generate the corresponding insurance policy.
For example, the request processing amount of the server of the insurance company in the daytime is usually greater than that of the server in the late night, and the insurance application request data corresponding to each request in the message cache queue is averagely pushed to the server for processing according to 24 hours, so that the server can avoid the situation of centralized processing when processing the request, and the pressure can not be brought to the insurance company to issue a single system when a large number of scattered households carry out online insurance application at the same time.
In order to avoid repeated processing of the same insurance request data by the server, further, in another optional manner of this embodiment, after successfully pushing the insurance request data corresponding to the policy output request in the predetermined message cache queue to the server, the method may further include: deleting the successfully pushed application request data from a preset message cache queue; or periodically or aperiodically delete the successfully pushed application request data from the predetermined message buffer queue. In this way, the same insurance application request data is prevented from being repeatedly pushed to the server for processing, the request processing amount of the server is reduced, and the load pressure of the server is further reduced.
For this embodiment, in order to speed up the request processing efficiency, further, when the request is pushed to the server for processing, a load balancing mechanism may be further adopted, and the server with a lower load pressure in the system is preferentially allocated for processing, so as to ensure the efficiency of request processing and achieve the purpose of load balancing among the servers.
In this embodiment, for a server with abnormal operation (for example, a downtime occurs, the request processing speed is too slow, and the like), the insurance application request data is not pushed to the server, and if the server is tested normally, the insurance application request data is sent to the server, so that the policy issuing request can be processed normally, and the request processing efficiency is ensured.
In order to further ensure that the server does not process the invalid request data, in yet another optional manner of this embodiment, before processing the insurance request data, the insurance company server first determines whether the verification result of the previous request for the data is successful, that is, repeats the verification result in the verification step 203, where to implement this implementation, when storing the insurance request data in the message cache queue, the verification result may be stored together, and then when pushing the insurance request data to the server, the verification result may be taken together, so that the server may perform reconfirmation according to the verification result before processing the request data, where the verification result may be regarded as a certificate for processing the insurance request data by the server.
If the server determines that the verification result is unsuccessful or does not carry the verification result, the insurance application request data can be returned to the abnormal data collection library, and task information with abnormal handling is pushed to related workers regularly or in real time; and if the server determines that the verification result is successful, processing the insurance request data to generate the insurance policy. By the method, the server can be ensured not to process invalid request data, the request processing amount of the server is reduced, and the load pressure of the server is further reduced.
By applying the technical scheme of the embodiment, data buffering transition is realized by utilizing the message buffering queue, the processing amount of the insurance company server to the order output request is reduced, the client can directly obtain the returned processing result in the asynchronous processing mode, meanwhile, the pressure of the server is effectively relieved, the burden of the insurance company order output system is further lightened, the downtime caused by overlarge pressure is avoided, the normal use of a user is not influenced, and high-concurrency large-batch order output can be supported by the mode.
Further, as a specific implementation of the method in fig. 1, an embodiment of the present application provides a device for processing a policy issuing request, and as shown in fig. 3, the device includes: an acquisition unit 31, a verification unit 32, a storage unit 33, and a pushing unit 34.
The obtaining unit 31 may be configured to obtain insurance application request data carried in the policy issuing request when the server receives the policy issuing request sent by the client;
the verification unit 32 may be configured to perform verification processing according to the application request data;
the storing unit 33 may be configured to store the insurance request data into a predetermined message cache queue if the verification by the verifying unit 32 is successful, where the insurance request data carried by different policy issuing requests to be processed by the server are stored in the predetermined message cache queue;
the pushing unit 34 may be configured to push, according to a predetermined pushing rule, the insurance request data corresponding to each policy issuance request in the predetermined message cache queue to the server for processing, so as to generate a corresponding policy.
In a specific application scenario, a user can quickly know whether an online application operation is successful, as shown in fig. 4, the apparatus further includes: a transmitting unit 35;
the sending unit 35 may be configured to send insurance application failure response information to the client if the verification by the verifying unit 32 fails, and further, enable the client to output prompt information related to insurance application failure according to the insurance application failure response information;
correspondingly, the storing unit may be specifically configured to, if the verification by the verifying unit 32 is successful, store the application request data in a predetermined message cache queue, and send application success response information to the client, further, enable the client to output prompt information related to application success according to the application success response information. By the method, the user can quickly know whether the online application operation is successful or not, the waiting time of the user is reduced, and the use experience of the user can be improved.
In a specific application scenario, in order to quickly determine whether the policy issuing request of this time meets some basic rule requirements of policy issuing, the verification unit 32 may be specifically configured to detect whether insurance products that an order placing user needs to purchase exist according to order data in the insurance application request data; if yes, detecting whether the stock of the insurance product is sufficient; and/or detecting whether the insurance product is paid successfully; if the payment is successful, detecting whether the corresponding purchase amount of the ordering user meets the purchase amount requirement of the insurance product; and/or inquiring the insurance product corresponding insurance application qualification, and detecting whether the policy issuing request of this time meets the policy issuing requirement of the insurance product by combining the information of the insurance applicant and the insured person filled by the ordering user in the insurance application request data;
correspondingly, when detecting that the insurance product does not exist, and/or the inventory of the insurance product is insufficient, and/or the payment of the insurance product is unsuccessful, and/or the purchase amount of the ordering user does not accord with the purchase amount requirement of the insurance product, and/or detecting that the policy issuing request does not accord with the issuing requirement of the insurance product, determining that the verification fails; and when the insurance product exists, the inventory of the insurance product is sufficient, the payment of the insurance product is successful, the purchase amount of the ordering user accords with the purchase amount requirement of the insurance product, and the policy issuing request accords with the issuing requirement of the insurance product, the verification is determined to be successful.
The policy issuing request can be judged whether to meet the basic requirements of some policies or not quickly by checking the checking rules, the insurance company server can be helped to filter and screen quickly, some requests which do not meet the requirements are filtered, and then the condition that the server processes invalid requests is reduced, so that the request quantity of the server is reduced to a certain extent, and the load pressure of the server is reduced.
In a specific application scenario, in order to ensure the security of the insurance policy issuing system and reduce the potential safety hazard of insurance services, the insurance policy issuing request may also carry client information, and correspondingly, the verification unit 32 may be further specifically configured to detect whether the age of the ordering user meets a predetermined purchase age condition according to the ordering user account information included in the client information; and/or inquiring credit information of the order placing user according to the account information of the order placing user, and detecting whether the credit of the order placing user meets the preset credit requirement or not according to the credit information; and/or according to the equipment identification of the order issuing terminal equipment and the user identification of the order issuing user contained in the client information, performing security verification by combining a preset white list and a preset black list; and/or according to the equipment identification and the user identification, counting whether the number of requests sent by the order-placing terminal equipment or the order-placing user received by the server in a preset time period is greater than a preset number threshold value;
accordingly, when the age of the order placing user is detected not to meet the predetermined purchasing age condition, and/or the credit of the order placing user does not meet the preset credit requirement, and/or the security verification fails, and/or the request number is larger than the preset number threshold value, the verification is determined to be failed.
Through the verification rules for ensuring the safety, the safety of the insurance policy issuing system can be ensured, the potential safety hazard of insurance business is reduced, and unnecessary property loss brought to users and insurance companies is avoided.
In a specific application scenario, the pushing unit 34 may be specifically configured to monitor a load condition of the server in real time, and determine whether the server is in an idle period according to the load condition; if the server is in an idle stage, sequentially pushing insurance application request data corresponding to each insurance policy order output request in a preset message cache queue to the server according to a preset sequence for processing so as to generate corresponding insurance policies; and if the server is in the busy period, stopping pushing the insurance application request data in the preset message buffer queue to the server for processing. Therefore, the request processing is carried out when the relative load pressure of the server is small, the pressure of the server is reduced, and the occurrence of the condition that the server is down is reduced.
In a specific application scenario, the pushing unit 34 may be further configured to push, according to a predetermined period, the insurance request data corresponding to each insurance policy issue request stored in the predetermined message buffer queue within the predetermined period to the server for processing, so as to generate a corresponding insurance policy. Therefore, the server can avoid the condition of centralized processing when processing the request, and can not bring pressure to the issuing of the insurance company when a large number of scattered households carry out online insurance application at the same time.
In a specific application scenario, in order to avoid the server from repeatedly processing the same application request data, as shown in fig. 4, the apparatus further includes: a deletion unit 36;
the deleting unit 36 is configured to delete the successfully pushed insurance request data from the predetermined message cache queue after successfully pushing the insurance request data corresponding to the policy issuing request in the predetermined message cache queue to the server; or periodically or aperiodically delete the successfully pushed application request data from the predetermined message buffer queue. In this way, the same insurance application request data is prevented from being repeatedly pushed to the server for processing, the request processing amount of the server is reduced, and the load pressure of the server is further reduced.
It should be noted that, for other corresponding descriptions of the functional units involved in the apparatus for processing a policy issuance request provided in the embodiment of the present application, reference may be made to corresponding descriptions in fig. 1 and fig. 2, which are not described herein again.
Based on the methods shown in fig. 1 and fig. 2, correspondingly, the embodiment of the present application further provides a storage medium, on which a computer program is stored, and the program, when executed by a processor, implements the method for processing the policy issuing request shown in fig. 1 and fig. 2.
Based on such understanding, the technical solution of the present application may be embodied in the form of a software product, which may be stored in a non-volatile storage medium (which may be a CD-ROM, a usb disk, a removable hard disk, etc.), and includes several instructions for enabling a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the method according to the implementation scenarios of the present application.
Based on the method shown in fig. 1 and fig. 2 and the virtual device embodiment shown in fig. 3 and fig. 4, in order to achieve the above object, an embodiment of the present application further provides an entity device for policy issuing request processing, which may specifically be a personal computer, a server, a network device, and the like, where the entity device includes a storage medium and a processor; a storage medium for storing a computer program; a processor for executing a computer program to implement the method for processing policy issuance requests as shown in fig. 1 and 2.
Optionally, the entity device for processing the policy issuance request may further include a user interface, a network interface, a camera, a Radio Frequency (RF) circuit, a sensor, an audio circuit, a WI-FI module, and the like. The user interface may include a Display screen (Display), an input unit such as a keypad (Keyboard), etc., and the optional user interface may also include a USB interface, a card reader interface, etc. The network interface may optionally include a standard wired interface, a wireless interface (e.g., a bluetooth interface, WI-FI interface), etc.
Those skilled in the art will appreciate that the physical device structure of the policy issuing request processing provided by the embodiment is not limited to the physical device, and may include more or less components, or combine some components, or arrange different components.
The storage medium may further include an operating system and a network communication module. The operating system is a program that manages and vouches for the physical device hardware and software resources of the outgoing request processing, supporting the operation of the information processing program as well as other software and/or programs. The network communication module is used for realizing communication among components in the storage medium and other hardware and software in the entity device.
Through the above description of the embodiments, those skilled in the art will clearly understand that the present application can be implemented by software plus a necessary general hardware platform, and can also be implemented by hardware. By applying the technical scheme of the application, data buffering transition is realized by utilizing the message buffering queue, the processing amount of the insurance company server to the order output request is reduced, the client can directly obtain the returned processing result in the asynchronous processing mode, meanwhile, the pressure of the server is effectively relieved, the burden of the insurance company order output system is further lightened, the downtime caused by overlarge pressure is avoided, the normal use of a user cannot be influenced, and high-concurrency large-batch order output can be supported by the mode.
Those skilled in the art will appreciate that the figures are merely schematic representations of one preferred implementation scenario and that the blocks or flow diagrams in the figures are not necessarily required to practice the present application. Those skilled in the art will appreciate that the modules in the devices in the implementation scenario may be distributed in the devices in the implementation scenario according to the description of the implementation scenario, or may be located in one or more devices different from the present implementation scenario with corresponding changes. The modules of the implementation scenario may be combined into one module, or may be further split into a plurality of sub-modules.
The above application serial numbers are for description purposes only and do not represent the superiority or inferiority of the implementation scenarios. The above disclosure is only a few specific implementation scenarios of the present application, but the present application is not limited thereto, and any variations that can be made by those skilled in the art are intended to fall within the scope of the present application.
Claims (10)
1. A processing method for policy issuing request is characterized by comprising the following steps:
establishing message cache queues of different insurance types in a data cache region between an output single framework of an application programming interface and a server; the message buffer queues of all insurance types respectively correspond to servers of different insurance types, and the length of the message buffer queues is determined according to the number of received policy order output requests;
when the application programming interface order output structure receives an insurance policy order output request sent by a client, acquiring insurance application request data carried in the insurance policy order output request;
verifying the application request data;
if the verification is successful, storing the insurance request data into a preset message cache queue, wherein the insurance request data carried by different insurance policy order-out requests to be processed by the server are stored in the preset message cache queue;
according to a preset pushing rule, pushing insurance application request data corresponding to each insurance policy order output request in the preset message cache queue to a server for processing so as to generate a corresponding insurance policy;
the method includes that, according to a predetermined pushing rule, the insurance request data corresponding to each policy issuing request in the predetermined message cache queue is pushed to a server for processing so as to generate a corresponding policy, and specifically includes: and according to a preset pushing rule, pushing insurance request data corresponding to each insurance policy order output request in the preset message cache queue to a server corresponding to the insurance category of the preset message cache queue for processing so as to generate a corresponding insurance policy.
2. The method of claim 1, wherein after performing the verification process based on the application request data, further comprising:
if the verification fails, sending insurance application failure response information to the client, so that the client outputs prompt information related to insurance application failure according to the insurance application failure response information;
if the verification is successful, storing the application request data into a preset message buffer queue, specifically comprising:
and if the verification is successful, storing the insurance request data into a preset message cache queue, and sending insurance success response information to the client so that the client outputs prompt information related to the insurance success according to the insurance success response information.
3. The method according to claim 1 or 2, wherein the verifying process is performed according to the application request data, and specifically comprises:
detecting whether insurance products required to be purchased by an order placing user exist according to order data in the insurance application request data;
if so, detecting whether the stock of the insurance product is sufficient; and/or
Detecting whether the insurance product is paid successfully;
if the payment is successful, detecting whether the corresponding purchase amount of the ordering user meets the purchase amount requirement of the insurance product; and/or
Inquiring the insurance application qualification corresponding to the insurance product, and detecting whether the policy issuing request of this time meets the policy issuing requirement of the insurance product by combining the information of the insurance application person and the insured person filled by the ordering user in the insurance application request data;
determining that the verification fails when detecting that the insurance product does not exist, and/or the inventory of the insurance product is insufficient, and/or the insurance product is not paid successfully, and/or the purchase amount of the ordering user does not accord with the purchase amount requirement of the insurance product, and/or detecting that the policy issuing request does not accord with the issuing requirement of the insurance product;
and when the insurance product exists, the inventory of the insurance product is sufficient, the payment of the insurance product is successful, the purchase amount of the ordering user accords with the purchase amount requirement of the insurance product, and the order issuing request of the current insurance policy accords with the order issuing requirement of the insurance product, the verification is determined to be successful.
4. The method according to claim 3, wherein the policy issuing request further carries client information, and the checking process is performed according to the insurance application request data, and specifically further comprises:
detecting whether the age of the ordering user meets the preset purchasing age condition or not according to the ordering user account information contained in the client information; and/or
Inquiring credit information of the ordering user according to the account information of the ordering user, and detecting whether the credit of the ordering user meets the preset credit requirement or not according to the credit information; and/or
According to the equipment identification of the order issuing terminal equipment and the user identification of the order issuing user contained in the client information, safety verification is carried out by combining a preset white list and a preset black list; and/or
Counting whether the number of requests sent by the order placing terminal equipment or the order placing user received by the server in a preset time period is larger than a preset number threshold or not according to the equipment identification and the user identification;
and when the age of the order placing user is detected to be not in accordance with the preset purchasing age condition, and/or the credit of the order placing user is detected to be not in accordance with the preset credit requirement, and/or the security verification is failed, and/or the request number is larger than the preset number threshold value, determining that the verification is failed.
5. The method according to claim 1, wherein the pushing insurance request data corresponding to each policy issuance request in the predetermined message buffer queue to a server for processing to generate a corresponding policy according to a predetermined pushing rule specifically comprises:
monitoring the load condition of a server in real time, and determining whether the server is in an idle time stage according to the load condition;
if the server is in an idle stage, sequentially pushing insurance application request data corresponding to each insurance policy issuing request in the preset message cache queue to the server according to a preset sequence for processing so as to generate corresponding insurance policies;
and if the server is in the busy period, stopping pushing the insurance application request data in the preset message buffer queue to the server for processing.
6. The method according to claim 1, wherein the pushing insurance request data corresponding to each policy issuance request in the predetermined message buffer queue to a server for processing to generate a corresponding policy according to a predetermined pushing rule specifically comprises:
and pushing the insurance request data corresponding to each insurance policy order output request stored in the preset message buffer queue within a preset period to a server for processing according to the preset period to generate a corresponding insurance policy.
7. The method according to claim 5 or 6, wherein after successfully pushing the insurance request data corresponding to the policy output request in the predetermined message buffer queue to the server, the method further comprises:
deleting the successfully pushed application request data from the preset message cache queue; or
And deleting the successfully pushed insurance request data from the preset message buffer queue regularly or irregularly.
8. An apparatus for processing policy issuance requests, comprising:
the system comprises a creating unit, a processing unit and a processing unit, wherein the creating unit is used for creating message cache queues of different insurance types in a data cache region between an output list architecture of an application programming interface and a server; the message buffer queues of all insurance types respectively correspond to servers of different insurance types, and the length of the message buffer queues is determined according to the number of received policy order output requests;
the acquiring unit is used for acquiring insurance application request data carried in an insurance policy issuing request when the policy issuing architecture receives the insurance policy issuing request sent by a client;
the verification unit is used for verifying the insurance application request data;
the storage unit is used for storing the insurance request data into a preset message cache queue if the verification of the verification unit is successful, wherein the insurance request data carried by different insurance policy issuing requests to be processed by the server are stored in the preset message cache queue;
and the pushing unit is used for pushing the insurance application request data corresponding to each insurance policy issue request in the preset message cache queue to a server corresponding to the insurance category of the preset message cache queue for processing so as to generate a corresponding insurance policy according to a preset pushing rule.
9. A storage medium on which a computer program is stored, the program implementing the method of processing a policy issuance request according to any one of claims 1 to 7 when executed by a processor.
10. A device for processing policy issuance requests, comprising a storage medium, a processor and a computer program stored on the storage medium and executable on the processor, wherein the processor implements the method for processing policy issuance requests according to any one of claims 1 to 7 when executing the program.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810173299.9A CN109729060B (en) | 2018-03-01 | 2018-03-01 | Processing method, device and equipment for policy issuing request |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810173299.9A CN109729060B (en) | 2018-03-01 | 2018-03-01 | Processing method, device and equipment for policy issuing request |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109729060A CN109729060A (en) | 2019-05-07 |
| CN109729060B true CN109729060B (en) | 2021-09-21 |
Family
ID=66293438
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201810173299.9A Active CN109729060B (en) | 2018-03-01 | 2018-03-01 | Processing method, device and equipment for policy issuing request |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109729060B (en) |
Families Citing this family (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110471966B (en) * | 2019-07-02 | 2023-08-01 | 平安科技（深圳）有限公司 | Information data verification method, device, computer equipment and storage medium |
| CN110611583B (en) * | 2019-08-14 | 2023-06-30 | 中国平安财产保险股份有限公司 | System service method, server and storage medium |
| CN110866833A (en) * | 2019-10-10 | 2020-03-06 | 北京鼎立保险经纪有限责任公司 | Insurance application method based on insurance business |
| CN110765167B (en) * | 2019-10-23 | 2022-07-22 | 泰康保险集团股份有限公司 | Policy data processing method, policy data processing device and policy data processing equipment |
| CN110750361A (en) * | 2019-10-25 | 2020-02-04 | 北京亿信华辰软件有限责任公司武汉分公司 | Optimization algorithm for processing concurrent requests |
| CN111027809B (en) * | 2019-11-13 | 2022-07-05 | 泰康保险集团股份有限公司 | Message notification method, device, medium and electronic equipment |
| CN113362129A (en) * | 2021-05-31 | 2021-09-07 | 北京京东振世信息技术有限公司 | Task processing method and device, electronic equipment and storage medium |
| CN114338539A (en) * | 2022-01-11 | 2022-04-12 | 平安科技（深圳）有限公司 | Concurrency control method and device, network equipment and readable storage medium |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105100059A (en) * | 2015-06-10 | 2015-11-25 | 努比亚技术有限公司 | Method, device and system for processing high-concurrent requests |
| CN107516277A (en) * | 2016-06-15 | 2017-12-26 | 平安科技（深圳）有限公司 | Control single method and apparatus of insuring out |
| CN107528922A (en) * | 2017-09-29 | 2017-12-29 | 深圳市金立通信设备有限公司 | A kind of information push method, terminal and computer-readable recording medium |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9110807B2 (en) * | 2012-05-23 | 2015-08-18 | Sybase, Inc. | Cache conflict detection |
| CN107742208A (en) * | 2017-11-23 | 2018-02-27 | 中国平安财产保险股份有限公司 | Vehicle is in danger querying method, device, equipment and the computer media of flow |
-
2018
- 2018-03-01 CN CN201810173299.9A patent/CN109729060B/en active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105100059A (en) * | 2015-06-10 | 2015-11-25 | 努比亚技术有限公司 | Method, device and system for processing high-concurrent requests |
| CN107516277A (en) * | 2016-06-15 | 2017-12-26 | 平安科技（深圳）有限公司 | Control single method and apparatus of insuring out |
| CN107528922A (en) * | 2017-09-29 | 2017-12-29 | 深圳市金立通信设备有限公司 | A kind of information push method, terminal and computer-readable recording medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CN109729060A (en) | 2019-05-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109729060B (en) | Processing method, device and equipment for policy issuing request | |
| CN110401720B (en) | Information processing method, device, system, application server and medium | |
| JP2002189650A (en) | Method and device for controlling computer, and recording medium stored with processing program therefor | |
| CN107527222B (en) | Information processing method, device and system | |
| CN106779673B (en) | Electronic payment method and system | |
| CN112561633A (en) | Order data verification method, device and equipment | |
| CN113179282A (en) | Method and device for merging account numbers and server | |
| CN110458544B (en) | Payment method and payment service system of multi-cash-register-crossing system | |
| CN111191925A (en) | Data processing method, device, equipment and storage medium | |
| CN107665453B (en) | Virtual resource processing method and device and server | |
| CN114626719A (en) | Network appointment platform risk assessment method, equipment and storage medium | |
| CN113626882A (en) | Method, device and medium for generating equipment identifier | |
| CN109242705A (en) | Method for processing business, equipment and storage medium based on alliance's committee member's chain | |
| CN111507585B (en) | Method, device and system for processing activity information | |
| CN110263044B (en) | Data storage method, device, equipment and computer readable storage medium | |
| CN113095891A (en) | Data processing method and device, storage medium and electronic device | |
| CN111292143A (en) | Electronic invoice issuing method, device and computer system | |
| CN111507594A (en) | Data processing method and equipment | |
| CN111507583A (en) | Method, device and system for processing activity information | |
| CN111726266A (en) | Hot spot data barreling method and system and computer equipment | |
| CN106130740B (en) | Digital certificate synchronous method, digital signature server and digital certificate synchronization system | |
| CN106296327A (en) | The self-service method of inspection of virtual objects and self-service transfer method | |
| CN111105315B (en) | Policy request processing method, policy request processing device, policy request processing medium and electronic equipment | |
| JP7221927B2 (en) | Information processing device, method and program | |
| CN117934075A (en) | Electronic rights issuing method, electronic rights issuing device, electronic equipment and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |