下文是对微信点餐系统项目的总结，使用 Spring Boot 开发，采用前后端分离架构，针对此项目技术细节给出具体解释，同样会分享源码给大家，可以关注微信公众号：Java后端，回复 点餐，即可获取源码地址。本文作者 Tommmmm 欢迎点击阅读原文访问作者博客。

前后端分离:

部署架构：

Nginx与Tomcat的关系在我的这篇文章，几分钟可以快速了解：

https://www.jianshu.com/p/22dcb7ef9172

补充：

setting.xml 文件的作用：settings.xml是maven的全局配置文件。而pom.xml文件是所在项目的局部配置。Settings.xml中包含类似本地仓储位置、修改远程仓储服务器、认证信息等配置。

maven的作用：借助Maven，可将jar包仅仅保存在“仓库”中，有需要该文件时，就引用该文件接口，不需要复制文件过来占用空间。

注：这个“仓库”应该就是本地安装maven的目录下的Repository的文件夹

分布式锁

线程锁：当某个方法或代码使用锁，在同一时刻仅有一个线程执行该方法或该代码段。线程锁只在同一JVM中有效，因为线程锁的实现在根本上是依靠线程之间共享内存实现的。如synchronized

进程锁：为了控制同一操作系统中多个进程访问某个共享资源。

分布式锁一般有三种实现方式：1. 数据库乐观锁；2. 基于Redis的分布式锁；3. 基于ZooKeeper的分布式锁。

乐观锁的实现：使用版本标识来确定读到的数据与提交时的数据是否一致。提交后修改版本标识，不一致时可以采取丢弃和再次尝试的策略。

分布式锁基于Redis的实现：(本系统锁才用的)

基本命令：

1. SETNX（SET if Not exist）：当且仅当 key 不存在，将 key 的值设为 value ，并返回1；若给定的 key 已经存在，则 SETNX 不做任何动作，并返回0。

2. GETSET：将给定 key 的值设为 value ，并返回 key 的旧值。先根据key获取到旧的value，再set新的value。

3. EXPIRE 为给定 key 设置生存时间,当 key 过期时，它会被自动删除。

Tips：欢迎订阅公众号 Java后端，接受每日技术博文推送。

加锁方式：

这里的 jedis 是Java对Redis的集成

错误的加锁方式1：如果程序在执行完setnx()之后突然崩溃，导致锁没有设置过期时间。那么将会发生死锁。

错误的加锁方式2：分布式锁才用（Key，过期时间）的方式，如果锁存在，那么获取它的过期时间，如果锁的确已经过期了，那么获得锁，并且设置新的过期时间

错误分析：不同的客户端之间需要同步好时间。

解锁：判断锁的拥有者后可以使用  jedis.del(lockKey) 来释放锁。

分布式锁基于Zookeeper的实现

Zookeeper简介：Zookeeper提供一个多层级的节点命名空间（节点称为znode），每个节点都用一个以斜杠（/）分隔的路径表示，而且每个节点都有父节点（根节点除外）。例如，/foo/doo这个表示一个znode，它的父节点为/foo，父父节点为/，而/为根节点没有父节点。

client不论连接到哪个Server，展示给它都是同一个视图，这是zookeeper最重要的性能。

Zookeeper 的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和 leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。

为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务，实现中zxid是一个64位的数字。

Zookeeper的分布式锁原理

获取分布式锁的流程：

1. 在获取分布式锁的时候在locker节点(locker节点是Zookeeper的指定节点)下创建临时顺序节点，释放锁的时候删除该临时节点。

2. 客户端调用createNode方法在locker下创建临时顺序节点，然后调用getChildren(“locker”)来获取locker下面的所有子节点，注意此时不用设置任何Watcher。

3. 客户端获取到所有的子节点path之后，如果发现自己创建的子节点序号最小，那么就认为该客户端获取到了锁。

4. 如果发现自己创建的节点并非locker所有子节点中最小的，说明自己还没有获取到锁，此时客户端需要找到比自己小的那个节点，然后对其调用exist()方法，同时对其注册事件监听器。

5. 之后，让这个被关注的节点删除，则客户端的Watcher会收到相应通知，此时再次判断自己创建的节点是否是locker子节点中序号最小的，如果是则获取到了锁，如果不是则重复以上步骤继续获取到比自己小的一个节点并注册监听。

我的解释：A在Locker下创建了Node_n —>循环 ( 每次获取Locker下的所有子节点 —> 对这些节点按节点自增号排序顺序 —> 判断自己创建的Node_n是否是第一个节点 —> 如果是则获得了分布式锁 —> 如果不是监听上一个节点Node_n-1 等它释放掉分布式锁。)

@ControllerAdvice处理全局异常

Mybatis注解方式的使用：

分布式系统的下的Session

1、分布式系统：多节点，节点发送数据交互，不共享主内存，但通过网络发送消息合作。

分布式：不同功能模块的节点

都是一个用户一个标志

3、分布式系统中的Session问题：

高并发：通过设计保证系统能够同时并行处理很多请求。

当高并发量的请求到达服务端的时候通过负载均衡的方式分发到集群中的某个服务器，这样就有可能导致同一个用户的多次请求被分发到集群的不同服务器上，就会出现取不到session数据的情况

根据访问不同的URL，负载到不同的服务器上去

通用方案：用Redis保存Session信息，服务器需要时都去找Redis要。登录时保存好key-value，登出时让他失效

垂直扩展：IP哈希  IP的哈希值相同的访问同一台服务器

session的一致性：只要用户不重启浏览器，每次http短连接请求，理论上服务端都能定位到session，保持会话。

Redis作为分布式锁

高并发：通过设计保证系统能够同时并行处理很多请求。

同步：Java中的同步指的是通过人为的控制和调度，保证共享资源的多线程访问成为线程安全。

线程的Block状态：join() 和 sleep() 方法，sleep() 时间结束或被打断

此外，在runnable状态的线程是处于被调度的线程，Thread类中的yield方法可以让一个running状态的线程转入runnable。

Q：为什么wait,notify和notifyAll必须与synchronized一起使用？

Q：Synchronized：

公平和非公平锁的队列都基于锁内部维护的一个双向链表，表结点Node的值就是每一个请求当前锁的线程。公平锁则在于每次都是依次从队首取值。

ReentrantLock重入性：

Spring + Redis缓存的两个重要注解：

对数据库加锁

这条sql 语句锁定了account 表中所有符合检索条件（name=”Erica”）的记录，使该记录在修改期间其它线程不得占有

代码层加锁：

其它

JAVA1.8的新特性StreamAPI：Collectors中提供了将流中的元素累积到汇聚结果的各种方式

For - each 写法：

for each虽然能遍历数组或者集合，但是只能用来遍历，无法在遍历的过程中对数组或者集合进行修改。

BindingResult：一个@Valid的参数后必须紧挨着一个BindingResult 参数，否则spring会在校验不通过时直接抛出异常

后台：

result.getFeildError.getDefaultMessage()可抛出“姓名必填” 的异常。

4、List转为Map

5、Collection的子类：List、Set

List：ArrayList、LinkedList 、Vector

Set：元素是无序的，不允许元素

HashMap的补充：它不是Collection下的

插入过程：通过一个hash函数确定Entry的插入位置index=hash(key),但是数组的长度有限,可能会发生index冲突，当发生了冲突时，会使用头插法，即为新来的Entry指向旧的Entry，成为一个链表。

为何加载因子默认为0.75？（0.75开始扩容）

源码地址：

喜欢文章，点个在看