High-concurrency and high-traffic website architecture: simple ideas and concurrent traffic Architecture

High-concurrency and high-traffic website architecture: simple ideas and concurrent traffic Architecture
*******************************
Front end
*******************************
1. Increase the necessary hardware and bandwidth, and reserve an additional part for the emergency
2. It monitors whether the network data traffic is normal. If there is a large number of crawlers, such as DDOS, the traffic can be throttled by iP addresses and cookies.
3. Use CDN to make necessary algorithm transformation and static/dynamic separation at the same time



*******************************
Code end
*******************************
1. Necessary code optimization and transformation, such as software upgrade, slow query, client cache, and Multithreading
2. Downgrade during design peak hours: Disable or suspend non-core page functions and backend statistics functions
3. horizontal expansion of SOA, preferably automated Expansion
4. Select Layer 7 or Layer 4 as the load will not be the bottleneck
5. Various High cache types: reids, mongdb, and memcache
6. From the web to the Database End, a "isolation zone" is required, allowing data to enter the database smoothly and continuously.
7. Try not to use stored procedures with complex business logic processing (in the case of centralized business logic processing in N big data results) to reduce the database CPU and memory pressure
8. functional modules should be isolated, so that data cannot be loaded by a function, which affects other non-interdependent functions.
9. Reasonable Connection Pool Design



*******************************
Backend
*******************************


1. Master-slave replication:

Case 1: It is difficult to achieve real-time performance, but some data may not be synchronized during switchover, resulting in data consistency problems.
You can record operation logs while operating the primary database. When you switch to the standby database, a check will be performed with the operation log to complete the data that has not been synchronized;


Case 2: dbrd + master-slave mode or share eveything Architecture


2. share nothing architecture of PXC or MGC Clusters


3. Split databases according to different requirements on the page: such as user login, shopping cart, order, payment, etc. distributed in different databases


4. DB by region: users in different regions, such as East China, North China, central China, South China, and West China, can access the databases of different IDCs. The data can be summarized to the Headquarters IDCs. When the problem breaks out, the global data is not affected; the DB pressure on a single data center is reduced.


5. Database hardware: such as SSD and flash storage.


6. Pure Memory Database: such as timesten, HANA, or custom development


7. killer:
1) forcibly set up data archiving for which refund is not possible even when the transaction is completed, such as the departure time. archive data is only available for query.


2) If the first type of forced archiving still has a huge amount of data, you can archive the data according to the day, such as 10 days ago. After all
More than 80 transactions will be completed, without a large amount of code modifications, such as front-end refund, change signature processing,
Directly insert data into the master database. After all, database insert is not the biggest bottleneck.


3) split by order status: the order is not paid, the payment is complete, the process is in progress, and the payment is complete, and the architecture is different from the table.



--------- Multi-data center Disaster Tolerance
1. Remote Data Center Disaster Tolerance
A-> P or A->


2. Multi-path optical fiber can be considered in a single data center


3. Underlying replication: hardware and software (RSYNC, DBRD, OGG)

Copyright Disclaimer: This article is an original article by the blogger and cannot be reproduced without the permission of the blogger.