关于Memcached及客户端相关的几个问题

这几天无业在家,在网上跟前同事聊到了Memcached,对于在对自己的产品的使用上,有两个问题比较显著,这里说说我的看法:

第一个:“最近访客”这个功能为何不使用其CAS特性来保证分布式场景下Memcached的应用?

答:首先,我们的memcached server均不支持cas,在启动时均关闭了该功能。经过之前的使用经验,关闭cas特性后能节省一些内存空间,其次,对性能也有提升的作用。当然,最主要的是,依赖cas来实现一种lock-free的机制,也只是“看起来很好”。

cas存在很多的问题,表面看起来是lock-free的,其实对于反应慢一点的机器来说,就是长时间的wait。这个是不合算的。尤其在现网运行的分布式模式下,很容易让客户端因为这个“作践”自己,而且出现数据问题后的debug过程会相当相当复杂,对生产环境冲击也很大。所以本着“少折腾”的原则,直接废弃了cas的使用,所以我们自己写的memcached客户端里,直接就没有对cas的支持。

对待memcached的cas模式,坚定的说:“我不看好你呦”。

第二个:为什么new MemcachedClient(“xxx”)的时候会出现因为缺乏线程而且导致异常?

这是因为所有的MemcachedClient期望于在系统启动的准备过程中去构建。如果在多人多团队协作的业务复杂的项目里,在应用层(目的:为了复用而抽取出的层)里可是随便new的话,那真的就没法管理了,因为我们的Memcached客户端的key是自动构建的,其中CacheClientName就是一部分,所以这样的重复名称会带来缓存数据的冲突。例如我们的IoC的注册机制,也是基于“管理”的目的才需要在启动时注册的。

而在使用double-lock的机制来“修复”这个“bug”是完全错误的做法。这会大量减少系统在高峰期重启的抗压能力,存在可能启动不起来Request Queue就达到Limit的风险。得不偿失。

posted @ 2010-12-09 11:24 new 维生素C.net() 阅读(...) 评论(...) 编辑 收藏