High-Concurrency Web Architecture: Concepts, Load Balancing, CDN, and PHP Concurrency Practices

High‑concurrency web architecture involves understanding metrics like QPS (queries per second), concurrent connections, throughput, response time, PV/UV, and bandwidth, as well as conducting proper stress testing without impacting production servers.

QPS: number of requests per second.

Peak QPS calculation: (80% of total PV) / (20% of 6‑hour seconds).

Concurrent connections: simultaneous requests handled.

Throughput: requests processed per unit time, usually determined by QPS and concurrency.

Response time: time from request issuance to response receipt.

PV: total page views.

UV: unique visitors.

Bandwidth: derived from peak traffic and average page size.

Overall high‑traffic solution ideas

Traffic optimization: prevent hotlinking, merge and compress static assets, use asynchronous AJAX, enable browser caching and gzip, employ CDN acceleration, and separate image servers.

Server‑side optimization: static‑page generation, asynchronous processing, multithreading, queue‑based async handling.

Database optimization: caching (Memcache, Redis), MySQL index tuning, sharding, master‑slave replication, and load balancing.

Load balancing

Four‑layer (L4) load balancing works on IP + port, while seven‑layer (L7) balances based on URL and application data. Nginx provides powerful L7 balancing with strategies such as IP‑Hash, weighted round‑robin, fair, generic hash, and consistent hash.

IP‑Hash: built‑in, similar to round‑robin but hashes client IP.

Weighted round‑robin: prefers higher‑weight servers until their weight drops.

Fair: selects the backend with the lowest response time.

Generic hash / Consistent hash: simple key‑based hashing, the latter supports memcached.

LVS terminology:

DS – Director Server (load balancer)

RS – Real Server (backend)

VIP – Virtual IP (public address)

DIP – Director IP (internal communication)

RIP – Real Server IP

CIP – Client IP

LVS balancing methods:

NAT – rewrites destination IP to the real server.

DR – rewrites destination MAC to the real server.

TUNNEL – rarely used, for remote disaster recovery.

CDN basics

Content Delivery Network (CDN) distributes cached copies of static assets to edge nodes, reducing latency, bandwidth usage, and protecting against attacks. Advantages include local cache acceleration, cross‑ISP speed, DNS‑based load balancing, and automatic mirroring.

Typical CDN workflow: client request → smart DNS selects nearest cache node → if cached, serve directly; otherwise fetch from origin, cache, and serve.

Common CDN implementations: commercial services (e.g., BAT), LVS L4 balancing, or using Nginx/Var​nish/Squid for L7 caching and reverse proxy.

Process, thread, and coroutine models

A process is an OS‑level resource‑owning execution unit; threads are lightweight execution flows within a process sharing resources; coroutines are user‑level lightweight threads with cooperative scheduling.

Process states: running, ready, blocked.

Thread states: ready, running, blocked.

Coroutines retain their stack and registers, enabling fast context switches without kernel involvement.

Multi‑process, multi‑thread, and coroutine models each have trade‑offs in resource consumption and concurrency handling.

Asynchronous non‑blocking model (Reactor)

High‑concurrency servers use epoll‑based reactors. The reactor monitors socket events and dispatches callbacks.

<code>- add: add a socket to reactor</code><code>- set: modify socket events (read/write)</code><code>- del: remove socket from reactor</code><code>- callback: function invoked on event</code>

Examples: Nginx (multi‑thread reactor), Swoole (multi‑thread reactor + multi‑process workers).

PHP concurrency with Swoole

Swoole provides async TCP/UDP, async MySQL/Redis, connection pools, async tasks, message queues, timers, async file I/O, and DNS.

Supports coroutine syntax similar to Go for writing asynchronous code in a synchronous style.

Typical use cases: order‑stock decoupling via message queues, traffic spike limiting, log processing, chat services, and concurrent HTTP requests (curl_multi_init).

MySQL caching layers

Database caching reduces I/O pressure and improves response speed. Options include query cache, Memcache, and Redis.

Query cache example:

<code>query_cache_type=1 SELECT SQL_NO_CACHE * FROM my_table WHERE condition;</code><code>query_cache_type=2 SELECT SQL_CACHE * FROM my_table WHERE condition;</code><code>SET GLOBAL query_cache_size = 134217728;</code>

Cache maintenance commands:

<code>FLUSH QUERY CACHE;  -- clear cache fragments</code><code>RESET QUERY CACHE;  -- remove all cached queries</code><code>FLUSH TABLES;    -- close tables and clear cache</code>

Memcache and Redis provide distributed in‑memory caching; Redis adds persistence (RDB/AOF) and richer data structures.

MySQL data‑layer optimization

Choose appropriate data types, use proper indexes, avoid leading wildcards in LIKE, limit SELECT *, use LIMIT, and split complex queries.

Prefer InnoDB engine, consider partitioning, sharding, master‑slave replication, and load balancing (LVS, MyCat).

Design for sudden traffic spikes (e.g., live streaming)

Scale Nginx horizontally.

Cache static assets via CDN.

Use Redis queues for rate limiting.

Cache user data.

Employ master‑slave DB architecture.

Enable elastic auto‑scaling.

Apply rate‑limit and circuit‑breaker patterns.