@hantsy 没说它们死掉，但是门面已经没了。

因特尔纯属自己把自己作死的，已经开始没落了，下一个诺基亚就在眼前。

能做 web 服务端的语言太多了，去学 go 也没跳出这个圈子，想靠多技能混饭吃，那也得去学前端，用不了两年 go 也饱和了。

这么多台服务器，一般不能才 1000 多 qps 。

感觉你这问题不是很难的样子，看看硬件资源消耗，再多看看各种日志，应该就能找到问题所在。

@ZSeptember 今天回答的问题太多，算了，就这样吧，没必要再讨论了，恐怕也讨论不出给所以然来。

@wzwb 服务端存的是资源和资源的状态，你却在纠结服务端数据库里面有保存数据，就是中心化，就是有状态。哪个人敢站出来说无状态就是不能在数据库里面存数据？你这是开始扯皮了？？？

@wzwb 这是客户端发送的请求头部啊，这有服务端什么事么？你真的知道这个是什么么？

@wzwb 你说的不是就会话么，而且是就是客户端会话，只不过借助 JWT 实现了，所以我才说你一直没离开会话，而我想讨论的就是完全离开会话，包括服务端会话和客户端会话。我这种 JWT，就是做认证用户的，多余的什么都没有，服务端也不保存，交互状态我也认为应该和 JWT 一样，都存在客户端，服务端什么都没有，根本就不存在中心化的问题，哪里来的单点和水平扩展问题。

算了算了，没啥好讨论的了。

@wzwb 大家公认的 Authentication: Basic username:password 这种是 RESTful 的，这种没去根据用户名和密码查询么？为了不在每次请求中都传输账户和密码，所以发明了令牌代替用户名和密码来做认证，所以有啥问题？

你能试着先把会话那一套东西忘掉么，要不然就没办法聊了，每说两三句，你的思路就回到会话那边去了。

@wzwb 你自己到底要用服务端会话还是不用？如果你选择不用，那你说的由服务器返回历史数据从何谈起？如果你选择用服务端会话，那就没啥要讨论的了。

在用户做选择的时候一个请求发给服务端，告诉服务端客户选了哪个角色当作自己的全局默认角色不就可以了，服务端把这种角色保存起来就可以了，而且这种数据也不应该保存在服务端会话中，这应该保存在数据库中吧。

@ZSeptember JWT 里面就一个用户标识和过期时间，然后存在客户端本地存储，用户当前所选的角色也存在客户端本地存储，每次向服务端发送请求，直接把 JWT 放在 Authentication 头中，把当前所选的角色放在请求参数或者主题中即可。如果有人把客户端选的角色删了，本次请求也验证不过啊，返回一个业务状态码就能和客户端说清楚了啊，所以有什么好担心的呢？

在服务端看来所谓的登陆就是创建一个令牌资源，令牌资源能创建，当然就该保存，当然也就能删除。服务端颁发 JWT 后，它确实能通过防篡改、伪造的检查，但 JWT 只不过是一个壳，真正重要的是 payload 里面的 jwt id，它可以用来识别用户，也可以被回收。

@wzwb 发起确实是用户发起，然后告知客户端，然后客户端发给服务端，然后服务端生成会话数据，然后发回到客户端保存，然后下次客户端再自动发回给服务端。第四句就是生成，然后你不觉得第三句到第五句是在兜圈子么？客户端都知道用户在交互中的选择了，干嘛还要发给服务端，直接自己保存不好么，然后每次请求都发给服务端，服务端直接用不就成了。

@ZSeptember 我这里不是说 token 啊，做认证的 token 当然在服务端生成，这没毛病。但是交互过程中又不仅仅登陆这一种“状态”，还有各种交互状态，很多人说把这些状态全部丢到客户端，就比如直接丢到 JWT 中。

还是拿我上面举过的例子来说吧。

比如，我有一个账户，即属于运营人员角色，又属于某种管理人员角色，但运行时角色只能二选一，即角色运行时互斥。比如服务端通过一个接口返回可选的角色，客户端把这些角色展现给用户，然后用户选择某个角色，客户端再把用户的选择（即所谓的“状态”）保存在客户端本地存储中，后面每次请求带上该角色（状态）即可。

注意，这个状态可不是服务端在服务端代码里面生成，然后再丢到响应头或者主体里面返回给客户端的，就是地地道道客户端自己生成并保存到客户端本地存储中的。你能说这种有问题么？再者服务端当然不会信客户端的数据啊，但是服务端本来就该做验证啊，比如验证用户是谁，存不存在，权限够不够等等，客户端发篡改的数据过来，服务端验证也过不了。

@lihongming 你说到 AWS 的情况，我猜测可能是 AWS 引入了 RBAC 模型，并且角色与会话绑定了，才会引发不得不这么做。

比如，我有一个账户，即属于运营人员角色，又属于某种管理人员角色，但运行时角色只能二选一，即角色运行时互斥，那就要这么做了。此时，如果我有两个浏览器，都用这个账号登陆，一个浏览器登陆后选择运营人员，一个浏览器登陆后选择管理人员，那用这种把 JWT 当作客户端会话的方法就很合适。

但是反过来，不在 JWT 中放入角色，也可以轻松实现同样的目的。比如服务端通过一个接口返回可选的角色，客户端展现，然后用户选择，客户端再把用户的选择（即所谓的“状态”）保存在客户端本地存储中，后面每次请求带上该角色（状态）即可。

这两种方法，都把状态存在了客户端而不是服务端，这是是没问题的。但区别是一个是服务端发起的保存和读取操作，另外一个是客户端自己发起保存和读取操作。很类似，但我个人确实觉得服务端发起和保存和读取操作，比较别扭，可能是我思维有点固化，没转变过来吧。

@libook 我和你的观点整体上是类似的。

@icyalala 我没有否定，也不敢轻易否定，但是确实有质疑，质疑一下没毛病吧。

@acmore 状态放在客户端没毛病，但是状态不应该“由服务端生成，然后放在客户端”，应该“由客户端生成，然后放在客户端”。

@kop1989 我当然知道要有状态，我也知道放在服务端不对，应该放在客户端，但是我觉得这些状态不应该由服务端生成和读取，应该由客户端自己生成本次交互过程的状态并存在本地存储，然后客户端发起请求时，从本地存储中取出来直接告知服务端，而不是“我把交互状态都发给你了，你自己看着选用吧”。

@msg7086 那就是了，完全是服务端在把控的东西（只不过存在客户端），还能说服务端“无状态”么？