我是web服务器。我是一个网络服务器。我的工作是为人类提供互联网服务。我每天为数以万计的人提供网页浏览服务。已经是深夜了，我还在紧张地和几个弟兄讨论一件事。“老大，现在我们每天处理的请求越来越多，session同步的问题不能再拖了，必须得想办法。”，我们是一个集群，我不是不知道你说的问题，我昨天听程序员讨论要给我们连接一个叫Redis的家伙，相信这个问题很快就会解决，还请多多包涵。”“Redis，他是谁，有什么背景？怎么没听说过这个人物？”“也没见过，等着瞧吧。”session-cookie时代到底出了什么问题，让我们兄弟急得起不来？火？事情得很多年前就开始了。。。那时候，在二哥来之前，只有我一个web服务器，每天处理一些静态资源文件，比如HTML，CSS，JS，图片等等，日子过得悠闲。白天，互联网正在悄然发生着变化，除了静态网页，可以动态交互的网络应用如雨后春笋般涌现，比如各种论坛，购物网站等等。这家公司的老板也不例外，他招了一个一群程序员搭建一个支持动态网页交互的网站，以前只需要按照HTTP协议的规范处理请求就大功告成了，但是动态交互应用出现后，我必须记住每个请求背后的用户是谁，否则它会b一团糟。为了解决这个问题，程序员想出了一个方法叫session：浏览器登录后，我分配一个sessionid代表一个session，然后返回给浏览器保存。待会儿提出要求的时候，我会带在身上，我就知道是谁了！还别说，这个方法还挺有效的，成功解决了用户身份识别的问题，而且已经用了好几年了。但是，互联网发展太快，用户越来越多，我却很担心。当用户数量较少时，很容易管理sessionid。现在用户越来越多，对应的sessionid也越来越多。我有点不知所措。终于，前不久，公司扩容了web服务器，给我找了两个小弟，特地加了一个nginx做负载均衡。现在我们已经变成了一个由3个Web服务器组成的小型集群。我的工作变得轻松了许多，两个小兄弟也分担了很多。本以为以后的生活会好过一些，没想到两个小弟弟的加入又带来了新的问题。虽然以前sessionid很多，我一个人累，但是好管理！现在人手增加了，sessionid的管理也变得复杂了。因为我们现在是一个集群，如果请求发给我，我会注册sessionid，但是下一个请求可能发给老二，一会儿又发给老三，这个是不确定的，所以我们如果手上的信息不一致，就会出现一些不正常的情况，用户可能会大喊：这是什么辣鸡网站？后来我们和nginx商量，让他把同一个用户的所有请求都发给我们固定的人。局势才稳定下来。但好景不长。我们三个兄弟都经历了一个接一个的宕机。这时候nginx还是要把请求交给还在干活的兄弟，原来的问题又出现了！我们很着急，商量了一下。暂时先让大佬们同步一下sessionid信息。如果有新的添加或者失败，请其他兄弟问候一下，每个人管理一个副本，这样就不会出现不一致的情况。搞了半天，变成了以前一个人管理所有sessionid的情况。不仅如此，还花时间跟几个兄弟同步，把sessionids搬来搬去。工作量不减反增。经历了这样一段艰难的时期，大家抱怨很多，所以一开始就有了议论。这一次，希望这个叫Redis的新伙伴能拯救我们。独立缓存——Redis折腾了几天，终于盼来了这个叫Redis的小伙伴！这孩子看起来很有活力。了解情况后，他告诉我们：“三位老哥，以后sessionid跟我一起存起来吧，不要分开存，这不是大家擅长的。”“你还好吗？”老二不太相信他说的话，一脸不屑，“没事的，你试试不就知道了？”接下来，我们按照Redis的建议，不再保存这个烦人的sessionid，全部交给大脑给他，我们会在需要的时候找到他。更何况，这小子个子不高，本事高，而且读写速度极快。令我们头疼的问题终于解决了！Token时代几个月后的一天……“你听说了吗？程序员，我们又要改sessionid的存储方案了。”这天老二神神秘秘的说道。“不行不行，我听到的版本是以后不会再用sessionid了，要改的！”老三也上来了。一旁的redis小哥听了不高兴，“怎么了？你嫌我做的不好？””我也急忙劝道：“你们两个别耍花样，把听到的说出来。老三示意大家围了一些，小声说道：“上次听两个程序员讨论，不知道从哪里学来了一种叫JWT（JSONWebToken）的技术，非要我们管理和保存session太麻烦了ids。很重，我以后不救了！还说，还是说……”“你说什么，你在说什么！“我也说了，Redis不是万能的，有崩溃的风险，一旦崩溃就完了，所以必须要创新技术。”老三继续说道。Redis一听，更加激动着急道：“我工作这么久，从来没有被挑上过。你怎么能这样说我？如果没有，我可以像你一样搭建一个集群。”“Redis哥，你别着急。唉，老三，这个不保存sessionid，以后怎么识别用户呢？你听他们说的了吗？”“听他们说，没有sessionid，而是换了一个token，用来标识用户的”老二一没在意：“是换个名字，但不是药！我们得把信物存起来，这样才能匹配到谁是谁。”老三摇头：“不，不是改个名字那么简单！这个token是由三部分组成的，像这样：""看，第一部分是JWT的基本信息，然后把用户的身份信息放在第二部分，然后结合第一部分做一个计算，在计算中加入一个只有我们自己知道的密钥secretkey，计算结果作为第三部分。最后三部分放在一起，作为最终的token，发送给客户端保存……”老三话没说完，老二就指出了重点：“原来如此，我们稍后会收到这个token的到时候时间，你可以用同样的算法验证前两部分的结果是否与第三部分相同，你就知道token是否是伪造的了！因为只有我们知道密钥，其他人无法伪造令牌！终于确认有效后，拿第二部分用户身份信息，你就知道是谁了！”听完他们的分析，我和Redis小哥默默点头，“有意思，这样一来，我们真的不必须保存！但是现在我们合作的很好，他们为什么要付出那么多的努力？”“我猜他们是想省钱，砍Redis哥！”老二说老三摇头，“在我看来，80%他们中的一些人想向领导展示他们的技术。晋级答辩都快到了，他们还想闹事！哦，老大，你怎么看这个？”“我啊，我……”小伙伴们，你怎么看？session-cookie和JWT，你更喜欢谁？本文转载自微信公众号”编程技术宇宙》，可通过以下二维码关注。转载请联系编程技术宇宙公众号。
