目录

resume-4

66.redis

redis为什么性能高

  • 本地方法

  • 线程模型

    http://img.cana.space/picStore/20210421101341.png

    6.x以后,为了充分利用cpu核心数,将io线程弄成多个,工作线程1个,默认不开启,如下图

    http://img.cana.space/picStore/20210421102507.png

redis使用场景

value:string、list、hash、set、sorted set(zset)

string

  • 字符串

    session共享;kv缓存

  • 数值

    计数器

  • bitmap

    统计分析

67.模拟题

1
2
3
4
有个接口不断被调用需要实现如果该接口  最近 10分钟被调用次数超过1000则不允许调用
假定每次调用前都会访问下面这个静态方法如果允许调用则返回true否则返回false
public static boolean canInvoke(String methodName,String callerId){
}
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
import java.util.*;
public class Main {
    // key: methodName_callerId, key:分钟 value:次数
    static Map<String, Map<Integer, AtomicInteger>> collection = new ConcurrentHashMap<>();
    public static void main(String[] args) {
        
    }
    
    public static boolean canInvoke(String methodName,String callerId){
        String key = methodName + "_" + callerId;
        Map<Integer, Integer> map = collection.get(key);
        
        // 刚开始调用
        if(map == null) {
            map = new HashMap<Integer, AtomicInteger>();
            collection.put(key, map);
        }
        
        // 当前分钟数
        int right = (int)(System.currentTimeMillis() / 1000 / 60);
        
        // 记数
        map.put(right, map.get(right).getAndIncrement());
       
        // 记数完之后判断是否可以调用
        int left = right - 9;
        // 计算十分钟内总数
        int count = 0;
        for(int i = left; i <= right; i++) {
            count += map.get(i);
        }
        // 清理left-1的数据
        collection.remove(left-1);
        
        if(count > 1000) return false;
        return true;
    }
    
}

68.https

参考:https://zhuanlan.zhihu.com/p/43789231

1.为什么需要加密

中间会经过很多物理网络节点,可能存在中间人攻击

2.什么是对称加密

3.为什么不能直接用对称加密

如果通信双方都各自持有同一个密钥,且没有别人知道,这两方的通信安全当然是可以被保证的,但是这样浏览器需要预存好世界上所有HTTPS网站的密钥,这么做显然不现实

4.非对称加密

只能保证单向的数据安全(公钥方->私钥方)

5.改良版的非对称加密

使用两组公私钥

6.非对称加密+对称加密

非对称加密算法非常耗时,对称加密快很多,且非对称加密、解密各只需用一次即可。HTTPS基本就是采用了这种方案。

7.中间人攻击

上面非对称加密+对称加密还是有漏洞的,存在中间人攻击,劫取网站的公钥,向浏览器传输自己的公钥,获得加密后的数据再用自己的私钥解密,再用网站的公钥加密对称密钥传给服务器。

中间人攻击问题的根本原因是浏览器无法确认收到的公钥是不是网站自己的

8.如何证明浏览器收到的公钥一定是该网站的公钥?

需要有一个可信机构类似政府一样给居民办法“身份证”,这样的可信机构就是CA,而CA机构办法的证书就是数字证书

9.数字证书

网站在使用https之前需要向ca机构申领一份数字证书,包含网站信息(域名等)、网站的公钥、指定的签名算法等,浏览器收到网站的数字证书后就可以放心使用提供的公钥进行加密对称密钥了,因为这个公钥必定是网站的。

但是这里也有个显而易见的问题是证书怎么能保证在传输过程没有被篡改呢,身份证运用了一些防伪技术,数字证书如何防伪的呢

10.如何放防止数字证书被篡改?

将证书原本的内容生成一份签名(对证书原本内容作一次哈希得到摘要,再使用ca机构的私钥进行加密),浏览器在拿到证书后使用证书里面的摘要算法哈希,将结果与数字签名比对就可以知道证书原本的内容有没有被篡改了。

以下是数字证书的制作以及验证过程

http://img.cana.space/picStore/20210712151653.png

10.中间人有可能篡改该证书吗?

如果中间人修改了证书内容,但是中间人没有ca机构的私钥所以无法得到的正确的数字签名,浏览器一比对就知道证书内容被篡改了。

既然不可能篡改,那整个证书被掉包呢?

11.中间人有可能掉包证书吗?

假设有个网站b模仿网站a做了个外壳,也在ca机构申领了数字证书,并且成为中间人在网站b向浏览器传输数字证书过程中拦截并替换成了自己的数字证书,之后浏览器就会错误地使用b的公钥进行对称公钥的加密传输,同之前的中间人攻击问题。

其实以上并不会发生,因为数字证书里包含了网站a的域名信息,浏览器只需要把自己请求的域名和数字证书里的域名信息比对一下就知道有没有掉包了。

12.为什么hash

  • 主要是性能问题,因为非对称加密算法效率较差,证书信息一般内容较长,比较耗时。而hash后得到的是固定长度的信息(比如用md5算法hash后可以得到固定的128位的值),这样加解密就快很多。
  • 安全上的原因

13.怎么证明CA机构的公钥是可信的?

浏览器怎么能确保持有的CA机构公钥是CA机构的,而不是中间人的呢?

让我们回想一下数字证书到底是干啥的?没错,为了证明某公钥是可信的,即“该公钥是否对应该网站”,那CA机构的公钥是否也可以用数字证书来证明?没错,操作系统、浏览器本身会预装一些它们信任的根证书,如果其中会有CA机构的根证书,这样就可以拿到它对应的可信公钥了。

实际上证书之间的认证也可以不止一层,可以A信任B,B信任C,以此类推,我们把它叫做信任链数字证书链。也就是一连串的数字证书,由根证书为起点,透过层层信任,使终端实体证书的持有者可以获得转授的信任,以证明身份。

另外,不知你们是否遇到过网站访问不了、提示需安装证书的情况?这里安装的就是根证书。说明浏览器不认给这个网站颁发证书的机构,那么你就得手动下载安装该机构的根证书(风险自己承担XD)。安装后,你就有了它的公钥,就可以用它验证服务器发来的证书是否可信了。

14.每次进行HTTPS请求时都必须在SSL/TLS层进行握手传输密钥吗?

这也是我当时的困惑之一,显然每次请求都经历一次密钥传输过程非常耗时,那怎么达到只传输一次呢?

服务器会为每个浏览器(或客户端软件)维护一个session ID,在TLS握手阶段传给浏览器,浏览器生成好密钥传给服务器后,服务器会把该密钥存到相应的session ID下,之后浏览器每次请求都会携带session ID,服务器会根据session ID找到相应的密钥并进行解密加密操作,这样就不必要每次重新制作、传输密钥了!

15.服务器怎么知道访问者就是真正的用户呢

现在用户知道自己访问的网站是正规的网站,向服务器传输数据也是安全的,否则用户浏览器会报错说不能用CA证书解析。服务器通过CA授予的数字证书自证了身份。但这里的安全隐患在于,服务器怎么知道访问者就是真用户呢?之前介绍的双向认证是可以通过数字证书验明用户的正身,现在用户为了省钱没有数字证书这种情况下一般是通过用户名密码来确认用户。所以,大家要保管好自己的密码。

小结

至此,我们已自上而下地打通了HTTPS加密的整体脉络以及核心知识点,不知你是否真正搞懂了HTTPS呢? 找几个时间,多看、多想、多理解几次就会越来越清晰的! 那么,下面的问题你是否已经可以解答了呢?

  1. 为什么要用对称加密+非对称加密?
  2. 为什么不能只用非对称加密?
  3. 为什么需要数字证书?
  4. 为什么需要数字签名?

69.cms三色标记

参考:https://zhuanlan.zhihu.com/p/375977480

1.根节点的确定

卡表是记忆集的实现,用来解决gc roots 跨代引用的问题

写屏障

伪共享

解决伪共享,jvm参数-XX:+UseCondCardMark

2.如何高效地标记对象

  1. 初始标记:标记GC ROOT能关联到的对象,这一步需要STW,但是停顿的时间很短。
  2. 并发标记:从GCRoots的直接关联对象开始遍历整个对象图的过程,这个时间会比较长,但是现在是可以和用户线程并发执行的,这个效率的问题就是三色标记关注的问题。

在三色标记法中,把从GC Roots开始遍历的对象标记为以下三种颜色:

  1. 白色,在刚开始遍历的时候,所有的对象都是白色的
  2. 灰色,被垃圾回收器扫描过,但是至少还有一个引用没有被扫描
  3. 黑色,被垃圾回收器扫描过,并且这个对象的引用也全部都被扫描过,是安全存活的对象

三色标记的问题:把存活对象标记成需要清理

只有同时满足两个条件才会发生这种对象消失的问题:

  1. 插入了一条或者多条黑色到某白色对象O的引用
  2. 删除了全部从灰色到白色对象O的引用

那么,针对这个问题也有两种解决方案:增量更新原始快照,如果对应到垃圾回收器的话,CMS使用的是增量更新,而像G1则是使用原始快照。

增量更新解决方案就是,他会把这些新插入的引用记录下来,扫描结束之后,再以黑色对象为根重新扫描一次。这样看起来不就是增量更新吗?新插入的记录再扫一次!

原始快照则是去破坏第二个条件,他把这个要删除的引用记录下来,扫描结束之后,以灰色对象为根重新扫描一次。所以就像是快照一样,不管你删没删,其实最终还是会按照之前的关系重新来一次。

70.线程池大小

https://mp.weixin.qq.com/s/HWRtiFxEVj3eHHDdlI08TQ

71.分布式事务

https://www.cnblogs.com/bluemiaomiao/p/11216380.html