关于cpu和缓存的一些探讨

缓存的数据可以放在那里呢？一般来说有这么几种，static变量，.NET类库提供的HttpRuntime.Cache或者就是一些分布式的缓存解决方案，比如memcached。

有一些误解，很多人非常不喜欢static变量，我想有两个原因，一是可能觉得把100M数据存放到一个变量中，这是很可怕的事情，一个变量竟然占用100M内存，其实我们大多时候缓存的是一个引用类型，变量存放的只是一个指针罢了，100M的值类型确实可怕，二是很多做ASP.NET的人会觉得不能乱用static变量，就产生了这个错觉。其实，我觉得static变量的问题在于它没有线程安全的机制，二是它作为缓存方案不能过期，一旦创建后也不能删除，只能把它设置为空引用，等待GC回收。但对于某些情况，静态变量是适合的，比如我们缓存的数据是只读并且永远不需要过期的，静态变量作为缓存的确足够简单，也不用担心“丢失”！

HttpRuntime.Cache 之类的方案的优势在于它提供了过期、依赖、线程同步的支持，也是我们用的最多的。

 

最后说说分布式缓存解决方案，比如memcached。其实我觉得在一般情况下不要去随便使用分布式的缓存方案，除非我们能满足以下的需求：1、缓存的数据非常多，一台机器的内存不够用，确实需要分布。2、需要确保数据不能丢失，在多台机器上做备份。为什么说不要轻易用，因为分布是有代价的，如果应用服务器和缓存服务器分开的话，势必就需要TCP通讯，这是一个消耗，另外一个消耗是缓存的数据需要序列化和反序列化。分布式缓存使用缓存一些直接能绑定到UI的数据，或者说直接用于呈现的数据，对于大块的数据非常不适合存放到memcached中。比如之前提到的List<string>，如果这个数据是100M，它不能直接用需要做一些计算再返回给WEB服务器，那么我们做的事情就是序列化后缓存到memcached中，然后再反序列化从TCP获取，放到内存中计算后返回给WEB服务器，然后内存中的100M数据等待GC回收。其中白白折腾了网络、CPU和内存（虽然会回收，但是GC一直回收100M的数据，谁受得了）。

上面的例子我想说明一个问题，缓存的方案需要根据应用来选择，静态变量不一定不好，分布式缓存也不一定好 。

 

最后，还有一个有关CPU占用的有趣问题，很多人很怕服务器占用CPU很高，觉得CPU占用一高就有性能问题。其实我想说的是，有的时候CPU占用的高不一定是坏事情。假设有两个网站。A网站它的数据源是数据库，每一个请求（假设是同步请求数据库）都需要1秒来从数据库获取数据，由于IO操作的时间会比CPU处理数据时间长很多，所以这个网站即使很繁忙，WEB服务器的CPU占用还不是很高，用户一个页面打开至少要等1秒，网站管理员看着WEB服务器CPU常年处理20%的情况觉得很满意，但想想这真能说明网站性能高吗？还有一个网站B，它数据都是从内存中读取的，由于内存的操作会比IO操作快很多，CPU处理一个请求的数据只需要20毫秒，由于网站页面速度快，用户满意度和数量比A网站高很多，CPU很忙，常年处于90%的负荷，网站管理员看了觉得很害怕，是不是哪里出现性能问题了，服务器会不会瘫痪。其实，我觉得B网站的管理员应该高兴，因为B网站的用户比A网站高一个数量级，服务器虽然很忙，但页面打开速度很快，CPU得到了充分的利用。

 

上面的例子我想说明一个问题，只要不是死循环等恶性代码问题的话，CPU如果占用的高不一定就是坏事情 。