MySQL生产环境下有哪些常见架构

MySQL架构必须结合前端业务进行设计和优化，所以无论采用哪种架构，最好都要结合业务需求来满足，不能一概而论，同时要注意数据安全（如ipsec、ssh、vpn传输）。

(二）常见的MySQL架构

MySQL的常见架构是业务分割、前端缓存、分库分表。如果查询量超过1亿，就会从业务、bbs、web、blog中拆成几组，然后做成主多从少、读写分离。

而且，在表的设计上，一般情况下，备份库往往充当备份查询，至于读写分离，在程序设计之初，读写是通过不同的IP入口，这是一个思路，或者定义类，或者用代理层，比如MySQL-proxy最多的场合，一般在应用层做读写分离，然后MySQL通过复制来实现，优点多，可控性非常好。

(三）常见的游戏架构

游戏中的好友关系、排行榜、计数器、队列、缓存等都很适合通过Redis来实现，不用在Redis的事务能力上花太多的心思。此外，Redis比Memcached要稳定得多。

(四) 电子商务的常见架构

在电子商务方面：生产环境也是主从架构，然后用DRBD+HA做主备，主备不推荐，高可用还是推荐DRBD方案，DRBD注意不要设置为自动启动，手动重启，脑裂的情况很少。但在工作中，基本不重启DRBD，更不重启服务器，基本没有遇到脑裂的问题，DRBD这种在灾备方面有风险，但不能起到扩容的作用，结合LVS相信是一个完美的解决方案，比如说。LVS+Keepalived可以通过脚本消除来自MySQL机器的缓慢延迟或故障，而且LVS是软件负载均衡器中最强的，在后端节点超过10个的情况下，估计只有LVS可以胜任了

(五）公司的规模（如新浪、淘宝）

1、不用集群是说mysql自己的集群用的不多（目前看还可以用）。

2、主站和从站可以是多个组，若干个

3、每个组可以是一个主站和多个从站（1/N的业务数据）。

4、3每个组在读或写时可能是一个前端调度器RS

5. 调度器的分布可以是哈希分组，数据可以根据用户ID进行切分，当然还有更高级的手段

提示：新浪开发经理承认，他们的SAE平台还是主从式的，甚至还有单点式的（通过监控和人工处理））。

(六）中型公司（如CSDN）

1、mysql一个主程序和多个从程序读写分离（甚至还没有实现），多组。出现问题后直接手动或自动切入更改主站（用脚本或程序来实现）

2、drbd+ha实现高可用（也是双主多从，自动切换M，正常备份M无法提供服务）。

3、或双主多从，前端结合，分别实现读写负载均衡