项目bug处理思考

问题描述:

项目当中使用了memcached做为缓存.经常会出现一些奇怪的问题,比如修改了数据并通过程序刷新缓存以后,在我们的一个服务程序里仍然读取到的依然是旧的缓存.

问题排查:

之前一直怀疑是memcached有问题,因为每次都是清空了缓存的,但是程序读到的确依然是旧的数据.

想到既然可能是memcached有问题,那就暂时先这样凑合着吧,反正目前也无能为力.

但是昨天突然灵光一闪,想到因为服务的那个进程一直读取有问题,是不是跟服务有关.

看了代码后,突然才恍然大悟.

因为程序的多线程的,所以在设置属性的时候,加了lock判断,这样第一个线程给属性赋值以后,其他线程再需要访问的时候,就不需要

再请求一次缓存了,直接读取静态变量即可.

这个代码本来是没有问题的,但是我们却忽略了一个问题,那就是这个程序的windows 服务形式的.那就说明这个进程是一直开着的.

这个变量第一次加载以后,就一直驻留在进程的内存里了,不管这个缓存以后如何变换,只要这个进程不断,变量的值就不会重新获取.

My God,竟然是这样的一个低级错误,导致了新的缓存一直无法获取.

问题解决:

既然问题的原因找到了,那么就要想下以后如何处理这个问题.

有2种方式:

以后修改缓存以后去手工重启下这个服务.(有点笨的方式,如果忘记操作就杯具了,不太适合程序员的偷懒精神)
能否在后台触发服务的自动重启?
想了一下,使用bat程序,然后弄个windows计划任务定时自动重启应该就可以搞定了吧.
(当然这种方式,并不能实时解决缓存刷新的问题)

3.尝试修改代码,并不是把整个list缓存在memcached的一个key里,而是一个key仅缓存一个对象.这样就不担心每次重复装载大量的缓存到变量中了.

扩展阅读:

memcached的简单限制就是键（key）和item的限制。最大键长为250个字符。可以接受的储存数据不能超过1MB，因为这是典型slab 的最大值。这里我们可以突破对key长度的限制。

解决后的思考:

在怀疑别人代码是否有问题时候,先检查自己的代码,有时候代码都没有问题的时候,就换个思路,是不是还有其他的问题可能.
有时候多半还可能是环境的为难题.(就象处理昨天一个同事不能打开邮箱里下载的excel文件,发现不是excel的问题,而是浏览器的问题.
浏览器会把报错的页面也存储为.xlsx结尾的了,导致小白同事以为文件已经下载,但是无法打开,然后告诉他换个浏览器问题即解决)
在想解决方案的时候,多思考一步,是否可以自动化运行,降低复杂度.

参考资料: