分布式架构的优势从目前来看，分布式架构的特点是高并发性和高稳定性。分布式架构下的会话共享也可以称为分布式会话一致性。关于这个问题，我们来谈谈解决方案。如果有其他解决方法，可以留言讨论。前段时间研究了两个分布式任务调度框架，一个是XXL-Job，现在很主流，很多常见的公司都在用，比如滴滴美团。这也是一款开源产品，下载导入到IDEA后就可以使用了。它有一个调度器、执行器和管理UI，有一个漂亮的UI界面，可以添加、删除和检查任务，支持自定义开发。有非常详细的帮助文档，还提供了demo。
分布式任务调度框架选型，如何选择一个合适的框架？
前端时间研究了两款分布式任务调度框架，一个是XXL-Job，现在非常主流，很多常见的一些公司都在使用，像滴滴美团这样的公司都在用，这也是一款开源产品，下载下来导入IDEA就可以使用，分调度器和执行器和管理UI，有很美观的UI界面，可以对任务做增删改查，以及支持自定义开发，有很详细的帮助文档，还提供有demo，傻瓜式的，很简单，亮点是提供了管理界面。
分布式架构下，session共享有什么方案么？
分布式架构下的session共享，也可以称作分布式session一致性关于这个问题，和大家说一说解决方案如果有其他的方案，可以留言讨论。session的作用如果大家做过web应用开发的话，应该对session比较熟悉服务器会为每个用户创建一个会话，存储用户的相关信息，以便在后面的请求中，可以够定位到同一个上下文。
例如用户在登录之后，再进行页面跳转的时候，存储在session中的信息会一直保持，如果用户还没有session，那么服务器会创建一个session对象，直到会话过期或主动放弃后退出，服务器才会把session终止掉。分布式架构中的session问题在N年前，那个都是单个服务器的年代，session直接保存在服务器中，是一点问题没有的，而且实现起来很容易。
但是随着分布式架构的流行，单个服务器已经不能满足系统的需要了，通常都会把系统部署在多台服务器上，通过负载均衡把请求分发到其中的一台服务器上，这样很可能同一个用户的请求被分发到不同的服务器上，因为session是保存在服务器上的，那么很有可能第一次请求访问的A服务器，创建了session，但是第二次访问到了B服务器，这时就会出现取不到session的情况。
于是，分布式架构中，session共享就成了一个很大的问题。解决方案不要有session大家可能觉得我说了句废话，但是确实在某些场景下，是可以没有session的，其实在很多接口类系统当中，都提倡API无状态服务也就是每一次的接口访问，都不依赖于session不依赖于前一次的接口访问存入cookie中将session存储到cookie中，但是缺点也很明显，例如每次请求都得带着session，数据存储在客户端本地，是有风险的session同步对个服务器之间同步session，这样可以保证每个服务器上都有全部的session信息，不过当服务器数量比较多的时候，同步是会有延迟甚至同步失败使用Nginx或其他复杂均衡软硬件中的ip绑定策略，同一个ip只能在指定的同一个机器访问，但是这样做风险也比较大，而且也是去了负载均衡的意义我们现在的系统会把session放到Redis中存储，虽然架构上变得复杂，并且需要多访问一次Redis，但是这种方案带来的好处也是很大的实现session共享，可以水平扩展增加Redis服务器，服务器重启session不丢失不过也要注意session在Redis中的刷新/失效机制，不仅可以跨服务器session共享，甚至可以跨平台例如网页端和APP端。
有多少互联网系统确实需要使用分布式架构？
不谈互联网的实际发展。现在即使面试应届毕业生，分布式的问题也基本不可避免。分布式架构简介在最简单的架构中，可以通过部署多个功能相似的服务器节点来实现分发。在实际应用中，只有一个域名暴露给用户，这个域名的地址通常对应一个Nginx，用于负载均衡。Nginx收到请求后，会根据当前情况将请求分配给不同的服务器节点进行响应。
