我的网站偶尔会有相当可预测的流量突发,吞吐量比平常增加100倍.例如,我们将在电视节目中亮相,我预计在演出后的一小时内,我将获得比正常情况多100倍的流量.

我的理解是MySQL(InnoDB)通常将我的数据保存在一堆不同的地方：

> RAM缓冲区
> commitlog
>二进制日志
>实际表格
>我的DB奴隶上面的所有地方

考虑到我在EC2节点上并且大多数东西都经过相同的网络管道(文件系统是网络连接的),这太“耐用”了.此外,驱动器速度很慢.数据价值不高,我宁愿少花几分钟的数据丢失,而不是在人群到来时很可能发生中断.

在这些流量突发期间,我希望只有在我负担得起的情况下才能完成所有这些I / O.我想尽可能多地保留在RAM中(与一小时内触摸的数据大小相比,我有相当大的RAM空间).如果缓冲区变得稀缺,或者I / O通道没有过载,那么我确定,我希望将事务转到commitlog或二进制日志以发送给slave.如果且仅当I / O通道没有过载时,我想回写实际的表.

换句话说,我希望MysqL / InnoDB使用“回写”缓存算法而不是“直写”缓存算法.我可以说服它这样做吗？

如果这是不可能的,我对一般的MysqL写性能优化技巧感兴趣.大多数文档都是关于优化读取性能的,但是当我收到大量用户时,我正在为所有用户创建帐户,因此这是一个繁重的工作量.