传统后台管理，在初始化时会在数据中插入超级管理员的初始用户用户名和密码，后续超级管理员通过界面添加普通管理人员的用户名和密码，普通用户再在登录界面输入用户名和密码完成登录。
由于卖家端涉及到的人员定位较少，微信的相关特性为重点。因此微信端设置为扫码登录。在该功能中，项目初始化时，其实是在数据库中添加了有访问权限用户的openId，这样微信授权拉取了用户身份后，如果openId有权限，则放行，否则拒绝。openId相当于用户的密码，用户名不用输入，扫码即可。
常规登录登出：
登录验证用户身份，通过后存储用户相关信息及浏览状态，登出本质是使用户的浏览状态失效。
至关重要的依赖：session
分布式下的session:
分布式系统：旨在支持应用程序和服务的开发，可以利用物理架构由多个自治的处理 元素，不共享内存，但通过网络发送消息合作。–Leslie Lamport
突出了分布式的三个特点：
1.多节点
2.消息通信
3.不共享内存
易混淆的概念：
分布式系统，集群，分布式计算。
厨房，一个洗菜的，一个炒菜的，就是分布式，两个都是炒菜的，就是集群。在本系统中，卖家端买家端，就可以理解为分布式，卖家端同样的程序部署在多台服务器上，就是卖家端集群。
不共享内存，但通过网络发送消息合作的解释：分布式系统中各个节点是通过发送消息来完成通信的，比如http，Resion接口，Rpc。前端通过resapi访问后台程序，获得接口数据，不共享内存：和分布式计算进行区别 这涉及到大数据了，视频中老师举的例子是：两个厨子炒同样的菜，最后放到一个盘子中合成 一盘菜，这时就分不清哪个菜是哪个厨子炒的。
分布式系统与集群的区别和联系：
分布式系统强调不同功能模块的节点，而集群强调相同业务功能的节点。
分布式中的每个节点都可以做集群：卖家端可以部署一个到多个，组成一个集群。集群规模由这个节点的业务规模来决定。
但是集群并不一定是分布式的，比如：前后端不分离，oninon所有业务模块都在一起，就算好多机器做了集群，但是这些节点并不需要消息通信，所以并不是分布式的。
Session：
有时候说的session比较狭义，http session，J2EE接口
针对本系统此时的session：
广义：即会话控制，http协议无状态，对同一个url请求并没有上下文关系。当用户完成登录时，需要有一个机制，能够保存用户的信息和状态，在后续的请求中能够验证用户的身份和检查用户信息，这个依赖就是会话控制session。
另一个角度看session：可以理解为一种保存key-value的机制，session机制中的关键点第一是如何设置和获取key，第二点如何能够保存和正确获取对应的value
key： sessionId和token
sessionId: 客户端请求服务端时，服务端通过SetCookie就可以在http头中设置sessionId的key和对应的value值，
而客户端的cookie会将其保存，后续请求中会自动带上，token：需要手动在http head头里或者url里设置token这个字段，服务器收到请求之后，再从head或url中取出token进行验证。
安全方面要求严格时：token需配合签名一起使用。
无论是sessionId还是token都是全局唯一的，一个用户一个标识，本质就是一个key。key对应的用户信息就是value；
无论key或value，一方没有保持住， 就可能分辨不出用户的身份，获取不到用户的信息，如依赖sessionId时，用户进入了cookie，有可能造成系统不断的让其重新登录，value一方就可能保持不住，因为：分布式系统中的session问题：用户请求通过Nginx到达Tomcat，Tomcat部署一个应用，这时session是保存在这个Tomcat应用的内存中。
那么当一个Tomcat扛不住时，考虑加多台Tomcat服务器，程序该怎么放？
水平扩展（集群）或者垂直（拆分服务：A有类目商品和订单三个服务，分别部署到不同的服务器上，之后配置Nginx，负载均衡，这样单台服务器压力会小），或者综合。
但是session问题依然存在，如：用户第一次访问A服务器，此时A使用了用户的session，接着用户做第二个请求，由于负载均衡，请求可能到了服务器A1，但是服务器A1上并没有用户的session信息，所以以为该用户没登录。
通用方案：专门的服务保存session信息，其他服务使用session信息实都找他要。通常用redis集群或者主从复制去做的。开发测试时单机版即可。这样无论水平还是垂直， 任何一个应用都可以通过用户的唯一标识来找到用户对应的信息，从而进行后续操作。登录时设置好key，保存好这个用户的信息即value， 登出时让value失效即可。
