坏处很明显就是asp.net的cache和session会变为多份难以控制，例如cache更新后一时是新数据一时是旧数据，可能是因为有多份吧。这个问题该怎么解决？
5 个解决方案
#1
顶一顶！！。。。。。。。。。。。。。。
#2
在asp.net 这类web服务机制下，Session集合本来其实就不应该使用，因为原本来说Session集合的数据就是经常丢失的。而Cache本来其技术就在于“缓存依赖项技术”，也就是说，那些懂得让缓存单元自动因为依赖项的改变而自动清理的，才是正的缓存，因为它的重点在于清除脏数据的机制；而那些只是简单认为把数据丢到内存里的保存的，根本不是缓存，而是根本不考虑清除脏数据。
因此在“园”之下，如果你当初不是使用了上述编程设计技术，那么就更不应该用这么高级的技术了。
在“园”之下，其实可以配置web服务器（例如iis）使得其将固定的sessionID，总是解析到固定的内部服务器ip上。这样可以缓解一些（原本就没有正确使用sessiion、cache造成的）问题。但是这样其实也就已定义一下丧失了web应用服务集群的特性。
web应用服务集群，最基本地你可以看到的是，你有更多的CPU可以并行工作了。比如说原来有4核CPU，通过水平扩展服务器，你可以把CPU加到40核。而当应用高峰过了，你又可以恢复到4核服务的水平。这不需要你去买一个上百万的服务器然后一直放着，你只要在高峰的那几天按照每天几毛钱的费用去水平扩展服务器就行了。因此这是一个真正有技术含量的“系统策略”，不是仅仅考虑编程小伎俩，如果不理解应用而仅仅从技术出发，那么只会看到麻烦而看不到需求。
再说开一些，有些人盲目地以为凡是“负载均衡”就是指web网站应用服务器集群化，这是错误的。实际上真正后端的业务处理，需要的是更高级的有关（异步）任务分发、任务处理、分布式存储等。比如说一个游戏系统有100台服务器，有10万人分别连到这100台服务器上，假设某个用户要跟另外一个用户“说一句话”，那么消息要跨服务器（甚至跨集群、跨IDC机房）直接发给对方所在的服务器上，最终直接发给对方的终端。这种集群消息和任务分发，才是真正的处理大量任务的理论原型。而web网站应用“园”只是非常简单的概念，只能处理（浏览器之类的）客户端单向查询功能而已。
因此在“园”之下，如果你当初不是使用了上述编程设计技术，那么就更不应该用这么高级的技术了。
在“园”之下，其实可以配置web服务器（例如iis）使得其将固定的sessionID，总是解析到固定的内部服务器ip上。这样可以缓解一些（原本就没有正确使用sessiion、cache造成的）问题。但是这样其实也就已定义一下丧失了web应用服务集群的特性。
web应用服务集群，最基本地你可以看到的是，你有更多的CPU可以并行工作了。比如说原来有4核CPU，通过水平扩展服务器，你可以把CPU加到40核。而当应用高峰过了，你又可以恢复到4核服务的水平。这不需要你去买一个上百万的服务器然后一直放着，你只要在高峰的那几天按照每天几毛钱的费用去水平扩展服务器就行了。因此这是一个真正有技术含量的“系统策略”，不是仅仅考虑编程小伎俩，如果不理解应用而仅仅从技术出发，那么只会看到麻烦而看不到需求。
再说开一些，有些人盲目地以为凡是“负载均衡”就是指web网站应用服务器集群化，这是错误的。实际上真正后端的业务处理，需要的是更高级的有关（异步）任务分发、任务处理、分布式存储等。比如说一个游戏系统有100台服务器，有10万人分别连到这100台服务器上，假设某个用户要跟另外一个用户“说一句话”，那么消息要跨服务器（甚至跨集群、跨IDC机房）直接发给对方所在的服务器上，最终直接发给对方的终端。这种集群消息和任务分发，才是真正的处理大量任务的理论原型。而web网站应用“园”只是非常简单的概念，只能处理（浏览器之类的）客户端单向查询功能而已。
#3
你只要在高峰的那几天按照每天几毛钱的费用去水平扩展 --> 你只要在高峰的那几天按照每天几十钱的费用去水平扩展
web园只是解决web网页服务器的负载均衡问题，主要用于网页。但是其实它不是能解决大公司核心业务的分布式任务处理的。
我们遇到一个用户，它的主要矛盾——系统经常奔溃——的问题在于它的系统的几千个繁忙的客户端系统采用了“每隔7秒钟轮训一遍服务器”的策略。因此它在当地找了最好的软件公司开发，系统上线后30分钟不到就垮掉了。那么这个系统崩溃的根本原因就是因为采用了web架构。而当地的软件公司的工程师，大概除了做网页就没有做过其它类型的通讯系统，因此他们不知道如何把消息推给这几千个客户端（每一个客户端要的信息都不完全一样），而只会让这些客户端去轮询服务器。用户将来终端数越发展，越容易垮掉，只有改为“服务推”的方式而不是像网页那样“客户端刷新”的方式，才是处理大型的核心业务的架构。
web园只是解决web网页服务器的负载均衡问题，主要用于网页。但是其实它不是能解决大公司核心业务的分布式任务处理的。
我们遇到一个用户，它的主要矛盾——系统经常奔溃——的问题在于它的系统的几千个繁忙的客户端系统采用了“每隔7秒钟轮训一遍服务器”的策略。因此它在当地找了最好的软件公司开发，系统上线后30分钟不到就垮掉了。那么这个系统崩溃的根本原因就是因为采用了web架构。而当地的软件公司的工程师，大概除了做网页就没有做过其它类型的通讯系统，因此他们不知道如何把消息推给这几千个客户端（每一个客户端要的信息都不完全一样），而只会让这些客户端去轮询服务器。用户将来终端数越发展，越容易垮掉，只有改为“服务推”的方式而不是像网页那样“客户端刷新”的方式，才是处理大型的核心业务的架构。
#4
当你有多个服务器的时候，那么显然，每一个服务器的网站进程都可以仅仅处理它自己的Cache、它本地的日志，甚至是查询它本地的数据库同步快照。那么用10台4核的服务器组成的集群，可能也会在性能一台40核的服务器。
另外假设你有10台服务器，假设突然坏了2台，“无所谓”，再扩展两台或者把它们修复后重启就行了。更新服务器软件也可以“先更新5台机器，重启之后，再更另外5台机器”。
等等等等。
所以设计服务系统有两种人，一种人就是只能用单机、多个应用服务器给他则也是荒废着、搞备份而已，另外一种人就是坚持至少要有2或者3台服务器才敢提供服务。这两种人能提供的服务的水平，是不同的。
另外假设你有10台服务器，假设突然坏了2台，“无所谓”，再扩展两台或者把它们修复后重启就行了。更新服务器软件也可以“先更新5台机器，重启之后，再更另外5台机器”。
等等等等。
所以设计服务系统有两种人，一种人就是只能用单机、多个应用服务器给他则也是荒废着、搞备份而已，另外一种人就是坚持至少要有2或者3台服务器才敢提供服务。这两种人能提供的服务的水平，是不同的。
#5
大师，再请教一下，希望您能直接回答，不要扯太远。。
假设我就一台服务器，一个iis站点，cpu内存也是固定的配置，我应该给他分配几个园更合理？
假设我就一台服务器，一个iis站点，cpu内存也是固定的配置，我应该给他分配几个园更合理？
#1
顶一顶！！。。。。。。。。。。。。。。
#2
在asp.net 这类web服务机制下，Session集合本来其实就不应该使用，因为原本来说Session集合的数据就是经常丢失的。而Cache本来其技术就在于“缓存依赖项技术”，也就是说，那些懂得让缓存单元自动因为依赖项的改变而自动清理的，才是正的缓存，因为它的重点在于清除脏数据的机制；而那些只是简单认为把数据丢到内存里的保存的，根本不是缓存，而是根本不考虑清除脏数据。
因此在“园”之下，如果你当初不是使用了上述编程设计技术，那么就更不应该用这么高级的技术了。
在“园”之下，其实可以配置web服务器（例如iis）使得其将固定的sessionID，总是解析到固定的内部服务器ip上。这样可以缓解一些（原本就没有正确使用sessiion、cache造成的）问题。但是这样其实也就已定义一下丧失了web应用服务集群的特性。
web应用服务集群，最基本地你可以看到的是，你有更多的CPU可以并行工作了。比如说原来有4核CPU，通过水平扩展服务器，你可以把CPU加到40核。而当应用高峰过了，你又可以恢复到4核服务的水平。这不需要你去买一个上百万的服务器然后一直放着，你只要在高峰的那几天按照每天几毛钱的费用去水平扩展服务器就行了。因此这是一个真正有技术含量的“系统策略”，不是仅仅考虑编程小伎俩，如果不理解应用而仅仅从技术出发，那么只会看到麻烦而看不到需求。
再说开一些，有些人盲目地以为凡是“负载均衡”就是指web网站应用服务器集群化，这是错误的。实际上真正后端的业务处理，需要的是更高级的有关（异步）任务分发、任务处理、分布式存储等。比如说一个游戏系统有100台服务器，有10万人分别连到这100台服务器上，假设某个用户要跟另外一个用户“说一句话”，那么消息要跨服务器（甚至跨集群、跨IDC机房）直接发给对方所在的服务器上，最终直接发给对方的终端。这种集群消息和任务分发，才是真正的处理大量任务的理论原型。而web网站应用“园”只是非常简单的概念，只能处理（浏览器之类的）客户端单向查询功能而已。
因此在“园”之下，如果你当初不是使用了上述编程设计技术，那么就更不应该用这么高级的技术了。
在“园”之下，其实可以配置web服务器（例如iis）使得其将固定的sessionID，总是解析到固定的内部服务器ip上。这样可以缓解一些（原本就没有正确使用sessiion、cache造成的）问题。但是这样其实也就已定义一下丧失了web应用服务集群的特性。
web应用服务集群，最基本地你可以看到的是，你有更多的CPU可以并行工作了。比如说原来有4核CPU，通过水平扩展服务器，你可以把CPU加到40核。而当应用高峰过了，你又可以恢复到4核服务的水平。这不需要你去买一个上百万的服务器然后一直放着，你只要在高峰的那几天按照每天几毛钱的费用去水平扩展服务器就行了。因此这是一个真正有技术含量的“系统策略”，不是仅仅考虑编程小伎俩，如果不理解应用而仅仅从技术出发，那么只会看到麻烦而看不到需求。
再说开一些，有些人盲目地以为凡是“负载均衡”就是指web网站应用服务器集群化，这是错误的。实际上真正后端的业务处理，需要的是更高级的有关（异步）任务分发、任务处理、分布式存储等。比如说一个游戏系统有100台服务器，有10万人分别连到这100台服务器上，假设某个用户要跟另外一个用户“说一句话”，那么消息要跨服务器（甚至跨集群、跨IDC机房）直接发给对方所在的服务器上，最终直接发给对方的终端。这种集群消息和任务分发，才是真正的处理大量任务的理论原型。而web网站应用“园”只是非常简单的概念，只能处理（浏览器之类的）客户端单向查询功能而已。
#3
你只要在高峰的那几天按照每天几毛钱的费用去水平扩展 --> 你只要在高峰的那几天按照每天几十钱的费用去水平扩展
web园只是解决web网页服务器的负载均衡问题，主要用于网页。但是其实它不是能解决大公司核心业务的分布式任务处理的。
我们遇到一个用户，它的主要矛盾——系统经常奔溃——的问题在于它的系统的几千个繁忙的客户端系统采用了“每隔7秒钟轮训一遍服务器”的策略。因此它在当地找了最好的软件公司开发，系统上线后30分钟不到就垮掉了。那么这个系统崩溃的根本原因就是因为采用了web架构。而当地的软件公司的工程师，大概除了做网页就没有做过其它类型的通讯系统，因此他们不知道如何把消息推给这几千个客户端（每一个客户端要的信息都不完全一样），而只会让这些客户端去轮询服务器。用户将来终端数越发展，越容易垮掉，只有改为“服务推”的方式而不是像网页那样“客户端刷新”的方式，才是处理大型的核心业务的架构。
web园只是解决web网页服务器的负载均衡问题，主要用于网页。但是其实它不是能解决大公司核心业务的分布式任务处理的。
我们遇到一个用户，它的主要矛盾——系统经常奔溃——的问题在于它的系统的几千个繁忙的客户端系统采用了“每隔7秒钟轮训一遍服务器”的策略。因此它在当地找了最好的软件公司开发，系统上线后30分钟不到就垮掉了。那么这个系统崩溃的根本原因就是因为采用了web架构。而当地的软件公司的工程师，大概除了做网页就没有做过其它类型的通讯系统，因此他们不知道如何把消息推给这几千个客户端（每一个客户端要的信息都不完全一样），而只会让这些客户端去轮询服务器。用户将来终端数越发展，越容易垮掉，只有改为“服务推”的方式而不是像网页那样“客户端刷新”的方式，才是处理大型的核心业务的架构。
#4
当你有多个服务器的时候，那么显然，每一个服务器的网站进程都可以仅仅处理它自己的Cache、它本地的日志，甚至是查询它本地的数据库同步快照。那么用10台4核的服务器组成的集群，可能也会在性能一台40核的服务器。
另外假设你有10台服务器，假设突然坏了2台，“无所谓”，再扩展两台或者把它们修复后重启就行了。更新服务器软件也可以“先更新5台机器，重启之后，再更另外5台机器”。
等等等等。
所以设计服务系统有两种人，一种人就是只能用单机、多个应用服务器给他则也是荒废着、搞备份而已，另外一种人就是坚持至少要有2或者3台服务器才敢提供服务。这两种人能提供的服务的水平，是不同的。
另外假设你有10台服务器，假设突然坏了2台，“无所谓”，再扩展两台或者把它们修复后重启就行了。更新服务器软件也可以“先更新5台机器，重启之后，再更另外5台机器”。
等等等等。
所以设计服务系统有两种人，一种人就是只能用单机、多个应用服务器给他则也是荒废着、搞备份而已，另外一种人就是坚持至少要有2或者3台服务器才敢提供服务。这两种人能提供的服务的水平，是不同的。
#5
大师，再请教一下，希望您能直接回答，不要扯太远。。
假设我就一台服务器，一个iis站点，cpu内存也是固定的配置，我应该给他分配几个园更合理？
假设我就一台服务器，一个iis站点，cpu内存也是固定的配置，我应该给他分配几个园更合理？