目录
41.常见的JOB实现方案？
42.Cookie和Session有什么区别？
43.谈谈会话技术的发展？
44.分布式会话有哪些解决方案？
45.什么是Session Stick？
41.常见的JOB实现方案？
基于上面Java任务演化出分布式Job方案：
quartz
JDBCJobStore 支持集群所有触发和Job都存储在数据库中无论服务器停止和重启都可以恢复任务同时支持事务处理
elastic job
elastic job是由当当网基于quartz二次开发之后的分布式调度解决方案，由两个相对独立的子项目Elastic Job Lite和Elastic JOB Cloud 组成。
Elastic Job Lite 定位为轻量级无中心化解决方案，使用jar包的形式提供分布式任务的协调服务。
Elastic Job Cloud使用Mesos+Docker（TBD)的解决方案，额外提供资源治理，应用分发以及进程隔离等服务
两点：
1.基于quartz定时任务框架为基础的，因此具备quartz的大部分功能
2.使用zookeeper做协调，调度中心，更加轻量级
3.支持任务的分片
4.支持弹性扩容，可以水平扩展，当任务再次运行时，会检查当前的服务器数量，重新分片，分片结束之后才会继续执行任务。
5.失效转移，容错处理，当一台调度服务器宕机或者跟zookeeper断开连接后，会立即停止作业，然后再去寻找其他空闲的调度服务器，来运行剩余的任务。
6.提供运维界面，可以管理作业和注册中心。
xxl job
一个轻量级分布式任务调度框架，主要分为调度中心和执行器两部分，调度中心在启动初始化的时候，会默认生成执行器的RPC代理
对象（http协议调用），执行器项目启动之后，调度中心在触发定时器之后通过jobHandle来调用执行器项目里面的代码，核心功能和elastic job差不多
42.Cookie和Session有什么区别？
Cookie和Session的方案虽然分别属于客户端和服务端，但是服务端的session的实现对客户端的cookie有依赖关系的，服务端执行session机制时候会生成session的id值，这个id值会发送给客户端，客户端每次请求都会把这个Id值放到http请求的头部发送给服务器，而这个id值在客户端会保存下来，保存的容器就是cookie,因此当我们完全禁掉浏览器的cookie的时候，服务端的session也会不能正常使用。
43.谈谈会话技术的发展？
单机 Session+Cookie
多机器
在负载均衡侧 Session粘滞
Session数据同步
多机器，集群，session集中管理，比如redis;目前方案上用的最多的是SpringSession，早前也有用tomcata集成方式的。
无状态token,比如JWT
44.分布式会话有哪些解决方案？
Session Stick
Session Replication
Session数据集中存储
Cookie Based
JWT
45.什么是Session Stick？
方案即将客户端的每次请求都转发至同一台服务器，这就需要负载均衡器能够根据每次请求的会话标识（Session ID）进行请求转发，如下图所示。
这种方案实现比较简单，对于Web服务器来说和单机的情况一样。但是可能会带来如下问题：
如果有一台服务器宕机或者重启，那么这台机器上的会话数据会全部丢失。
会话标识是应用层信息，那么负载均衡要将同一个会话的请求都保存同一个Web服务器上的话没救需要进行应用层（第7层）的解析，这个开销比第4层大。
负载均衡器将编程一个有状态的节点，要将会话保存到具体的web服务器的映射。和无状态节点相比，内存消耗更大，容灾方面也会更麻烦。
PS：为什么这种方案到目前还有很多项目使用呢？因为不需要在项目代码侧改动，而是只需要在负载均衡侧改动。
