关于缓存和数据库结合的应用——写操作的瓶颈
2015-03-11 17:25
218 查看
上周做了个活动,有个计数器功能,压力测试的时候,读操作的QPS可以达到1万,但是写操作却只有800QPS。从代码角度分析原因,无非是读操作的时候是从缓存读取数据,没有命中才读数据库。而写操作是次都要向数据库里写入数据。所以当写操作的时候,对于数据库的访问便成为了瓶颈。
因为这次活动的QPS要求并没有达到上限,因此目前这个方案可以应付目前的活动,但是如果下次碰到更高要求的业务场景时候呢,有什么办法可以弥补?
于是我思索了下,参考数据库的主从分离的拆分方法,将每次的用户访问不直接写入数据库,而是定时把缓存的增量数据更新到数据库呢,这个方法有以下几个
优点:
理论上,可以大大提高QPS的压力值,因为减轻了数据库的访问频率和压力
缺点:
1.数据精度可能下降,如果缓存不命中或者丢失,会造成部分数据的流失(缓存不命中或丢失的情况)
2.代码量增大,需要使用多个缓存来保存数据,并且需要写关于定时更新的代码
3.此方法适合计数器之类的单一数据的保存,不适合大数据的保存,因为此方法是把数据先暂时保存在缓存中,再更新到数据库中,所以对大量数据的场景不适合
总结:此方法适合于保存计数器之类功能的小数据,且对数据精度要求不高,QPS巨大的业务场景使用。其它业务场景,可以考虑把数据库的写操作用异步的方式放入数据池之类方法实现。当然,还有个方法就是使用持久化缓存(ldb)来做,这样就不关数据库什么事了~
因为这次活动的QPS要求并没有达到上限,因此目前这个方案可以应付目前的活动,但是如果下次碰到更高要求的业务场景时候呢,有什么办法可以弥补?
于是我思索了下,参考数据库的主从分离的拆分方法,将每次的用户访问不直接写入数据库,而是定时把缓存的增量数据更新到数据库呢,这个方法有以下几个
优点:
理论上,可以大大提高QPS的压力值,因为减轻了数据库的访问频率和压力
缺点:
1.数据精度可能下降,如果缓存不命中或者丢失,会造成部分数据的流失(缓存不命中或丢失的情况)
2.代码量增大,需要使用多个缓存来保存数据,并且需要写关于定时更新的代码
3.此方法适合计数器之类的单一数据的保存,不适合大数据的保存,因为此方法是把数据先暂时保存在缓存中,再更新到数据库中,所以对大量数据的场景不适合
总结:此方法适合于保存计数器之类功能的小数据,且对数据精度要求不高,QPS巨大的业务场景使用。其它业务场景,可以考虑把数据库的写操作用异步的方式放入数据池之类方法实现。当然,还有个方法就是使用持久化缓存(ldb)来做,这样就不关数据库什么事了~
相关文章推荐
- 关于c#数据库的简单应用-datagriview连接数据库及更相关操作
- 关于学生管理系统的简单操作(数据库应用)
- TimesTen 应用层数据库缓存学习:10. 监控缓存组的autorefresh操作
- JDBC之关于数据库操作回滚研究(JDBC之四)
- 结合存储过程开发数据库应用程
- 关于“我的藏书阁:.NET/数据库应用开发”的几点看法。
- JAVA操作数据库方式与设计模式应用
- DhtmlxGrid组件应用---结合Ajax实现对表格数据的无刷新操作
- FLASH结合ASP进行对数据库的操作
- JAVA中数据库操作的各种方式与设计模式的应用
- JAVA操作数据库方式与设计模式应用--数据库连接池技术
- javascript 中关于select 的应用和相关操作
- Relaxlife.net数据库操作的应用,数据库操作/表操作/表结构操作/索引(Index),主键操作/字段值操作(原版)
- JAVA中数据库操作的各种方式与设计模式的应用
- JAVA中数据库操作的各种方式与设计模式的应用
- 关于NTKO_office的操作(从数据库中提取数据,写入到NTKO_office_Word中)
- 关于O/R Mapping,在很久以前我就考虑过,这才是数据库的终极应用!
- java 数据库基本操作及ResultSet高级应用
- 关于数据库持久层操作 的开源项目
- JAVA操作数据库方式与设计模式应用