一种关于缓存数据什么时候更新的解决思路 初遇 Asp.net MVC 数据库依赖缓存那些事儿 初遇 Asp.net MVC 数据库依赖缓存那些事儿

为何写？

和你们同样，我有天天逛逛博客园的习惯，今天在博客园看到了“一只攻城狮”写的《初遇 Asp.net MVC 数据库依赖缓存那些事儿》。该朋友利用.Net的SqlCacheDependency缓存依赖，解决了缓存数据什么时候更新的问题。

可是该思路具备必定的局限性，如：要利用数据库的存储过程，来通知客户端更新缓存，这就离不开微软的Sql Server那套体制，若是利用别的数据库，恐怕就没有那么好实现了。且存储过程须要在数据库中执行，不利于将业务向服务程序转移。

 

程序员比较忌讳造轮子，相信程序员写博客也是如此，所以，我仍是想站在巨人的肩膀上，借用“一只攻城狮”在《初遇 Asp.net MVC 数据库依赖缓存那些事儿》写的背景，来引出我想说的内容，若是“一只攻城狮”以为有何不妥之处，请联系我作下架处理。

 

 

--------------------------------------------------------------引用开始-----------------------------------------------

最近作一个很是简单的功能，就是使用ajax请求的方式从服务端请求一段下拉表的数据。

　　之前也有作过这个功能，只不过此次作这个功能的时候冒出了一个想法：

　　我请求的这段数据它是一段相对比较固定的数据，也就是说它不怎么改变，也许几个月才会改变一次。因为这种数据的变化周期很长，因此之前作这种功能的时候，会使用缓存进行优化，能够直接从缓存中读取数据，避免每一次接收了ajax请求后都要向数据库要数据，减小服务器与数据库之间的交互，减轻数据库服务器的压力。可是问题来了，数据的变化周期再长终究是要变化的，当数据库中的数据变化的时候你就要对旧有的缓存内容进行移除（remove）操做。

                 .......................{中间省略XXX字，中间做者大体讲诉了设置了缓存按期过时}.................................

　　缓存按期过时有一个坏处：在还没到达过时时间的这段时间里，请求的数据依然是原来的缓存中数据，若是数据库数据在这期间进行了更新，那么缓存数据和数据库中的数据并不一致。

　　其中设置的绝对过时时间点要根据实际的数据刷新的可容忍度来进行设定，而刚好在个人这个应用场景中的可容忍度最不能把握，它要求的是 当数据库中的数据改变之后，缓存中对应的数据在下一次请求结束后必定要立刻跟着改变，固然你也能够把过时时间尽量的调小，调到一秒。固然，这样的话仍是要频繁的向数据库进行请求，那不是背离了咱们本来使用缓存优化的目的了吗？

 

　　因此如今的问题是：有没有一种方法能让数据库和服务器程序创建一种联系，这种联系比如是一种“心灵感应”，当数据库表中的数据发生变化的时候，立刻就能让服务器中的对应的缓存项“感应”到这个变化，从而让原来的缓存项失效呢？

 

--------------------------------------------------------------引用结束------------------------------------------

个人作法

　　综上所述，客户端（或浏览器）缓存数据的痛点在于，数据什么时候更新？如何让客户端知道，服务端数据变了？

　　分四步走。

第一步，初次请求数据时

客户端在初次请求数据时，会把客户端想要的数据连同数据的版本号（数据上次的更新时间）一块儿发送给客户端，数据版本号时存在Redis数据库中的，咱们知道，Redis中的数据存储在内存中且读取数据比关系型数据库快的不是一点点。

客户端收到数据后，会把收到的数据和数据版本号缓存下来。

 

第二步，当数据库数据更新时

当数据库数据更新时，服务端在更新关系型数据库的同时会把Redis的数据版本号更新为当前时间。

第三步，客户端用数据时：

客户端须要使用缓存数据时，会向服务端索要数据版本号（也就是数据上次的更新时间），若是该数据版本号与客户端缓存的数据版本号一致，那么，客户端缓存的数据时安全可用的，若是不一致，那么说明数据已经更新了，客户端把新的版本号缓存下来并从新获取。那么，执行第四步。

第四步，从新获取数据

从新获取数据时，就不用携带版本号了，客户端在第三步时已经获取并缓存下来了。

 

利弊

好处：

1.当请求的数据量交大可是变更又不频繁时，客户端与服务端没必要频繁地交换大型数据，只需交换数据版本号便可。

2.数据版本号存储在Redis数据库中，不只读取速度快，并且数据量小，因此响应快，交换成本低。

3.该思路通用性强，适合任何类型的关系型数据库与Nosql数据库搭配使用。

弊端：

1.客户端在每次使用数据前，都要与服务端进行一次通信进行校验数据版本号。

 

好与坏不是绝对的，适合的才是最好的，以上是个人解决思路，你们有不一样观点，欢迎留言讨论，也感谢“一只攻城狮”提供讨论背景！