一张图概括bingosession使用
首先，写这个小插件的原因，和分布式无关。是对于现在开源的主流go Session插件都不太满意，或多或少存在以下几个问题：
1.生成SessionID使用完全随机方式，无法保证唯一性。
2.Session回收机制不完善（只考虑了用户主动注销，对于修改密码这种情况，没有提供销毁的接口，而且因为设计问题，通过改写插件去实现非常麻烦）。
3.大量接口实际形同虚设（由于Session类型不同，有的类虽然实现了接口，但是都是空实现），方法暴露严重，不能给开发人员直观的API调用。
4.配置参数开放不完整，或者格式杂乱。
5.文件Session没有定期清理机制。
核心问题
一.分布式SessionID的生成
关于UUID的生成网上的也讨论过很多了，参考美团的这篇技术文档——《Leaf——美团点评分布式ID生成系统》
美团主要是订单生成业务，他们的需求总共4点：
1.全局唯一性：不能出现重复的ID号，既然是唯一标识，这是最基本的要求。
2.趋势递增：在MySQL InnoDB引擎中使用的是聚集索引，由于多数RDBMS使用B-tree的数据结构来存储索引数据，在主键的选择上面我们应该尽量使用有序的主键保证写入性能。
3.单调递增：保证下一个ID一定大于上一个ID，例如事务版本号、IM增量消息、排序等特殊需求。
4.信息安全：如果ID是连续的，恶意用户的扒取工作就非常容易做了，直接按照顺序下载指定URL即可；如果是订单号就更危险了，竞对可以直接知道我们一天的单量。所以在一些应用场景下，会需要ID无规则、不规则。
和订单号业务有点区别，SessionID的生成不需要考虑2和3的问题。相对来说订单号业务对4的要求不算高，就算订单号规则泄露，没有令牌也是无法操作订单状态的。但是SessionID规则泄漏，就危险了。
综上所述：
如上SessionID生成业务主要考虑以下几点
1.全局唯一性 2.高可用 3.信息安全
为了高可用，bingosession使用的生成方式是本地生成，生成规则如下
【UUID】=【当前时间戳（纳秒）】+【进程内自增序列号】+【本机MAC地址】+【当前进程id】+【int64随机数】
为了保证信息不泄露，最后UUID=md5（UUID+签名key），得到32位长度的SessionID。
对于snowflake的时间回退问题，【进程内自增序列号】+【当前进程id】可以避免。那为什么还要加个随机数？以防万一。说起某站源码泄漏事件，我看了源码然后发现SessionID是根据【uid+时间戳（秒）+随机数+签名key】生成的，如果没有随机数，那知道uid和签名key的情况下，令牌就可以暴力破解了。某站的uid还是直接暴露在URL的，害怕。
随机数除了意外情况，感觉就是防内部作案用的吧（劳资防的就是这个友军）。
暂时先这样了（感觉32位的md5还是有点长，生成16位的感觉又不太安全？）
二.回收机制
现有的插件都有用户注销后把令牌回收的机制（其实就是把Cookie清空了），但是很多都没有提供-非用户请求下的回收接口，会导致改密后原来的令牌还有效。
怎么做到实时回收SessionID呢，想想只能是每次HTTP请求都通过缓存去验证SessionID的有效性了。那如何将这个验证对服务器的压力降到最低呢？
下面我把Session分为两种：
1.纯Cookie的Session
这种Session将用户信息、过期时间、签名都存在Cookie里，用户请求后，验证签名通过，且没有过期，则认为Session有效。（类似jwt）
这种肯定是无法主动回收的，为什么呢？把SessionID也放里面去，然后关联缓存不就可以了吗？——那就不是纯Cookie了，它的目的就是避免直接请求缓存造成的性能消耗。
纯Cookie适用于无用户状态的请求，例如购物车这种，就算无法回收也没关系，因为只有在提交订单时，它才需要用户状态。
当然是不是纯Cookie不重要，你也可以把这样的一个对象存在cookie里
{
"uid": 1,
"name": "bingo",
"session_id": "7f6ffaa6bb0b408017b62254211691b5",
"expire": 1556785244,
"sign":"8f6ffaa6bb0b408017b62254211691b5"
}
session_id只用于判断Redis里是否还有这key。
2.Cookie只保留SessionID
这种适合用于有用户状态请求，SessionID就是缓存的key，每次HTTP请求都需要访问一次缓存。用什么做缓存好呢？DB？Memcached ？Redis？还是文件？
文件只适合单节点，这里就不考虑了。
想了一下，无论用哪种，最后似乎都离不开DB，因为改密的时候，要把所有的SessionID回收，所以肯定事先要把用户的SessionID存起来，最适合的应该就是DB了。那直接用DB不就行了？想想感觉不好，因为关系型数据库查询效率相对较低。（每次用户请求还得查一次数据库？强迫症的我不能忍受！）最后决定的是用Redis，因为我比较熟悉这个，据说Memcached性能更好，后面考虑加入。
bingosession目前以上的两种Session都有用到，目前支持的缓存方式：
1.纯Cookie（无法主动回收）
2.Redis
3.文件
4.Cookie+Redis
Cookie+Redis的情况，Redis只用于验证有效性，不存放数据。
后续考虑加入Memcached。
其它:
数据解析使用jsoniter库（测试解析速度完爆gob）
redis库使用redigo
现在没有DB支持，暂时不考虑加入DB支持。（这里的DB支持和用户登录无关，是指直接使用DB存储Session）。因为本菜鸟目前只懂一点mysql，其它DB不熟。对于mysql的性能心里还是有点逼数，而且不同的业务场景，Table结构应该都不一样，不适合。
也不打算加入登录注销改密之类的管理，这些也是和业务相关的了。
bingo~~就到这里吧
最后欢迎各位大佬指（帮我找）教（Bug）
网友评论