I have received a project.
Thinking after design, this project is to provide WAPPUSH technology to different user groups (company), which is to make a formulated PPG. The specific transmission has been encapsulated by the underlying layer, and provides a specification API, which is required to complete the interface for different SPs, allowing them to transmit PUSH through this system. The functional requirements of this system are required to have a stable performance and have logging.
Here is the design I received:
1. Interface part, providing Socket interface calls to SP, in order to improve performance, multi-threaded and combined with the queue implementation. And provide an example of a client
Note that you need to use the identity authentication, otherwise an error is reported.
2. Database design: (implemented with mysql) 3 tables: SP table: Mobile_user: Every Push should register the user in this table, sp_id can be obtained by logging in, please Keith supplements. Pushlog Table: Record the information sent each time in this table.
3. Management interface: (implementation with PHP) A.SP's Add, Remove, Delete, Update, Search May Not Required b. Give a mobile phone number, can I find the Push sent by the SP, how much, list it, list C. Select SP, statistically send information, how many strips, success rate D. Give one topic, can I find which SP sent
4. Database ER diagram:
------------------------------------------------
After reading the above design, I gave me the head reply as follows:
Hey: Design has been received, but I personally feel that some places may need to discuss: 1 First Use Socket to implement the interface If only Socket is available, there will be platform compatibility issues because each SP may use Different development languages, of course, this problem should be able to solve, but this also increases the difficulty of SP. If the work is added, each SP may consider calling other difficulty to require a lower PUSH gateway to implement. I suggest we offer two sets of interfaces: Socket interface and webservice interface. 2 Database design part, I personally have some doubts after designing, say we discuss it :) If you implement the current database, analyze the PUSH request from a SP to our mobile phone users. Procedure, I think there are two ways to implement: a) Directly send one step to the implementation method; b) Adopt supplier-consumer mode. First let's analyze the first way: When a call request to SP reaches our system, we first perform SP authentication (certification), perform SELECT operation on the SP table (recommended to use memory database technology for SP authentication) To improve performance), in the case of authentication, we will perform a sending operation, first need to perform SELECT operations on the Mobile_User table (because maybe this SP's Mobile_User already exists), divided into two cases according to the results of SELECT: 1. If This mobile phone user does not have this mobile phone user in this sp. The mobile_user table is inserted, and then go to the next step; 2. If this user already exists, the next step is performed directly. The next step is to perform the sending operation (we call the underlying interface), and perform the INSERT operation of the Pushlog table after sending. The fear of this implementation is: 1. Excess SELECT for Mobile_User, each SP-PUSH call request to perform SELECT to mobile_user, and with the system's run time growth, the number of records of the Mobile_User table is growing, The system performance consumed here will be more and more; 2. If the system has an exception, the user's mobile phone number and other resources cannot be recorded, and the SP-Push call cannot be logged, because we are logging at the end of all operations; 3. If we call the underlying interface PUSH send unable to succeed or our call part has an error exception, the system will be paralyzed, and the Sep-Push log and the RE-PUSH operation cannot be recorded.
Then let's analyze the second way: second way to use the supplier - consumer mode implementation (I tend to this way, because this model fundamentally avoids the first, third, third, 3 points of the first implementation ). When the PUSH request of the SP reaches our system, first authentication, this process does not need to say, after the authentication passes the ability to perform SELECT operations (because maybe this SP's Mobile_User already exists), divided into two situations according to the results of SELECT : 1. If this mobile phone user does not have this mobile phone user in this SP's Mobile_User table, the mobile_user table is inserted, then go to the next step; 2. If this user already exists, the next step is performed directly. The next step is to perform the INSERT operation of the Pushlog table, the INSERT PUSHLOG table (these fields) may include: ID, mobilej_user_mb_id, subject, url, create_date [adopt supplier - consumer mode must add this field], Sent_Status. This is the end of the supplier behavior. The consumer operation of colleagues is relatively simple: First, the mobile_User table and the Pushlog table are combined with SELECT operations (retrieve Sent_Status is recorded "unprecedented" state), then send (call the underlying interface), and finally perform Update operation on the Pushlog table (Updated fields may include: Sent_Date, Sent_Status). This implementation is concerned: 1. The supplier's excess Select of Mobile_User, each SP-PUSH call request to perform SELECT to mobile_user, and with the system's run time growth, the number of records of the Mobile_User table is also Convergency, the system performance consumed here will be more and more; 2. Suppliers and consumer colleagues perform Write operation on the Pushlog table, very frequent operation, the number of records of the Pushlog table (will grow over time), very To generate database dead locks; 3. Consumers' combined SELECT operations for Mobile_User tables and Pushlog tables, these two tables grow continuously over time (from equilibrium angle measure, the former is linearly latter, causing a couple) Relationship), then system consumption of this operation also increases nonlinear growth as the system's runtime. -------------------------------------------------- -------------------------------------------------- -----------------------------------------
Please help analyze if my analysis is correct? There is also a question, just about using the Socket interface or use the WebService interface to implement the debate, from performance, security, etc., which way is better?
