持久存储是网站的生命线，搜索引擎、缓存、应用服务器挂了不要紧，一致性也相对好解决，因为它们都从存储层拿数据。

我在大公司和小公司都做了几年，存储层的负载均衡和高可用方案，一直没有找到一个完美的可以分享传播的方案，同行们有什么建议呢？

持久存储主要指两方面：文件、数据库

文件可以用分布式文件系统解决，且通常没有修改的需求（改文件内容的时候，名字也改了），也不会像关系数据库那样有大量的过滤和排序，性能瓶颈不明显。所以，主流分布式文件系统似乎基本解决了这个问题，我在淘宝用过HDFS、TFS，在目前公司用的FastDFS和又拍云存储。

数据库的就比较麻烦了，阿里系IOE组合成本太高（对小公司来说），MySQL主从复制有延时问题（特别是Statements Based Replication），MySQL Cluster太吃内存且无成熟成功案例。我现在用的是MySQL/Galera，三节点互为master，但也遇到了较多问题：
1.任意一个主节点都可写入，mysql内置的一些特性（如autoincrement）不能使用，需要全局的序列号发生器
2.三节点互为master，在启动服务时总要指定一个复制源给它（它是集群第一台就不用指定了），这样三个节点的启动就必须有顺序，万一三台机器断电，我怎么知道哪台机器该是下一次启动的第一个节点？
3.在实际使用过程中也出现了异常，PHP的正常CURD操作居然导致复制失败，一个节点因此退出集群自立门户，而这时负载均衡器还不知道，仍将PHP的写请求平均分配到三个节点上，导致数据不一致

还有一个最省事的做法，买EMC、NetApp之类的高端存储设备，将数据库的运算和持久存储分离，相信高端存储的可靠性，承担运算的虚拟机很好做高可用。

请教一下各路高手：小公司如何做持久存储层的负载均衡和高可用呢？

评论太长，摘要一些在这里吧：

• 淘宝丁奇提到，打开基于行的复制（RBR），可以用淘宝开源出来（已在阿里集团生产环境投入使用）的Transfer实现多线程复制，对同一行记录保证复制顺序，可很好解决延时问题。淘宝Transfer地址： http://dinglin.iteye.com/blog/1672742 ，RBR和SBR优缺点： http://hi.baidu.com/byp_lm/item/01072...
• MySQL 5.5开始支持了半同步复制（Semi-sync Repication），可以保证集群内至少有一台Slave已经收到了Master的binlog并写入relay log才告诉应用写成功了，中文介绍： http://hcymysql.blog.51cto.com/522330...
• saemon的成功案例：使用mysql cluster支持几千万用户、几十G大小的数据库，商业应用，生产环境
• 数据库垂直切分也许能从设计上简化问题，假设一个B2C网站，spider抓取回来的资讯内容存在传统的主从mysql集群里（偶尔有点延时问题也不大）；商品数据存在三节点的galera集群里，因为写入时间和频率都容易预测，可以只拿出其中一个节点暴露给LB提供写服务，能保证无延时，唯一的写节点挂掉了让运营不要上传商品等待恢复就是了；消费者活动订单（三个月以内的）放到mysql cluster集群，数据规模小，取结果集的性能压力也不大，也能有超过3个节点任意写入，实时同步；非活动订单只读不写（至少不可能由消费者来写），放到传统master-slave, master-master都可以