大家已经看到很多关于Asp.Net缓存的文章了。所以我写的时候要改变一下思路，从缓冲写数据开始说起。缓冲写数据的意思是在数据需要更新时不马上把数据存到数据库，而是先缓冲一下，然后在适当的时机再写入到数据库中。

缓冲写数据可以避免在网站并发访问多的时候，数据库瞬间承受过大压力，而造成死锁或响应不及时的情况。

那么什么时候适合缓冲写呢？是不是所有情况都适用呢？缓冲写会导致数据在内存中或者web server硬盘或者第三方存储中驻留一段时间，在这段时间内如果从数据库中查询最新数据的话，会有遗漏。大多数事物都有两面性，我们需要学会趋利避害；换句话说在保证缓冲写不会导致用户感觉数据缺少的情况下，或者在使用适当措施不让用户感觉数据缺失的情况下就可以使用缓冲写。我有两个具体的实例来介绍如何使用缓冲写：

1. Pv(页面浏览量)统计，大多数网站都有这个功能，有些网站还专门做这个服务
　　网站每有一个页面被浏览时，就会需要给对应页面的Pv+1；这种情况下，如果直接更新到数据库中，访问量稍微大一些就会造成数据库压力过大的问题。

　　所以我们需要对Pv计数做缓冲，在单web server的情况下我们可以在内存中维护一个hashtable，然后用一个异步的线程去定时扫描这个hashtable，当点击数达到“一定数字”时更新到数据库。听上去很简单，不过也需要一个小技巧，上一句话中说的“一定数字”四个字不能是随便的一个数字，如果它是4，试想一下会出现什么情况，我们的所有Pv数都会是4的倍数，用户会怀疑我们是不是在Pv上造假了；我们没有造假却留下了造假的迹象！这个“一定数字”必须是一个素数，我们可以取7，也可以用13，如果我们的访问量很大也可以取23或31；这样就不会出现“造假的迹象”了。

2. 发送站内短消息
　　站内短消息也是一个比较通用的模块，他可以说是一种离线消息，并非im即时消息，所以我们可以利用这个业务特性，　　来对发消息做下缓冲。当有短消息发送时我们可以先将这个短消息放到硬盘文件中，然后很快的响应用户，在ui上告诉用户，你的消息已经发出去了，然后我们可以用另一个线程（或者做一个windows服务）去监视缓冲短消息的目录顺序的将短消息存储到数据库中。

以上两个场景都是比较经典的利用缓冲写的例子，在现实中需要我们去具体分析业务和某个业务是否会造成数据库压力来决定是否缓冲写，如果业务本身对数据库的压力就很小，那当然就没必要考虑了，反之如果业务压力较大我们就需要做一些工作避免缓冲写的问题并利用缓冲写。

请尊重作者的劳动，转载请保留链接 玉开的技术博客