我们利用 redis 原生 set 来实现分布式锁，之后会不断改进来解决一些死锁问题
我们的项目是部署到内网的，其中 nginx 帮我们进行反向代理，当用户访问 doermall.com 的时候，我们可以利用 nginx 将请求转发给商品服务 192.168.2.100:9200 服务
本文只是尝试 nginx 反向代理教学，负载均衡请看**Nginx 负载均衡地反向代理**
Elastcisearch 是分布式的文档存储。它能以实时的方式存储和检索复杂的数据结构——序列化成为JSON 文档。换句话说，一旦一个文档被存储在 Elasticsearch 中，它就是可以被集群中的任意节点检索到。
尽管现存的 NoSQL 解决方案允许我们以文档的形式存储对象，但是他们仍旧需要我们思考如何查询我们的数据，以及确定哪些字段需要被索引以加快数据检索。在 Elasticsearch 中， 每个字段的所有数据都是默认被索引的 。 即每个字段都有为了快速检索设置的专用倒排索引。而且，不像其他多数的数据库，它能在 同一个查询中 使用所有这些倒排索引，并以惊人的速度返回结果。
ES 的底层是开源库 Lucene，ES 是对 Lucene 的封装，对外提供了REST API的操作接口，外部调用就是向 ES 发送请求即可，做到开箱即用。
前面我们后端数据校验每个 controller 校验的 bean 的属性上添加上校验注解，然后在 controller 入参上加上@Valid 注解，然后通过紧跟着的 BindingResult 来进行获取校验的结果，如果错误则返回给前端，否则正常入库。这样有一个弊端就是每个 controller 都需要进行一套将错误信息封装到 Request 中的过程，这是十分重复的。我们可以利用 Advice 来解决。
- 那么我们如果获取数据校验错误的信息 呢？
如果我们不添加 BindResult 来绑定抛出的结果的话，controller 则会把异常抛出，我们可以通过抛出的特定异常**@ExceptionHandler**来捕捉
- 如何获取 Controller 层发出的异常
通过注解**@ControllerAdvice或@RestControllerAdvice**注解