这几天在看MYSQL架构 的书
1、MySQL Replication
优势：部署简单，实施方便，维护也不复杂，是MySQL 天生就支持的功能。且主备机
之间切换方便，可以通过第三方软件或者自行编写简单的脚本即可自动完成主备切换。
劣势：如果Master 主机硬件故障且无法恢复，则可能造成部分未传送到Slave 端的
数据丢失；
2、MySQL Cluster
优势：可用性非常高，性能非常好。每一分数据至少在不同主机上面存在一份拷贝，且
冗余数据拷贝实时同步。
劣势：维护较为复杂，产品还比较新，存在部分bug，目前还不一定适用于比较核心的
线上系统。
关于第一种架构，相信应该是比较成熟了，读写分离，并且有Amoeba For MySQL 代理更好的实现Master-slave...
大部分都理解了。。
问题在于第二种，冒似在集群的时候对各个node的内存很消耗，
网上有人说在集群的整体性能上好象不如单节点的情况，
http://www.iteye.com/topic/183480
有人使用过这种架构吗？？ 能说说其性能到底好不好。。。
问题补充
我们在N年前测试过cluster，对网络的要求非常高，如果不是非常高的网络（如光纤内联的独立局域网，类似Oracle RAC要求），性能很一般，真的不如单机。cluster的好处就是解决了master单点的问题，如果仅仅追求性能，master-slave模式还是很主流的。
[url]http://bbs.chinaunix.net/viewthread.php?tid=1667934[/url]
我用过Master - slave模式,后来网上有讲关于豆X, FacebXXX,之流的架构(早期),也是用这种模式.
可能与我能力有关,还有数据库设计的问题,我的replication一直有delay,偶然还会整个死掉,最后只能用作一个backup,不能用作load balance.
另外,还有一些mysql proxy的东西,可以支持这种技术.
我觉得表设计,会严重影响数据库性能.有可能让一个应用就让mysql 慢得要死,如果光tune mysql,我觉得不能解决问题
第二个肯定有资源消耗啊， 每个cluster都备份一份， 相当于局域网广播， 还得磁盘读写 ， 有消耗， 但可以通过好的硬件抵消 ， 只要集群数不高， 问题不大， 可数量不高了， 还做什么集群啊。 矛盾， 很难和谐。
cluster 在大并发的写操作的性能很好，读的性能比较差。因为需要从不同数据节点读取数据来汇总，所以总时间=最慢节点的返回时间+汇总时间，这个比单台数据节点要慢。如果你知道需要查询的数据放在那个节点，mysql提供拉一套api直接去访问指定的数据节点，这样读取得速度会比较快。
因为cluster 中的数据节点和数据库节点都可以配置成多个，所以通过数量的优势可以大幅度的提高各种事务的吞吐率，从这个意义上看单条查询语句的执行差一点到不是什么大的问题。
楼主可否pm下是哪本书？