分布式缓存memcached出现服务停掉的原因分析与处理过程

下面是博客园采用分布式缓存memcached，突然发现分布式缓存memcached服务停止的原因分析与处理方法，博客园团队一位在数据库服务器中修改了一个设置

　　将"Use query governor to prevent long-running queries"设置为500，500代表的是查询成本，不是查询执行时间，如果SQL Server认为查询成本超过500，就会返回超时错误。

　　之前我们经常使用这个设置，这样可以避免一些执行时间过长的查询影响整体数据库的性能。但这不是解决问题的办法，只是让局部问题不去影响整体，真正解决问题还是要优化执行时间长的查询。

　　而就在修改过这个设置之后某个时候，担任缓冲重任的memcached服务突然偷偷地罢工了，血案就这样开始了...

　　发现问题

　　有些用户在博客中发评论时出现了超时错误，有人在闪存上进行反映，我们在闪存看到并进行测试，也遇到了超时问题，当时我们以为是同时连接过多造成服务器压力大造成的，从日志中发现有过于频繁访问的IP，屏蔽了该IP之后，可以正常发表评论了，我们以为问题已经解决了，从最新评论看，大家也能发表评论。

　　实际上问题依然存在，会在特定的条件下发生，只不过我们的测试时没有遇到这样的条件。如果没有设置"Use query governor to prevent long-running queries"，这个问题更难发现，因为这时发评论只会速度变慢，不会出现超时，大家不会去反馈这个速度慢的问题。后来，超时出现越来越频繁，有用户在闪存上进行反馈，我们才知道了这个问题。

　　采取措施

　　我们怎么也没想到memcached服务已经罢工了，之前memcached服务还从来没罢工过，于是把解决问题的焦点放在评论功能相关的数据库优化。在SQL Server 2005管理工具中执行添加评论的存储过程，执行速度也很慢，查看执行计划，发现成本在聚集索引的插入上，于是我们以为是评论表的聚集索引设置有问题（看来不能仅从执行计划去分析问题）。评论表的聚集索引本来是建立在自增ID上的（博客文章表的聚集索引建立在发表时间上），因为评论表的查询主要就是根据ParentID进行查询（查询结果根据ID进行排序），之外最多的操作就是插入记录。既然成本在聚集索引的插入上，我们就取消了聚集索引，这样可以避免在插入记录时的聚集索引插入。这样操作之后，发评论的速度提升了，但速度还是不理想，还是会出现超时...

　　柳暗花明

　　后来，无意间发现memcached服务停掉了，立即想到这才是罪魁祸首，不是聚集索引的问题，为什么会这么想呢，看一下添加评论的存储过程就知道了：

BEGIN TRANSACTION
UPDATE blog_Content
SET FeedBackCount = FeedBackCount+1,LastCommentTime = GETDATE() 
WHERE [ID] = @ParentID
INSERT INTO blog_Comment([Text],Author)VALUES(@Text,@Author)    
Select @ID = @@Identity    
COMMIT TRANSACTION