flashcache mysql_FlashCache 运维经验分享

经过一段测试后，被闪存的随机读写性能所折服，故在生产环境中就出现闪存的大量使用，而又随着数据量的不断增长，SSD、Fusion-IO单盘容量小的限制，如果增加容量以适应容量，那么就必须添加更多的盘，这样价格就会越来越多，这样就滋生了FlashCache技术的大量使用，具体的FlashCache实现方式，就不细谈了，可以参照官方文档(https://github.com/facebook/flashcache)这里指出运维中的几点，作为备忘

1、当SSD、SAS盘(或者SATA盘)联合组成FlashCache mapper盘时，我们必须把Mysql的随机读写与顺序读写分离(即把log直接放在后端的磁盘上，而不能放在mapper盘上)，这样性能会提高很多

2、开始时以为所有的业务都适合FlashCache

，因为他是write

back模式(目前我们只用这个模式)，且我们的写入非常的大很适合Flashcache，这样即能提高写，也能提高读，其实不然，就目前的运行来看，以下几点的模式其实不太适合(有的可能更适合CacheCade)

a：经常有count(*)、并且count(*)扫描的行数很多的模式，因为count(*)

经常会扫描很多冷数据会导致大量的换入换出操作；

b：写入的数据，与读取的数据完全不一样的模式即你写的数据不是你马上要读取的数据，譬如：当你已时间维度分表的端口，如：2010年的信息库，当你最新的数据写入时也会存入这个库(为了保证数据的完整性，不删除数据)，这样就导致你写入的是2011年的信息，读取的确是2010年的信息，而2010年的信息又很不集中，这样闪存的换入换出导致后端SAS盘的大压力，FlashCache

性能会表现的非常的差

总的来说，如果写入数据就是马上要读取的数据，或者你写入很小，而读取的热点数据很集中，那么这种肯定适合FlashCache

这种所谓的二级缓存技术，我还是很喜欢FlashCache的。