一起session共享引起的车祸现场
昨天在帮子公司同事调试充值时出现了一个很奇怪的问题,一个内部请求的功能,客户端请求A接口,A接口内部curlB接口,其中AB接口都处在同个域名下,调试时通过观察nginx日志发现A请求B无论设置多久的超时时间,B请求都会返回499,而在机器上直接请求B接口是可以正常返回结果的,更加诡异的是B总会在请求的最后一秒返回成功,对于客户端来说却是个灾难级的超时现象。
首先排除网络解析的问题,经简单测试,发现网络请求连通性不存在问题,后续观察超时花的时间都在B上,因此开启了php的慢日志查询原因,慢日志一开启后,问题也就浮出水面了。
1 2 3 4 5 6 7 8 9 10 11 | [0x00007fabf55e9708] session_start() /data/wwwroot/api_simple/system/classes/kohana/session/native.php:44 [0x00007fabf55e9480] _read() /data/wwwroot/api_simple/system/classes/kohana/session.php:306 [0x00007fabf55e90f8] read() /data/wwwroot/api_simple/system/classes/kohana/session.php:130 [0x00007fabf55e8d08] __construct() /data/wwwroot/api_simple/system/classes/kohana/session.php:54 [0x00007fabf55e88d8] instance() /data/wwwroot/api_simple/application/classes/controller/service/common.php:32 [0x00007fabf55e85a8] auth() /data/wwwroot/api_simple/application/classes/controller/service/common.php:20 [0x00007ffd7af91bd0] before() unknown:0 [0x00007fabf55e8358] invoke() /data/wwwroot/api_simple/system/classes/kohana/request/client/internal.php:103 [0x00007fabf55e74c0] execute_request() /data/wwwroot/api_simple/system/classes/kohana/request/client.php:64 [0x00007fabf55e72d8] execute() /data/wwwroot/api_simple/system/classes/kohana/request.php:1141 [0x00007fabf55e6f50] execute() /data/wwwroot/api_simple/index.php:174 |
很明显,是session_start()出了问题,怀着疑问上google查阅了相关关键字,果然发现了问题:当前机器环境session是写到文件中的,而session文件调用session_start()后如果不是主动释放资源,则会被当前的php进程持续加锁占有,恰巧的是AB两个请求都带上了同个session_id,造成了资源循环等待的死锁问题,一切真相大白。解决方案也很简单,将session转移到mc中,即可解决当前问题:
1 2 | session.save_handler = memcache session.save_path = "tcp://mem_master.4399sy.com:11210?persistent=1" |
文章参考:
javascript判断元素是否在数组内(转) 利用watch命令制作简单监控