请大牛帮我看看，我这样自己做一个缓存服务器前端是否合理？应该怎么样修改？

Question

现在有一个项目，按照不同的城市，数据保存在三个结构相同，但是数据内容不同的数据库里面。由于每个库里面都有一个表（暂时叫 A1,A2,A3）被访问查询非常频繁，所以现在考虑做一个缓存服务器。
开始的时候我也考虑过memcache等。。不过由于看到这些缓存方法都是按照key-->value方式存储，且不能支持sql查询。所以放弃。
最后考虑自己使用简单方法搭建一个缓存服务器，方法为：
1、专门购买一台服务器作为缓存服务器。
2、缓存服务器上设计一个站点，比如cache.abc.com这样的
3、站点内建立一个名为cache的webservice
4、每次站点启动的时候在gloabl.asax里面直接启动缓存初始化服务－－具体的就是把三个库内的A1,A2,A3缓存到该服务器内存中。
5、当用户对表A1,A2,A3更新的时候，同时通过webservice更新缓存的table
6、用户对表查询的时候只通过webservice在缓存中查找。
7、查询的时候，webservice通过获取相应的缓存数据，使用DataTable的筛选功能去完成查询，并且返回数据。
请问我这样的设计算不算是一个缓存服务器？或者说如果要实现我这样的功能有什么免费的软件之类的，非常感谢！
希望大家能给点具体的意见。

Answer 1

有必要搞个机器放Cache吗?
不是很懂,算学习了.
Cache放那里?还不是存在内存里.
A1,A2,A3数据量大吗

Answer 2

第5步，如果是这种结构，为何不直接把所有请求（查询和更新）都指向新服务器的web service，然后由web service决定向A1，A2还是A3取数据，再缓存

Answer 3

现在有个新问题，如果我在缓存服务器中整表缓存在一个table里面，貌似我每个针对table进行查询的时候都需要先copy一个表到临时表里面，如果并发请求数量大的话，貌似开销很吓人！！不知道大家都是怎么处理的？另外datatable好像不能直接分页吧？

Answer 4

你这样设计架构的话，就是一个问题了。一般而言，分层设计的原则就是将业务和数据分离，相互的操作通过统一的接口进行。比如，UI层要查询，都是通过调用Web Service来获得数据，那么，你返回给UI的是缓存还是数据库拿回来的表，就由Web Service来决定了。我的意思是，缓存机制就可以在Web Service里面切入。而按照你的描述，我的理解是，你的UI有多种途径来获得数据，你的想法是当UI更改了数据以后，再通知Web Service修改缓存。。我觉得这样的逻辑是比较混乱的。
说到缓存机制，基于你的架构，我看到的解决方法有2个：
1）如果A1,A2,A3加起来的数据量不大（例如几个G）可以考虑缓存到内容。
case 1：查询。当Web Service接收到查询请求时，先检查本机的缓存是否有记录。如有，就根据页码返回一页数据。如果没有，就根据城市决定是去A1/A2还是A3去取数据，取回来后缓存下来，再返回数据给终端case 2：修改。当Web Service接收到修改请求时，根据城市决定去哪张表修改。修改完后，将修改后的内容缓存在本机。以此类推。次缓存服务器需要设计一个机制什么时候清除缓存中的什么数据。一般的设计方法是，当某种情况（例如内存还剩500M，或者缓存容量大于多少G时）发生时，运行一个清除的操作（例如把操作次数小于100的记录从缓存中删除，然后再将剩余的操作计数清零）。。这些机制可以通过写一个服务进程（可靠），或者用ASP.NET的timer（不可靠，不一定保证执行）也行。根据你自己的需求2）如果A1+A2+A3很大，则可考虑用数据库来代替内存。也就是用一张总表来记录缓存。case 1：查询。当Web Service接收到查询请求时，先检查本机的总表是否有记录。如有，就根据页码返回一页数据。如果没有，就根据城市决定是去A1/A2还是A3去取数据，取回来后缓存下来，写入总表，再返回数据给终端case 2：修改。当Web Service接收到修改请求时，根据城市决定去哪张表修改。修改完后，将修改后的内容更新在总表。同样，也需要有一个机制去决定怎么删除总表中长期没被使用的数据，以保证缓存容量不会爆。

Answer 5

用lock啊，lock可以保证所有的线程不会冲突
lock (this) {
......
}
如果你想处理得好一点，避免“死锁”可以用Monitor对象
这是细节设计里的一项目。。基本上跟缓存机制是没有冲突的。。
如果你说用文件来做缓存的话。。我建议你直接用数据库吧。.NET里对数据库的优化之后。。其实差别不是太明显，特别是查询频率怎么密的应用。。数据库是首选

Answer 6

我考虑了一下用数据库来做缓存的方法，不过还是有个地方难以明了，如果用数据库来做缓存查询的话，应该是用一张缓存表了，可是我这个平台，查询频率相当的频繁，而且，查询条件组合非常多，这样的话，一个问题就是导致这个表可能会很大，另外，在缓存过期以及新加入缓存的时候，如果并发产生频繁的insert插入，以及更大量的select，死锁似乎难以避免？

Answer 7

死锁是完全可以避免的。现在的锁至少有2个层次，一个是程序的层次，.NET中有好几种保证同步访问资源的方法，你可以google一下相关的资料。另一个层次是数据库的层次，一般的查询，不需要锁，数据库引擎帮你解决。。涉及更新一个地方或者一次更新的，也并需要锁而通常涉及一次要更新几个表，或者有2个以上更新/插入的，一般要用事务去做你所担心的大部分的东西，.NET框架和数据库都帮你做了，所以我才会说如果用文件来缓存，还不如用数据库因为用文件，你自己需要考虑很多问题，而数据库的话，你只需要关心怎么处理你的数据，其他东西，引擎都帮你做了

Answer 8

这个我们现在就是全部交给数据库去做的，不过现在看来，死锁的状况还是比较多的，平均至少也有2次每天。非常烦人的。
看来还是需要衡量下那种方式更合适了，因为本意做缓存就是想分担数据库压力的不过不管怎么样，都要谢谢superplayboy了，给分