Master Web Architecture: Load Balancing, Static/Dynamic Separation, and MySQL Replication Explained

21. How do Nginx and Tomcat transfer data?

Answer: Nginx acts as a reverse proxy for Tomcat. Static resources (JS, CSS, images) are served directly by Nginx, while dynamic requests (e.g., .jsp, /api) are forwarded via proxy_pass to Tomcat. Tomcat processes the request and returns the response to Nginx, which then sends it to the client, achieving static‑dynamic separation and reducing Tomcat load.

22. Why separate static and dynamic content?

Answer: Static content (unchanging files) is served directly by Nginx with caching, avoiding unnecessary backend calls. Dynamic requests are routed to the application server. This division dramatically lowers backend pressure and improves response speed, especially under high concurrency.

23. Common Nginx modules

Answer: Core modules include http_ssl_module (HTTPS), http_proxy_module (reverse proxy), http_upstream_module (backend definition), and http_rewrite_module (URL rewriting). Enable only needed modules to keep the gateway lightweight.

24. Typical load‑balancing algorithms in Nginx

Answer: Default round‑robin ( rr); weighted round‑robin ( wrr) for server‑specific weights; ip_hash for session persistence; least_conn for directing traffic to the least‑connected node. Choose based on service characteristics.

25. Main features of Nginx

Answer: Asynchronous non‑blocking architecture, low memory usage, high stability, concise configuration, built‑in health checks, hot upgrades without downtime, and minimal network dependencies make Nginx ideal for reverse proxy and load‑balancing entry points.

26. Parameter optimizations for Nginx

Answer: Optimize security, performance, and availability: hide version info, set client_max_body_size, use limit_req for rate limiting, enable gzip compression, configure anti‑hotlinking, enable HTTPS, and use location blocks for static‑dynamic separation based on real‑world benchmark data.

27. Matching priority of the location module

Answer: Exact match (=) has highest priority, followed by prefix match (^~), then regular expressions (~ or ~* ) in file order, and finally ordinary prefix matches. Matching stops at the first successful rule.

28. Principle of MySQL master‑slave replication

Answer: Replication is asynchronous and driven by the binary log ( binlog). The slave’s I/O thread connects to the master, reads the binlog position, and the SQL thread replays the relay log to apply changes.

29. Common causes of master‑slave desynchronization

Answer: Network latency or interruption, binlog transmission failures, version incompatibility, mismatched max_allowed_packet, large transactions failing on the slave, SQL thread errors (e.g., duplicate keys), or master crashes. Diagnose with SHOW SLAVE STATUS.

30. What is read/write separation?

Answer: Write operations (INSERT/UPDATE/DELETE) go to the master, while reads (SELECT) are distributed to one or more slaves. This improves read throughput but may introduce lag, requiring special handling for strong consistency scenarios.

31. How to fail over when the master crashes?

Answer: Check SHOW SLAVE STATUS on all slaves, compare Exec_Master_Log_Pos, promote the most up‑to‑date slave, run STOP SLAVE, enable log_bin, restart MySQL, execute RESET MASTER, and point remaining slaves to the new master with CHANGE MASTER TO. Production environments should use automation tools such as MHA or Orchestrator.

32. Four ACID properties and rollback

Answer: Transactions guarantee Atomicity, Consistency, Isolation, and Durability. On error, the undo log rolls back changes, restoring the state before the transaction began.

33. MySQL backup methods

Answer: Logical backup with mysqldump (suitable for small databases), physical backup with xtrabackup (hot backup), binary‑log incremental backup, and cold backup of slaves in a master‑slave setup. Choose based on RPO/RTO requirements and verify restores regularly.

34. Relationship between MySQL and MariaDB

Answer: MariaDB is a fork created by the original MySQL developers after Oracle’s acquisition. It remains fully compatible with MySQL protocols and APIs while adding new storage engines (e.g., Aria, MyRocks) and features.

35. Common storage engines and differences

Answer: MyISAM – no transactions, fast reads; InnoDB – supports transactions, row‑level locking, foreign keys; Memory – stores data in RAM for temporary tables or caching. InnoDB is the default engine for balanced safety and performance.

36. Relational vs. NoSQL databases

Answer: MySQL is relational, using fixed schemas, SQL, and ACID transactions. NoSQL databases (e.g., Redis, MongoDB) use flexible key‑value or document models without fixed schemas, offering high scalability for specific workloads.

37. Database lock mechanisms

Answer: In MySQL InnoDB, row locks, gap locks, and next‑key locks are used together with MVCC to reduce contention. Exclusive locks protect writes; repeatable‑read snapshots avoid locking for reads. Proper indexing and transaction sizing minimize lock wait and deadlocks.

38. High‑availability load‑balancing cluster

Answer: A typical setup combines LVS (layer‑4 load balancer) with Keepalived for VRRP‑based failover. Keepalived moves a virtual IP ( VIP) to a backup node when the primary fails, ensuring seamless traffic continuity.

39. What is DNS and how does it work?

Answer: DNS translates domain names to IP addresses. Resolution steps: check hosts, local cache, then query recursive DNS servers, which may iterate from root → TLD → authoritative servers. Smart DNS selects the optimal CDN node based on client IP and ISP.

40. How to add a DNS resolver

Answer: For a temporary change, edit /etc/resolv.conf and add a nameserver line. For a permanent change, modify the network interface configuration (e.g., /etc/sysconfig/network‑scripts/ifcfg‑eth0) or use nmcli. In containers or cloud environments, ensure the DNS settings are not overwritten by the platform.

Conclusion

Understanding service architecture is just the beginning; modern operations have moved into the cloud‑native era where containers, Kubernetes, and automated deployments dominate.