前不久,俺写了篇文章谈到了.Net下面的分布式缓存的一些问题,并结合DNT里面实现模式发表了一些自己的看法，近来通过学习相关的东西又有了一些新的体会, 写在这里作为分布式缓存列系文章的第二部分.
其实对于性的扩展无非是Scale Up(向上扩展）或者是Scale Out(向外扩展）, 微软对此的看法是一个App的缓存最好是以它自己为物理边界进行读写，而不要放到别处去，这样带的问题可能有对象的序列化传送，反序列化，网络连接开销，跨进程的开销，对于高性能的站点来说都是不能忽视的问题.出于对这些因素的考虑微推荐的作法不是把多个应用放在一起在多台Server布署，而是将一个App划分成若干个小的应用布署到不同的服务器，下面的关系图展示了这种关系, 这样每种应用就可以独立管理自己的缓存数据，但是对于象用户数据这样的通用数据仍然会存在多处.
两种解决方案为了解决缓存同步的问题，有人想出了解决办法, 可以参考这两个地方，这个是MS的，这里还有一个，先来看看Peter的这个吧, 主要思想就是把要放到缓存里面的东西加上一层包装CacheControlItem, 实现代码请去原文出处下载.
每台机器都维护一个WebFarm里面的成员服务器的列表，如果有新的服务器进来发现自己不在这个列表中则会通知其它的服务器把它加到这个名单里面。添加缓存的这程是这样， A服务器需要插入一个新的缓存值，它把这个项目插入到自己的缓存中，然后用它初始化一个CacheControlItem并指定它的缓存策略（优先级，缓存生存时间），设定它的动作，即添加，然后把这个结象序列化通过Web传送到每一个成员服务器，接受到这些数据的服务器跟据这个对象的Action指令，把反序列化后的对象加入到自己的缓存里面，这样一个同步的过程就完成了，移除缓存对象的过程与之类似，只不过不需要传送对象，只在包装类里面设定它的Action为删除就可以了. 当然，为了提高性能，可以实现一个异步的侦听线程专门用来响应缓存通知的请求. 总体上讲这处办法的效率比较低，在数据量较大的情况下可能会造成大量缓存数据的同步数据流。
我们再来看看M$是怎么做的，它的想法类似，只不过它不在WebFarm的成员服务器之间同步缓存，而只是保证每台机器不要读到已经失效的缓存数据，当缓存数据失效时(相关依赖数据被更新), 通过维护一个需要通知的服务器列表依次调用每台服务器上的WebService，如果当前服务器上存在这键值的缓存则使它失效.
这两个老外写的东西似乎都比较啰索，不过对初学者来说比较友好，可以一步步地知道这件事情的来龙去脉，理解会清楚更刻一些。
Memcached到底有多快?看了这些如果还不满意，那么您可以试试Memcached它可以运行在Win32平台下，在上篇文章中我们已经提到了这个东西，但是它在.Net的平台下面究竟表现如何？是否能象在PHP平台下面一样地优秀，我们现在来做一个简单的测试, 对比使用.Net自带的Cache和Memcached两种实现方式，看看差距究竟有多大，过程是这样，分别生成10000个字符串对象并分别设定键值插入到缓存中，然后再取出来，看看花费的总时间. 服务器端:memcached-1.2.1-win32, 客户端: memcacheddotnet_clientlib-1.1.5, 服务器端的使用也比较简单，解压文件之后在命令行下面输入: c:\memcached -d install 先安装服务, 接着 c:\memcached -d start就可以了，详细使用方法见说明文件 -h 是查看帮助, 测试环境如下:
Memcached服务器 : Win2003 sp1, Framework 2.0,P4 D 3.4G, 768MB 内存, 千兆网卡.
Memcached客户机 : Win2003 sp1, Framework 2.0,T2060, 1G内存( 沙加的神舟笔记本;) ), 千兆网卡.
两台机器通过直连线相连.
.Net Cache单机测试 : P4 D 3.4G, 768MB 内存.
测试结果, 存取10000个条目的时间:
Memcached
Set(秒) 1.48 1.37 1.48 1.37 1.46
Get(秒) 2.42 2.42 2.42 2.43 2.42
HttpRuntime.Cache
Set(秒) 0.015 0.015 0.015 0.015 0.015
Get(秒)
0.015 0.015 0.015 0.015 0.015
.Net内建缓存测试代码HttpRuntime.Cache
protected void Page_Load(object sender, EventArgs e)
{
int start = 200;
int runs = 10000;
string keyBase = "testKey";
string obj = "This is a test of an object blah blah es, serialization does not seem to slow things down so much. The gzip compression is horrible horrible performance, so we only use it for very large objects. I have not done any heavy benchmarking recently";
long begin = DateTime.Now.Ticks;
for(int i = start; i < start+runs; i++)
{
HttpRuntime.Cache.Add(keyBase + i, obj,null,System.Web.Caching.Cache.NoAbsoluteExpiration,
TimeSpan.FromMinutes(1),System.Web.Caching.CacheItemPriority.Normal,null);
}
long end = DateTime.Now.Ticks;
long time = end - begin;
Response.Write(runs + " sets: " + new TimeSpan(time).ToString() + "ms<br />");
begin = DateTime.Now.Ticks;
int hits = 0;
int misses = 0;
for(int i = start; i < start+runs; i++)
{
string str = (string) HttpRuntime.Cache.Get(keyBase + i);
if(str != null)
++hits;
else
++misses;
}
end = DateTime.Now.Ticks;
time = end - begin;
Response.Write(runs + " gets: " + new TimeSpan(time).ToString() + "ms");
}
Memcached测试代码Memcached
namespace Memcached.MemcachedBench
{
using System;
using System.Collections;
using Memcached.ClientLibrary;
public class MemcachedBench
{
[STAThread]
public static void Main(String[] args)
{
int runs = 100;
int start = 200;
if(args.Length > 1)
{
runs = int.Parse(args[0]);
start = int.Parse(args[1]);
}
string[] serverlist = { "140.192.34.72:11211", "140.192.34.73:11211" };
// initialize the pool for memcache servers
SockIOPool pool = SockIOPool.GetInstance();
pool.SetServers(serverlist);
pool.InitConnections = 3;
pool.MinConnections = 3;
pool.MaxConnections = 5;
pool.SocketConnectTimeout = 1000;
pool.SocketTimeout = 3000;
pool.MaintenanceSleep = 30;
pool.Failover = true;
pool.Nagle = false;
pool.Initialize();
MemcachedClient mc = new MemcachedClient();
mc.EnableCompression = false;
string keyBase = "testKey";
string obj = "This is a test of an object blah blah es, serialization does not seem to slow things down so much. The gzip compression is horrible horrible performance, so we only use it for very large objects. I have not done any heavy benchmarking recently";
long begin = DateTime.Now.Ticks;
for(int i = start; i < start+runs; i++)
{
mc.Set(keyBase + i, obj);
}
long end = DateTime.Now.Ticks;
long time = end - begin;
Console.WriteLine(runs + " sets: " + new TimeSpan(time).ToString() + "ms");
begin = DateTime.Now.Ticks;
int hits = 0;
int misses = 0;
for(int i = start; i < start+runs; i++)
{
string str = (string) mc.Get(keyBase + i);
if(str != null)
++hits;
else
++misses;
}
end = DateTime.Now.Ticks;
time = end - begin;
Console.WriteLine(runs + " gets: " + new TimeSpan(time).ToString() + "ms");
Console.WriteLine("Cache hits: " + hits.ToString());
Console.WriteLine("Cache misses: " + misses.ToString());
IDictionary stats = mc.Stats();
foreach(string key1 in stats.Keys)
{
Console.WriteLine(key1);
Hashtable values = (Hashtable)stats[key1];
foreach(string key2 in values.Keys)
{
Console.WriteLine(key2 + ":" + values[key2]);
}
Console.WriteLine();
}
SockIOPool.GetInstance().Shutdown();
}
}
}结论通过这个对比测试我们可以看出内建的Cache比使用Memcached要快出约130倍,但是从总体速度上来看并不慢，这两种方式可以在项目中有选择性地结合使用可以产生很棒的效果.并且Memcached可使用的内存数量要多得多，同时也可以做集群避免单点问题. 做人要厚道，请注明转自酷网动力(www.ASPCOOL.COM)。
其实对于性的扩展无非是Scale Up(向上扩展）或者是Scale Out(向外扩展）, 微软对此的看法是一个App的缓存最好是以它自己为物理边界进行读写，而不要放到别处去，这样带的问题可能有对象的序列化传送，反序列化，网络连接开销，跨进程的开销，对于高性能的站点来说都是不能忽视的问题.出于对这些因素的考虑微推荐的作法不是把多个应用放在一起在多台Server布署，而是将一个App划分成若干个小的应用布署到不同的服务器，下面的关系图展示了这种关系, 这样每种应用就可以独立管理自己的缓存数据，但是对于象用户数据这样的通用数据仍然会存在多处.
两种解决方案为了解决缓存同步的问题，有人想出了解决办法, 可以参考这两个地方，这个是MS的，这里还有一个，先来看看Peter的这个吧, 主要思想就是把要放到缓存里面的东西加上一层包装CacheControlItem, 实现代码请去原文出处下载.
每台机器都维护一个WebFarm里面的成员服务器的列表，如果有新的服务器进来发现自己不在这个列表中则会通知其它的服务器把它加到这个名单里面。添加缓存的这程是这样， A服务器需要插入一个新的缓存值，它把这个项目插入到自己的缓存中，然后用它初始化一个CacheControlItem并指定它的缓存策略（优先级，缓存生存时间），设定它的动作，即添加，然后把这个结象序列化通过Web传送到每一个成员服务器，接受到这些数据的服务器跟据这个对象的Action指令，把反序列化后的对象加入到自己的缓存里面，这样一个同步的过程就完成了，移除缓存对象的过程与之类似，只不过不需要传送对象，只在包装类里面设定它的Action为删除就可以了. 当然，为了提高性能，可以实现一个异步的侦听线程专门用来响应缓存通知的请求. 总体上讲这处办法的效率比较低，在数据量较大的情况下可能会造成大量缓存数据的同步数据流。
我们再来看看M$是怎么做的，它的想法类似，只不过它不在WebFarm的成员服务器之间同步缓存，而只是保证每台机器不要读到已经失效的缓存数据，当缓存数据失效时(相关依赖数据被更新), 通过维护一个需要通知的服务器列表依次调用每台服务器上的WebService，如果当前服务器上存在这键值的缓存则使它失效.
这两个老外写的东西似乎都比较啰索，不过对初学者来说比较友好，可以一步步地知道这件事情的来龙去脉，理解会清楚更刻一些。
Memcached到底有多快?看了这些如果还不满意，那么您可以试试Memcached它可以运行在Win32平台下，在上篇文章中我们已经提到了这个东西，但是它在.Net的平台下面究竟表现如何？是否能象在PHP平台下面一样地优秀，我们现在来做一个简单的测试, 对比使用.Net自带的Cache和Memcached两种实现方式，看看差距究竟有多大，过程是这样，分别生成10000个字符串对象并分别设定键值插入到缓存中，然后再取出来，看看花费的总时间. 服务器端:memcached-1.2.1-win32, 客户端: memcacheddotnet_clientlib-1.1.5, 服务器端的使用也比较简单，解压文件之后在命令行下面输入: c:\memcached -d install 先安装服务, 接着 c:\memcached -d start就可以了，详细使用方法见说明文件 -h 是查看帮助, 测试环境如下:
Memcached服务器 : Win2003 sp1, Framework 2.0,P4 D 3.4G, 768MB 内存, 千兆网卡.
Memcached客户机 : Win2003 sp1, Framework 2.0,T2060, 1G内存( 沙加的神舟笔记本;) ), 千兆网卡.
两台机器通过直连线相连.
.Net Cache单机测试 : P4 D 3.4G, 768MB 内存.
测试结果, 存取10000个条目的时间:
Memcached
Set(秒) 1.48 1.37 1.48 1.37 1.46
Get(秒) 2.42 2.42 2.42 2.43 2.42
HttpRuntime.Cache
Set(秒) 0.015 0.015 0.015 0.015 0.015
Get(秒)
0.015 0.015 0.015 0.015 0.015
.Net内建缓存测试代码HttpRuntime.Cache
protected void Page_Load(object sender, EventArgs e)
{
int start = 200;
int runs = 10000;
string keyBase = "testKey";
string obj = "This is a test of an object blah blah es, serialization does not seem to slow things down so much. The gzip compression is horrible horrible performance, so we only use it for very large objects. I have not done any heavy benchmarking recently";
long begin = DateTime.Now.Ticks;
for(int i = start; i < start+runs; i++)
{
HttpRuntime.Cache.Add(keyBase + i, obj,null,System.Web.Caching.Cache.NoAbsoluteExpiration,
TimeSpan.FromMinutes(1),System.Web.Caching.CacheItemPriority.Normal,null);
}
long end = DateTime.Now.Ticks;
long time = end - begin;
Response.Write(runs + " sets: " + new TimeSpan(time).ToString() + "ms<br />");
begin = DateTime.Now.Ticks;
int hits = 0;
int misses = 0;
for(int i = start; i < start+runs; i++)
{
string str = (string) HttpRuntime.Cache.Get(keyBase + i);
if(str != null)
++hits;
else
++misses;
}
end = DateTime.Now.Ticks;
time = end - begin;
Response.Write(runs + " gets: " + new TimeSpan(time).ToString() + "ms");
}
Memcached测试代码Memcached
namespace Memcached.MemcachedBench
{
using System;
using System.Collections;
using Memcached.ClientLibrary;
public class MemcachedBench
{
[STAThread]
public static void Main(String[] args)
{
int runs = 100;
int start = 200;
if(args.Length > 1)
{
runs = int.Parse(args[0]);
start = int.Parse(args[1]);
}
string[] serverlist = { "140.192.34.72:11211", "140.192.34.73:11211" };
// initialize the pool for memcache servers
SockIOPool pool = SockIOPool.GetInstance();
pool.SetServers(serverlist);
pool.InitConnections = 3;
pool.MinConnections = 3;
pool.MaxConnections = 5;
pool.SocketConnectTimeout = 1000;
pool.SocketTimeout = 3000;
pool.MaintenanceSleep = 30;
pool.Failover = true;
pool.Nagle = false;
pool.Initialize();
MemcachedClient mc = new MemcachedClient();
mc.EnableCompression = false;
string keyBase = "testKey";
string obj = "This is a test of an object blah blah es, serialization does not seem to slow things down so much. The gzip compression is horrible horrible performance, so we only use it for very large objects. I have not done any heavy benchmarking recently";
long begin = DateTime.Now.Ticks;
for(int i = start; i < start+runs; i++)
{
mc.Set(keyBase + i, obj);
}
long end = DateTime.Now.Ticks;
long time = end - begin;
Console.WriteLine(runs + " sets: " + new TimeSpan(time).ToString() + "ms");
begin = DateTime.Now.Ticks;
int hits = 0;
int misses = 0;
for(int i = start; i < start+runs; i++)
{
string str = (string) mc.Get(keyBase + i);
if(str != null)
++hits;
else
++misses;
}
end = DateTime.Now.Ticks;
time = end - begin;
Console.WriteLine(runs + " gets: " + new TimeSpan(time).ToString() + "ms");
Console.WriteLine("Cache hits: " + hits.ToString());
Console.WriteLine("Cache misses: " + misses.ToString());
IDictionary stats = mc.Stats();
foreach(string key1 in stats.Keys)
{
Console.WriteLine(key1);
Hashtable values = (Hashtable)stats[key1];
foreach(string key2 in values.Keys)
{
Console.WriteLine(key2 + ":" + values[key2]);
}
Console.WriteLine();
}
SockIOPool.GetInstance().Shutdown();
}
}
}结论通过这个对比测试我们可以看出内建的Cache比使用Memcached要快出约130倍,但是从总体速度上来看并不慢，这两种方式可以在项目中有选择性地结合使用可以产生很棒的效果.并且Memcached可使用的内存数量要多得多，同时也可以做集群避免单点问题. 做人要厚道，请注明转自酷网动力(www.ASPCOOL.COM)。
