asp.net Cache缓存问题

Question

System.Runtime.Cache
看下这个吧，frame4.0以上开始支持

Answer 1

这个WebService所在的服务器压力就很大你测试过到底是那个部分压力大嘛请求？通讯？业务处理？

Answer 2

按照你的这种架构思路，几乎不太可能使用缓存。你干脆就把数据库整个弄成内存数据库吧（就好像那些任性的、又能够烧钱的互联网公司一样）。原因是，设计一个业务服务SOA系统必须是“粗粒度”的，要求心灵尽量少、速度快，对客户端支持到“刚刚够”就行了。如果你是想把所有东西“增删改查”给开放，那么你心目中要“主动失控”的东西比一个业务服务SOA系统高100倍都不止。这时候就不太好说如何缓存的问题，你只能整体地升级你的硬件。比如说你去订票点买火车票，那么售票系统只给开放一个非常简单的购票输入界面和简单的付款、确认流程。它不给你开放什么后台数据库80个表的“增删改查”至少320个接口这类“又杂又慢又危险”的功能。那么它就能把精力用在它提供的那4、5个功能接口上，这时候才能考虑到缓存问题。所以在系统要提升档次而进行研究改造方案时，你看一个设计师，如果他从业务出发、而手底下立刻可以实现业务功能接口，你就能信他。如果他满口都是底层“我把数据库表给你们开放吧”，那么你就不能信他真的能改造好这个系统。

Answer 3

要求心灵尽量少、速度快，对客户端支持到“刚刚够”就行了 -->  要求信令尽量少、速度快，对客户端支持到“刚刚够”就行了从你的描述看，你们系统还是在做OA的局域网小软件的思路上。所以不要轻易趟这趟“浑水”，不要管这种系统的升级工作。

Answer 4

你理解的这个，不叫做缓存。这叫做“数据库复制”。例如一个Master数据库在某一个IDC机房，它（某些数据）修改时自动复制异地IDC机房的其它多个数据库中。基本上最近10年出来的正规的、流行的数据库系统都有这个功能。可能你以前没有使用过。

Answer 5

按照你的这种架构思路，几乎不太可能使用缓存。你干脆就把数据库整个弄成内存数据库吧（就好像那些任性的、又能够烧钱的互联网公司一样）。原因是，设计一个业务服务SOA系统必须是“粗粒度”的，要求心灵尽量少、速度快，对客户端支持到“刚刚够”就行了。如果你是想把所有东西“增删改查”给开放，那么你心目中要“主动失控”的东西比一个业务服务SOA系统高100倍都不止。这时候就不太好说如何缓存的问题，你只能整体地升级你的硬件。比如说你去订票点买火车票，那么售票系统只给开放一个非常简单的购票输入界面和简单的付款、确认流程。它不给你开放什么后台数据库80个表的“增删改查”至少320个接口这类“又杂又慢又危险”的功能。那么它就能把精力用在它提供的那4、5个功能接口上，这时候才能考虑到缓存问题。所以在系统要提升档次而进行研究改造方案时，你看一个设计师，如果他从业务出发、而手底下立刻可以实现业务功能接口，你就能信他。如果他满口都是底层“我把数据库表给你们开放吧”，那么你就不能信他真的能改造好这个系统。
那像我说的这种情况，每个公司都有自己的Web应用服务器，数据库在上海服务器上，最好的部署方式是哪种？ 还是说把上海数据库公开到Internet，每个分公司的数据连接指向这个外网的IP数据库？ 还是我现在这种发布WebService到外网。或者还有更好的方法。

Answer 6

你的思路有问题，你要明白缓存的意义是干嘛，是为了不经常变动的数据查询优化避免直接访问db从内存中直接读取提高性能。所以客户端数据更新操作是不可能直接去更新缓存的。缓存中的数据是根据db更新的。所以你完全可以在每台缓存服务器上安装quartz.net 服务 定时按周期去更新缓存。 当然为了保证数据一致性 建议先把数据库数据读到一台服务器A 然后其他缓存服务器 去服务器A拿数据。这样就可以保证数据完整性和一致性了