持久存储是网站的生命线，搜索引擎、缓存、应用服务器挂了不要紧，一致性也相对好解决，因为它们都从存储层拿数据。
我在大公司和小公司都做了几年，存储层的负载均衡和高可用方案，一直没有找到一个完美的可以分享传播的方案，同行们有什么建议呢？
持久存储主要指两方面：文件、数据库
文件可以用分布式文件系统解决，且通常没有修改的需求（改文件内容的时候，名字也改了），也不会像关系数据库那样有大量的过滤和排序，性能瓶颈不明显。所以，主流分布式文件系统似乎基本解决了这个问题，我在淘宝用过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都可以
Amazon RDS？
Google App Engine Datastore？
我们现在用的是mysql cluster。千万级的用户，几十个G的数据。既然说是“小”公司，应该差不多了吧。除非你和我理解的“小”的标准不同。
说太耗内存，现在内存才几个钱。能用硬件和金钱解决的问题，都不是什么大问题，省几个人月出来，什么都齐了。两台64G内存的服务器足以做一个2api+2data的replication高可用完整cluster了。
就我们目前的使用来看，还是很健壮的，没有乱七八糟的问题。当然了，由于当前缺少最佳实践，所以很多东西都要自己摸索。
从楼主的描述看来，这些相关方案已经很熟悉了～
说一下自己的一些看法。Gelara包括Xtradb Cluster, 目前成熟度还没有到生产环境可以使用。可以再观察一段。
MySQL Cluster可以设置仅索引在内存里，当然还是挺好内存的，而且内存一旦不足，集群就出问题，这点比较伤。
主从同步是现在比较常见的做法。如果你们会考虑将Master改成row based binlog，可以考虑Transfer这个方案（http://dinglin.iteye.com/blog/1672742）。只要主从的机器配置一样，从库不会延迟。