# 学习HTTPS





看了JWT的加密过程，开始对HTTPS的加密过程感兴趣了，所以顺便也一起详细了解一下

比如如何防止篡改，之前听说过中间人攻击，就是截取了HTTP请求，然后对你发送的数据进行篡改后，再次发给服务端，那服务端就要解决一个问题，我怎么知道这个数据被篡改了呢？

### 为什么要加密？？
HTTP请求原先是明文传输的，所以请求如果被劫持，信息则全泄漏了，且可能被篡改信息，而服务端和客户端双方都没有察觉，所以需要对信息进行加密

#### 对称加密
如果通信双方都各自持有同一个密钥，且没有其他人知道，双方的通信安全就可以被保证

但是需要保证该密钥只有双方知道，其他人并不知道，因为服务端和客户端之间传输过程是可能被劫持的，被劫持后就可以通过该密钥来解开双方传输的任何内容

所以得保证传输过程安全，而这个就是我们想做的，那去掉传输这一步怎么样？

第一个想法是像服务端一样，一开始就保存好了，但是想要浏览器像服务端一样保存着所有HTTPS网站的密钥是不可能的

那这时候就需要非对称密钥

#### 非对称密钥

即使用一个私钥和一个公钥，私钥存储于服务端，公钥的话则由服务端生成并传输给客户端，公钥加密的只能由私钥来进行解析，而私钥加密的只能由公钥进行解析，这就可以保证前面说的，客户端用公钥加密后传输给服务端，而服务端来进行解析，可以保证客户端传输的只能由服务端来解析，保证数据安全，但是由于服务端传输给客户端的数据可以用公钥进行解析，那这条路线上的数据就不一定安全了，如果拿到了第一个明文传输的公钥，则可以对服务端传输的数据进行解析，所以在一定程度上也不安全

那一组公钥私钥可以满足单线路上的传输安全，那两组的话是不是就可以保证双向安全了呢？

其实是可以的，但是非对称加密的计算十分耗费时间，HTTPS就没有采取这种方法

#### 非对称加密+对称加密
HTTPS采取的是非对称加密+对称加密，减少了非对称加密的次数

过程：
    
    服务器拥有用于非对称加密的公钥A,私钥A'
    浏览器向服务端请求，服务器将公钥A明文传输给浏览器
    浏览器随机生成一个用于对称加密的密钥X，用公钥A加密后传给服务器
    这样用公钥A加密后只能由A'进行解密，所以保证这个对称加密的密钥X的传输安全
    服务器拿到加密后的X，用私钥A'进行解密得到密钥X
    这时就保证了双方都拥有密钥X，且别人无法得知，就可以安全地传输信息了
    
HTTPS基本就是采用了这种方法，但还是有漏洞

这时候又需要详细了解`中间人攻击`了，它仍可以拿到你传输的数据，只不过没有密钥无法解密而已

但是要记住，我们有一步是明文传输的，即第一步将公钥明文传输给浏览器，这时候先进行中间人劫持把公钥明文拿到，那想想如果你拿到了能干什么呢？

    首先不能让这个公钥正常传输给浏览器，否则后面对称加密后我也没有任何办法去解密了，那我能不能
    偷偷用把这个公钥换成我自己的，把公钥A换成我生成的公钥B，然后我有自己的私钥B'可以解密
    那这时候的步骤就是这样
    1.服务器生成公钥A，私钥A'，传输公钥A给浏览器
    2.中间人劫持，将公钥A改为公钥B
    3.浏览器拿到公钥B，用公钥B加密生成的对称加密的密钥X传给服务器
    4.中间人劫持后用私钥B'解密得到密钥X，再用公钥A加密后传给服务器
    5.这时服务器拿到的还是公钥A加密后的X，然后用私钥A'解密得到对称加密的密钥X
    
这样的步骤下来，双方都没发现异常，但是对称加密的密钥X已经被中间人拿到了，那它也可以参与解密cs之间传输的数据了，那发生这个情况的原因是`浏览器无法确认收到的公钥是否是该服务器发送的`，该公钥也无法进行加密，否则又需要进行解密，就成套娃了

那这时候就要引入一个新的概念，数字证书

#### 数字证书

网站在使用HTTPS前，需要向CA机构申请一份数字证书，证书里包括持有者信息，公钥信息等，服务器把证书传输给浏览器，浏览器从证书里获取公钥即可

证书在这里就是身份证，证明一个公钥对应的是该网站，那如何防止这个证书被篡改，就是`签名`所解决的问题

#### 签名过程

数字签名的制作过程
1. CA机构拥有非对称加密的私钥和公钥
2. CA机构对证书明文数据T进行hash
3. 对hash后的值用私钥加密，得到数字签名S

明文和数字签名共同组成了数字证书，然后将数字证书颁发给网站，即服务端

浏览器拿到服务端发来的数字证书后，需要验证数字证书是否被篡改

浏览器验证过程：
1. 拿到证书，取出明文T，签名S
2. 用CA机构的公钥对S解密（机构的公钥则是由于机构是浏览器信任的机构，浏览器默认保有公钥），得到S'
3. 用证书里指明的hash算法对明文T进行hash得到T'
4. 验证T'是否等于S'，若相等则表明证书可信，否则是被明文或签名被篡改

数字签名就是对明文hash后再私钥加密后得到的值，为什么要用hash，直接加密不可以吗？

      主要是性能问题，非对称加密效率差，证书信息一般较长，而hash后得到的是固定长度的信息，加
      解密就更快了，而且还有安全上的问题


那如何保证安全？

首先中间人攻击仍然能拿到第一个，不过这时拿到的是一个数字证书，如果篡改了明文，由于没有私钥，无法对篡改后的值进行加密后签名，所以浏览器拿到的会发现原文和签名解密值不一致。

而且攻击者无法整体替换证书，因为浏览器可以比对证书的域名以及请求域名，如果不同则说明被篡改了

其实总结起来，前面的一大堆非对称加密步骤是为了后面的对称加密，数据传输的加解密还是通过对称加密进行的，而数字证书是为了解决非对称加密的公钥的可信问题


每次进行HTTPS请求时在SSL/TLS层不需要每次都传输密钥

服务器会为每个浏览器维护一个sessionid，在TLS握手阶段传给浏览器，浏览器生成好密钥传给服务器，服务器将密钥存到相应的sessionid，之后每次请求都携带sessionid，服务器根据sessionid找到密钥进行加解密，就不需要每次都重新制作、传输密钥


先到这里吧，后面可能会研究一下TLS的握手机制

读懂HTTPS

# JWT介绍



互联网服务离不开用户认证，一般流程如下！：

>  1.用户向服务器发送用户名和密码
>  
>  2.服务器验证通过后，在当前对话(session)里面保存相关数据，比如用户角色、登录时间等
>  
>  3.服务器向用户返回一个session_id，写入用户的 Cookie
>  
>  4.用户随后的每一次请求，都会通过Cookie，将session_id传回服务器
>  
>  5.服务器收到session_id，找到前期保存的数据，由此得知用户的身份

但使用这种方法，首先是扩展性不好，如果是单机服务那问题不大，如果是服务器集群的话，就需要实现session数据共享，使得每台服务器都能够读取session

这样的话就有一种解决方法是将session数据持久化，写入数据库或者别的持久层，各种服务收到请求后，都去向持久层请求得到数据，但是如果持久层挂掉了就会单点失败

另外一种就是将session由客户端进行保存，减少服务端的负载，每次请求都携带返回给服务器，JWT就是这种方法的一个方案

#### JWT(JSON WEB TOKEN)

一般在鉴权或者信息交换的过程中使用，主要是Authorization时使用，一旦用户登录，后续每个请求都将包含JWT，允许用户访问该令牌允许的路由、服务和资源。单点登录是现在广泛使用的JWT的一个特性，因为开销很小


##### JWT由三部分组成
- Header
- Payload
- Signature

一个jwt看起来就是xxxx.yyyy.zzzz

Header由两部分组成，token的类型("JWT")和算法名称比如(SHA256或RSA等等)
```golang
{
    'alg':"HS256",
    'typ':"JWT"
}
```

用base64对其进行编码就得到第一部分

Payload包含声明(要求)，声明是关于实体(通常是用户)和其他数据的声明，声明有三种类型：registered,public和private
- Registered claims
    
    是一些官方推荐的使用的字段，提供了一些有用的信息，iss(issuer):签发人
    exp(expiration time)：注册时间     sub(subject):主题
    aud(audience):受众  nbf(Not Before):生效时间   iat(Issued At):签发时间
    jti(JWT ID):编号
- Public claims

    在使用JWT时可以被自定义
- Private claims

    用户自定义的一些信息
    
    
Signature(签名)

对第一部分和第二部分进行签名使用，用来验证是否是我们服务器发起的token，secert是我们的密钥
具体的签名过程则之后的文章再讲解，这里先跳过

那一个JWT验证的过程是怎么样的？

主要包括两个流程，一个是签名验证，另外一个是payload里面各个标准claim的验证

- 签名验证
   
 接收到一个JWT时，首先对完整性进行验证，防止被串改，因为签名是加入了私钥进行计算的，可以将签名段看为一个原始数据，然后对接收到的header解码，就能知道JWT用的是什么算法做的签名，然后再利用这个算法，对header和payload做一次签名，并比较两个签名是否完全相同，若相同则验证成功
 
- payload验证

 之后则对payload的claim验证
 
 iss:如果签发时claim是'a.com',验证时不是的话则失败
 
 sub:如果与签发时不同则验证失败

 除了给定的registered claims验证以外，还需要开发者对自定义的claims进行验证
 
 
##### 缺点：

即jwt不会注销，在过期时间之前它是始终有效的，比如用户点击了注销按钮，即结束了这个会话，客户端正常会清空它存储的token，但是实际上这个token在用户注销后还是有用的，还可以被攻击者窃取后进行使用，直到过期时间结束

那这时候就可以利用redis来撤销JWT产生的令牌，当用户点击注销后，且令牌在redis存储的时间与令牌在jwt的有效时间相同，当有效时间到了以后，令牌会自动被redis删除，然后每次先检验令牌在redis中是否存储，然后点击注销的时候也会发送请求注销令牌

# 动态规划



主要思想是将复杂问题(带有许多递归分析)分解为更小的子问题，然后保存到内存当中，这样就不需要在每次使用的时候重复进行计算

例如`斐波那契数列`的计算，计算F(5)的时候需要知道F(3)和F(4)，而计算F(4)需要知道F(3)和F(2),以此类推往下，就会有很多重复的计算，例如这里F(3)就会被计算了两遍，所以我们要想办法将F(3)存储起来，即在计算F(4)的时候获得的F(3)能够在计算F(5)时接着使用，就变成了常量相加，意味着序列中每个单独元素的计算都是O(1)

动态规划的三个步骤：
1. 确定适用于所述问题的递归关系
2. 初始化内存、数组、矩阵的初始值
3. 确保当我们进行递归调用时可以访问到子问题的答案

这时看一个例子
[Leecode 青蛙跳台阶问题](https://leetcode.cn/problems/qing-wa-tiao-tai-jie-wen-ti-lcof/)
>  一只青蛙一次可以跳上一级台阶，也可以跳上2级台阶，求该青蛙跳上一个10级台阶总共有多少种跳法

思路就是，跳上第10阶有两种可能，即在第九级往上跳一次，或者在第八级往上跳两级，即`F(10) = F(9) + F(8)`,同理可以往下推，其实就有点像斐波那契数列了

可以使用递归解法
```java
class Solution {
    public int numWays(int n){
        if(n==1) return 1;
        if(n==2) return 2;
        return numWays(n-1)+numWays(n-2);
    }
}
```
去解题时发现，报错StackOverflow，该递归的时间复杂度较高

递归时间复杂度 = 解决一个子问题时间 * 子问题个数

> 一个子问题时间 = f(n-1) + f(n-2),即O(1)，但是问题个数=递归树节点的总数，递归树节点的总数为2^n-1

所以时间复杂度为O(2^n),即指数级别，如果n比较大的话，就很容易超时了

这时候就有另外一种解法，即备忘录解法,即对递归树进行剪枝，去掉一些重复计算的部分，思路就是F(10)=F(9)+F(8),那就将F(9)和F(8)存于备忘录，所以需要去计算F(9)和F(8)的值，所以到最后是先将F(9)计算出来，即计算了F(1)-F(9)的值，那其他计算就是直接从备忘录里中取值，速度就快了好多


```java
class Solution {
    HashMap<Integer,Integer> map = new HashMap<Integer,Integer>();
    public int numWays(int n){
        // 递归解法--这里会超时或栈溢出，递归过多了
        // if(n==1) return 1;
        // if(n==2) return 2;
        // return numWays(n-1)+numWays(n-2);

        // 备忘录解法
        // HashMap<Integer,Integer> map = new HashMap<Integer,Integer>();
        if(n==0) return 1;
        if(n<=2) return n;
        if(map.containsKey(n)) {
            return map.get(n);
        }else {
            // 备忘录不存在则计算并加入备忘录
            map.put(n,(numWays(n-1)+numWays(n-2))%1000000007);
            return map.get(n);
        }
    }
}
```
接下来就是讲一下关于动态规划的解法，与备忘录的思路类型，不过备忘录是自顶向下，而动态规划是自底向上的解法，从F(1)往F(10)方向求解

动态规划有几个典型特征
- 最优子结构
    
    f(n-1)和f(n-2)称为最优子结构
    
- 状态转移方程
    
    f(n)=f(n-1)+f(n-2)就是状态转移方程

- 边界
    
    f(1) = 1,f(2) = 2就是边界

- 重叠子问题

    f(10) = f(9) + f(8),f(9) = f(8) + f(7)，f(8)就是重叠子问题
    
动态规划有一个基本的框架


```js
# 初始化 base case
dp[0][0][...] = base
for 状态1 in 状态1的所有取值:
    for 状态2 in 状态2的所有取值:
        for ...
            dp[状态1][状态2][...] = 求最值(选择1,选择2...)
```


在这道题就是

```java
int[] dp = new int[n+1];
dp[1] = dp[2] = 1;
for (int i = 3;i<=n;i++){
    dp[i] = dp[i-1]+dp[i-2];
}
return dp[n];
```
接下来还可以进行状态压缩，即只需要用到dp表的某个固定长度的值，则可以减少空间的使用
```java
int a = 1,b = 2;
for(int i = 3;i<=n;i++){
    int sum = a+b;
    a = b;
    b = sum;
}
```

接下来刷一道难一点的题目
[Leecode 72 编辑距离](uhttps://leetcode.cn/problems/edit-distance/

> 给你两个单词 word1 和 word2， 请返回将 word1 转换成 word2 所使用的最少操作数  。
>
> 你可以对一个单词进行如下三种操作：
>
>    插入一个字符
>    
>    删除一个字符
>    
>    替换一个字符


![图片.png](http://malyue.cn/static/img/dac7bbaa0a797c2a41acb399e8c939fb.%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87.png)

这道题呢我们已经知道是用动态规划了，那就想怎么进行，首先是dp如何定义，dp[i][j]自然是计算出来的最少操作次数，那i和j呢，在这里是对应word1和word2的第[i]个和第[j]个单词，这个没有什么诀窍，写久了自然能看出来

那状态转移方程怎么写

像dp表，我们从前往后遍历，所以新增的一定是在单词串的最后，即每次新增一个改怎么操作，其实无非就是增删改三种操作选一种

所以f[i][j] = Math.min(增加前的状态，删除前的状态，修改前的状态)+1

那增加前的状态是什么，我们知道，增加的话自然是增加一个最新的word2[j],即求word1[0...i]转为word2[0...j-1]的次数

而删除也类似，即word1删除了word1[i]，求word[0...i-1]转为word2[0...j]的次数

修改则是两个都去掉，改为求word[0...i-1]转为word2[0...j-1]的次数

当然还有一种情况，类似修改的，即新增的word1[i]==word2[j]，那就不需要进行额外的操作，直接dp[i][j]=dp[i-1][j-1]

```java
class Solution {
    public int minDistance(String word1, String word2) {
        // 三种操作 插入，删除，替换
        // 先定义dp表的元素含义，值肯定是最少操作数，那i和j呢，应该可以代表word1和word2的长度

        int[][] dp = new int[word1.length()+1][word2.length()+1];
        // 首先(0,0) 为 0
        // 如果word1[i] 与word2[j] 相等，则无须进行操作，即dp[i][j] = dp[i-1][j-1]
        // 如果不等的话，则要进行调整，即三选一，word[i]改为word[j]，则dp[i][j] = dp[i-1][j-1]
        // 如果插入的话，则dp[i][j] = dp[i][j-1] + 1
        // 如果删除的话，则dp[i][j] = dp[i-1][j] + 1

        for(int i = 1;i<word1.length()+1;i++) {
            dp[i][0] = dp[i-1][0] + 1;
        }
        for(int j = 1;j<word2.length()+1;j++) {
            dp[0][j] = dp[0][j-1] + 1;
        }

        for(int i = 1;i<word1.length()+1;i++) {
            for(int j = 1;j<word2.length()+1;j++) {
                // 即在末尾加上了一个一样的，所以和去掉时所需要进行的操作没差别
                if(word1.charAt(i-1) == word2.charAt(j-1)) {
                    dp[i][j] = dp[i-1][j-1];
                    continue;
                }
                //如果是加上了不一样的，则类似于在上一个的情况进行增删改
                // 增加即在a的末尾加上当前b新加上的字符，即求a转为b去掉当前字符的次数再加1
                // 删除则是将a的末尾删掉后直接转为b再加1
                // 修改则是两个都去掉，即直接将word1[i]转为word2[j]，然后再加上去掉后的直接转换的次数
                dp[i][j] = Math.min(dp[i-1][j-1],dp[i-1][j]);
                dp[i][j] = Math.min(dp[i][j],dp[i][j-1]) + 1;
            }
        }
        return dp[word1.length()][word2.length()];
    }
}
```

算法（四）

# TCP & UDP 入门

TCP和UDP是传输层的协议，目的都是在程序之间传输数据




## TCP
- TCP提供一种面向连接的、可靠的字节流服务
- 在一个TCP连接中，仅有两方进行彼此通信，广播和多播不能用于TCP
- TCP使用校验和，确认和重传机制来保证可靠运输
- TCP给数据分节进行排序，并使用累计确认保证数据的顺序不变和非重复
- TCP使用滑动窗口机制来实现流量控制，通过动态改变窗口的大小进行拥塞控制

TCP不能保证数据对方一定能接收到，它不是100%可靠的协议，所以能提供的是数据的可靠传递或故障的可靠通知。

## TCP的设计

首先TCP是一个以太网协议栈，主要实现的是消息收发，一般是应用层进行数据传输，这时调用操作系统进行消息传递，操作系统就交由协议栈来处理。

可能会认为有IP协议来进行分发即可，为什么还需要TCP来中间处理，这是因为IP协议只是一个地址协议，并不保证数据包的完整，如果路由器丢包(比如缓存满了，新进来的数据包丢失)，就需要发现丢了哪一个包，以及如何重新发送这个包

> 简单说，TCP协议的作用是保证数据通信的完整性和可靠性，防止丢包

以太网数据包的大小是固定的，如今为`1522字节`,其中`1500字节`是负载，`22字节`是头信息

而IP数据包也有自己的头信息，最少需要20字节，即负载最多为1480字节，而TCP数据包也需要存储头信息，因此其最大负载是1480 - 20 = 1460字节，除此之外还有额外的头信息，所以实际TCP负载为1400字节左右，因此一条1500字节的信息需要两个TCP数据包

由于有时需要发送多个包，即拆开了后那么客户端需要想办法让服务端知道怎么样算收到所有的包，且应该以怎么样的顺序组装，而且某个包未收到也能通知客户端进行重传，所以设置了`seq`位,即序号位

服务端收到了一个TCP包，查看他的seq为1，而负载为1000，则服务端马上就知道下一个要收到的应该是1001的seq的包，而且可以根据这个顺序来组装这些包

当然实际情况下，TCP的第一个包的seq不会是1，而是随机计算的一个数，这是为了不被人轻易猜出传输的顺序等，所以服务端想知道哪个是第一个包，这时就要介绍一个连接的过程了

客户端想和服务端建立连接，就是所谓的`三次握手`,客户端先从应用程序的套接字拿到ip和端口，之后向服务端发送第一个包即SYN段，将包头中`SYN`设置为1，且也将计算的初始序列号(Sequence number)在这里一起传输给服务端，
这样就可以解决上面说的问题，`这是第一次握手的过程`

`第二次握手`自然就是服务端的返回，服务端会返回SYN+ACK段，即在包头中`SYN和ACK位`字段设置为1的数据包，且由于TCP通讯是全双工的，即服务端也能向客户端发送消息，所以需要将服务端的初始序列号也发给客户端,这一步也是在这里一起发的，而最后一步就是设置Acknowledgement number = J+1来表示确认已收到客户端的SYN段的(Sequence number = J)

那接下来就来到`第三次握手`了，客户端会给服务端一个ACK段响应(包头中ACK位字段设置为1)，该段中使Acknowledgement number = K + 1表示收到服务器的SYN段(Sequenct number = K)

![图片.png](http://malyue.cn/static/img/7166fc45c3d2bf32d52314effea40c07.%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87.png)

第一次握手

客户端经过socket()创建套接字，进行connect()后主动(active open)连接上服务器，发送SYN，这时客户端的状态是`SYN_SENT`,服务端则进行socket(),bind(),listen()后等待客户的连接，收到连接后服务端将该连接的状态会变为`SYN_RCVD`状态，然后将连接信息放到半连接队列(Syn queue)中，如果半连接队列已满，则服务器不会修改该连接的状态为`SYN_RCVD`，且将该连接直接丢弃

syn flood 攻击就是利用队列已满则丢弃连接的原理进行攻击,应对方法之一就是使得syncookies生效，设置为1，这样即使队列满了也可以接受正常的非恶意攻击的客户端请求
> 攻击方的客户端只发送SYN给服务器，然后对服务端的返回不进行处理，直接忽略掉，而不是发送ACK给服务端，这样这个连接就会一直占据着服务器的半连接队列的资源，导致正常的客户端连接无法连接上服务器
> (SYN flood攻击方式分为两种，第一种是攻击方客户端一直发送SYN，对于服务器响应直接忽略，第二种是发送SYN时，将源IP改为一个虚假的IP，然后服务器将SYN+ACK发送到虚假的IP，这样也得不到ACK响应)

第二次握手

服务器返回SYN+ACK后，客户端收到该段，则状态从SYN_SENT变为ESTABLISHED，即既定状态

第三次握手

这时服务端收到客户端发送的ACK，则该连接状态从SYN_RCVD变为ESTABLISHED，然后服务器将该连接从半连接队列中移除，连接信息放到全连接队列中，如果全连接队列已满，则不会修改连接状态

为什么要三次握手而不是两次握手？
> 防止已失效的连接请求又传送到服务端，因而产生错误

> 或者看看第三次握手，主要也是对接受发的起始序列号进行确认，如果没有第三次握手则另外一分的序列号不能被确认


![图片.png](http://malyue.cn/static/img/117f8daf2bb45c2194c9f13fc60c4d9c.%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87.png)

首要原因是防止旧的重复连接初始化造成混乱

有这样一个场景，客户端发送了SYN报文(seq=90)，然后客户端宕机了，而且这个SYN报文被网络堵塞了，服务端没有收到，接着客户端重启后，再次向服务端建立连接，发送SYN(seq=100)报文，而如果旧的比新的先到达了，那么第三次握手就会传递一个RST报文告诉服务端，这个连接过期了，不要用了。

断开连接 - 四次挥手

了解TCP和UDP

# Redis学习

基础语法的话可以自己去学习，这里主要记录一下一些有意思的使用方法




## redis实现文章点赞效果

点赞的话第一下是点赞，第二下则是取消点赞，自然不能存储在数据库中，否则频繁点击的话多次对数据库进行读写会很影响性能，所以这里考虑使用redis来进行存储

第一种方法，因为点赞不能重复，所以最先想到的就是set，每次点击后就会将数字存到对应的set当中

`sadd article:10 100`

获得点赞总数

`scard article:10`

判断是否点赞

`sismember article:10 100`

取消点赞

`srem article:10 100`

但是这样其实有些问题，不是功能上的问题，而是内存上的问题，如果有1000篇文章，那就至少要设置1000个对应的set的key，且每个之内还需要储存N个用户id，如果文章和用户数量一大，就会占用较大的内存

那我们可不可以用别的方法来进行存储？
还记得Redis还有一种叫`Bitmap`的东西，是一串连续的二进制数组(0或1)，可以通过偏移量定位元素
那可不可以就用这二进制的一位来存储代表某个id的用户呢？

其实就是用bitmap的第n为来代表id为n的用户，如果点赞则设为1

查看id为100的数字是否点赞
`getbit like:10 100`

id为100的人进行点赞
`setbit like:10 100 1`

查看多少人点赞
`bitcount like:10`

这样每一位就可以存储一个会员id，只用100M就可以存储接近9亿个会员id

但其实看似很好，我觉得还是有缺陷的，比如如果我使用的是uuid作为用户的id，生成的一个id就是十几位，且最小的也是十几位，那一个bitmap的前面大量的空间就被浪费了，完全起不到作用，而由于uuid是随机的，所以也无法按照一定的规则将其减小，所以其实是自增id的话用bitmap就会很适合

而且bitmap并不会压缩，如果会员id很大，偏移量很高，可能几个会员id就会占用较大的内存，再加上bitmap的最大偏移量为2^32-1，但如果会员id的类型为long类型，int64，那会员id过大就会导致超出偏移量上限。

而且单一实例操作，因为key固定，所以bitmap存储的内容不会分散到集群，而是固定在一个实例上存储，如果集群模式，数据都存一个实例，且所有的对这个bitmap的操作redis请求全部打到一台实例上，尤其是这种判断是否参与过的程序放在程序的首要部分，并发度较高，导致单一实例负载过高，redis集群失去作用