消息中间件RabbitMQ

2018-07-07

一、消息中间件RabbitMQ

1、RabbitMQ介绍

RabbitMQ是一个开源并实现了高级消息队列协议(AMQP)的消息中间件，支持单一节点部署，也支持多个节点的集群部署。
RabbitMQ提供了后端管理控制台，用来实现RabbitMQ的队列，交换机，路由，消息和服务节点的管理。
RabbitMQ可以通过客户端管理相应的用户，主要是分配相应的操作权限和数据管理权限

2、RabbitMQ应用场景

RabbitMQ实现了高性能存储分发消息的分布式中间件，它的作用如下图

2.1、异步通信和服务解耦

1、以用户注册为场景，传统的方式用户注册过程如下

分析用户注册流程，核心业务就是判断用户注册信息的合法性以及把用户信息写入到数据库。
发送邮件，短信验证码服务不归属用户注册的核心流程，可以使用消息中间件进行异步通信，将这一块解耦出来。

2、引入RabbitMQ消息中间件后用户注册的流程

3、好处

引入RabbitMQ，可以将一条业务线走到底，系统的接口的整体响应时间明显降低，实现了低延迟，给用户带啦很好的体验效果。

2.2、接口限流和消息分发

1、以电商网站商品抢购活动的传统处理流程

分析抢购活动开始的那一刻，将会产生巨大的用户抢购流量，请求几乎在同一时刻到达后端系统接口。
首先校验用户和商品信息的合法性，校验通过后
会判断当前商品的库存是否重组，如果充足，代表当前用户将能成功抢购
最后将用户抢购成功的相关数据保存到数据库
异步通知用户抢购成功，尽快进行付款

分析发现后端接口在处理用户抢购整体业务流程太长，业务处理逻辑，先取出库存然后进行判断，然后进行减1更新。在高并发情况下，会导致商品超卖，数据不一致，用户等待时间过长，系统接口直接挂了，如果是商品抢购，商品秒杀等某一时刻产生高并发的请求就不行了。

2、引入RabbitMQ的商品抢购流程

引入RabbitMQ主要用来优化系统如下：
- 接口限流：当前端产生高并发请求的时候，不会立刻到达后端接口，而是先将请求按照先来后到加入到RabbitMQ队列，一定程度上实现接口限流。
- 消息异步分发：当商品库存充足，当前抢购的用户将可以抢到商品，然后会异步发送短信通知用户抢购成功，然后告知用户付款，一定程度上实现消息异步分发。

2.3、业务延迟处理

1、实际场景分析

以12306抢票来分析，春运的时候12306抢票抢到车票的时候，12306会提醒用户，请在30分钟内付款。
正常情况用户会立刻付款，然后付款成功12306会发短信通知。
然而也存在一些特殊情况，比如抢到车票的用户迟迟没有付款，过了30分钟，系统会自动取消这笔订单。
需要延迟一定的时间后再进行处理的业务在实际生产环境常见。

2、传统处理方式-采用定时器

传统处理方式采用一个定时器定时的去获取用户没有付款的订单，然后判断用户的下单时间距离当前时间是否超过30分钟，超过没有付款则设置订单失效。
- 分析发现，春运抢票可以看做是一个大数据量，高并发请求场景，如果定时器频繁的从数据库获取未付款状态的订单，数据量非常大，假如有大量用户在30分钟内没付款，那么数据库中获取数据量一直增长，达到一定程度，给数据库服务器和应用服务器带来巨大的压力，直接压跨服务器，导致抢票全线崩溃。
- 早期12306网站每次赶上春运，经常出现网站崩溃卡顿无响应等状态，因为某一时刻产生高并发，定时频繁拉取数据库得到数据量过大，导致内存，CPU，网络和数据库服务负载过高导致的。

2、引入RabbitMQ优化

优化流程看出，RabbitMQ的引入主要替代传统处理流程的定时器处理逻辑，而采用RabbitMQ的延迟队列来进行处理。
延迟队列：可以延迟一定的时间后再处理相应的业务逻辑
常见的成功抢到票30分钟没付款流程，商城抢购没有在规定时间付款，点外卖下单成功后，没有在规定时间付款的流程，都是用RabbitMQ的延迟队列来实现。

3、RabbitMQ的简单使用

由于我本地使用docker来运行RabbitMQ，如何使用docker安装RabbitMQ以及运行，请点击链接看我这篇博客
运行好RabbitMQ后，然后浏览器输入访问地址(http://localhost:15672/)
默认用户名密码都为guest/guest，即可进入RabbitMQ管理后台

展开全文 >>

Redis应用场景之抢红包系统(四)

2018-06-21

一、Redis应用场景之抢红包系统(四)

1、Jmeter压力测试高并发抢红包

Apache Jmeter是Apache组织开发的基于Java的压力测试工具。可以用来模拟生产环境中高并发产生的巨大负载。
下载链接

下载好后，解压运行Jmeter

cd ~/下载/软件安装包
tar -zxvf apache-jmeter-5.2.1.tgz
cd apache-jmeter-5.2.1
cd bin
./jmeter.sh

首先用Postman先新建一个用户userId假设为10030，生成一个新的红包全局id
测试计划–>右键–>添加–>线程(用户)–>线程组

线程组面板，设置线程属性，设置线程数为1000个
线程组–>右键–>添加–>取样器–>HTTP请求
线程组–>右键–>添加–>配置原件–>CSV数据文件设置

假设录入新的用户userId是从10030~10035的data.csv数据文件

然后点击Jmeter上面的三角符号运行按钮进行测试
线程组–>右键–>添加–>监听器–>查看结果树
打开MySQL查询抢红包的明细表发现已经抢过红包的用户后续又抢到红包，比如10030已经抢过，后又抢到红包，说明是高并发引起的线程安全问题

2、问题分析

当某一时刻的同一个用户在疯狂的点红包，如果前端不加以控制，同一时间的同一个账户将发起多个抢红包请求。
后端接口接收到这些请求后，很可能同时在redis中判断是否有红包，并成功通过，然后导致一个用户抢到多个红包。
后端接口并没有考虑到高并发请求，原因在于当前请求还没有处理完核心业务逻辑，其他同样的请求过来，导致后端接口几乎来不及做重复判断

3、优化方案

同一时刻多个并发的线程对共享资源进行了访问操作，导致最终出现数据不一致或者结果并非自己所预料的现象，就是多线程高并发时出现的并发安全问题。
传统的单体Java应用，为了解决高并发，最常见的方法是在核心的业务逻辑代码中加锁，也就是Synchronized关键字。
在微服务、分布式系统架构，这样做法行不通，因为Synchronized关键字是跟单一服务节点所在的JVM相关联，而分布式系统架构的服务一般是部署在不同的节点服务器上，从而当出现高并发请求时，Synchronized同步操作力不从心。
为了保证单一节点核心业务代码的同步控制，也要保证当扩展到多个节点部署同样的实现核心业务逻辑，就出现了分布式锁。
分布式锁只是一种解决方案，主要是为了解决分布式系统高并发请求时出现并发访问共享资源导致的并发安全问题；
分布式锁的实现有多种
- 基于数据库级别的乐观锁和悲观锁
- 基于Redis的原子操作实现分布式锁
- 基于Zookeeper实现分布式锁

4、Redis分布式锁实战

4.1、redis的底层分析

由于Redis底层架构是采用单线程进行设计的，所以它提供的这些操作都是单线程的，也就是操作具有原子性。
原子性就是在同一时刻只能有一个线程来处理核心业务逻辑，当有其他线程对应的请求过来的时候，如果前面的线程没有处理完毕，那么当前线程将进入等待(阻塞)状态，直到前面的线程处理完毕。

4.2、分布式锁实现

因为抢红包的核心业务逻辑在于拆红包操作。
可以通过redis的原子操作setIfAbsent()方法对业务逻辑加分布式锁
setIfAbsent()方法：
- 如果当前的key不存在redis中，就设置对应的value，然后返回true
- 如果当前key存在，则设置value失败，返回false
方法具有原子性单线程操作，所以多个并发的线程同一时刻调用setIfAbsent()，redis底层会将线程加入队列排队处理

@Override
   public BigDecimal robByDistributeLock(Integer userId, String redId) throws Exception {
       ValueOperations valueOperations = redisTemplate.opsForValue();
       /**
        * 处理用户抢红包之前，需要先判断一下当前用户是否已经抢过红包
        * 如果抢过，则直接返回红包金额
        */
       Object data = valueOperations.get(redId + userId + ":rob");
       if (data != null) {
           BigDecimal redPacket = new BigDecimal(data.toString());
           log.info("从redis中获取数据，当前用户抢到红包了：userId={} key={} 金额={}", userId, redId, redPacket);
           return redPacket;
       }
       Boolean res = clilck(redId);
       //如果为true代表redis中仍然还有红包，也就是红包个数>0
       if (res) {
           //上分布式锁：一个红包每个人只能抢到一次随机金额，也即是永远保证一对一关系
           final String lockKey = redId+userId+"-lock";
           //调用setIfAbsent()方法，其实就是间接实现了分布式锁
           Boolean lock = valueOperations.setIfAbsent(lockKey, redId);
           //设置分布式锁的过期时间为24h
           redisTemplate.expire(lockKey,24L,TimeUnit.HOURS);
           try {
               //表示当前线程获取到了该分布式锁
               if(lock) {
                   //从小红包随机金额列表弹出一个随机金额
                   Object value = redisTemplate.opsForList().rightPop(redId);
                   if (value != null) {
                       /**
                        * 更新redis中剩余的红包个数，也就是红包个数减1
                        */
                       String redTotalKey = redId + ":total";
                       Object total = valueOperations.get(redTotalKey);
                       Integer curTotal = 0;
                       if (total != null) {
                           curTotal = (Integer) total;
                       }
                       valueOperations.set(redTotalKey, curTotal - 1);
                       //直接处理红包的单位变为分，如果此处不处理，需要前端处理也是一样的
                       BigDecimal redPacket = new BigDecimal(value.toString()).divide(new BigDecimal(100));
                       //将抢到红包的用户信息异步保存到数据库
                       redService.recordRobRedPacket(userId, redId, new BigDecimal(value.toString()));
                       //将当前用户抢到红包的用户设置到redis中，表示当前用户已经抢过红包了，设置过期时间24h
                       valueOperations.set(redId + userId + ":rob", redPacket, 24L, TimeUnit.HOURS);
                       log.info("当前用户抢到红包了：userId={} key={} 金额={}", userId, redId, redPacket);
                       return redPacket;
                   }
               }
           }catch (Exception e){
               throw new Exception("系统异常-抢红包-加分布式锁失败！");
           }
       }
       //null表示当前用户没有抢到红包
       return null;
   }

4.3、测试结果

首先利用postman调用发红包接口，重新生成一个红包全局id

然后配置到Jmeter的http请求的redId上
然后利用Jmeter测试步骤同样的，最后查看抢红包明细表发现，没有出现同一个账户又重复抢到红包的情况，从而实现分布式锁控制

5、总结与分析

代码的核心业务逻辑已经加上分布式锁，也能扛得住秒级高并发的请求，但是从业务层来看，我们只设置了10030~10035这6个用户来抢红包，发红包我们设置了10个红包，那么剩下4个红包的剩余金额还没处理，首先需要归还个发红包的人，这块业务逻辑就不在写。
多线程高并发时产生的并发安全问题，需要对核心业务处理逻辑加同步控制操作，也就是加上分布式锁

展开全文 >>

Redis应用场景之抢红包系统(三)

2018-06-20

一、Redis应用场景之抢红包系统(三)

1、业务模块分析

抢红包业务对应的后端接口需要频繁的访问Redis，用来获取红包剩余个数和随机金额列表，来判断用户点红包、拆红包是否成功。
用户每次成功抢到红包之后，后端接口需要及时更新缓存系统中红包剩余个数，将相应的信息保存到数据库

2、开发流程介绍

抢红包系统处理用户请求的过程和数据流向如下：

3、抢红包模拟实战

前端用户发起抢红包请求，需要带上红包全局唯一标识串redId和当前用户userId。
后端接口根据redId去查询Redis中获取红包剩余个数和随机金额列表。

3.1、发红包的控制器RedPacketController

package com.victor.controller;

import com.victor.model.redpacket.RedPacketRequest;
import com.victor.model.redpacket.BaseResponse;
import com.victor.model.redpacket.StatusCode;
import com.victor.service.redpacket.IRedPacketService;
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.validation.BindingResult;
import org.springframework.validation.annotation.Validated;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestBody;
import org.springframework.web.bind.annotation.RestController;

/**
 * @Description: 红包处理逻辑Controller
 * @Author: VictorDan
 * @Version: 1.0
 */
@RestController
@Slf4j
public class RedPacketController {

    @Autowired
    private IRedPacketService redPacketService;

    private static final String PREFIX = "red/packet";
    
    /**
     * 抢红包-请求方式为Get
     * @param userId
     * @param redId
     * @return
     */
    @GetMapping(value = PREFIX + "/rob")
    public BaseResponse rob(@RequestParam Integer userId, @RequestParam String redId) {
        BaseResponse<BigDecimal> response = new BaseResponse<>(StatusCode.Success);
        /**
         * 调用抢红包，返回最终的红包金额，如果为null表示已被抢完
         */
        BigDecimal data = redPacketService.rob(userId, redId);
        if (data != null) {
            response.setData(data);
        } else {
            response = new BaseResponse<>(StatusCode.Fail.getCode(), "红包已被抢完！");
        }
        return response;

    }
}

2.3、抢红包的核心逻辑Service

抢红包接口IRedPacketService

package com.victor.service.redpacket;

import com.victor.model.redpacket.RedPacketRequest;

import java.math.BigDecimal;

/**
 * @Description:
 * @Author: VictorDan
 * @Version: 1.0
 */
public interface IRedPacketService {
    /**
     * 发红包核心业务逻辑
     * @param request
     * @return
     * @throws Exception
     */
    String handOut(RedPacketRequest request) throws Exception;

    /**
     * 抢红包
     * @param userId
     * @param redId
     * @return
     */
    BigDecimal rob(Integer userId,String redId);
}

抢红包核心逻辑

package com.victor.service.redpacket.impl;

import com.victor.model.redpacket.RedPacketRequest;
import com.victor.service.redpacket.IRedPacketService;
import com.victor.service.redpacket.IRedService;
import com.victor.util.RedPacketUtil;
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.stereotype.Service;

import java.math.BigDecimal;
import java.util.List;

/**
 * @Description:
 * @Author: VictorDan
 * @Version: 1.0
 */
@Service
@Slf4j
public class RedPacketServiceImpl implements IRedPacketService {
    @Autowired
    private RedisTemplate redisTemplate;
    /**
     * 红包业务逻辑处理过程记录到数据库的服务
     */
    @Autowired
    private IRedService redService;

    //存储到Redis中定义key前缀
    private static final String KEY_PREFIX = "redis:red:packet:";

    /**
     * 抢红包
     * @param userId 当前抢红包的用户id
     * @param redId 红包的全局唯一标识符
     * @return
     */
    @Override
    public BigDecimal rob(Integer userId, String redId) {
        ValueOperations valueOperations = redisTemplate.opsForValue();
        /**
         * 处理用户抢红包之前，需要先判断一下当前用户是否已经抢过红包
         * 如果抢过，则直接返回红包金额
         */
        Object data = valueOperations.get(redId + userId + ":rob");
        if (data != null) {
            BigDecimal redPacket = new BigDecimal(data.toString());
            log.info("从redis中获取数据，当前用户抢到红包了：userId={} key={} 金额={}", userId, redId, redPacket);
            return redPacket;
        }
        Boolean res = clilck(redId);
        //如果为true代表redis中仍然还有红包，也就是红包个数>0
        if (res) {
            //从小红包随机金额列表弹出一个随机金额
            Object value = redisTemplate.opsForList().rightPop(redId);

            if (value != null) {
                /**
                 * 更新redis中剩余的红包个数，也就是红包个数减1
                 */
                String redTotalKey = redId + ":total";
                Object total = valueOperations.get(redTotalKey);
                Integer curTotal = 0;
                if (total != null) {
                    curTotal = (Integer) total;
                }
                valueOperations.set(redTotalKey, curTotal - 1);
                //直接处理红包的单位变为分，如果此处不处理，需要前端处理也是一样的
                BigDecimal redPacket = new BigDecimal(value.toString()).divide(new BigDecimal(100));
                //将抢到红包的用户信息异步保存到数据库
                redService.recordRobRedPacket(userId, redId, new BigDecimal(value.toString()));
                //将当前用户抢到红包的用户设置到redis中，表示当前用户已经抢过红包了，设置过期时间24h
                valueOperations.set(redId + userId + ":rob", redPacket, 24L, TimeUnit.HOURS);
                log.info("当前用户抢到红包了：userId={} key={} 金额={}", userId, redId, redPacket);
                return redPacket;
            }
        }
        //null表示当前用户没有抢到红包
        return null;
    }

    /**
     * 点红包的业务逻辑，如果为true代表还有红包，否则代表红包已经抢光
     *
     * @param redId
     * @return
     */
    private Boolean clilck(String redId) {
        ValueOperations valueOperations = redisTemplate.opsForValue();
        String redIdKey = redId + ":total";
        /**
         * 获取redis中红包的剩余个数
         */
        Object total = valueOperations.get(redIdKey);
        /**
         * 判断红包剩余个数total是否大于0，如果大于0，则返回true代表还有红包，否则false
         */
        return total != null && Integer.valueOf(total.toString()) > 0;

    }
}

2.4、异步保存红包业务逻辑处理过程数据到数据库

红包业务逻辑处理过程数据接口

package com.victor.service.redpacket;

import com.victor.model.redpacket.RedPacketRequest;

import java.util.List;

/**
 * @Description: 红包业务逻辑处理过程数据记录
 * @Author: VictorDan
 * @Version: 1.0
 */
public interface IRedService {
    /**
     * 记录发红包
     * @param dto
     * @param redId
     * @param list
     */
    void recordRedPacket(RedPacketRequest dto, String redId, List<Integer> list);
    
    /**
     * 将抢到红包的用户信息以及红包金额异步保存到数据库
     * @param userId
     * @param redId
     * @param data
     */
    void recordRobRedPacket(Integer userId, String redId, BigDecimal data);
}

红包业务逻辑处理过程数据实现类

package com.victor.service.redpacket.impl;

import com.victor.model.redpacket.RedPacketRequest;
import com.victor.model.redpacket.RedDetail;
import com.victor.model.redpacket.RedRecord;
import com.victor.repository.redpacket.RedDetailRepo;
import com.victor.repository.redpacket.RedRecordRepo;
import com.victor.repository.redpacket.RedRobRecordRepo;
import com.victor.service.redpacket.IRedService;
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.scheduling.annotation.Async;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;

import java.math.BigDecimal;
import java.util.Date;
import java.util.List;

/**
 * @Description: 红包业务逻辑处理过程数据记录
 * @Author: VictorDan
 * @Version: 1.0
 */
@Slf4j
@Service
public class RedServiceImpl implements IRedService {
    @Autowired
    private RedRecordRepo redRecordRepo;

    @Autowired
    private RedDetailRepo redDetailRepo;

    @Autowired
    private RedRobRecordRepo redRobRecordRepo;

    /**
     * 将成功抢到红包的用户信息以及红包金额异步保存到数据库
     * @param userId 用户账号
     * @param redId 红包全局唯一标识串
     * @param data 抢到的红包金额
     */
    @Override
    @Async
    @Transactional(rollbackFor = Exception.class)
    public void recordRobRedPacket(Integer userId, String redId, BigDecimal data){
        RedRobRecord redRobRecord = new RedRobRecord();
        redRobRecord.setAmount(data);
        redRobRecord.setUserId(userId);
        //红包的全局唯一标识串
        redRobRecord.setRedPacket(redId);
        redRobRecord.setRobTime(new Date());
        redRobRecord.setIsActive(true);
        //将抢到红包的信息保存到数据库
        redRobRecordRepo.saveAndFlush(redRobRecord);
    }
}

2.5、测试结果

分别输入10个userId，假设输入的从10010到10019,然后当输入到10011就会提示红包抢光

使用PostMan测试接口结果如下：

查看数据库记录

#查看发红包表
SELECT * FROM victor.red_record;
#查看红包明细表，是否对应总金额
SELECT sum(amount) FROM victor.red_detail where record_id=1 and is_active=1;

查看抢红包表
汇总红包明细表的金额与总金额对比

4、开发总结

4.1、缺陷

首先这些请求都是串行的，因为在PostMan测试的时候，都是一个一个账户的请求，是有时间间隔的。
没有达到生产环境中秒级高并发请求。
高并发就是，在同一时刻突然有成千上万甚至百千万的数量级请求到达后端接口。
这里没有考虑高并发抢红包的情况，高并发请求的本质是高并发多线程，多线程的高并发如果出现抢占共享资源而不加以控制，会造成数据不一致。

展开全文 >>

Redis应用场景之抢红包系统(二)

2018-06-19

一、Redis应用场景之抢红包系统(二)

1、开发流程介绍

抢红包系统处理用户请求的过程和数据流向如下：

1.1、发红包请求处理

后端主要根据用户输入的金额和个数预生成相应的红包随机金额列表，然后将红包的总个数和对应的随机金额列表缓存到Redis中。
将红包的总金额、随机金额列表和红包全局唯一标识串信息异步记录到对应的数据库表中。

1.2、抢红包请求处理

后端接口先接收到前端用户账号以及红包的全局唯一标识串等请求信息，假设用户账号合法性等信息全部校验通过，然后开始处理用户点开红包的逻辑
主要是从Redis中获取当前剩余的红包个数，根据红包个数是否大于0，则开始处理用户拆红包的逻辑。
拆红包逻辑主要是从Redis中的随机金额队列中弹出一个红包金额，并根据金额是否为null判断是否成功抢到红包

1.3、状态码设计

保证系统整体开发流程规范，约定处理用户请求信息后将返回统一的响应格式。

BaseResponse类

package com.victor.model.redpacket;

import lombok.Data;
import lombok.ToString;

/**
 * @Description: 响应信息类
 * @Author: VictorDan
 * @Version: 1.0
 */
@Data
@ToString
public class BaseResponse<T> {
    /**
     * 状态码
     */
    private Integer code;
    /**
     * 描述信息
     */
    private String msg;
    /**
     * 响应数据-采用泛型表示可以接受通用的数据类型
     */
    private T data;

    public BaseResponse(Integer code, String msg, T data) {
        this.code = code;
        this.msg = msg;
        this.data = data;
    }

    public BaseResponse(StatusCode statusCode) {
        this.code = statusCode.getCode();
        this.msg = statusCode.getMsg();
    }

    public BaseResponse(Integer code, String msg) {
        this.code = code;
        this.msg = msg;
    }
}

StatusCode类

package com.victor.model.redpacket;

import lombok.ToString;

/**
 * @Description: 状态码类
 * 注：状态码类是枚举类，所以不能使用@Data，需要自己生成getter/setter方法
 * @Author: VictorDan
 * @Version: 1.0
 */
@ToString
public enum  StatusCode {
    /**
     * 以下是暂时设定的几种状态码
     */
    Success(0,"成功"),
    Fail(-1,"失败"),
    InvalidParams(201,"非法参数！"),
    InvalidGrantType(202,"非法的授权类型");

    /**
     * 状态码
     */
    private Integer code;
    /**
     * 描述信息
     */
    private String msg;
    
    StatusCode(Integer code,String msg) {
        this.code=code;
        this.msg=msg;
    }

    public Integer getCode() {
        return code;
    }

    public String getMsg() {
        return msg;
    }

    public void setCode(Integer code) {
        this.code = code;
    }

    public void setMsg(String msg) {
        this.msg = msg;
    }
}

1.4、红包金额随机生成算法

抢红包系统的核心部分主要在于抢红包的逻辑处理，而能否抢到红包，主要取决于红包个数和红包随机金额列表。
红包随机金额列表采用预生成的方式，也就是通过给定红包的总金额M和总人数N，采用随机数算法生成红包随机金额列表，并将它放到Redis中，用来拆分红逻辑的处理

1、随机数算法要求

所有人抢到的金额之和等于红包金额
每个人至少抢到0.01元
要保证所有人抢到金额的记录相等。

采用蒙特卡洛方法，主要构造一个数学模型，将若干个随机变量和统计分析的方法求出若干个随机数。

2、二倍均值法

实际中红包随机金额的生成算法有许多，二倍均值法是比较典型。
根据每次剩余的总金额M和剩余人数N，执行M/N，然后在乘以2,所得到的数E，在0到E的区间内，随机产生一个随机金额。
重复上面的步骤，直到剩余最后一个人。

package com.victor.util;

import java.util.ArrayList;
import java.util.List;
import java.util.Random;

/**
 * @Description: 发红包工具类
 * @Author: VictorDan
 * @Version: 1.0
 */
public class RedPacketUtil {
    /**
     * 发红包算法，二倍均值法
     *
     * @param totalAmount    红包总金额，单位为分
     * @param totalPeopleNum 总人数
     * @return
     */
    public static List<Integer> divideRedPacket(Integer totalAmount, Integer totalPeopleNum) {
        List<Integer> list = new ArrayList<>();
        /**
         * 判断总金额和总个数参数的合法性
         */
        if (totalAmount > 0 && totalPeopleNum > 0) {
            //记录剩余总金额，初始化为红包总金额
            Integer restAmount = totalAmount;
            //记录剩余总人数，初始化为指定的总人数
            Integer restPeopleNum = totalPeopleNum;
            //产生随机数
            Random random = new Random();
            //不断循环遍历，更新迭代产生随机金额，直到N-1>0
            for (int i = 0; i < totalPeopleNum - 1; i++) {
                //随机范围:[1,剩余人均金额的两倍),随机金额为分，至少一个人得到1分钱
                int amount = random.nextInt(restAmount / restPeopleNum * 2 - 1) + 1;
                //更新剩余的总金额
                restAmount = restAmount - amount;
                //更新剩余的人数
                restPeopleNum--;
                //将产生的随机金额加入到list
                list.add(amount);
            }
            //循环完毕，将剩余的金额也即是最后一个随机金额，加入到list
            list.add(restAmount);
        }
        return list;
    }
}

2、发红包模拟实战

发红包模块的核心处理逻辑在于接受前端发红包设定的总金额M和总个数N，后端接口根据这2个参数，然后采用二倍均值算法生成N个随机金额的红包，最后将红包个数N和随机金额list存到缓存，然后把相关的数据异步记录到数据库中。
后端接口在接收到前端用户发红包请求的时候，可以采用时间戳作为红包全局唯一标识串，然后将这个串返回给前端，后续用户发红包的时候，会带上这个参数，目的为了给发出的红包打标记，把这个标记作为key去缓存中查询红包个数和随机金额列表等。

2.1、发红包请求参数RedPacketRequest

package com.victor.model.redpacket;

import lombok.Data;
import lombok.ToString;

import javax.validation.constraints.NotNull;

/**
 * @Description: 处理发红包的请求参数
 * @Author: VictorDan
 * @Version: 1.0
 */
@Data
@ToString
public class RedPacketRequest {
    /**
     * 用户账号id
     */
    private Integer userId;
    /**
     * 红包个数
     */
    @NotNull
    private Integer total;
    /**
     * 总金额-单位为分
     */
    @NotNull
    private Integer amount;
}

2.2、发红包的控制器RedPacketController

package com.victor.controller;

import com.victor.model.redpacket.RedPacketRequest;
import com.victor.model.redpacket.BaseResponse;
import com.victor.model.redpacket.StatusCode;
import com.victor.service.redpacket.IRedPacketService;
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.validation.BindingResult;
import org.springframework.validation.annotation.Validated;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestBody;
import org.springframework.web.bind.annotation.RestController;

/**
 * @Description: 红包处理逻辑Controller
 * @Author: VictorDan
 * @Version: 1.0
 */
@RestController
@Slf4j
public class RedPacketController {

    @Autowired
    private IRedPacketService redPacketService;

    private static final String PREFIX = "red/packet";

    /**
     * 发红包-请求方式为post，数据格式采用JSON交互
     *
     * @param request
     * @param result
     * @return
     */
    @PostMapping(value = PREFIX + "/hand/out")
    public BaseResponse handOut(@Validated @RequestBody RedPacketRequest request, BindingResult result) {
        //参数校验
        if (result.hasErrors()) {
            return new BaseResponse(StatusCode.InvalidParams);
        }
        BaseResponse<String> response = new BaseResponse<>(StatusCode.Success);
        String redId;
        try {
            //核心业务逻辑处理，然后返回红包的唯一标识串
            redId = redPacketService.handOut(request);
            response.setData(redId);
        } catch (Exception e) {
            log.error("发红包发生异常，请求request={},异常信息为：{}", request, e.getMessage());
            return new BaseResponse(StatusCode.Fail.getCode(), e.getMessage());
        }
        return response;
    }
}

2.3、发红包的核心逻辑Service

发红包接口IRedPacketService

package com.victor.service.redpacket;

import com.victor.model.redpacket.RedPacketRequest;

import java.math.BigDecimal;

/**
 * @Description:
 * @Author: VictorDan
 * @Version: 1.0
 */
public interface IRedPacketService {
    /**
     * 发红包核心业务逻辑
     * @param request
     * @return
     * @throws Exception
     */
    String handOut(RedPacketRequest request) throws Exception;

    /**
     * 抢红包
     * @param userId
     * @param redId
     * @return
     */
    BigDecimal rob(Integer userId,String redId);
}

发红包核心逻辑

package com.victor.service.redpacket.impl;

import com.victor.model.redpacket.RedPacketRequest;
import com.victor.service.redpacket.IRedPacketService;
import com.victor.service.redpacket.IRedService;
import com.victor.util.RedPacketUtil;
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.stereotype.Service;

import java.math.BigDecimal;
import java.util.List;

/**
 * @Description:
 * @Author: VictorDan
 * @Version: 1.0
 */
@Service
@Slf4j
public class RedPacketServiceImpl implements IRedPacketService {
    @Autowired
    private RedisTemplate redisTemplate;
    /**
     * 红包业务逻辑处理过程记录到数据库的服务
     */
    @Autowired
    private IRedService redService;

    //存储到Redis中定义key前缀
    private static final String KEY_PREFIX = "redis:red:packet:";

    /**
     * 发红包
     *
     * @param request
     * @return
     * @throws Exception
     */
    @Override
    public String handOut(RedPacketRequest request) throws Exception {
        if (request.getTotal() > 0 && request.getTotal() > 0) {
            List<Integer> list = RedPacketUtil.divideRedPacket(request.getAmount(), request.getTotal());
            //生成红包全局唯一标识串
            String timestamp = String.valueOf(System.nanoTime());
            //根据缓存key的前缀与其他信息拼接成一个新的用来存储红包总数的key
            String redId = KEY_PREFIX + request.getUserId() + ":" + timestamp;
            //将随机金额写入到redis的list中（从队列左边全部push进去）
            redisTemplate.opsForList().leftPushAll(redId, list);
            //将红包总个数写入redis中
            String redTotalKey = redId + ":total";
            redisTemplate.opsForValue().set(redTotalKey, request.getTotal());
            //异步记录红包的全局标识符，红包个数与随机金额列表到数据库
            redService.recordRedPacket(request, redId, list);
            //返回红包的全局唯一标识符给前端
            return redId;
        } else {
            throw new Exception("系统异常--->分发红包参数不合法");
        }

    }

    @Override
    public BigDecimal rob(Integer userId, String redId) {
        return null;
    }
}

2.4、异步保存红包业务逻辑处理过程数据到数据库

红包业务逻辑处理过程数据接口

package com.victor.service.redpacket;

import com.victor.model.redpacket.RedPacketRequest;

import java.util.List;

/**
 * @Description: 红包业务逻辑处理过程数据记录
 * @Author: VictorDan
 * @Version: 1.0
 */
public interface IRedService {
    /**
     * 记录发红包
     * @param dto
     * @param redId
     * @param list
     */
    void recordRedPacket(RedPacketRequest dto, String redId, List<Integer> list);
}

红包业务逻辑处理过程数据实现类

package com.victor.service.redpacket.impl;

import com.victor.model.redpacket.RedPacketRequest;
import com.victor.model.redpacket.RedDetail;
import com.victor.model.redpacket.RedRecord;
import com.victor.repository.redpacket.RedDetailRepo;
import com.victor.repository.redpacket.RedRecordRepo;
import com.victor.repository.redpacket.RedRobRecordRepo;
import com.victor.service.redpacket.IRedService;
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.scheduling.annotation.Async;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;

import java.math.BigDecimal;
import java.util.Date;
import java.util.List;

/**
 * @Description: 红包业务逻辑处理过程数据记录
 * @Author: VictorDan
 * @Version: 1.0
 */
@Slf4j
@Service
public class RedServiceImpl implements IRedService {
    @Autowired
    private RedRecordRepo redRecordRepo;

    @Autowired
    private RedDetailRepo redDetailRepo;

    @Autowired
    private RedRobRecordRepo redRobRecordRepo;

    /**
     * 发红包记录-异步方式
     * @param dto 红包总金额+个数
     * @param redId 红包全局唯一标识串
     * @param list 红包随机金额列表
     */
    @Transactional(rollbackFor = Exception.class)
    @Async
    @Override
    public void recordRedPacket(RedPacketRequest dto, String redId, List<Integer> list){
        RedRecord redRecord = new RedRecord();
        redRecord.setUserId(dto.getUserId());
        redRecord.setAmount(BigDecimal.valueOf(dto.getAmount()));
        redRecord.setTotal(dto.getTotal());
        redRecord.setRedPacket(redId);
        redRecord.setIsActive(true);
        redRecord.setCreateTime(new Date());
        //保存到发红包记录表
        redRecordRepo.save(redRecord);

        RedDetail redDetail;
        //遍历随机金额列表，将金额等信息设置到对应字段
        for (Integer data:list) {
            redDetail = new RedDetail();
            redDetail.setRecordId(redRecord.getId());
            redDetail.setAmount(BigDecimal.valueOf(data));
            redDetail.setCreateTime(new Date());
            redDetail.setIsActive(true);
            //保存红包明细金额表
            redDetailRepo.saveAndFlush(redDetail);
        }

    }
}

2.5、测试结果

使用PostMan测试接口结果如下：

查看数据库记录

#查看发红包表
SELECT * FROM victor.red_record;
#查看红包明细表，是否对应总金额
SELECT sum(amount) FROM victor.red_detail where record_id=1 and is_active=1;

查看发红包表

查看红包明细表
汇总红包明细表的金额与总金额对比

展开全文 >>

Redis应用场景之抢红包系统(一)

2018-06-18

一、Redis应用场景之抢红包系统(一)

1、业务流程

信息流：包括用户操作背后的请求通信和红包信息在不同用户与用户群中的流转等
业务流：主要包括发红包、点红包和抢红包等业务逻辑
资金流：主要包括红包背后的资金转账和入账等流程

1.1、业务系统流程图

1.2、业务流程分析

系统整体业务流程包括2大业务组成：发红包和抢红包。其中的拆红包又可以拆分2个小业务，用户点红包和用户拆红包。

1.2.1、发红包整体业务流程

1.2.2、抢红包整体业务流程

2、业务模块划分

缓存中间件Redis模块：主要用来发红包时缓存红包个数和由随机数算法产生的红包随机金额列表，同时将借助Redis单线程特性和操作的原子性实现抢红包时锁的操作
引入Redis一方面是大大减少高并发情况下频繁查询数据库的操作，减少数据库的压力。
另一方面是提供系统整体响应性能和保证数据的一致性。

3、数据库表设计与环境搭建

主要有3张表，发红包记录红包的信息表，发红包时对应的随机金额信息表，抢红包时用户抢到红包的金额记录表

3.1、实体类Model

发红包记录表RedRecord

package com.victor.model.redpacket;

import com.fasterxml.jackson.annotation.JsonFormat;
import lombok.Data;
import lombok.ToString;

import javax.persistence.*;
import java.math.BigDecimal;
import java.util.Date;

/**
 * @Description: 发红包记录表
  * @Author: VictorDan
 * @Version: 1.0
 */
@Data
@ToString
@Entity
@Table(name = "red_record")
public class RedRecord {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "id")
    private Integer id;
    /**
     * 用户id
     */
    private Integer userId;
    /**
     * 红包全局唯一标识串
     */
    private String redPacket;
    /**
     * 红包指定可以抢的总人数
     */
    private Integer total;
    /**
     * 红包总金额
     */
    private BigDecimal amount;
    /**
     * 是否有效
     */
    private Boolean isActive;

    @JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss",timezone = "GMT+8")
    private Date createTime;
}

红包明细金额表RedDetail

package com.victor.model.redpacket;

import com.fasterxml.jackson.annotation.JsonFormat;
import lombok.Data;
import lombok.ToString;

import javax.persistence.*;
import java.math.BigDecimal;
import java.util.Date;

/**
 * @Description: 红包明细金额表
 * @Author: VictorDan
 * @Version: 1.0
 */
@Data
@ToString
@Entity
@Table(name = "red_detail")
public class RedDetail {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "id")
    private Integer id;
    /**
     * 红包记录id
     */
    private Integer recordId;
    /**
     * 红包随机金额
     */
    private BigDecimal amount;
    /**
     * 是否有效
     */
    private Boolean isActive;

    @JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss",timezone = "GMT+8")
    private Date createTime;
}

抢红包记录表RedRobRecord

package com.victor.model.redpacket;

import com.fasterxml.jackson.annotation.JsonFormat;
import lombok.Data;
import lombok.ToString;

import javax.persistence.*;
import java.math.BigDecimal;
import java.util.Date;

/**
 * @Description: 抢红包记录表
 * @Author: VictorDan
 * @Version: 1.0
 */
@Data
@ToString
@Entity
@Table(name = "red_record")
public class RedRobRecord {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "id")
    private Integer id;
    /**
     * 用户id
     */
    private Integer userId;
    /**
     * 红包全局唯一标识串
     */
    private String redPacket;
    /**
     * 抢到红包的金额
     */
    private BigDecimal amount;
    /**
     * 是否有效
     */
    private Boolean isActive;
    /**
     * 抢到时间
     */
    @JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss",timezone = "GMT+8")
    private Date robTime;
}

3.2、持久层Repository

发红包记录表RedRecordRepo

package com.victor.repository.redpacket;

import com.victor.model.redpacket.RedRecord;
import org.springframework.data.jpa.repository.JpaRepository;
import org.springframework.stereotype.Repository;

/**
 * @Description:
 * @Author: VictorDan
 * @Version: 1.0
 */
@Repository
public interface RedRecordRepo extends JpaRepository<RedRecord,Long> {
}

红包明细金额RedDetailRepo

package com.victor.repository.redpacket;

import com.victor.model.redpacket.RedDetail;
import org.springframework.data.jpa.repository.JpaRepository;
import org.springframework.stereotype.Repository;

/**
 * @Description:
 * @Author: VictorDan
 * @Version: 1.0
 */
@Repository
public interface RedDetailRepo extends JpaRepository<RedDetail,Long> {
}

抢红包记录表RedRobRecordRepo

package com.victor.repository.redpacket;

import com.victor.model.redpacket.RedRobRecord;
import org.springframework.data.jpa.repository.JpaRepository;
import org.springframework.stereotype.Repository;

/**
 * @Description:
 * @Author: VictorDan
 * @Version: 1.0
 */
@Repository
public interface RedRobRecordRepo extends JpaRepository<RedRobRecord,Long> {
}

展开全文 >>

Redis实战场景分析总结

2018-06-17

一、Redis实战之场景1：缓存穿透

1、正常流程

项目中使用缓存Redis查询数据的正常流程，如下图

前端用户要访问获取数据时，后端首先会在Redis中查询
如果能查询到数据，则直接将数据返回给用户，流程结束
如果查不到数据，就前往数据库中查询，如果能查到数据，将数据返回给用户，同时将数据塞入缓存Redis中，流程结束
如果在数据库中没有查询到数据，则返回null，同时流程结束。

2、问题分析

当查询数据库的时候如果没有查询到数据，就直接返回null给前端用户，流程结束，如果前端频繁发起访问请求，恶意提供数据库中不存在的Key，则此时数据库中查询到的数据永远为null。由于null数据是不存入到Redis中，所以每次访问请求时将查询数据库，如果此时有恶意攻击，发起“洪流”式的查询，则很有可能会对数据库造成极大的压力，甚至压垮数据库。这个叫缓存穿透，就好像永远越过了缓存而直接永远的访问数据库。

3、解决方案

当查询数据库时，如果没有查询到数据，将null返回给前端用户，同时将该null数据塞入Redis，并对对应的Key设置一定的过期时间，流程结束，具体过程如下图

4、实战过程

1、建立数据库连接

#redis
#spring.redis.database=0
spring.redis.host=localhost
spring.redis.port=6379
#spring.redis.password=
#spring.redis.jedis.pool.max-active=8
#spring.redis.jedis.pool.max-wait=-1
#spring.redis.jedis.pool.max-idle=8
#spring.redis.lettuce.pool.min-idle=0
#spring.redis.timeout=1000
server.port=8080
#mysql
spring.jpa.show-sql=true
spring.datasource.url=jdbc:mysql://localhost/victor
spring.datasource.username=root
spring.datasource.password=root
spring.datasource.driver-class-name=com.mysql.jdbc.Driver

2、引入依赖

<!--			jpa-->
<dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-data-jpa</artifactId>
        </dependency>
<!--            lombok-->
        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <optional>true</optional>
        </dependency>
<!--        redis-->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-data-redis</artifactId>
        </dependency>

3、实体类Person

package com.victor.model;

import com.fasterxml.jackson.annotation.JsonFormat;
import lombok.Data;
import lombok.ToString;

import javax.persistence.*;
import java.io.Serializable;
import java.util.Date;

/**
 * @Description:
 * 使用JPA查询必须要有@Entity和@Table两个注解，否则报错
 * @Author: VictorDan
 * @Version: 1.0
 */
@Data
@ToString
@Table(name = "person")
@Entity
public class Person implements Serializable {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "id")
    private Integer id;
    private String userName;
    private String password;
    @JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss",timezone = "GMT+8")
    private Date createTime;
    private String status;
}

4、操作数据库的PersonRepository

package com.victor.repository;

import com.victor.model.Person;
import org.springframework.data.jpa.repository.JpaRepository;
import org.springframework.stereotype.Repository;

import java.util.List;

/**
 * @Description:
 * @Author: VictorDan
 * @Version: 1.0
 */
@Repository
public interface PersonRepo extends JpaRepository<Person,Long> {
    Person findByUserName(String name);
}

5、操作Redis的CachePersonService

package com.victor.service;

import com.fasterxml.jackson.databind.ObjectMapper;
import com.victor.model.Person;
import com.victor.repository.PersonRepo;
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.data.redis.core.ValueOperations;
import org.springframework.stereotype.Service;

import java.util.concurrent.TimeUnit;

/**
 * @Description: 缓存穿透实战Controller
 * @Author: VictorDan
 * @Version: 1.0
 */
@Service
@Slf4j
public class CachePersonService {
    @Autowired
    private RedisTemplate redisTemplate;

    @Autowired
    private PersonRepo personRepo;

    @Autowired
    private ObjectMapper objectMapper;

    private static final String keyPrefix = "person:cache";

    public Person getPerson(String userName) throws Exception {
        Person person = new Person();
        final String key = keyPrefix + userName;
        ValueOperations valueOperations = redisTemplate.opsForValue();
        //先从redis中获取，如果没有则查MySQL，并把查询的数据写入到redis
        if (redisTemplate.hasKey(key)) {
            log.info("---------获取个人信息--->从Redis缓存中------>姓名为：{}", userName);
            Object result = valueOperations.get(key);
            if (result != null && result.toString() != null && !"".equals(result.toString())) {
                person = objectMapper.readValue(result.toString(), Person.class);
            }
        } else {
            log.info("--------获取个人信息--->Redis中不存在--->从MySQL中查询---->姓名为：{}", userName);
            person = personRepo.findByUserName(userName);
            if (person != null) {
                //如果数据库张查询到该人信息，将它序列化后写入到Redis中
                String str = objectMapper.writeValueAsString(person);
                valueOperations.set(key, str);
            } else {
                //如果数据库中查不到就将key设置过期时间为30s，实际情况根据实际业务决定
                valueOperations.set(key, "", 30L, TimeUnit.MINUTES);
            }
        }
        return person;
    }
}

6、前端控制器CachePersonController

package com.victor.controller;

import com.victor.model.Person;
import com.victor.service.CachePersonService;
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;

import java.util.HashMap;
import java.util.Map;

/**
 * @Description: 缓存穿透实战Controller
 * @Author: VictorDan
 * @Version: 1.0
 */
@RestController
@Slf4j
public class CachePersonController {
    @Autowired
    private CachePersonService cachePersonService;

    @GetMapping(value ="/cache/person")
    public Map<String,Object> getPerson(@RequestParam String userName){
        Map<String,Object> map=new HashMap<>();
        map.put("code",0);
        map.put("msg","success");
        try {
            //调用缓存穿透处理Service得到返回结果，并添加到map中
            Person person = cachePersonService.getPerson(userName);
            map.put("data",person);
        } catch (Exception e) {
            log.error("查询失败：{}",e.getMessage());
            map.put("code",-1);
            map.put("msg","failed"+e.getMessage());
        }
        return map;
    }
}

二、Redis实战之场景2：缓存雪崩

在某个时间点，缓存中的key集体发生过期失效使得大量查询数据的请求都落到了DB上，导致数据库负载过高，压力暴增，甚至有可能压垮数据库。
原因分析：
- 大量的key在某个时间点或者某个时间段过期失效导致。
- 为了避免这种问题发生，一般的做法是给这些key设置不同的过期时间，随机的TTL，从而错开Redis中的key失效时间点，可以在某种成都上减轻数据库的压力。

三、Redis实战之场景3：缓存击穿

Redis中某个频繁被访问的key或者叫热点key，在不停地扛着前端的高并发请求，当这个key突然在某个时间过期失效的是偶，持续的高并发访问请求就会穿破缓存，直接请求数据库，导致数据库压力在某一瞬间暴增。
原因分析：
- 主要是热点的key过期失效
- 实际开发中，既然这个key被当做频繁访问，那么就给这个key设置永不过期，这样前端的请求将几乎永远不会落在数据库上。

四、总结

不管是缓存穿透，缓存雪崩，缓存击穿，其实它们最终导致的后果几乎都是一样的，给数据库造成压力，甚至压垮数据库。解决方案也都有一个共同特征，就是加强防线，尽量让高并发的读请求落在缓存中，从而避免直接跟数据库打交道。

展开全文 >>

缓存常识总结

2018-06-16

一、缓存穿透，缓存击穿，缓存雪崩

1、缓存穿透

缓存穿透是指查询一个一定不存在的数据，由于缓存是不命中时被动写的

并且出于容错考虑，从存储层查不到数据则不写入缓存，这将导致这个

不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。在流量大的时候，可能DB就

挂掉了，要是有人利用不存在的key频繁攻击我们的应用，这就是漏洞。

解决方案

有很多种方法可以有效的解决缓存穿透的问题，最常见的就是布隆过滤器

将所有可能存在的数据hash到一个足够大的bitmap位示图中，一个一定不存在的数据会

被这个bitmap过滤掉，从而避免了对底层存储系统的查询压力。另外也有一个更为简单

粗暴的方法(我们采用的就是这种)，如果一个查询返回的数据为空(不管是数据不存在，还是系统故障)

仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过5min

2、缓存雪崩

缓存雪崩是指在我们设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求

全部发到DB，DB瞬时压力过重雪崩。

解决方案

缓存失效时的雪崩效应对底层系统的冲击非常可怕，大多数系统设计者考虑用加锁

或者队列的方式保证缓存的单线程(进程)写，从而避免失效时大量的并发请求落到

底层存储系统上，这里分享一个简单方案：将缓存失效时间分散开，比如我们可以在原有失效

时间基础上增加一个随机值，比如1-5min随机，这样每一个缓存的过期时间的重复率就会降低

就很难引发集体失效的事件。

3、缓存击穿

对于一些设置了过期时间的key，如果这些key可能会在某些时间点被超高并发的访问，是一种

非常热点数据，这个时候，需要考虑一个问题：缓存被击穿的问题，这个和缓存雪崩的区别

在于，缓存击穿针对某一key缓存，缓存雪崩是很多key

缓存在某个时间点过期的时候，恰好在这时间点对这个key有大量的并发请求过来，这些请求

发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把

后端DB压垮。

解决方案

1、使用互斥锁mutex key

常用的做法是：使用mutex，就是在缓存失效的时候，判断拿出来的值为空，不是立即去load db

而是先使用缓存工具的某些带成功操作返回值得操作，比如redis的setnx

去set一个mutex key。当操作返回成功时，在进行load db的操作，并回设缓存，否则，就重试

整个get缓存的方法。

setnx==set if not exists的缩写。也就是只有不存在的时候才设置，可以利用它来实现缓存击穿

public String get(String key){
    String value=redis.get(key);
    if(value==null){
        //设置3min的超时，防止del操作失败的时候，下次缓存过期一直不能load db
        if(redis.setnx(key_mutex,1,3*60)==1){//代表设置成功
            vlaue=db.get(key);
            redis.set(key,value,expire_secs);
            redls.del(key_mutex);
        }else{//这个时候代表同时候的其他线程已经load db并回设到缓存了，这个时候，重试获取缓存值就行。
            sleep(50);
            get(key);//重试
        }
    }else{
        return vlaue;
    }
}

4、为什么要用redis缓存

Redis就是一个数据库，不过传统数据库不同是Redis数据是存在内存中。

Redis被广泛用于缓存方向，Redis也经常用来做分布式锁。

5、为什么要用Redis而不用map/guava做缓存？

缓存分本地缓存和分布式缓存。Java中使用自带的map或者guava实现的是本地的缓存，轻量快速，生命周期随着JVM的销毁而结束，并且在多实例的情况下，每个实例都需要各自保存一份缓存，缓存不具有一致性。

使用Redis或者memcached之类是分布式缓存，在多实例情况下，各实例共用一份缓存数据，缓存具有一致性。

缺点：Redis需要保持服务的高可用，整个程序架构比较复杂。

6、Redis和Memcached的区别

Redis支持更丰富的数据类型，也就意味着支持更复杂的应用场景

不仅仅是支持简单的key、value数据，同时还提供list，set，zset，hash等数据的存储。memached支持简单的数据类型，string
Redis支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用，而Memecached把数据全部存在内存之中，重启就没了。
集群模式：Memcached没有原生的集群模式，需要依靠客户端来实现往集群中分片写入数据。大师Redis是原生支持cluster模式的
Memcache是多线程，非阻塞IO复用的网络模型
Redis使用单线程的多路IO复用模型

7、Redis常见数据结构以及使用场景分析

String

常用命令：set,get,decr,incr,mget

String数据结构是简单的key-value，value可以是String，也可以是数字。

常规key-value缓存应用，常规计数，微博数，粉丝数。
Hash

常用命令：hget，hset，hgetall

hash是一个string类型的field和value的映射表

hash特别适合用来存储对象。可以用hash数据结构来存储用户信息，商品信息
1
2
3
4
5
6
7
key=javatest12343
value={
'id':1,
'name':'vitor',
'age':12,
'locatoin':'shanghai'
}
List

常用命令：lpush，rpush，lpop，lrange

list就是链表，Redis list的应用场景非常多，比如微博的关注列表，粉丝列表，消息列表等功能都是用Redis的list结构来实现

Redis list的实现是一个双向链表，既可以支持反向查找和遍历，但是带了额外的内存开销。

还可以利用list实现简单的高性能分页。
Set

常用命令：sadd,spop,smembers,sunion等

set对外提供的功能与list类似是一个列表功能。只不过set可以自动去重
Sorted Set

常用命令：zadd,zrange,zrem,zcard

和set相比，sorted set增加了一个权重参数score，使得集合的元素能够按照score进行排序。比如在直播系统中，实时排行信息包含直播间在线用户列表，各种礼物排行榜，弹幕消息。

8、Redis设置过期时间

Redis中有个设置时间过期的功能，对存储在Redis数据库中的值可以设置一个过期时间。作为一个缓存数据库，这是非常实用的，如我们一般项目中的token或者一些登录信息，尤其是短信验证码都是有时间限制的，按照传统的数据库处理方式，一般都是自己判断过期，这样会严重影响项目性能。

所以，我们set key的时候，都可以给一个expire time过期时间，通过过期时间我们可以指定这个key可以存活的事件。如果假设你设置了一批key只能存活1个小时，那么接下来1个小时后，redis怎么删除key？

1、定期删除+惰性删除

定期删除:redis默认是每隔100ms就随机抽取一些设置了过期时间的key，检查是否过期，如果过期就删除。

这里是随机抽取的，因为随机抽取，假如redis存了几十万的key，每隔100ms就遍历所有的设置过期时间的key话，就会给cpu带来很大复杂
惰性删除：定期删除可能会导致很多过期key到了时间并没有被删除掉。就有了惰性删除。假如你的过期key，靠定期删除没有被删除掉，还停留在内存里，除非你的系统去查一下那个key，才会被redis给删除掉。这就是所谓的惰性删除。

但是仅仅通过设置过期时间还是有问题的，如果定期删除漏掉了很多过期的key，然后也没有及时去查，也就没有惰性删除。如果大量过期key堆积在内存里，导致redis内存耗尽，redis内存的淘汰机制就出现了。

2、Redis内存淘汰机制

MySQL里有2000w数据，Redis中只存20w的数据，如何保证Redis中的数据都是热点数据？

Redis.conf中有相关注释

Redis提供6中数据淘汰策略：
- volatile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰。
- volatile-ttl:从已设置过期时间的数据集（server.db[i].expires)中挑选将要过期的数据淘汰
- volatile-random：从已设置过期时间的数据集中任意选择数据进行淘汰
- allkeys-lru:当内存不足以容纳新写入数据的时候，在key空间中，移除最近最少使用的key（这是最常用的）
- allkey-radom：从数据集（server.db[i].dict）中任意选择数据淘汰
- volatile-lfu:从已设置过期时间的数据集（server.db[i].expires）中挑选最不经常使用的数据淘汰
- allkeys-lfu:当内存不足容纳新写入数据，在key空间，移除最不经常使用的key

注：redis设置过期时间以及内存淘汰机制

3、Redis持久化机制（怎么保证Redis挂掉之后再重启数据可以进行恢复）

很多时候我们需要持久化数据也就是将内存中的数据写入到硬盘里面，大部分原因是为了之后重用数据（比如重启机器，机器故障之后恢复数据），或者是为了防止系统故障而将数据备份到一个远程位置

Redis不同于Memcached重点是Redis可以持久化，支持两种不同持久化操作。

快照（Snapshotting RDB）：

Redis可以通过创建快照来获取存储在内存里面的数据在某个时间点的副本。Redis创建快照后，可以对快照进行备份，可以将快照复制到其他服务器从而创建具有相同数据的服务器副本（Redis主从结构，主要用来提供Redis性能），还可以将快照留在原地以便重启服务器的时候使用。

#在900s之后，如果至少有1个key发生变化，redis就会自动触发BGSAVE命令创建快照
save 900 1
#在300s之后，如果至少有10个key发生变化，redis就会自动触发BGSAVE命令
save 300 10
#在60s之后如果有1w个key发生变化，redis就会自动触发BGSAVE命令
save 60 10000

追加文件（append-only file,AOF）

与快照持久化相比，AOF持久化的实时性更好，因此也成为主流的持久化方案。

默认情况下redis没有开启AOF方式持久化

1	appendonly yes

开启AOF持久化后每执行一条会更改redis中的数据的命令，redis就会将该命令写入硬盘中的AOF文件。AOF文件的保存位置和RDB文件位置相同都是通过dir参数设置

默认文件名为appendonly.aof

#每次有数据修改发生都会写入aof，这样会严重降低redis的速度
appendfsync always
#每秒钟同步一次，显式的将多个写命令同步到硬盘
appendfsync everysec
#让操作系统决定何时同步
appendfsync no

为了兼顾数据和写入性能，用户可以考虑appendfsync everysec选项，让redis每秒同步一次AOF文件，redis性能几乎没收到任何影响。即使系统崩溃，用户也最多只会丢失一秒之内产生的数据。当硬盘忙于执行写入操作，redis还会放慢自己的速度来适应硬盘的最大写入速度。

Redis4.0对于持久化机制的优化

4.0开始支持RDB和AOF的混合持久化（默认关闭，可以通过配置项aof-use-rdb-preamble开启）

混合持久化开启，AOF重写的时候就会直接把RDB的内容写到AOF文件开头。这样的好处可以结合RDB和AOF的优点，可以快速加载同时避免丢失过多的数据。

缺点是：AOF里面的RDB部分也不是AOF的压缩格式，可读性差。
AOF重写

AOF重写可以产生一个新的AOF文件，这个新的文件和原有的AOF文件所保存的数据库状态一样，但是体积更小

AOF重写是一个有歧义的名字，功能是通过读取数据库中的键值来实现。程序无需对现有的AOF文件进行任何读入，分析重写，

4、Redis事务

redis通过multi，exec，watch等命令来实现事务transaction功能。

事务提供了一种将多个命令请求打包，然后一次性，按顺序执行多个命令的机制。

5、解决Redis的并发竞争key的问题

所谓redis的并发竞争key的问题也就是多个系统同时对一个key进行操作，但是最后执行的顺序和我们期望的顺序不同。也就导致了结果的不同

解决方案：

分布式锁zookeeper和redis都可以实现分布式锁。如果不存在redis的并发竞争key问题及，不要使用分布式锁，这样影响性能。

基于zookeeper临时有序结点可以实现的分布式锁

大致思想：每个客户端对某方法加锁时，在zookeeper上的与该方法对应的指定节点的目录下，生成一个唯一的瞬时有序结点。

判断是否获取锁的方式很简单，只需要判断有序结点中序号最小的一个。当释放所得时候，只要将这个瞬时结点删除就行。同时也避免服务挂了导致锁无法释放，从而产生死锁问题。

什么是RedLock

特性：

安全性：互斥访问，也就是永远只有一个client能拿到锁
避免死锁：最终client都可能拿到锁，不会出现死锁的情况，原本锁住某资源的client crash或者出现了网络分区
容错性：只要大部分redis结点存活就可以正常提供服务。

展开全文 >>

分布式锁的使用

2018-06-15

一、分布式锁

1、为什么要使用分布式锁

如果需要对一个共享变量进行多线程同步访问的时候，可以使用java多线程进行运行。

如果是单机应用，也就是所有的请求都会分配到当前服务器的JVM内部，然后映射为操作系统的线程进行处理，而这个共享变量只是在这个JVM内部的一块内存空间。

后续业务发展，需要做集群，一个应用需要部署好几台机器然后做负载均衡。

一个共享变量A，存在JVM1，JVM2，JVM3，这3个JVM内存中，这个变量A主要体现是在一个类中的一个成员变量，是一个有状态的对象。

比如UserController中的一个int类型的成员变量。如果不加任何控制的话，变量A同时都会在JVM分配一块内存，3个请求发过来，同时对这个变量操作，显然结果是不对的。即使不是同时发过来，3个请求分别操作3个不同JVM内存区域的数据，变量A之间不共享的话，也不具有可见性的话，处理结果也是不对的。

2、解决问题

为了保证一个方法或者属性在高并发情况下的同一时间只能被同一个线程运行，在传统单体应用单机部署的情况下，可以使用Java并发处理相关的API（比如ReentrantLock，Synchronized）进行互斥控制。在单机环境中，Java中提供了很多并发处理的API。但是随着业务发展的需要，原来的单机部署的系统被演化为分布式集群系统后，由于分布式系统多线程，多进程并且分布在不同机器上，这将使得原单机部署情况下的并发控制锁策略失效，单纯的Java API并不能呢提供分布式锁的能力。为了解决这个问题就需要一种跨JVM的互斥机制来控制共享资源的访问，这就是分布式锁要解决的问题。

3、分布式锁具备的条件

在分布式系统环境下，一个方法在同一时间只能被一个机器的一个线程执行。
高可用的获取锁与释放锁
高性能的获取锁与释放锁
具备可重入特性
具备锁失效机制，防止死锁
具备非阻塞锁特性，也就是没有获取到锁将直接返回获取锁失败。

4、分布式锁的3种实现方式

目前大型网站应用都是分布式部署，分布式场景中的数据一致性问题一直是一个重要的问题。出现了CAP定理。任何一个分布式系统都无法同时满足一致性(Consistency)，可用性(Availablility)，分区容忍性(Partition tolerance)，只能同时满足2个。

目前在绝大多数场景中，都是需要牺牲强一致性来换取系统的高可用性，系统往往只需要保证最终一致性就行。也就是只要这个最终时间是在用户可以接受的范围内就行。

在很多场景中，我们为了保证数据的最终一致性，需要很多技术支持。比如分布式事务，分布式锁。需要保证一个方法在同一个时间内只能被同一个线程执行。

基于数据库实现分布式锁
基于缓存Redis等，实现分布式锁
基于Zookeeper实现分布式锁

1、基于数据库实现排它锁(互斥锁)

1.1、解决方法1：使用唯一索引约束。

DROP TABLE IF EXISTS `method_lock`;
CREATE TABLE `method_lock` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键',
  `method_name` varchar(64) NOT NULL COMMENT '锁定的方法名',
  `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  `PRIMARY KEY (`id`),
  UNIQUE KEY `uidx_method_name` (`method_name`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8 COMMENT='锁定中的方法';

1 2	--获取锁 insert into method_lock(method_name,desc) values('xxxService','methodName';)

这种解决方法，对method_name做了唯一性约束，这里如果有多个请求同时提交到数据库的话，数据库会保证只有一个操作可以成功。

1.2、解决方法2：先获取锁的信息，然后更新状态。

DROP TABLE IF EXISTS `method_lock`;
CREATE TABLE `method_lock` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键',
  `method_name` varchar(64) NOT NULL COMMENT '锁定的方法名',
  `state` tinyint NOT NULL COMMENT '1:未分配；2：已分配',
  `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  `version` int NOT NULL COMMENT '版本号',
  `PRIMARY KEY (`id`),
  UNIQUE KEY `uidx_method_name` (`method_name`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8 COMMENT='锁定中的方法';

--先获取锁的信息
select id,method_name,state,version from method_lock where state=1 and method_name='methodName';
--占有锁
update method_lock set state=2,version=2,update_time=now()
where method_name='methodName' and state=1 and version=2;
--如果没有更新影响到的这一行数据，说明这个资源已经被别人占位了。

1.3、这2种方案都是有弊端

缺点：
- 这把锁很依赖数据库的可用性，如果数据库是单个节点，一旦数据库挂了，则业务系统不可用了。
- 这把锁还没有失效时间，一旦解锁失败(更新state状态失败)，就会导致锁记录一直在数据库中，其他线程无法获取锁。
- 这把锁是非阻塞的，因为数是insert操作，一旦插入失败就会直接报错，没有获取锁的线程就不会进入到等待队列，要想再次获取锁就必须再次触发获取锁的操作。
- 这把锁是不可重入的，同一个线程在没有释放锁之前无法再次得到这个所，因为数据已经在数据库中存在了。
解决方案：
- 数据库是单点的话，可以数据库集群，然后数据之前进行同步，一旦挂掉，快速切换到备份库上。
- 没有失效时间，可以搞一个定时任务，每隔一段时间把数据库中的超时的数据delete。
- 他是非阻塞的，可以搞一个while循环，直到insert成功后再返回。
- 它是不可重入的，可以在数据库表上加一个字段，记录当前获取锁的机器的主机信息和线程信息，那么下次获取锁的时候可以先查询数据库，如果当前及其的主机信息和线程信息在数据库可以查到的话，直接把锁分配给他就行了。

2、基于Redis实现分布式锁

1 2	## 获取锁使用的命令： SET resource_name_value NX PX 30000

@Autowired
private RedisTemplate redisTemplate;

private static final String LOCK="distribute_key";

public boolean test(String lockKey){
    Boolean lock=false;
    /**
     * 加锁的时候，在try块中，尝试获取锁，在finaly块中释放锁。
     */
  try {
      //如果key不存在，则新增，如果存在则不改变已经有的值
      lock = redisTemplate.opsForValue().setIfAbsent(lockKey, LOCK);
      log.info("test方法是否获取到锁：" + lock);
      if (lock) {
          //todo 业务逻辑
          redisTemplate.expire(lockKey, 1, TimeUnit.MINUTES);
          return true;
      } else {
          log.info("test方法没有获取到锁，不执行任务！");
      }
  }finally {
      if(lock){
          redisTemplate.delete(lockKey);
          log.info("test方法任务结束，释放锁！");
      }else{
          log.info("test方法没获取到锁，不需要释放锁！");
      }
      return false;
  }
}

2.1、弊端

首先是这主从结构存在明显的竞争状态：

客户端A从master获取到锁，在master将锁同步到slave之前，master挂掉了，slave节点被晋级为master节点，客户端B取的了同一个资源被客户端A已经获取到的另外一个锁。安全失效。

3、基于Zookeeper实现

Zookeeper中有节点的概念，Zk的数据存储结构就像一棵树，这棵树由节点组成，节点叫Znode，有点类似Linux的文件系统结构。

Znode有4种类型：

持久节点Persistent

默认的节点类型，创建节点的客户端与zk断开连接后，这个节点仍然存在。
持久节点顺序节点Persistent_Sequential

顺序节点，就是在创建节点的时候，zk根据创建的时间顺序给该节点名称进行编号。
临时节点Ephemeral

和持久节点相反，当创建节点的客户端与zk断开后，临时节点会被删除。

临时顺序节点（Ephemeral_Sequential）

临时顺序节点就是结合了临时节点和顺序节点的特点：在创建临时节点的时候，zk根据创建的时间顺序给节点名称进行编号，当创建节点的客户端与zk断开连接后，临时顺序节点被删除。

3.1、Zookeeper分布式锁的原理

Zk分布式锁使用的是临时顺序节点，也就是客户端断开连接后，会删除该节点，然后客户端创建节点的时候，会按照时间顺序来对临时节点命名。

获取锁
- 首先在zk中创建一个持久节点ParentLock，当第一个客户端想要获取锁的时候，需要在ParentLock这个节点下面创建临时顺序节点Lock1。

Client1查找ParnentLock下面所有的临时顺序节点并排序，然后判断自己创建的节点Lock1是不是顺序最靠前的一个节点。如果是第一个节点，就成功获取锁。
这个时候，再有一个客户端Client2前来获取锁，首先在ParentLock下再创建一个临时顺序节点Lock2
Client2查找ParnentLock下面所有的临时顺序节点并排序，判断它自己创建的节点Lock2是不是顺序最靠前的一个，结果发现节点Lock2并不是最小的。于是，Client2向排序仅仅比他靠前的节点Lock1注册Watcher，用来监听Lock1节点是否存在。这意味者此时Client2抢锁失败，进入了等待状态。
假如这个时候，又有一个客户端Client3前来获取锁，则在ParentLock下再创建一个临时顺序节点Lock3
Client3查找ParentLock下面所有的临时顺序节点并排序，判断自己所创建的节点Lock3是不是顺序最靠前的一个，结果同样发现节点Lock3并不是最小的。

于是，Client3向排序仅仅比他靠前的节点Lock2注册Watcher，用来监听Lock2节点是否存在，这意味这Client3同样抢锁失败，进入了等待状态。
这样就形成了，Client1获取了锁，Client2监听了Lock1，Client3监听额Lock2。从而形成了一个等待队列，很像Java中ReentrantLock所依赖的。

释放锁
- 1、任务完成，客户端显示释放
  
  当任务完成后，Client1会显示调用删除节点Lock1的指令。
- 2、任务执行过程中，客户端崩溃
  
  得到锁的Client1在执行任务过程中，突然挂了，则会断开与Zk服务端的连接，根据临时节点的特性，它自己创建的节点也会被自动删除。
  
  由于Client2一直监听者Lock1的存在状态，当Lock1节点被删除后，Client2会立刻得到通知，这时候Client2会再次查ParentLock下面的所有节点，确认自己创建的节点Lock22是不是目前最小的节点，如果是最小，则Client2就成功获取了锁。
  
  同理，如果Client2也因为任务完成或者节点崩溃而删除了Lock2，那么Client3会收到通知。
  
  最终，Client3成功获取锁。

3.2、实现方法

可以直接使用zk第三方库Curator客户端，这个客户端封装了一个可重入的锁服务。

/**
     * InterProcessMutex是分布式锁的实现，acquire方法用户获取锁，release释放锁
     */
    @Autowired
    private InterProcessMutex interProcessMutex;
    
    public boolean tryLock(long timeout,TimeUnit unit){
        
        try {
            interProcessMutex.acquire(timeout,unit);
        } catch (Exception e) {
            e.printStackTrace();
        }
        return true;
    }
    @Autowired
    private ExecutorCompletionService executorService;
    public boolean unLock(){
        try {
            interProcessMutex.release();
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            //executorService.schedule(new Cleaner(client,path),delayTimeForClean,TimeUnit.MILLISECONDS);
        }
        return true;
    }

缺点：

性能上，并没有缓存那么高，因为每次在创建锁和释放锁的过程中，都需要动态创建按，销毁临时顺序节点来实现锁功能。zk中创建和删除节点只能通过leader服务器来执行，然后将数据同步到所有的follwer服务器上。

使用zk也有可能带来并发问题，只是并不常见。由于网络抖动，客户端与zk集群的session连接断了，那么zk以为客户端挂了，就会删除临时节点，这时候其他客户端就可以获取到分布式锁了。也有可能产生并发问题，并不常见，因为zk有重试机制，一旦zk集群检测不到客户端的心跳，你就会重试，Curator客户端（操作zk的客户端）支持多种重试策略，多次重试之后还是不行的话，就会删除临时节点。因此，选择一个合适的重试策略也很重要，要在锁的粒度和并发之前找一个平衡。

5、总结

分布式锁	优点	缺点
Zk	1、有封装好的框架，容易实现。2、有等待锁的队列，大大提升抢锁效率。	添加和删除节点性能比较低
Redis	Set和Del执行的性能比较高	1、实现复杂，需要考虑超时，原子性，误删的情况。2、没有等待锁的队列，只能在客户端自旋来等待，效率比较低。

6、3种方案比较使用

3种方法，就如同CAP一样，在复杂性，可靠性，性能等方面无法同事满足。应该根据不同应用场景，选择最合适的分布式锁。

6.1、从理解的难易程度上，从低到高

数据库——->Redis——->Zk

6.2、从实现的复杂程度上，从低到高

zk————->Redis——->数据库

6.3、从性能角度，从低到高

数据库————–>zk———>Redis

6.4、从可靠性角度，从低到高

zk—————>Redis—————>数据库

展开全文 >>

分布式锁

2018-06-14

一、分布式锁

在单机场景下，可以使用Java里的内置所来实现进行同步。但是在分布式场景下，需要同步的进程可能位于不同的节点上，那么就需要使用分布式锁。

阻塞所通常使用互斥量来实现：

互斥量mutex为0表示有其他进程在使用锁，此时处于锁定状态。
互斥量mutex为1表示未锁定状态。

1和0可以用一个整形值表示，也可以用某个数据是否存在表示。

1、数据库的唯一索引

获取锁时向表中插入一条记录，释放锁时删除这条记录。唯一索引可以保证该记录只被插入一次，那么就可以用这个记录是否存在来判断是否在锁定状态。

存在以下几个问题：

锁没有失效时间，解锁失败的话，其他进程无法再获得该锁。
只能是非阻塞锁，插入失败直接就报错，无法重试。
不可重入，已经获得锁的进程也必须重新获取锁。

2、Redis的SETNX指令

使用SETNX（set if not exist）指令插入一个键值对，如果key已经存在，那么会返回false，否则插入成功并返回true。

SETNX指令和数据库的唯一索引类似，保证了只存在一个key的键值对，那么可以用一个key的键值对是否存在来判断是否存于锁定状态。

EXPIRE指令可以为一个键值对设置一个过期时间，从而避免了数据库唯一索引方式中释放锁失败的问题。也就是数据库的唯一索引解决方案的升级而已，只是可以设置过期时间。

3、Redis的RedLock算法

使用了多个Redis实例来实现分布式锁，这是为了保证在发生单点故障时仍然可用。多个Redis实例实现，也就是即使一台Redis挂了，还可以有其他的服务可用。

尝试从N个互相独立的Redis实例中获取锁。
计算获取锁消耗的时间，只有当这个时间小于锁的过期时间，并且从大多数(N/2+1)，半数以上的实例上获取锁，那么就认为获取锁成功了。
如果锁获取失败，就到每个实例上释放锁。

4、Zookeeper的有序节点

1、Zookeeper抽象模型

Zookeeper提供了一种树型结构的命名空间，/app1/p_1节点的父节点为app1。有点类似linux系统文件系统，文件目录树

2、节点类型

永久节点：不会因为会话结束或者超时而消失。
临时节点：如果会话结束或者超时就会消失。
有序节点：会在节点名的后面加上一个数字后缀，并且是有序的。例如生成的有序节点为/lock/node-0000000000，它的下一个有序节点就是/lock/node-0000000001，以此类推。

3、监听器

为一个节点注册监听器，在节点状态发生改变的时候，会给客户端发送消息。

4、分布式锁实现

创建一个目录/lock。
当一个客户端需要获取锁时，在/lock下创建临时的且有序的子节点。
客户端获取/lock下的子节点列表，判断自己创建的子节点是否为当前子节点列表中序号最小的子节点，如果是则认为获得锁。否则监听自己的前一个子节点，获得子节点的变更通知后重复此步骤直到获取锁为止。
执行业务代码，完成后，删除对应的子节点。

5、会话超时

如果一个已经获的锁的会话超时了，因为创建的是临时节点，所以该会话对应的临时节点会被删除，其他会话就可以获取锁。可以看到zookeeper分布式锁不会出现数据库的唯一索引的分布式锁释放锁失败的问题。

6、羊群效应

一个节点未获得锁，只需要监听自己前一个子节点，这是因为如果监听所有的子节点，那么任意一个子节点状态改变，其他所有子节点都会收到通知(羊群效应)，而我们秩序网它的后一个子节点收到通知。

展开全文 >>

JVM相关

2018-06-13

一、JVM相关的笔记

简历上可以写，熟悉JVM架构与GC垃圾回收机制，以及相应的参数调优，有过在Linux上进行系统优化的经验。

面试官让你谈谈jvm优化，我是根据淘宝周志明那哥们写的那本深入理解java虚拟机书，99*%的优化的是堆Heap，1%的优化的是方法区Method Area，虚拟机栈Stack是私有的，不可能优化，最多是栈溢出StackOverFlow，调整一下栈的大小-xss参数
静态变量+常量+类信息+运行时常量池存在方法区。方法区一般放的是类的构造函数和接口的代码。所有定义的方法的信息都保存在方法区。
引用存在虚拟机栈里。实例变量存在堆里面。

1、栈

栈，也叫栈内存，主管java程序的运行，是在线程创建是创建，它的生命周期跟随线程的生命周期，线程结束栈内存也就释放，对于栈来说，不存在垃圾回收，生命周期和线程一致，是线程私有的。
基本类型变量和对象的引用变量，都是在函数的栈内存里分配。

1.1、栈存储的是什么？

栈是先进后出，比如你main方法调用test1，test1调用test2，等等，所以main在最底下，可以看作一个栈帧对应一个方法。
栈帧里面存3种类型变量：

本地变量（local variables），输入参数和输出参数，以及方法内的变量。
栈操作（ operand stack）出栈和入栈的操作
栈帧数据（Frame data）：包括类文件，方法等，言下之意，每一个方法就是一个栈帧。

public class{
    //test的栈帧在上面，直接如此调用，把栈给撑爆了，所以栈溢出
    public void test(){
          test();
     }
    //main方法的栈帧在最底部
    public static void main(String[] Args){
         test();
     }
}
 //死循环，或者循环递归调用,出现的异常java.lang.StackOverflowError

2、堆Heap

一个JVM实例只存在一个堆内存，堆内存大小是可以调节的。类加载器读取了类文件后，需要把类、方法、成员变量存在堆内存中，保存所有引用类型的真实信息，以方便执行器执行，堆内存分为三个部分：

2.1、Young generation space 新生代 young

新生代分为3个区：

Eden space伊甸区
Survivor 0 space 幸存0区
Survivor 1 space 幸存1区

2.2、Tenure generation space 养老区 Old

2.3、Permanent space 永久区 Perm

二、3种JVM

SUN公司的HotSpot虚拟机
BEA公司的JRockit虚拟机
IBM公司的J9VM虚拟机

展开全文 >>