高可扩展性高实时性（最多允许响应几十毫秒）业务逻辑应该是无状态的还是有状态的？
我知道这听起来很普遍的问题，但我真的对无状态服务感兴趣，我想知道它是否可以或不能在这些限制（无状态）下完成。 例如谷歌有很多服务。 我更关心那些需要非常非常快地返回结果（最多几十毫秒）的服务，并且它们有大量分散的数据（也许它们在某个地方保存了即时摘要）。 在这些情况下，任何人都可以判断他们的“业务逻辑”服务器是无状态的还是有状态的？无状态可能具有将状态简单地移动到存储层（gfs/memcached/bigtable）的优点，但是对于有状态，如果将请求传输到同一节点，那么您可以从内部存储器中快速获得结果。有人有过这种巨大的可扩展性和巨大的实时问题的经验吗？
I know it sounds very general question, but i'm really interested in having stateless services i want to know if it can or cannot be done with these limitations (stateless).
for example google has many services.
I'm more concerned about the services where they need to return results very very fast (a few tens of milliseconds at most) and they have huge data scattered (maybe they keep a summary someowhere for immediate).
in these cases can anyone tell if their "business logic" servers are stateless or statefull? stateless might have the benefit of simplicity moving the state to the storage layer (gfs/memcached/bigtable) however with stateful if you transfer the requests to same node then you could have the result in a snap from internal memory. anyone has experience with this kind of huge scalability huge realtime issues?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如前所述，无状态服务更容易扩展 - 但您应该注意，无状态意味着您可以解决其他人的问题（数据库、分布式缓存等）。如果他们可以处理负载，并且延迟、带宽等都支持您有能力使您的服务无状态并获得好处。
如果在您的项目（例如预算）的限制内，您无法让其他人解决状态问题，您就必须使您的服务有状态
As noted stateless services are easier to scale - but you should note that Stateless means you make the state someone else's problem (the DB, the distributed cache etc.) If they can handle the load and the latencies, bandwidths etc. are all supportive you can afford to make your service stateless and get the benefits.
If, within the constraints of your project (e.g. budget) you can't have someone else solve the state problem you'd have to make your services stateful
只是无国籍。有状态服务服务很难扩展，因为在这种情况下您必须处理状态同步。
Only stateless. Stateful services services are very hard to scale as you have to deal with synchronization of state in that case.