CN115567730A - Medicine shaking platform - Google Patents

Abstract

The invention discloses a medicine shaking platform which is characterized by comprising a mobile client, a load balancing SLB, a nginx application server, a getaway gateway, a nacos service center, a feign business service center, a rocktmq message queue, a Redis cache, an elastic search engine and data storage.

Description

Medicine shaking platform

Technical Field

The invention relates to the technical field of live broadcast systems for major health major medicine major health major, in particular to a medicine shaking platform.

Background

Shaking medicine is a big healthy direct broadcast platform of medicine, and is developed aiming at the needs major of the pharmaceutical industry, and opens the stay for pharmaceutical enterprises (pharmaceutical industry, pharmaceutical business, chain pharmacy, retail pharmacy, platform) and medical practitioners (doctors, pharmacists, store managers). Supports B2B and B2C multi-state live broadcast, and meets the multi-element requirements of a medical industry end, a basic business end and a retail pharmacy end. Constructing a separate sowing system, aiming at performing quality direct sowing with 'actual effect', breaking single direct sowing effect, forming a body systematization, prolonging the period and forming a hematopoietic direct sowing ecology;

in the prior art, for example, chinese patent numbers are: CN108632636A discloses a method and system for live video broadcast in the field of medicine, wherein the method includes: receiving a video live broadcast request sent by a first client, establishing a current video live broadcast session, responding to a video live broadcast participation request sent by a second client, and adding the second client into the established video live broadcast session; receiving image data sent by the first client, and sending the image data to the second client, so that the image data is displayed in a current live broadcast picture of the second client; and identifying an operation instruction applied to the image data by the first client, converting the operation instruction into a visual identifier, and displaying the identifier at an operation position in the image data, which is aimed by the operation instruction, so that the identifier is synchronized in a current live screen at the second client. The technical scheme provided by the application can be convenient for improve the communication efficiency of the medicine main body.

However, in the prior art, most of the existing live broadcast platforms are shared by various industries and cannot meet the special requirements of the pharmaceutical industry. More serve entertainment and commodity transaction, and more the health science popularization is carried out for the user to the big healthy live broadcast of medicine. At present, no professional medicine direct broadcast platform exists in the market, the requirement for medicine health to directly broadcast contents is higher, and the medicine is more professional and can be used only by being developed for the specific professional.

Disclosure of Invention

Aiming at the defects of the prior art, the technical scheme adopted by the invention for solving the technical problems is as follows: a medicine shaking platform, which is provided with a medicine shaking platform, the method comprises a mobile client, a load balancing SLB, an nginx application server, a gateway, a nacos service center, a feign service center, a rocktmq message queue, a Redis cache, an elastic search engine and a data storage, wherein:

load balancing:

the SLB load balancing is adopted, the method is a service for carrying out on-demand distribution on the traffic, the throughput capacity of an application system is expanded by distributing the traffic to different back-end servers, single-point faults in the system can be eliminated, and the availability of the application system is improved. The method has the advantages of multi-protocol support, multi-level disaster tolerance, higher safety and reliability, super-strong performance guarantee and flexible scheduling strategy.

An application server:

the application server nginx is adopted, is a lightweight Web server/reverse proxy server and an electronic mail (IMAP/POP 3) proxy server, and simultaneously provides IMAP/POP3/SMTP service, and is characterized by less memory, strong concurrency, strong stability, rich function set, simple configuration file and low system resource consumption.

The service center:

a service center of the nacos is adopted,

dynamic configuration service:

when the configuration item needs to be updated, the configuration item can be operated to update through the management system, and after the update is finished, the configuration item is actively pushed to a client subscribing the configuration;

service discovery and management:

aiming at a distributed micro-service cluster system, a certain cluster A provides service, other application clusters need to consume the service of the cluster A, a system is needed to manage an ip list of the cluster A, other application clusters need to obtain the ip list of the cluster A and call the ip list, meanwhile, the system can automatically remove the ip which cannot work in the cluster A, and therefore the calling method can be guaranteed to be successfully called.

Dynamic DNS service:

the method has the advantages that the Nacos provides more convenient management capability than the DNS domain name server, a domain name is newly added, only one domain name needs to be configured on a console of the Nacos, meanwhile, the Nacos also provides capabilities which comprise weight, health check, attributes, routing and the like and are not possessed by the DNS server, and the flexibility and the stability of a product are better.

A gateway:

the gateway is used as the only external inlet of the system, and is an intermediate layer between the client and the server, and the gateway has the functions of processing non-service and providing routing request, authentication, monitoring, caching, current limiting and the like.

Different microservices generally have different network addresses, and a client may need to call a plurality of service interfaces to complete a service requirement; the complexity of the client is reduced, and the client does not need to request different micro services for many times; cross-domain requests are avoided, and processing is relatively simple; not every service requires independent authentication; easy to reconfigure, multiple services may be merged into one or split into multiple;

the business service center:

the Feign call service is adopted, the bottom layer realizes the feign.client interface class through java.net.HttpULConnection of JDK, and a new HttpULConnection link is created every time a request is sent, which is the reason why the performance of Feign is poor under the default condition. High-performance Http clients based on a connection pool, such as Apache Http client or Okhttp3, can be used by expanding the interface; the method is based on an interface-oriented dynamic proxy mode to generate an implementation class; analyzing the annotation information of the interface class into an internal expression according to the Contract protocol rule; dynamically generating a Request based on the RequestBean, and extracting a corresponding value from the Request according to the introduced Bean object and annotation information to construct an HttpRequest object; converting the Bean into an Http message text by using an Encoder; the interceptor is responsible for carrying out decoration processing on the request and the return; the HTTP request is sent based on the retry device, the retry device is arranged in the HTTP request, and when IO abnormality occurs to the HTTP request, feign sends the request with a maximum number of attempts;

message queue:

the message forwarding method adopts the rocktmq, wherein the rockmq mainly comprises a Producer, a Broker and a composer, wherein the Producer is responsible for producing messages, the composer is responsible for consuming messages, and the Broker is responsible for storing messages. The Broker corresponds to one server in the actual deployment process, each Broker may store a plurality of Topic messages, and each Topic message may also be stored in different brokers in pieces. The MessageQueue is used for storing the physical addresses of the messages, and the message address in each Topic is stored in a plurality of messagequeues. ConsumerGroup is composed of multiple Consumer instances.

The message Producer (Producer) is responsible for producing messages, typically by the business system. A message producer will send messages generated in the business application to the brooker server. The RocketMQ provides various sending modes, namely synchronous sending, asynchronous sending, sequential sending and unidirectional sending. Both synchronous and asynchronous modes require the Broker to return acknowledgement information, and unidirectional transmission is not required.

Message consumers (consumers), which are responsible for consuming messages, typically backend systems, are responsible for asynchronous consumption. A message consumer will pull a message from the Broker server and provide it to the application. From the perspective of the user application, two forms of consumption are provided: pull-type consumption and push-type consumption.

Topic (Topic) represents a collection of messages, each Topic contains several messages, each message can only belong to one Topic, and the Topic is a basic unit for message subscription of a RockettMQ.

The proxy server (BrokerServer) is in charge of storing and forwarding messages and has a message transfer role. The proxy server is responsible in the rocktmq system for receiving and storing messages sent from the producer, while preparing for the consumer's pull request. The proxy server also stores message-related metadata including consumer groups, consumption progress offsets and topics, and queue messages, among others.

Name service (NameServer), which acts as a provider of routing messages. The producer or consumer can look up the corresponding BrokerIP list for each topic through the name service. Multiple instances of Namesrv form a cluster, but are independent of each other, with no information exchange.

Pull Consumer (PullConsumer), a type of Consumer by the Consumer, typically actively invokes the Consumer's pull message method to pull messages from the Broker server, with the initiative being controlled by the application. Once the batch of messages is obtained, the application initiates the consumption process.

Push Consumer (pushConsumer), a type of Consumer Consumer, in which the Broker actively pushes data to the Consumer after receiving the data, and the consumption mode is generally high in real-time.

Producer group (Producer group), a collection of producers of the same type that send messages of the same type and send messages logically in unison. If a transaction message is sent and the original producer crashes after sending, the Broker server will contact other producer instances of the same producer group to commit or backtrack consumption.

Consumer group (ConsumerGroup), a collection of consumers of the same type, which typically consume the same type of messages and consume logically in agreement. The consumer group makes it very easy to achieve the goals of load balancing and fault tolerance in terms of message consumption. It is noted that the consumer instances of the consumer group must subscribe to the exact same Topic. The rockmq supports two message modes: cluster consumption (Clustering) and broadcast consumption (Broadcasting).

Cluster consumption (Clustering) in cluster consumption mode, each Consumer instance of the same Consumer group amortizes messages equally.

Broadcast consumption (Broadcasting) in broadcast consumption mode, each Consumer instance of the same ConsumerGroup receives the full amount of messages.

Normal order messages (normalrededmessage), in normal order consumption mode, messages received by a consumer through the same consumption queue are ordered, and messages received by different message queues may be unordered.

Strict order messages (stricllyorderedmessage), in strict order message mode, all messages received by a consumer are sequential.

Messages (messages), the physical carrier of information transmitted by the messaging system, the smallest unit of production and consumption data, each Message must belong to a topic. Each message in the rockmq has a unique MessageID and can carry a Key with a service identifier. The system provides the function of querying messages through the MessageID and Key.

Tag (Tag), a flag set for a message, used to distinguish different types of messages under the same subject. Messages from the same service unit can be provided with different labels on the same subject according to different service purposes. The tags can effectively maintain the clarity and coherence of the code and optimize the query system provided by the RockketMQ. The consumer can realize different consumption logics of different sub-themes according to the Tag, and better expansibility is realized.

Caching:

by adopting the persistence of the Redis and Redis supporting data, the data in the memory can be stored in a disk, and can be loaded again for use when being restarted. Redis not only supports simple key-value type data, but also provides storage for String, list, set, zset, hash, etc. data structures. Redis supports backup of data, i.e., data backup in master-slave mode. The performance is very high-the speed that Redis can read is 110000 times/s, and the speed that writes is 81000 times/s. All operations of atomic-Redis are atomic, while Redis also supports atomic execution after merging of several operations. Rich features, redis also supports publish/describe, notify, set key validity, and so on features.

A search engine:

an ElasticSearch, real-time (indexing data to about 1s capable of being searched) distributed search and analysis engine is adopted, and is mainly used for full-text search, structured search and analysis. The elastic search uses Lucene as an internal engine, but when the elastic search is used for full-text search, only uniformly developed APIs (application program interfaces) are needed, the operation principle of the Lucene with complex back does not need to be known, so that the elastic search is realized in an out-of-box and ready-to-use distributed mode, and a large number of default values are defined in the elastic search. The elastic search is not only as simple as Lucene, but also includes a full-text search function, and can perform the following work:

distributed real-time file storage and indexes each field so that it can be searched.

Distributed search engines for real-time analysis.

It can be extended to hundreds of servers, handling PB-level structured or unstructured data.

And (3) data storage:

mysql, mongodb and oss are adopted;

mysql connector management: the method comprises the following steps that firstly, a database connector is mainly responsible for establishing connection, authority acquisition, management connection and the like with a client, and as the whole connection establishing process is complex, long connection is used as much as possible. If the database is abnormal and is recovered quickly, the system can be restarted to reestablish the connection.

Mysql cache: the mysql request first looks at the cached data, the key is the result of the sql statement value, and if it exists, it returns directly. If not, go directly downward.

mysql caching is more appropriate for some static data and is preferably not used for data with high real-time performance.

An analyzer: the sql statement executed by you is parsed by first lexical analysis including some keyword recognition, then syntactic analysis to see if this statement conforms to mysql statement.

An optimizer: through your statement analysis, find those queries hit the index, as well as the order of connections between tables, etc.

An actuator: through the above series of verifications, the interface provided by the engine is used. After the query result is continuously stored in the result set, how many lines are scanned by the executor specifically can be seen through the explain.

Mongodb：

A database based on distributed file storage aims at providing an extensible high-performance data storage solution for WEB application, is a product between a relational database and a non-relational database, and has the most abundant functions in the non-relational database;

architecture mode replicast: a replication set, which is a "replication set" cluster formed by three peer nodes, and has multiple roles of "primary" and secondary, where primary is responsible for read-write requests, secondary can be responsible for read requests, and there is a configuration decision, where secondary follows primary and applies write operations; if primay fails, the cluster performs "majority assignment" election to elect a new primay, i.e., failover mechanism, i.e., HA architecture. The replication set solves the problem of single point failure, is also the minimum unit of monardab vertical expansion, and certainly, each shard node in the shardingcluster can also use the replicast to improve the data availability; shardingcluster: clustering by fragmentation, one of the means of data horizontal spreading; the drawback of this architecture of replicase is that the "cluster data capacity" is limited by the disk size of a single node, and if the data volume is increasing, it will be very difficult to expand it, so we need to adopt Sharding mode to solve this problem. The data of the whole collection is shared to a plurality of mongod nodes according to the sharing key, namely each node holds a part of data of the collection, the cluster holds all the data, and the sharing can support data of the number TB in principle.

The persistence mode has a highly configurable persistence setting, which loops from no guarantee at all to full persistence, where it specifically initiates a thread (unless the application crash is dropped) to fetch data to be persisted from the defer queue and write to the disk at journal and mongofile for a certain period of time, of course because it is not written to the disk when the user adds a record.

OSS：

Objects are the fundamental units of OSS stored Data, also called attributes of OSS file objects, meta information (ObjectMeta), user Data (Data) and file names (keys). The object is identified by a Key that is unique inside the memory space. The object meta-information is a key-value pair, which represents some attributes of the object, and the size of the object is not limited differently according to different uploading modes.

The object's lifecycle is from the successful upload to the deleted location. The object information is not changeable throughout the lifecycle. Repeated uploaded objects overwrite previous objects and therefore OSS does not support operations to modify portions of the contents of a file. The storage space attributes can be set and modified to control regions, access rights, life cycles and the like, and the attribute settings directly act on all objects in the storage space and flexibly create different storage spaces to complete different management functions.

The invention has the following beneficial effects:

1. aiming at professional development of medical industry requirements, the method is open to medical enterprises (medical industry, medical business, chain pharmacy, retail pharmacy and platform) and medical practitioners (doctors, pharmacists and store clerks), provides a better solution for the expansion and popularization of the industry enterprises, creates heat insulation brands of the medical industry practitioners, and provides accurate data statistics for the popularization of the industry enterprises.

2. The system supports live broadcast relay and distribution, meets the multiple requirements of a medical industry end, a basic business end and a retail pharmacy end aiming at B2B and B2C multi-state live broadcast, supports WeChat small programs, APP and computers to use OBS (open broadcasting software) to carry out live broadcast, meets various broadcast scenes, and provides a professional communication platform for medical major health industry users.

Drawings

FIG. 1 is a flow chart of the system of the present invention.

Detailed Description

The invention is described in further detail below with reference to the drawings and the detailed description. The embodiments of the present invention have been presented for purposes of illustration and description, and are not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to practitioners skilled in this art. The embodiment was chosen and described in order to best explain the principles of the invention and the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.

The first embodiment is as follows:

referring to fig. 1, the present invention provides a technical solution: the system comprises a mobile client, a load balancing SLB, an nginx application server, a gateway, a nics service center, a feign service center, a rocktmq message queue, a Redis cache, an elastic search engine and a data storage;

a spring couled micro-service architecture is adopted, a single application program is divided into a group of small services, the services are mutually coordinated and fused, each service is in an independent process, a lightweight communication mechanism is adopted between the services for mutual cooperation, each service is constructed around a specific service and can be independently deployed to a production environment, a similar production environment and the like; reference to related components: load balancing, application servers, service centers, gateways, business service centers, monitoring layers, message queuing, databases, caches, and the like. The system development functions include: live broadcast management, member management, commodity management, order management, data statistics, marketing activities and the like.

Load balancing:

the SLB load balancing is adopted, the service is used for distributing the traffic as required, the throughput capacity of the application system is expanded by distributing the traffic to different back-end servers, single-point faults in the system can be eliminated, and the availability of the application system is improved. The method has the advantages of multi-protocol support, multi-level disaster tolerance, higher safety and reliability, super-strong performance guarantee and flexible scheduling strategy.

An application server:

the nginx application server is adopted, is a lightweight Web server/reverse proxy server and an electronic mail (IMAP/POP 3) proxy server, simultaneously provides an IMAP/POP3/SMTP service, and is characterized by less memory occupation, strong concurrency capability, strong stability, rich function set, simple configuration file and low system resource consumption.

The service center:

a service center of the nacos is adopted,

(1) Dynamic configuration service:

when the configuration item needs to be updated, the configuration item in the management system can be operated and updated through the management system, and after the update is finished, the configuration item is actively pushed to a client subscribing the configuration;

(2) Service discovery and management:

aiming at a distributed micro-service cluster system, a certain A cluster provides service, other application clusters need to consume the service of the A cluster, a system is needed to manage an ip list of the A cluster, other application clusters can acquire the ip list of the A cluster and call the IP list, meanwhile, the system can automatically remove the ip which cannot work in the A cluster, and therefore the calling method can be guaranteed to be successfully called.

(3) Dynamic DNS service:

the method has the advantages that the Nacos provides more convenient management capability than the DNS domain name server, a domain name is newly added, only one domain name needs to be configured on a console of the Nacos, meanwhile, the Nacos also provides capabilities which comprise weight, health check, attributes, routing and the like and are not possessed by the DNS server, and the flexibility and the stability of a product are better.

A gateway:

the gateway is used as the only external inlet of the system, and is an intermediate layer between the client and the server, and the gateway processes non-service functions and provides functions of routing request, authentication, monitoring, caching, current limiting and the like.

Different microservices generally have different network addresses, and a client may need to call a plurality of service interfaces to complete a service requirement; the complexity of the client is reduced, and the client does not need to request different micro services for many times; cross-domain requests are avoided, and processing is relatively simple; not every service requires independent authentication; easy to reconfigure, multiple services may be merged into one or split into multiple;

the business service center:

the Feign call service is adopted, the bottom layer realizes the feign.client interface class through java.net.HttpURLconnection of JDK, and a new HttpURLCONNECTION link is created every time a request is sent, which is the reason why the performance of Feign is poor under the default condition. High-performance Http clients based on a connection pool, such as Apache Http client or Okhttp3, can be used by expanding the interface; the method is based on an interface-oriented dynamic proxy mode to generate an implementation class; analyzing the annotation information of the interface class into an internal expression according to the Contract protocol rule; dynamically generating a Request based on the RequestBean, and extracting a corresponding value from the Request according to the introduced Bean object and annotation information to construct an HttpRequest object; converting the Bean into an Http message text by using an Encoder; the interceptor is responsible for performing decoration processing on the request and the return; the HTTP request is sent based on the retry device, the retry device is arranged in the HTTP request, and when IO abnormality occurs to the HTTP request, feign sends the request with a maximum number of attempts;

message queue:

the method adopts rocktmq, wherein rockmq mainly comprises three parts, namely a Producer, a Broker and a Consumer, wherein the Producer is responsible for producing messages, the Consumer is responsible for consuming messages, and the Broker is responsible for storing messages. The Broker corresponds to a server in the actual deployment process, each Broker may store a plurality of Topic messages, and each Topic message may also be stored in different brokers in pieces. The MessageQueue is used for storing the physical addresses of the messages, and the message address in each Topic is stored in a plurality of messagequeues. ConsumerGroup is composed of multiple Consumer instances.

The message Producer (Producer) is responsible for producing messages, typically by the business system. A message producer will send messages generated in the business application to the brooker server. The RocketMQ provides various sending modes, namely synchronous sending, asynchronous sending, sequential sending and unidirectional sending. Both synchronous and asynchronous modes require the Broker to return acknowledgement information, and unidirectional transmission is not required.

Message consumers (consumers), which are responsible for consuming messages, typically backend systems, are responsible for asynchronous consumption. A message consumer will pull a message from the Broker server and provide it to the application. From the perspective of the user application, two forms of consumption are provided: pull-type consumption and push-type consumption.

Topic (Topic) represents a collection of messages, each Topic contains several messages, each message can only belong to one Topic, and the Topic is a basic unit for message subscription of a RockettMQ.

The proxy server (BrokerServer) is in charge of storing and forwarding messages and has a message transfer role. The proxy server is responsible for receiving and storing messages sent from the producer in the rocktmq system, and preparing for pull requests of the consumers. The proxy server also stores message-related metadata including consumer groups, consumption progress offsets and topics, and queue messages, among others.

Name service (NameServer), which acts as a provider of routing messages. The producer or consumer can look up the corresponding BrokerIP list for each topic through the name service. Multiple instances of Namesrv form a cluster, but are independent of each other, with no information exchange.

Pull Consumer (PullConsumer), a type of Consumer by the Consumer, typically actively invokes the Consumer's pull message method to pull messages from the Broker server, with the initiative being controlled by the application. Once the batch of messages is obtained, the application initiates the consumption process.

Push Consumer (pushConsumer), a type of Consumer consumption, in which a Broker actively pushes data to a Consumer after receiving the data, and the consumption mode is generally high in real-time.

Producer group (Producer group), a collection of producers of the same type that send messages of the same type and send messages logically in unison. If a transaction message is sent and the original producer crashes after sending, the Broker server will contact other producer instances of the same producer group to commit or backtrack consumption.

Consumer group (ConsumerGroup), a collection of consumers of the same type, which generally consume the same type of messages and consume logically in agreement. The consumer group makes it very easy to achieve the goals of load balancing and fault tolerance in terms of message consumption. It is noted that consumer instances of a consumer group must subscribe to the exact same Topic. The rockmq supports two message modes: cluster consumption (Clustering) and broadcast consumption (Broadcasting).

Cluster consumption (Clustering) in cluster consumption mode, each Consumer instance of the same Consumer group amortizes messages equally.

Broadcast consumption (Broadcasting) in broadcast consumption mode, each Consumer instance of the same ConsumerGroup receives the full amount of messages.

Normal order messages (normalrededmessage), in normal order consumption mode, messages received by a consumer through the same consumption queue are ordered, and messages received by different message queues may be unordered.

Strict order messages (stricllyorderdmessage), in strict order message mode, all messages received by a consumer are ordered.

Messages (messages), the physical carrier of information transmitted by the messaging system, the smallest unit of production and consumption data, each Message must belong to a topic. Each message in the rockmq has a unique MessageID and can carry a Key with a service identifier. The system provides the function of querying messages through the MessageID and Key.

Tag (Tag), a flag set for a message, used to distinguish different types of messages under the same topic. Messages from the same service unit can be provided with different labels on the same subject according to different service purposes. The tags can effectively maintain the clarity and consistency of the code and optimize the query system provided by the RockettMQ. The consumer can realize different consumption logics of different sub-themes according to the Tag, and better expansibility is realized.

Caching:

by adopting the persistence of the Redis and Redis supporting data, the data in the memory can be stored in a disk, and can be loaded again for use when being restarted. Redis not only supports simple key-value type data, but also provides storage for String, list, set, zset, hash, etc. data structures. Redis supports backup of data, i.e., master-slave mode data backup. The speed of reading is 110000 times/s, and the speed of writing is 81000 times/s. All operations of atomic-Redis are atomic, while Redis also supports atomic execution after merging of several operations. The rich feature-Redis also supports publish/describe, notify, set key validity, and other features.

A search engine:

an ElasticSearch, real-time (indexing data to about 1s that can be searched) distributed search and analysis engine is adopted, and is mainly used for full-text search, structured search and analysis. The elastic search uses the Lucene as an internal engine, but when the elastic search is used for full-text search, only uniformly developed APIs (application program interfaces) are needed, the operation principle of the Lucene which is complicated behind the elastic search does not need to be known, so that the elastic search is realized in an out-of-box and in-use distributed mode, and a large number of default values are defined in the elastic search. The elastic search is not only as simple as Lucene, but also includes a full-text search function, and can perform the following work:

distributed real-time file storage, and indexing each field so that it can be searched;

a distributed search engine for real-time analysis;

it can be extended to hundreds of servers, handling PB-level structured or unstructured data.

Data storage:

mysql, mongodb and oss are adopted;

mysql connector management: the method comprises the steps that firstly, a database connector is mainly responsible for establishing connection, authority acquisition, management connection and the like with a client, and as the whole connection establishing process is complex, long connection is used as much as possible. If the database is abnormal and is recovered quickly, the system can be restarted to reestablish the connection.

Mysql cache: the mysql request firstly looks at the cache data, the sql statement value as the key is the result of the query, and if the query exists, the query is directly returned. If not, go directly downward.

Note that: mysql caching is more appropriate for some static data and is preferably not used for data with high real-time performance.

An analyzer: the sql statement executed by you is parsed by first lexical analysis including some keyword recognition, then syntactic analysis to see if this statement conforms to mysql statement.

An optimizer: through your statement analysis, find those queries hit the index, as well as the order of connections between tables, etc.

An actuator: through the above series of verifications, the interface provided by the engine is used. After the query result is continuously stored in the result set, how many lines are scanned by the executor specifically can be seen through the explain.

Mongodb：

A database based on distributed file storage aims at providing an extensible high-performance data storage solution for WEB application, is a product between a relational database and a non-relational database, and has the most abundant functions in the non-relational database;

architecture mode replicast: a replication set, generally, three peer nodes form a "replication set" cluster, and has multiple roles of "primary" and secondary, where primary is responsible for a read-write request, secondary can be responsible for a read request, and there is a configuration decision, where secondary follows primary and applies write operation; if primay fails, the cluster performs "majority assignment" election to elect a new primay, i.e., failover mechanism, i.e., HA architecture. The replication set solves the problem of single point failure, is also the minimum unit of monardab vertical expansion, and certainly, each shard node in the shardingcluster can also use the replicast to improve the data availability;

shardingcluster: clustering by fragmentation, one of the means of data horizontal spreading; the drawback of this architecture of replicase is that the "cluster data capacity" is limited by the disk size of a single node, and if the data volume is increasing, it will be very difficult to expand it, so we need to adopt Sharding mode to solve this problem. Data of the whole collection is shared to a plurality of mongod nodes according to the sharing key, namely each node holds a part of data of the collection, the cluster holds all the data, and the sharing can support data with the number of TB in principle.

The persistence mode has a highly configurable persistence setting that cycles from no guarantee at all to full persistence, where he specifically initiates a thread (unless the application crash is removed) to fetch data to be persisted from the defer queue and write to disk at journal and mongofile for a period of time, of course because it is not written to disk when the user adds a record.

OSS：

Objects are the basic units of OSS stored Data, also called attributes of OSS file objects, meta information (ObjectMeta), user Data (Data) and file names (Key). The object is identified by a Key that is unique inside the memory space. The object meta-information is a key-value pair representing some properties of the object.

The size limit of the object is different according to different uploading modes. The object's lifecycle is from the successful upload to the deleted location. The object information is not changeable throughout the lifecycle. The repeatedly uploaded object may overwrite the previous object, so the OSS does not support the operation of modifying part of the content of the file. The storage space attributes can be set and modified to control regions, access rights, life cycles and the like, and the attribute settings directly act on all objects in the storage space and flexibly create different storage spaces to complete different management functions.

It is to be understood that the described embodiments are merely a few embodiments of the invention, and not all embodiments. All other embodiments, which can be derived by one of ordinary skill in the art and related arts based on the embodiments of the present invention without any creative effort, shall fall within the protection scope of the present invention. Structures, devices, and methods of operation not specifically described or illustrated herein are generally practiced in the art without specific details or limitations.

Claims (7)

1. The drug shaking platform is characterized by comprising a mobile client, a load balancing SLB, an nginx application server, a getaway gateway, a nacos service center, a feign business service center, a rocktmq message queue, a Redis cache, an elastic search engine and a data storage, wherein:

load balancing:

SLB load balancing is adopted, and the method is a service for distributing traffic according to needs;

an application server:

the nginx application server is adopted, is a lightweight Web server/reverse proxy server and an electronic mail (IMAP/POP 3) proxy server, simultaneously provides an IMAP/POP3/SMTP service, and is characterized by less memory occupation, strong concurrency capability, strong stability, rich function set, simple configuration file and low system resource consumption.

2. The drug shaking platform of claim 1, wherein: the service center adopts a nacos service center:

(1) Dynamic configuration service:

the configuration items in the system are managed through the system;

(2) Service discovery and management:

aiming at a distributed micro-service cluster system, a certain cluster A provides service, other application clusters need to consume the service of the cluster A, a system is needed to manage an ip list of the cluster A, other application clusters need to acquire the ip list of the cluster A and call the ip list, meanwhile, the system needs to be capable of automatically removing the ip which cannot work in the cluster A, and therefore the calling method can be guaranteed to be successfully called;

(3) Dynamic DNS service:

usually, an api of http is accessed in a code, and usually a domain name is taken, and when a request is made, the user generally firstly goes to a DNS domain name server to find an ip corresponding to the domain name, and then sends an http request.

3. The medicine shaking platform of claim 1, wherein: the gateway adopts a gateway, is the only outward inlet of the system, is an intermediate layer between the client and the server, and processes non-service functions to provide functions of routing request, authentication, monitoring, caching, current limiting and the like;

the business service center:

the method has the advantages that Feign call service is adopted, the bottom layer realizes the feign.client interface class through java.net.HttpURLconnection of JDK, and a new HttpURLconnection link is created each time a request is sent.

4. The medicine shaking platform of claim 1, wherein: the message queue adopts a rocktmq, wherein the rockmq mainly comprises a Producer, a Broker and a Consumer, wherein the Producer is responsible for producing messages, the Consumer is responsible for consuming messages, and the Broker is responsible for storing messages; the method comprises the following steps that a Broker corresponds to a server in the actual deployment process, each Broker can store a plurality of Topic messages, and each Topic message can be stored in different Brokers in a fragmentation mode; the MessageQueue is used for storing the physical addresses of the messages, the message address in each Topic is stored in a plurality of MessageQueues, and the Consumer group consists of a plurality of Consumer instances;

a message Producer (Producer) is responsible for producing messages, generally a service system is responsible for producing messages, one message Producer can send messages generated in a service application system to a Broker server, a RocktMQ provides multiple sending modes, synchronous sending, asynchronous sending, sequential sending and unidirectional sending are adopted, the synchronous and asynchronous modes both need a Broker to return confirmation information, and unidirectional sending is not needed;

a message Consumer (Consumer) responsible for consuming messages, typically a backend system responsible for asynchronous consumption, one message Consumer pulling a message from the Broker server and providing it to the application;

from the perspective of the user application, two forms of consumption are provided: pull-type consumption and push-type consumption;

the Topic (Topic) represents a collection of messages of a type, each Topic comprises a plurality of messages, each message only belongs to one Topic, and the Topic is a basic unit for message subscription of the RocketMQ;

the proxy server (BrokerServer) is used for transferring the message and is responsible for storing and forwarding the message;

name service (NameServer), the name service acts as the provider of routing message, producer or consumer can look for the correspondent BrokerIP tabulation of every theme through the name service, a plurality of Namesrv examples make up the cluster, but independent each other, there is no information exchange;

pull Consumer (PullConsumer), one type of Consumer of the Consumer, an application usually actively calls a Consumer message pull method to pull a message from a Broker server, the initiative is controlled by the application, and once a batch of messages are obtained, the application starts a consumption process;

push Consumer (pushConsumer), a type of Consumer consumption, in which the Broker actively pushes data to the Consumer after receiving the data;

producer group (Producer group), a collection of Producer of the same type, which sends messages of the same type and sends the logic is consistent, if the sent messages are transaction messages and the original Producer crashes after sending, the Broker server contacts other Producer instances of the same Producer group to submit or backtrack consumption;

consumer group (ConsumerGroup), a collection of consumers of the same type, which generally consume the same type of messages and consume logically consistent;

normal sequential messages (normalrededmessage), in the normal sequential consumption mode, messages received by a consumer through the same consumption queue are sequential, and messages received by different message queues may be unordered;

strict order messages (stricllyorderedmessage), in which all messages received by a consumer are ordered;

messages (messages), physical carriers of information transmitted by a Message system, and minimum units of production and consumption data, wherein each Message must belong to a subject, each Message in the RockcketMQ has a unique Message ID and can carry a Key with a service identifier, and the system provides a function of querying the Message through the Message ID and the Key;

a Tag (Tag), a flag set for a message, for distinguishing different types of messages under the same theme, and a different Tag may be set under the same theme according to different service purposes for a message from the same service unit.

5. The medicine shaking platform of claim 1, wherein: the cache supports data persistence by adopting Redis and Redis, can store data in a memory in a disk, and can be loaded again for use when being restarted.

6. The drug shaking platform of claim 1, wherein: the search engine adopts an elastic search and real-time distributed search and analysis engine, and is mainly used for full-text search, structured search and analysis.

7. The drug shaking platform of claim 1, wherein: the data storage adopts mysql, mongodb and oss;

mysql connector management: firstly, a database connector is mainly responsible for establishing connection, authority acquisition, management connection and the like with a client;

mysql cache: the mysql request first looks at the cached data, the key is the result of the sql statement value, and if it exists, it returns directly. If not, directly walking downwards;

Mongodb：

a database based on distributed file storage aims at providing an extensible high-performance data storage solution for WEB application, is a product between a relational database and a non-relational database, and has the most abundant functions in the non-relational database;

OSS：

objects are the fundamental units of OSS stored Data, also called attributes of OSS file objects, meta information (ObjectMeta), user Data (Data) and file names (keys).

Images