标签:
上周做了个活动,有个计数器功能,压力测试的时候,读操作的QPS可以达到1万,但是写操作却只有800QPS。从代码角度分析原因,无非是读操作的时候是从缓存读取数据,没有命中才读数据库。而写操作是次都要向数据库里写入数据。所以当写操作的时候,对于数据库的访问便成为了瓶颈。
因为这次活动的QPS要求并没有达到上限,因此目前这个方案可以应付目前的活动,但是如果下次碰到更高要求的业务场景时候呢,有什么办法可以弥补?
于是我思索了下,参考数据库的主从分离的拆分方法,将每次的用户访问不直接写入数据库,而是定时把缓存的增量数据更新到数据库呢,这个方法有以下几个
优点:
理论上,可以大大提高QPS的压力值,因为减轻了数据库的访问频率和压力
缺点:
1.数据精度可能下降,如果缓存不命中或者丢失,会造成部分数据的流失(缓存不命中或丢失的情况)
2.代码量增大,需要使用多个缓存来保存数据,并且需要写关于定时更新的代码
3.此方法适合计数器之类的单一数据的保存,不适合大数据的保存,因为此方法是把数据先暂时保存在缓存中,再更新到数据库中,所以对大量数据的场景不适合
总结:此方法适合于保存计数器之类功能的小数据,且对数据精度要求不高,QPS巨大的业务场景使用。其它业务场景,可以考虑把数据库的写操作用异步的方式放入数据池之类方法实现。当然,还有个方法就是使用持久化缓存(ldb)来做,这样就不关数据库什么事了~
标签:
原文地址:http://www.cnblogs.com/xujanus/p/4330482.html