浅析电商、社区、游戏常用的 MySQL 架构

【原文】

一般、或者必须是这样遵从：MySQL 架构一定要结合业务来分析、设计、优化。

所以不管是那种架构、根据业务要求组合成符合需求的即是最好的、不能泛泛而谈，同时、也必须注意数据的安全（如ipsec,ssh，vpn传输）。

常见的架构都是进行业务切分、前端缓存、分库分表；

若是过亿的查询量，先从业务上拆分、将 bbs、web、blog 分成几个组、然后再做成一主多从、读写分离的方式；

而且、在设计表的时候、一般情况下、备库常充当起备份查询的作用。

至于、读写分离、在程序设计之初、读和写是通过不同的IP入口、或者定义类、或者用代理层，比如 MySQL-proxy。

大多数的场合、一般在应用层做读写分离、然后 MySQL 通过复制来实现、优点比较多，可控性非常好；

MySQL Replication、这个是王道、起码现在是、将来说不准哈，相比复制而言、Cluster 在生产环境核心环节基本不用、或者现在少用

因为、前期投入的硬件成本(相对于主从)较高、一般的小项目不会使用、Cluster的成本（大部分是维护成本）还是比较高的

但随着后续版本的发布、估计案例会越来越多、毕竟是非常好的 sharding-nothing 的方案

游戏中的：好友关系、排行榜、计数器、队列、cache 都很适合通过 Redis 来实现

至于 Redis 的事务功能、可以不必放太多的心思去关心

另外、Redis 相对 Memcached 而言、也稳定很多

电商中、生产环境也都是主从架构、然后用 DRBD + HA 做 Master 备份

主主不推荐、高可用还是推荐 DRBD 方案

DRBD 注意不设置自动启动、重启时候手动启动、脑裂的情况发生非常的少

不过、工作中基本不重启 DRBD、更不会重启服务器了、基本上没遇到脑裂的问题

DRBD 这个在做风险容灾的时候有一定作用、但不能起到扩展、结合 LVS相信也是一种 perfect方案

如：LVS+Keepalived 可以通过脚本剔除延迟慢或失效的从MySQL机器、

而且LVS在软件负载均衡器中是最强的、在后端节点超过10台以上的情况、估计只有LVS能胜任

规模大的公司（如Sina、taobao）

1、不用集群是说mysql自身的集群用的不多（目前看也是可以用的）

2、主从可以是多组，数个

3、每组都可能一主多从（业务数据的1/N）

4、3中每一组里的读或写 都可能是前端调度器的一个RS

5、调度器分发可以hash分组，可以根据用户ID切分数据，当然还有更高级的手段

提示：SINA开发经理承认，他们的SAE平台还是主从，甚至还有单点（靠监控和手工处理））

规模中等的公司（如CSDN）

1）mysql一主多从程序读写分离（甚至还没实现），多组。出问题直接手工或自动切从后在change master（脚本或程序实现）

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

3）或双主多从，前端结合读及写分别负载均衡

自建电商 MySQL 5G游戏

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。