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