【秒杀系统】分布式扩展

Nginx 反向代理负载均衡

单机容量问题，水平扩展

表象：单机 cpu 使用率增高，memory 占用增加，网络带宽使用增加
cpu us：用户空间的 cpu 使用情况 (用户层代码)
cpu sy：内核空间的 cpu 使用情况 (系统调用)
load average：1, 5, 15 分钟 load 平均值，跟着核数系数，0 代表通常 1 代表打满 1+ 代表等待阻塞
memory：free 空闲内存，used 使用内存

nginx反向代理

make
make install

动静分离 负载均衡配置

动态资源的配置

除了 /resourse 之外的都当做动态资源处理

重新加载配置

Nginx 高性能的原因

• epoll多路复用

java bio 模型，阻塞进程式

linux select 模型，变更触发轮训查找（其中任何一个变化我都要轮询遍历一遍效率非常低），有1024数量上限

epoll模型，变更触发回调直接读取,理论上无上限

• master worker进程模型

启动了master进程之后，创建socket文件句柄监听在80端口上面，启动epoll多路复用模型，client发送请求会建立tcp/ip三次握手会向socket的80窗口发送connect的操作，这个时候epoll模型会产生一个回调，这个时候master是不会去处理请求的而是让worker进程去处理（worker进程会抢占内存锁成功后调用socket的accept方法完成这次客户端的请求连接）

这种方式是非常高效的，master只处理管理员的信号把请求连接交给worker进程处理，如果worker进程死亡，master会马上接管权限并创建新的worker进程

worker进程只有一个线程，如果线程内部没有任何的阻塞操作的，那对应的单线程调用比多线程的调用更快，阻塞操作会交给epoll模型管理调用

• 协程机制

依附于线程的内存模型,切换开销小

遇阻塞及归还执行权,代码同步

无需加锁

总结：
依靠epoll多路复用，解决IO阻塞回调通知的问题；依靠master worker进程模型平滑过渡重启；基于协程机制将每一个用户的请求对应到协程中，在协程中使用epoll多路复用来完成同步调用的开发

分布式会话管理

基于cookie传输sessionid : java tomcat容器session实现

jssionId就是tomcat返回内嵌cookie的标识，jssionId对应到tomcat内，就是获取用户对应session的

基于token传输类似sessionid : java代码session实现

分布式环境下，这两种方式都是不生效的，单体是对tomcat内存去做实现的，session没有做集中式管理只存在于一台服务器上不能共享

使用redis实现分布式会话存储

我们需要将基于 java tomcat 容器 session 实现迁移到 redis，redis是一个集中式的缓存中间件是分布式会话存储的不二之选

工程引入依赖，引入了这两个jar包，springboot就会把session存储到redis中

    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-data-redis</artifactId>
    </dependency>
    <dependency>
      <groupId>org.springframework.session</groupId>
      <artifactId>spring-session-data-redis</artifactId>
      <version>2.0.5.RELEASE</version>
    </dependency>

@Component
@EnableRedisHttpSession(maxInactiveIntervalInSeconds = 3600)
public class RedisConfig {
}

#配置springboot对redis的依赖
spring.redis.host=127.0.0.1
spring.redis.port=6379
spring.redis.database=10
#spring.redis.password=

#设置jedis连接池
spring.redis.jedis.pool.max-active=50
spring.redis.jedis.pool.min-idle=20

两台服务器部署redis，打成jar包重新上传到服务器替换原jar包

修改redis配置文件

基于token传输类似sessionid

更改用户下单controller

@Controller("order")
@RequestMapping("/order")
@CrossOrigin(origins = {"*"},allowCredentials = "true")
public class OrderController extends BaseController {
    @Autowired
    private OrderService orderService;

    @Autowired
    private HttpServletRequest httpServletRequest;

    @Autowired
    private RedisTemplate redisTemplate;

    //封装下单请求
    @RequestMapping(value = "/createorder",method = {RequestMethod.POST},consumes={CONTENT_TYPE_FORMED})
    @ResponseBody
    public CommonReturnType createOrder(@RequestParam(name="itemId")Integer itemId,
                                        @RequestParam(name="amount")Integer amount,
                                        @RequestParam(name="promoId",required = false)Integer promoId) throws BusinessException {

        //Boolean isLogin = (Boolean) httpServletRequest.getSession().getAttribute("IS_LOGIN");
        String token = httpServletRequest.getParameterMap().get("token")[0];
        if(StringUtils.isEmpty(token)){
            throw new BusinessException(EmBusinessError.USER_NOT_LOGIN,"用户还未登陆，不能下单");
        }
        //获取用户的登陆信息
        UserModel userModel = (UserModel) redisTemplate.opsForValue().get(token);
        if(userModel == null){
            throw new BusinessException(EmBusinessError.USER_NOT_LOGIN,"用户还未登陆，不能下单");
        }


        //UserModel userModel = (UserModel)httpServletRequest.getSession().getAttribute("LOGIN_USER");

        OrderModel orderModel = orderService.createOrder(userModel.getId(),itemId,promoId,amount);

        return CommonReturnType.create(null);
    }
}