#region 使用Redis保存Session string address = Configuration["RedisAddress"] + ",password=" + Configuration["RedisPassWord"]; //添加数据保护(把sessionid存储到redis) services.AddDataProtection() .SetApplicationName("sessionIdSave") .PersistKeysToStackExchangeRedis(Helper.getSessionConfig(address), "session_afsweb"); //添加redis配置 services.AddDistributedRedisCache(option => { //redis 连接字符串 option.Configuration = address; //redis 实例名 option.InstanceName = Configuration["InstanceName"]; }); //添加session配置 services.AddSession(options => { //session存活时间 options.IdleTimeout = TimeSpan.FromHours(Convert.ToDouble(Configuration["SessionTimeOut"])); options.IOTimeout = TimeSpan.FromHours(Convert.ToDouble(Configuration["SessionTimeOut"])); //设为httponly options.Cookie.HttpOnly = true; }); #endregion
使用redis存储sesionid和session中的数据
项目为内部项目,并发量不大,两台centos7,nginx反向代理+ip_hash
分析过程:
1、通过日志发现,凌晨也会出现这个问题,所以判断和并发量应该无关
2、猜测可能和session配置有关,options.Cookie.IsEssential = true;//强制存储cookie
3、猜测和nginx有关,但具体哪方面不清楚
由于是生产环境,问题排查了半天没有出结果,而且没有发现明显的问题,所以就只能用治标的方法先把问题临时解决,就是在拦截器中进行判断,sessionid为空字符串的暂时放行,因为正常的请求都是有sessionid,所以理论上应该不会出现跳过权限验证的问题,所以就临时发布,再持续观察,后面经过2天的运行,成功临时解决sessionid为空的问题,并且未发现其他意外问题。
临时解决了问题,但是并没有根本解决问题,所以如鲠在喉,后续准备进行验证上面的猜想2,这是想起之前从cookie方式改成session方式了,可以不用ip_hash了,所以就直接猜想2和猜想3的ip_hash一起进行验证
ip_hash是先放开的,options.Cookie.IsEssential = true;是后发布的,个人推测大概率是ip_hash的原因
如果读者有幸遇到一样的问题,可以参考
经过一个下午和一个一个早上的运行,发现貌似问题真的解决了,后续再进行持续跟踪,如果没有再出现问题,则不再更新,如果再出现问题,就会再次更新说明
时间:2021-6-9 10:21:27
---------------------------------------------------------分割线---------------------------------------------------------
时间:2021-6-10 09:46:00
又经过一天的运行,事实证明问题并没有从根本上解决,仍然会有比之前更小的频率出现问题,尴了个尬,后续再尝试其他解决方案