目标1：抢单程序隔离实现

目标2：WebSocket知识学习

目标3：Sentinel限流讲解

目标4：LVS+Nginx集群讲解

用户下单

商品分为热点商品抢单和非热点商品抢单，因此此系统中抢单模式并非一种。

抢单分析

如上图，用户登录后经过nginx，进行抢单，此时会先判断商品是否是热点商品，如果是非热点商品，则直接调用订单系统进行下单操作，如果是热点商品，则向Kafka生产消息进行排队下单，订单系统会订阅排队下单信息，这样可以降低服务器所直接承受的抢单压力，这种操作也叫队列削峰。

非热点商品抢单

我们在订单系统中实现非热点商品抢单操作，非热点商品只用在订单系统中实现抢单即可，但抢单的时候要注意这么几个问题：

1.先递减库存

2.库存递减成功后，执行下单

3.下单失败，需要实现分布式事务

4.下单成功后，要记录用户抢单信息，在24小时内不允许再抢该商品

5.抢单中，有可能存在抢购的商品正好变成了热点商品，此时应该走排队的方式抢单，否则商品数量会发生不精准问题

库存递减

这里我们需要控制数据的原子性，因此不能在内存中进行操作，需要用SQL语句在数据库中执行。

抢单实现

当库存递减成功后，需要给用户直接下单，如果递减不成功，会出现商品变成热卖商品的现象，我们需要向Kafka发送队列数据，所以需要引入Kafka配置。

bootstrap.yml配置kafka：

kafka:

producer:

acks: all #acks:消息的确认机制，默认值是0， acks=0：如果设置为0，生产者不会等待kafka的响应。acks=1：这个配置意味着kafka会把这条消息写到本地日志文件中，但是不会等待集群中其他机器的成功响应。acks=all：这个配置意味着leader会等待所有的follower同步完成。这个确保消息不会丢失，除非kafka集群中所有机器挂掉。这是最强的可用性保证。

retries: 0 #发送失败重试次数，配置为大于0的值的话，客户端会在消息发送失败时重新发送。

batch‐size: 16384 #当多条消息需要发送到同一个分区时，生产者会尝试合并网络请求。这会提高client和生产者的效率。

buffer‐memory: 33554432 #即32MB的批处理缓冲区

key‐serializer: org.apache.kafka.common.serialization.StringSerializer

value‐serializer: org.apache.kafka.common.serialization.StringSerializer

bootstrap‐servers: kafka‐server:9092 #如果kafka启动错误，打开debug级别日志，出现Can't resolve address: flink:9092 的错误，需要在 windows下修改IP映射即可， C:\Windows\System32\drivers\etc\hosts, 192.168.234.128 flink。

consumer:

group‐id: test

auto‐offset‐reset: latest #（1）earliest:当各分区下有已提交的offset时，从提交的offset开始消费；无提交的offset时，从头开始消费；（2）latest:当各分区下有已提交的offset时，从提交的offset开始消费；无提交的offset时，消费新产生的该分区下的数据 ；（3）none：topic各分区都存在已提交的offset时，从offset后开始消费；只要有一个分区不存在已提交的offset，则抛出异常

enable‐auto‐commit: true #如果为true，消费者的偏移量将在后台定期提交。

auto‐commit‐interval: 1000 #消费者偏移自动提交给Kafka的频率 （以毫秒为单位），默认值为5000

max‐poll‐records: 5 #一次拉起的条数

key‐deserializer: org.apache.kafka.common.serialization.StringDeserializer

value‐deserializer: org.apache.kafka.common.serialization.StringDeserializer

bootstrap‐servers: kafka‐server:9092

抢单测试

编写lua脚本控制抢单，当用户处于已登录状态，则执行下单,脚本如下：

在nginx.conf中添加api以及抢单请求路径的路由，配置如下：

热点商品抢单

上面我们完成了非热点商品抢单，接着我们实现以下热点商品抢单。热点商品和非热点商品不一样，热点商品已经隔离出来，在Redis缓存中，并且热点商品抢单要实现高效率操作而且还能抗压，Nginx的并发能力远远超越tomcat，因此热点商品抢单我们可以使用Lua+Nginx。

抢单流程分析

用户进入抢单流程，通过Lua脚本判断令牌是否有效，如果有效，则进入抢单环节，抢单环节执行过程我们做一个分析：

1.判断该商品用户是否在24小时内购买过

2.如果购买了，直接提示用户24小时内无法购买

3.如果用户没有购买过该商品，则判断该商品是否属于热点商品

4.如果是非热点商品，则走非热点商品抢单流程

5.如果是热点商品，则走热点商品抢单流程

6.判断该商品用户是否已经排队，如果没有排队，则进入排队，如果已经排队，则提示用户正在排队

7.下单过程交给订单系统，订单系统通过队列订阅读取用户下单信息，并进行下单

Lua实现Redis操作

判断用户是否在24小时内抢购过该商品，我们可以将用户抢单信息存入到Redis缓存中，定时24小时过期即可，此时需要在Lua里面实现Redis集群操作，需要第三方库的支持 lua-resty-redis-cluster 。我们需要安装 lua-resty-redis-cluster ，下载地址： <
https://github.com/cuiweixie/lua-resty-redis-cluster> ，下载该文件配置后即可实现Redis集群操作。

Lua实现Kafka操作

用户抢单的时候，如果是热点商品，这时候需要实现用户排队，用户排队我们需要向kafka发送抢单信息，因此需要使用Lua脚本操作kafka，我们需要依赖 lua-restry-kafka 库，该库我们也已经配置使用过了，所以这里无需再配置了。

库文件使用：
https://github.com/doujiang24/lua-resty-kafka

以后使用kafka的地方也有可能会有很多，所以针对kafka我们也可以单独抽取出一个配置脚本，创建一个脚本名字叫'kafka.lua'，用于配置kafka的操作，代码如下：

编写一段代码向kafka发送信息，修改 nginx.conf ,添加如下代码：

抢单实现

抢单这里分为2部分，首先需要向Kafka发送抢单信息实现排队，排队后，订单系统订阅抢单信息实现下单操作，所有的数据操作一律在Redis中完成，降低程序对服务器的压力。

排队抢单需要引入redis和kafka，我们的实现思路如下：

1.校验用户令牌，如果不通过直接结束程序提示用户

2.令牌校验通过，从Redis中获取用户在24小时内是抢购过该商品，如果抢购过直接结束程序并提示用户

3.如果符合购买该商品条件，则校验该商品是否是热点商品，如果不是，直接请求后台下单

4.如果是热点商品，并且库存>0，校验用户是否已经在排队，使用redis的incr自增判断排队次数可以去除重复排队

5.如果没有排队，则向Kafka发送消息实现排队

WebSocket实战

目前用户抢单操作我们已经完成，无论是非热点商品还是热点商品抢单，抢单完成后，我们应该要通知用户抢单状态，非热点商品可以直接响应抢单结果，但热点商品目前还没有实现通知响应，通知用户抢单状态用户可以通过定时向后台发出请求查询实现，但这种短连接方式效率低，会和服务器进行多次通信，这块我们可以使用长连接websocket实现。

1 WebSocket介绍

WebSocket 是 HTML5 开始提供的一种在单个 TCP 连接上进行全双向通讯的协议。

WebSocket 使得客户端和服务器之间的数据交换变得更加简单，允许服务端主动向客户端推送数据。在WebSocket API 中，浏览器和服务器只需要完成一次握手，两者之间就直接可以创建持久性的连接，并进行双向数据传输。

现在，很多网站为了实现推送技术，所用的技术都是 Ajax 轮询。轮询是在特定的的时间间隔（如每1秒），由浏览器对服务器发出HTTP请求，然后由服务器返回最新的数据给客户端的浏览器。这种传统的模式带来很明显的缺点，即浏览器需要不断的向服务器发出请求，然而HTTP请求可能包含较长的头部，其中真正有效的数据可能只是很小的一部分，显然这样会浪费很多的带宽等资源。

HTML5 定义的 WebSocket 协议，能更好的节省服务器资源和带宽，并且能够更实时地进行通讯

浏览器通过 JavaScript 向服务器发出建立 WebSocket 连接的请求，连接建立以后，客户端和服务器端就可以通过TCP 连接直接交换数据。

当你获取 Web Socket 连接后，你可以通过 send() 方法来向服务器发送数据，并通过 onmessage 事件来接收服务器返回的数据。

2 Websocket API

创建 WebSocket 对象：

var socket = new WebSocket(url, [protocol] );

WebSocket属性：

WebSocket事件

WebSocket方法

3 WebSocket实例

客户端

WebSocket 协议本质上是一个基于 TCP 的协议。为了建立一个 WebSocket 连接，客户端浏览器首先要向服务器发起一个 HTTP 请求，这个请求和通常的 HTTP 请求不同，包含了一些附加头信息，其中附加头信息"Upgrade:WebSocket"表明这是一个申请协议升级的 HTTP 请求，服务器端解析这些附加的头信息然后产生应答信息返回给客户端，客户端和服务器端的 WebSocket 连接就建立起来了，双方就可以通过这个连接通道自由的传递信息，并且这个连接会持续存在直到客户端或者服务器端的某一方主动的关闭连接。

我们按照上面的API实现客户端代码如下：

服务端

Sentinel限流

Sentinel 目前已经针对 Servlet、Dubbo、Spring Boot/Spring Cloud、gRPC 等进行了适配，用户只需引入相应依赖并进行简单配置即可非常方便地享受 Sentinel 的高可用流量防护能力。Sentinel 还为 Service Mesh 提供了集群流量防护的能力。未来 Sentinel 还会对更多常用框架进行适配。

Sentinel 分为两个部分:

核心库（Java 客户端）不依赖任何框架/库，能够运行于所有 Java 运行时环境，同时对 Dubbo / SpringCloud 等框架也有较好的支持。

控制台（Dashboard）基于 Spring Boot 开发，打包后可以直接运行，不需要额外的 Tomcat 等应用容器。

Sentinel 的关注点在于：

• 多样化的流量控制
• 熔断降级
• 系统负载保护
• 实时监控和控制台

Sentinel和Hystrix对比：

Lvs+Nginx集群配置

Lvs介绍