#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

又经过一天的运行，事实证明问题并没有从根本上解决，仍然会有比之前更小的频率出现问题，尴了个尬，后续再尝试其他解决方案