session事故

事故本身

某个子系统在某个时间段内，突然爆发大量的用户频繁被退出登录。

事故原因

根据初步定位到是session存储的memcache容量不够，导致大量旧的session数据失效，因此大量先登录的用户被强制挤退。
session存储的memcache是独立配置的，容量为128M，一般情况下，128M的容量是足够存储的，但是本次可能是由于业务逻辑上存在的漏洞，往session中写入大量数据，同时登录用户量剧增导致存在问题出现。

解决方案

方案1

增大memcache的容量，这是一个最快的解决方案，但是治标不治本，真正导致session容量不够的原因还需要再定位

方案2

预防

这次的事故后，我才深深体会到前人所说的，多做一层封装的好处。
通过这次之后，我觉得对session的所有操作，都应该经过我们封装的方法进行处理后在set进memcache中。

实现：
session最常用的两个操作，set跟get
其中set方法是本次主要的封装对象

主要的做法有两个

1. 针对set方法，做一个判断，当线上环境，不做任何处理，测试环境时，set进来的某个值，单个值大小超过某个阈值，或者是set成功后，当前session的大小超过另外一个阈值时【阈值需要根据实际情况去评估】，发出告警消息

2. 定期监控memcache，主要监控两方面，总的数据容量是否超过某个阈值，另外就是检测每一个session是否超过某个阈值。因为一般情况下，我们session存储的memcache是单独开一个服务的，可以单独检查，并及时告警