Evolution of MySQL Server Architecture for a High‑Traffic Discuz Site

Assuming a Discuz website grows from a tiny visitor count to ten million daily page views, the MySQL server architecture evolves in several stages.

Stage 1 : When daily PV is below 10,000, a single machine runs both web and database services; no architectural tuning or caching is required, though a simple master‑slave replication may be added for data safety.

Stage 2 : At several tens of thousands of daily PV, the load on a single machine becomes noticeable, prompting separation of web and database servers and the introduction of a memcached cache. MySQL can still run on a single node, optionally with master‑slave replication for safety.

Stage 3 : With daily PV reaching hundreds of thousands, a single MySQL instance strains performance. The architecture shifts to a master‑multiple‑slave cluster to ensure data consistency, using tools such as MySQL‑proxy or Discuz’s built‑in read‑write splitting to direct writes to the master and reads to the slaves.

Stage 4 : When daily PV climbs to a few million, the traditional one‑master‑multiple‑slave setup hits bottlenecks because the master must ship bin‑logs to many slaves, causing latency. The solution is a hierarchical replication: one primary master for writes, a secondary master that feeds numerous downstream slaves, reducing synchronization overhead.

Stage 5 : At ten million daily PV, write traffic overwhelms the single master. The system adopts database sharding (分库分表) by separating high‑traffic modules (e.g., user data, permissions, points) into distinct databases, possibly further splitting large tables. This mirrors the approach used by large Chinese e‑commerce platforms, which partition data by region, buyer/seller, time, etc.