# 两个slice之间怎么判断是否相等



相等的前提首先是，数据长度一致，顺序一致

## byte相等
```golang
    a:=[]byte{0,1,3,2}
    b:=[]byte{0,1,3,2}
    c:=[]byte{1,1,3,2}
    
    bytes.Equal(a,b)
    bytes.Equal(a,c)
```

## 直接调用方法
比较两个对象内部包含的所有元素是否相等
```golang
    a := []int{1,2,3,4}
    b := []int{1,3,2,4}
    c := []int{1,2,3,4}
    reflect.DeepEqual(a,b)
    reflect.DeepEqual(a,c)
```

## 手写比较
reflect会比较消耗性能

这个就是手写遍历循环，就不细说了，不过缺点是只能针对某个类型写，但之后有泛型的话可以统一写了

Slice判等

# 记录一些零零碎碎的方法




记录一些不好分类的，偶然看到的知识吧
# 两数交换的方法
有三种
- 一种是用tmp存储作为过渡，然后进行交换
```golang
a := 0
b := 1
tmp := a
a = b
b = tmp
```
优点：适合各自数据类型

缺点：需要开辟新的空间

- 利用 b = a+b-b a = a+b-(a+b-b)
```golang
a := 0;b:= 1
a = a + b
b = a - b
a = a - b
```
优点：节省空间

缺点：两数和可能会越界，这个也是用到两数和可能出现的问题，而且只适用数值类型

- 异或操作,两个数相同异或为0
```golang
a = a^b
b = a^b
a = a^b
```
优点：
    
- 节省空间
- 不会超出范围
- 效率高

缺点：
- 只适用于数值类型

理解这个方法要懂异或操作：
二进制两数运算为
    
    0 ^ 0 = 0
    0 ^ 1 = 1
    1 ^ 0 = 1
    1 ^ 1 = 0
假设a = 10，b=12
二进制分别为 1010 1100
在二进制看来，就是交换不同的01，在这里即是中间两位
第一次 a = a ^ b = 0110,相当于找到不同的位，将不同的位置为1,存到a
第二次 b = a ^ b = 0110 ^ 1100 = 1010,就是对两个不同的数进行取反，那不同的位置已经为1，所以如果是为1的话异或就为0，如果是0的话异或就为1，相当于取反了
第三次 a ^ b = 0110 ^ 1010 = 1100 ,这一次的b就是相当于交换前的a，所以是对a中间两位数取反


## 位运算
- 按位取反
  
  ~  0 - 1, 1- 0
- 按位与

  & 同为1为1，其余为0
- 按位或

  | 存在1为1，否则为0
- 按位异或
  
  ^ 相同为0，不同为1
  
主要是异或的性质，如果两个相同的数异或得0，而且异或是有交换律和结合律的,与0异或都是他本身，简单来说，异或后得到的结果中，1即为两数不同的位置，可以注意这个性质，就可以得到上面两数交换的第三种方法
        
    eg.找出没有重复的数
    存在一列数据，其中大部分数据两两配对，只有一个数据落单，请找出这个落单的数据
    解释：这时候就可以利用异或的性质
    
    public static int find(int[] arr){
        int tmp = arr[0];
        for(int i = 1;i<arr.length;i++){
            tmp = tmp ^ arr[i];
        }
        return tmp;
    }
    
    两两相异或，最后重复的异或后得到0，0与落单的进行异或得到落单的数
    
    还有一种时间复杂度一样，但空间复杂度为O(n)的算法，就是用哈希再存储
    
### 题目
#### 找出不大于N的最大的2的幂指数
思路不难，如果转为二进制来看，比如000100100，那最大的就是000100000，就是把最左边的1后面的数字转为0
```java
public static int findN(int n) {
    n | n >> 1;
    n | n >> 2;
    n | n >> 4;
    n | n >> 8;
    return (n + 1) >> 1;
}
```
   
    假设最左边的1处于二进制中的第k位，那么把n右移一位之后，得到的结果中第k+1位也必定为1，然后
    把n与右移后的结果做或运算，即有1为1，那么k和k+1位都为1，然后再位移两位，k+2和k+3必定为1，
    然后再或运算，以此类推，最多将k以及k以后的都变为1
    之后再将得到的最后值+1，即获得最大值的前一位为1，其余为0，那么就右移一位就得到结果
    
#### 求平均值
防止爆int
- (a&b) +((a^b)>>1)
- (b-a)/2+a;
- ((b-a)>>1)+a;

讲一下第一个的原理，a = 10 = 1010,b = 12 = 1100

那么a&b = 1000 = 8,a^b = 0110 = 6,a^b >> 1 = 0011 = 3

a^b前面也说了，就是可以获得两数不同的位置，那右移一位，就是除以2求平均值

a&b是求同一个bite位上相同的平均值，即为其自身

所以就是求相同位置的平均值加上不同位置的平均值

### 快速幂
可以用O(log n)的时间复杂度计算乘方

#### 递归
正常计算一个数的2的n次幂，一般是要经过n次乘法，但其实好像也可以用2^n/2 * 2^n/2来得出结
果，而2^n/2也可以推为另外两个计算
那就可以使用递归来获得结果
```golang
 int qpow(int a,int n) {
    if(n == 0) return 1;
    else if(n%2==1) return qpow(a,n-1) * a;
    else {
        int tmp = qpow(a,n/2);
        return tmp * tmp;
    }
}
```

#### 非递归
将幂转换为二进制的形式，即7^10,看为7^(1010),可以看成若干个7(100...)相乘，即7^1,7^2,7^4,所以将底数平方就可以计算它们.
```golang
int qpow(int a,int n){
    int ans = 1;
    while(n){
        if(n&1) ans *= a;
        a *= a;
        n >> = 1;
    }
    return ans;
}
```

## 如何写出CPU跑得更快的代码
即如果能在CPU Cache命中的话，会带来较大的性能提升
L1 Cache一般分为[数据缓存]和[指令缓存]

### 提升数据缓存的命中率
```golang
array[N][N] = 0;
// Demo1
for(int i = 0;i<N;i++){
    for(int j = 0;j<N;j++){
        array[i][j] = 0;
    }
}

// Demo2
for(int i = 0;i<N;i++){
    for(int j = 0;j<N;j++){
        array[j][i] - 0;
    }
}
```
两个Demo里面，数据缓存命中率高的是1，因为数组是连续线性存储在内存里的，当array[0][0]没在cacha里查到，则CPU会将array[0][0]和之后的一段一起放入Cache里面，这个就是缓存的`空间局部性原理`，还有一个`时间局部性`是这次被使用，则在之后一段时间也可能再次被使用,所以如果下次访问的刚好在前一段刚好带来Cache里面的部分，则可以直接命中，而Cache一次性加载的元素大小与Linux里的`coherency_lone_size`有关，通常是64个字节

### 提升指令缓存的命中率
```golang
int array[N]
for(int i = 0;i<N;i++){
    array[i] = rand() % 100;
}

// 操作一：数组遍历
for(int i =0;i<N;i++){
    if(array[i] < 50){
        array[i] = 0;
    }
}

// 操作二：排序
sort(array,array+N);
```

那么先遍历再排序快还是先排序再遍历快

那先了解CPU的`分支预测器`,对于if语句，意味着至少可以选择跳转到两段不同的指令执行，即if还是else
，如果可以预测到接下来执行的是if还是else的话，就可以把对应的指令提前放到指令缓存里，这样CPU可以直接从Cache读取到指令。

当数组种元素随机，则分支预测就无法有效工作，当数组元素都是顺序，分支预测器会动态地根据历史名字数据对未来进行预测，这样命中率就会很高

所以先排序再遍历会快

### 提升多核CPU的缓存命中率

现代CPU是多核心的，线程在不同CPU核心来回切换执行，这对CPU Cache不是有利的，虽然L3 Cache是多核心之间共享，但L1，L2都是每个核心独有的.如果一个线程在不同核心之间来回切换的话，命中率就会受影响，所以当有多个同时执行[计算密集型]的线程，为了防止因为切换到不同核心，可以把线程绑定在某一个CPU核心上


## LCM && gcd
```java
    public static int gcd(int a,int b){
        return b != 0 ? gcd(b,a%b):a;
    }
    
    public static int lcm(int a,int b){
        return a * b / gcd(a,b);
    }
```


## DNS查询
DNS查询其实会先经过三步，浏览器会先去查询浏览器的缓存，然后由操作系统查询一遍缓存，最后查询一遍本地hosts文件，如果没有才会请求本地DNS服务器

杂七杂八的东西

# Redis五种基本数据结构的实现



## String

### SDS
SDS(simple dynamic string，SDS),简单动态字符串

redis是用C写的，但是字符串没有使用C语言的字符串进行表示，而是自己实现了一个，C的字符串只是被使用于一个字符串常量，而要可以修改的话，则是使用SDS表示字符串值

```C
struct sdshr {
    // 记录buf数组中已使用字节的数量
    // 等于 SDS 所保存字符串的长度
    int len;
    
    // 记录 buf 数组中未使用字节的数量
    int free;
    
    // 字节数组，用于保存字符串
    char buf[];
}
```

主要好像是多了未使用空间和已使用长度这两部分，那这两部分的作用是什么？

已使用长度倒是比较明确，可以以常数复杂度获取字符串长度，因为C字符串并不记录自身的长度信息，而是遍历整个字符串，为遇到的每个字符进行计数，直到遇到代表字符串结尾的空字符为止，确保获取字符串长度不会成为性能瓶颈

而free部分，则可以避免缓冲区溢出，C语言如果直接拼接两个字符串，若分配的空间不够，且它对应存储的空间有另外一个字符串连续，则可能会直接修改下一个字符串的内容，而Redis的SDS API则不会，可以先检查是否有足够的剩余空间，再进行下一步的拼接

### 空间预分配
    是为了减少C语言进行内存重分配扩展s空间的次数，因为内存重分配设计复杂算法，可能需要执行系统
    调用，所以Redis采取了两种空间预分配策略
    
    - 当len<1MB时，那么会给分配和len属性同样大小的未使用空间
    - 当len>1MB时，那么会给分配1MB未使用空间
    
### 惰性空间释放

     用于优化SDS的字符串缩短操作：当SDS的API需要缩短SDS保存的字符串时，程序并不立即使用内存重
     分配来回收缩短后多出来的字节，而是使用free属性将这些字节的数量记录起来，并等待将来使用
     
### 二进制安全

还有另外一个优点是二进制安全，C语言是通过空字符判断字符串结束的，但是redis如果存储二进制数据的话，其中也有可能存在空字符，所以redis直接把所有数据当作二进制来存储，然后取值是通过len属性判断实际内容长度的

二进制安全简单来说，就是只关心二进制话的字符串，不关心具体形式

### 使用场景
1. 缓存对象

    - 直接缓存整个对象的JASON
    - 将key进行分离采用MSET存储，用MGET获取各属性值

2. 常规计数器

    - 比如IP限流，点赞，转发，库存数量等等

3. 分布式锁

    - SETNX，实现`key不存在才会插入`，可以用来实现分布式锁：
        - 如果key不存在，则显示插入成功，表示加锁
        - key存在，插入失败，加锁失败

    对锁还会加上过期时间，避免死锁或者程序宕机不释放锁
    `SET lock_key unique_value NX PX 10000`
    
    解锁过程则需要区判断是否执行操作的客户端是加锁的客户端，是的话才允许将其删除
    
    可以看出解锁有两个操作，1是判断，2才是删除，所以需要保证原子操作，这时候就需要lua脚本来保证解锁的原子性
    
    ```lua
    if redis.call("get",KEYS[1]) == ARGV[1] then
        return redis.call("del",KEYS[1])
    else
        return 0
    end
    ```

4. 共享Session
    
    单系统应用中常直接将Session信息保存在服务器端，而分布式则不能这样操作
    
    例如用户一建立会话，Session信息存储到了服务器一中，但第二次访问时被分配到了服务器二上，这时候服务器二上没有用户一的Session信息，即认为他没有登录，就需要他重新登录了，因为分布式系统每次都会将请求随机分配到不同的服务器上
    
    所以需要用一个能将Session信息存储起来且可以被所有服务器访问到的方法，即可以用Redis对这些信息进行统一的存储和管理
    
## List
    
   底层数据结构是由`双向链表或压缩列表`实现
    - 如果列表元素个数小于512，列表每个元素值小于64字节，则会用压缩列表作为底层数据结构
    - 否则使用双向链表
    
   不过在3.2版本之后，List数据类型底层数据结构就只由quicklist实现了
    
#### 使用场景
    
   - 消息队列
   消息队列在存取消息时，必须要满足三个需求，分别是`消息保序、处理重复的消息和保证消息可靠性`
   Redis的`List`和`Stream`两种数据结构，可以满足上面三个需求
   
   1. 如何满足消息保序
    
   List本身是按照先进先出的顺序对数据存取的，所以已经满足保序的需求了，例如用LPUSH+RPOP实现消息队列，选择一个方向即可满足
   
   不过这样存在的问题是，生产者写入数据时，生产者不会主动去通知消费者，所以消费者需要开启一个协程不断的调用RPOP命令，等有消息写入时，立刻返回结果，否则返回空值则继续循环，所以会使得消费者程序的CPU一直消耗在执行RPOP命令上，带来不必要的性能损失
   
   所以可以使用Redis的`BRPOP`命令,称为阻塞式读取，客户端在没有读到队列数据时，自动阻塞直到有新数据写入再读取新数据，相比前一种方法这样更节省CPU性能
   
   2. 处理重复的消息
   
   消费者要实现重复消息的判断，需要两个方面的要求：
   - 每个消息都要有一个全局ID
   - 消费者要记录已经处理的消息ID

   不过LIST的缺点就是不会为每个消息生成ID，所以我们需要自行为每个消息生成一个全局唯一ID，生成之后，再用LPUSH命令把消息插入List时，在消息中包含这个全局唯一ID
   
   3. 如何保证消息可靠性？
   
   当消费者从List读取一条，则该消息就不存在了，所以如果消费者处理一半时出现了宕机，则该消息就无效了且无法找回
   
   为了留下这个消息，使用List的`BRPOPLPUSH`命令，读取出来，并且存到一个备份的List留存
   
### 缺点
   读取完就被删除了，只支持单个消费者读取
   
   
## Hash
底层数据结构是由压缩列表或哈希表实现

- 如果哈希类型元素个数小于512个，所有值小于64字节，Redis会使用压缩列表作为Hash类型的底层数据结构
- 如果哈希类型元素不满足上面条件，Redis会使用哈希表作为Hash类型的底层数据结构

#### 使用场景
- 购物车
    - 添加商品 HSET cart:{用户id} {商品id} 1
    - 添加数量 HINCRBY cart:{用户id} {商品id} 1
    - 商品总数 HLEN cart:{用户id}
    - 删除商品 HDEL cart:{用户id} {商品id}
    - 获取购物车所有商品 HGETALL cart:{用户id}

- 令牌桶限流

## Set
无序并唯一的键值集合，存储顺序不会按照插入的先后顺序进行存储

一个集合最多可以存储`2^32-1`个元素，概念和数学中的集合基本类似，可以交集，并集，差集等，所以Set类型除了支持集合内的增删改查，同时还支持多个集合取交，并，差

### 内部实现
Set类型的底层数据结构是`哈希表`或`整数集合`实现
- 如果集合元素都是整数且个数小于512，则使用整数集合作为Set类型的底层数据结构
- 如果集合中的元素不满足上面条件，则使用哈希表作为Set类型的底层数据结构

### 使用场景
- 点赞
 保证一个用户只能点一个赞，添加到集合中
- 共同关注
- 抽奖活动
 允许重复中奖，则使用`SRANDMEMBER`，如果不允许重复中奖，可以使用`SPOP`命令
 
## Zset
在Set的基础上多了一个排序属性score
### 内部实现
底层数据结构是由`压缩列表或跳表`实现
- 如果有序集合的元素个数小于128个，并且每个元素的值小于64字节，Redis会使用压缩列表作为Zset类型的底层数据结构
- 如果有序集合的元素不满足上面条件，会使用跳表

> Redis7.0中，压缩列表换为了listpack数据结构了

### 应用场景
- 排行榜
  ```golang
  ZADD user:xiaolin:ranking 200 article:1
  ZADD user:xiaolin:ranking 40 article:2
  ZADD user:xiaolin:ranking 70 article:3
  ZADD user:xiaolin:ranking 31 article:4
  
  // 点赞
  ZINCRBY user:xiaolin:ranking 1 article:3
  
  //查看某篇文章的点赞数量
  ZSCORE user:xiaolin:ranking article:3
  
  //倒序获取有序集合key才start下标到stop下标的元素
  ZREVRANGE user:xiaolin:ranking 0 2 WITHSCORES
  1) "article:1"
  2) "200"
  3) "article:3"
  4) "70"
  5) "article:2"
  6) "40"

  //获取区间
  ZRANGEBYSCORE user:xiaolin:ranking 100 200 WITHSCORES
  ```
  
- 手机号、姓名
 这里的分数需要一致，主要是对key进行排序
 ```golang
 ZADD phone 0 13100111100 0 13110114300 0 13132110901
 ZADD phone 0 13200111100 0 13210114300 0 13252110901
 
 // 获取所有号码
 ZRANGEBYLEX phone - +
 
 // 获取132号段的号码
 ZRANGEBYLEX phone [132 (133
 
 // 姓名排序
 ZADD names 0 Toumas 0 Jake 0 Bluetuo 0 Gaodeng 0 Aimini 0 Aidehua
 
 // 获取所有人
 ZRANGEBYLEX names - +
 
 // 获取名字中大写字母A开头的所有人
 ZRANGEBYLEX names [A (B
 
 // 获取名字中大写字母C到Z的所有人
 ZRANGEBYLEX names [C [Z
 ```
   
## Bitmap
位图，一连串的`0|1`构成的，通过`offset`偏移量来查找定位元素

### 使用场景
- 签到统计
一个bit代表一天，一个用户只需要31个bit即可，一年也只需要365个bit
```golang
// 统计id为100的用户在22年6月的签到情况

// 三号签到
SETBIT uid:sign:100:202206 2 1

// 检验三号签到
GETBIT uid:sign:100:202206 2

// 统计6月签到
BITCOUNT uid:sign:100:202206

// 找到6月第一次打卡时间
BITPOS key bitValue [start] [end]
BITPOS uid:sign:100:202206 1
```
- 判断用户登录状态
- 连续签到用户数
 多个bitmap，记录每天的签到人员，然后进行与操作
 
 ## HyperLogLog
 用于`基数统计`的数据集合，即统计一个集合中不重复的元素个数，不过HyperLogLog是基于概率完成的，标准误算率为0.81%
 
 优点是在数量很大时，计算基数所需的内存空间总是固定的且很小
 
 每个HyperLogLog只需要12KB内存，就可以计算接近2^64个不同元素的基数
 
 ### 命令
 ```shell
 PFADD key element [element ...]
 PFCOUNT key [key ...]
 PFMERGE destkey sourcekey [sourcekey ...]
 ```
 
 ### 使用场景
 - 百万级网页UV计数
 
 
 ## GEO
 主要是地理位置的存储，内部是Sorted Set类型，即Zset
 
 使用GeoHash编码方法实现了经纬度到Sorted Set中元素权重分数的转换，关键机制是[对二维地图做区间划分]和[对区间进行编码],一组经纬度落在某个区间后，就用区间的编码值来表示，并把编码值作为Sorted Set元素的权重分数，就可以根据这个权重实现`搜索附近`的需求
 
 
 ## Stream
 专门为消息队列设计的数据类型
 在之前使用的方法都有缺陷
 - 发布订阅模式：
  不能持久化可靠的保存消息，并且对于离线重连的客户端不能读取历史消息
 - List
  不能重复消费，需要实现全局唯一ID
   
 相比前面两种方法，Stream实现了消费组
 ```golang
 // 0-0表示从第一条消息开始读取
 XGROUP CREATE mymq group1 0-0
 XGROUP CREATE mymq group2 0-0
 
 // 消费组group1内消费者从mymq消息队列
 ```
 
 具体使用会比前面难一点，这个在之后进行补充
 
 ### 缺点
 使用Redis作为消息队列有一些缺点：
 1. Redis作为中间件本身会使得数据丢失
 2. 面对消息挤压，内存资源会紧张，因为Redis会将消息存于内存当中，当然可以设置队列最大长度，当队列最大长度超出上限，旧消息会被删除，只保留固定长度的新消息，但这样又可能会使得消息丢失了


 ### 发布订阅的缺点
 1. 没有基于任何数据类型实现，所以不具备[数据持久化]的能力，所以宕机后所有数据都会丢失
 2. 发布订阅模式是【发后即忘】的工作模式，如果有订阅者重连则不能消费之前的历史信息
 3. 当消费端有一定的消息积压时，即消费者消费不过来生产者的消息，消费端会被强行断开

所有只适合即时通讯的场景，比如构建哨兵集群的场景采用了发布/订阅机制

Redis数据结构

# 限流的多种方法




近期随着微服务流行，服务之间的依赖加深，为了防止某个服务的请求突增而给下游服务带来较大压力，往往需要采取方法来保证稳定性，往往就通过缓存、限流、熔断等级、负载均衡等多种方法保证，这里主要是讲限流

## 限流方法
    即对请求或并发数进行限制，通过对一个时间窗口内的请求量进行限制保障系统正常运行
- 阈值：在一个单位时间内允许的请求量，如QPS限制为10，说明1s内最多10次请求
- 拒绝策略：超过阈值的请求的拒绝策略，常见的是直接拒绝、排队等待

### 固定窗口算法
又称计数器算法，通过一个支持原子操作的计数器来累计1s内的请求次数，当达到阈值时触发拒绝策略，每过1s计数器重置为0开始重新计数

但是这种方法有一定的问题，比如在时间窗口的临界处如果此时有大量请求，在下一个窗口的开始也有大量请求，例如QPS为10，第一个窗口1s的后500ms突然有9个请求，而接下来计数器清空，在下一个窗口的前500ms突然也有9个请求，那这样两个500ms也是1s，而这个1s的窗口里就超出了QPS了

### 滑动窗口算法
在固定窗口的基础上改进，比如500ms滑动一次窗口，只要滑动的间隔越短，临界突变问题发生的概率也就越小，不过只要有窗口的存在就仍然有可能发生该问题

### 滑动日志算法
逻辑就是记录下每个请求的时间点，如何新请求到达时去判断时间范围内的请求数量是否超过指定阈值，这样就没有时间窗口的问题了，不过每次都需要去记录请求的时间点，需要占用较大内存

### 漏通算法
请求看为生产者，每个请求如同一滴水，放到一个队列(漏桶)中，而桶底有一个孔，不断漏出水滴，消费的速率等于限流阈值，例如QPS为2，则效率速率为`1s/2=500ms`,当请求堆积超出指定容量会触发决绝策略
缺点就是因为消费速率固定，那如果漏桶接近满的时候，无法一次性处理多个请求，只能按照QPS速率处理

### 令牌桶算法
系统服务作为生产者，按照指定频率向桶中添加令牌，如QPS为2，每500ms向桶里添加一个令牌，如果桶中令牌数量达到阈值，则不再添加

而请求执行为消费者，每个请求都需要拿一个令牌，如果没拿到则触发拒绝策略

这些算法理解起来是很容易的，但是具体实现可能会比较复杂一点

限流方法

# Lua



是一种轻量的脚本语言，设计目的是为了嵌入应用程序中，为应用程序提供灵活的扩展和定制功能

特性：
- 轻量级 用标准c语言编写并以源代码形式开放
- 可扩展 提供了非常易于使用的扩展接口和机制
- 支持面向过程编程和函数式编程
- 自动内存管理，只提供了一种通用类型的表，可以用它实现数组、哈希表、集合、对象


这里主要是用redis的时候了解了一下lua脚本，所以这里主要记录redis中的使用

- 减少网络开销，将多个请求通过脚本的形式一次性发送，减少时延
- 原子操作，会将整个脚本作为一个整体执行，中间不会被其他请求插入
- 复用：客户端发送的脚本会永久存在redis中，其余客户端就可以复用这一脚本

lua可以用`redis.call()`调用redis命令
```lua
return redis.call('GET',KEYS[1])
```

redis中的一些lua命令
- EVAL
    - EVAL script numkeys key[key ...] arg[arg ...]
    - script是脚本程序
    - numkeys指定后续的key个数
    - key表示在脚本中所用的Redis键，在Lua脚本中通过KEYS[1],KEYS[2]获取
    - arg附加参数，ARGV[1]获取

```lua
-- 相当于SETEX key1 60 10
EVAL "redis.call('SET',KEYS[1],ARGV[1]);redis.call("EXIPRE',KEYS[1],ARGV[2]);return 1" 1 key1 10 60
```

- SCRIPT LOAD
    - SCRIPT LOAD script
    - SCRIPT LOAD 将脚本script添加到Redis服务器的脚本缓存中，并不立即执行，而是对输入的脚本进行求值，并返回给定脚本的SHA1校验和，如果给定的脚本已经在缓存里面，那么不执行任何操作

- EVALSHA
    - EVALSHA sha1 numkeys key[key...] arg[arg...]
    - 在脚本加入到缓存之后，在任何客户端通过EVALSHA命令，可以使用脚本的SHA1校验和来调用这个脚本，脚本可以在缓存中一直保存直到缓存被清除（SCRIPT FLUSH）

- SCRIPT EXISTS
    - SCRIPT EXISTS sha1[sha1...]
    - 给定一个或多个脚本的SHA1校验和，返回一个包含0和1的列表，表示校验和所指定的脚本是否已经被保存到缓存当中

- SCRIPT FLUSH
    - SCRIPT FLUSH
    - 清除redis服务端所有lua脚本缓存

- SCRIPT KILL
    - SCRIPT KILL
    - 杀死正在运行的lua脚本，当且仅当这个脚本没有进行任何写操作时，这个命令才生效，主要用于终止运行时间过长的脚本，比如一个因为Bug而无限loop的脚本
    - 加入当前正在运行的脚本已经执行过写操作，那么无法杀死，否则违反了lua脚本的原子性，在这种情况下只能使用`SHUTDOWN NOSAVE`命令，停止整个redis进程来停止脚本的运行，防止不完整的信息写入数据库

消费者案例，主要是进行原子操作以及防抖重复购买，以及避免超卖

```golang
package main

import (
	"fmt"
	"github.com/gomodule/redigo/redis"
	"math/rand"
	_redis "redis-example/redis"
	"time"
)

const Script = `
if redis.call("EXISTS",KEYS[1]) ==1 then
    return 2
else
    if redis.call("EXISTS",KEYS[2]) == 1 and tonumber(redis.call("GET",KEYS[2]))>0 then
        redis.call("DECR",KEYS[2])
        redis.call("HINCRBY",KEYS[1].."buy",KEYS[2],1)
        redis.call("SET",KEYS[1],1)
        redis.call("EXPIRE",KEYS[1],1)
        return 1
    else
        return 0  
    end
end
`

func producer(c redis.Conn, product string) {
	defer c.Close()
	for {
		// 自增
		c.Do("INCR", product)
		fmt.Println(product + "+1")
		time.Sleep(time.Second)
	}
}

func consumer(c redis.Conn, user string, product string) {
	defer c.Close()
	lua := redis.NewScript(2, Script)
	for {
		res, err := lua.Do(c, user, product)
		if err != nil {
			fmt.Println(err, 111)
			return
		}
		if r, _ := res.(int64); r == 1 {
			fmt.Println(user + " buy " + product)
		} else if r == 0 {
			fmt.Println("Unlucky " + user + "," + " the " + product + " is sold out!")
		} else {
			fmt.Println(user + " you hava buy in this second")
		}
		time.Sleep(time.Millisecond * time.Duration(rand.Intn(10)*100))
	}
}

func main() {
	c := _redis.GetRedisConn()
	c.Do("FLUSHALL")
	c.Close()

	go producer(_redis.GetRedisConn(), "apple")
	go producer(_redis.GetRedisConn(), "pineapple")
	go consumer(_redis.GetRedisConn(), "1", "apple")
	go consumer(_redis.GetRedisConn(), "2", "apple")
	go consumer(_redis.GetRedisConn(), "2", "pineapple")
	time.Sleep(time.Second * 10)
	//go consumer(_redis.GetRedisConn(), "用户1")
}

```