发表于 | 分类于 ，

Run Docker Image

1
docker run -d -p 8081:8081 --name nexus -e INSTALL4J_ADD_VM_PARAMS="-Xms4g -Xmx4g -XX:MaxDirectMemorySize=3g  -Djava.util.prefs.userRoot=/nexus-data/user/root" -v $PWD/volume:/nexus-data sonatype/nexus3:3.19.1

Deploy on Kubernetes

Deployment

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
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
apiVersion: apps/v1beta1
kind: StatefulSet
metadata:
  name: nexus-repository
spec:
  selector:
    matchLabels:
      app: nexus-repository
  serviceName: nexus-repository-service
  replicas: 1
  template:
    metadata:
      labels:
        app: nexus-repository
    spec:
      initContainers:
        - name: init-container
          image: busybox:1.31.1
          command: ["chmod", "777", "/nexus-data"]
          volumeMounts:
            - name: nexus-repository-pv
              mountPath: /nexus-data
      containers:
        - image: gcr.io/leverup-app-sit/nexus:3.19.1
          imagePullPolicy: IfNotPresent
          name: nexus-repository
          resources:
            requests:
              cpu: 0.5
              memory: 5Gi
            limits:
              cpu: 2.0
              memory: 5Gi
          env:
            - name: INSTALL4J_ADD_VM_PARAMS
              value: "-Xms4g -Xmx4g -XX:MaxDirectMemorySize=2g -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap -Djava.util.prefs.userRoot=/nexus-data/user/root"
          ports:
            - containerPort: 8081
          livenessProbe:
            httpGet:
              path: /
              port: 8081
            initialDelaySeconds: 30
            periodSeconds: 30
            failureThreshold: 3
          readinessProbe:
            httpGet:
              path: /
              port: 8081
            initialDelaySeconds: 30
            periodSeconds: 30
            failureThreshold: 3
          volumeMounts:
            - name: nexus-repository-pv
              mountPath: /nexus-data
  volumeClaimTemplates:
    - metadata:
        name: nexus-repository-pv
      spec:
        accessModes: ["ReadWriteOnce"]
        storageClassName: pd-standard
        resources:
          requests:
            storage: 100Gi

Permission Error

1
2
3
4
5
6
mkdir: cannot create directory '../sonatype-work/nexus3/log': Permission denied
mkdir: cannot create directory '../sonatype-work/nexus3/tmp': Permission denied
OpenJDK 64-Bit Server VM warning: Cannot open file ../sonatype-work/nexus3/log/jvm.log due to No such file or directory
Warning:  Cannot open log file: ../sonatype-work/nexus3/log/jvm.log
Warning:  Forcing option -XX:LogFile=/tmp/jvm.log
java.io.FileNotFoundException: ../sonatype-work/nexus3/tmp/i4j_ZTDnGON8hezynsMX2ZCYAVDtQog=.lock (No such file or directory)

Solution：修改 /nexus-data 目录的权限为777或者757

Role

  1. add only read role, permission follow:
1
2
nx-repository-view-*-*-*
nx-search-read
  1. add deploy role, permission follow:
1
2
3
4
nx-repository-view-*-*-add
nx-repository-view-*-*-read
nx-repository-view-*-*-edit
nx-repository-view-*-*-browse

Usage

Maven Configuration

1
2
3
4
5
6
7
8
9
10
11
12
13
14
<settings>
  <servers>
      <server>
          <id>nx-releases</id>
          <username>admin</username>
          <password></password>
      </server>
      <server>
          <id>nx-snapshots</id>
          <username>admin</username>
          <password></password>
      </server>
  </servers>
</settings>

Project Pom

1
2
3
4
5
6
7
8
9
10
11
12
 <distributionManagement>
    <repository>
        <id>nx-releases</id>
        <name>Releases</name>
        <url>http://localhost:8081/repository/maven-releases/</url>
    </repository>
    <snapshotRepository>
        <id>nx-snapshots</id>
        <name>Snapshot</name>
        <url>http://localhost:8081/repository/maven-snapshots/</url>
    </snapshotRepository>
</distributionManagement>

Minimal deploy maven jar permission

1
2
3
4
nx-repository-view-*-*-add
nx-repository-view-*-*-read
nx-repository-view-*-*-edit
nx-repository-view-*-*-browse

Sync maven lib

1
2
3
4
5
6
7
8
9
10
11
12
<repositories>
    <repository>
        <id>nx-releases</id>
        <name>Releases</name>
        <url>http://xxxx:8081/repository/maven-releases/</url>
    </repository>
    <repository>
        <id>nx-snapshots</id>
        <name>Snapshot</name>
        <url>http://xxxx:8081/repository/maven-snapshots/</url>
    </repository>
</repositories>

Deploy to Private Repository

1
mvn deploy

Multiple Repository

Reference

发表于 | 分类于

Algorithm

Leaky Bucket - 漏桶

The image shows the usage of leaky bucket algorithm in traffic shaping. If we map(与..有关)) it our limiting requests to server use case, water drops from the faucets(水龙头) are the requests, the bucket is the request queue and the water drops leaked from the bucket are the responses. Just as the water dropping to a full bucket will overflow, the requests arrive after the queue becomes full will be rejected.

Token Bucket

Suppose there are a few tokens in a bucket. When a request comes, a token has to be taken from the bucket for it to be processed. If there is no token available in the bucket, the request will be rejected and the requester has to retry later. The token bucket is also refilled per time unit.

Fixed Window Counter

Sliding Window Log

Sliding window log algorithm keeps a log of request timestamps for each user. When a request comes, we first pop all outdated timestamps before appending the new request time to the log. Then we decide whether this request should be processed depending on whether the log size has exceeded the limit. For example, suppose the rate limit is 2 requests per minute:

Sliding Window

Reference

发表于 | 分类于

Introduction

对象池模式一般用来管理一组可重用对象，以供调用组件使用，它可以为组件提供多个完全相同的对象。

Advantage：

  1. 节省了创建类的实例的开销；
  2. 节省了创建类的实例的时间；

Disadvantage：

  1. 存储空间随着对象的增多而增大；

Object Pool 适用在什么地方？

  1. 类的实例可重用；
  2. 类的实例化过程开销较大；
  3. 类的实例化的频率较高；
  4. 类的使用周期有限，在周期结束后回收对象；

Practice

  1. 初始化，准备需要的对象集合；
  2. 借出对象，需要对象的组件从池子中借出对象；
  3. 组件使用借到的对象完成任务，对象池保证这个对象在其被归还之前不会再借给其他组件；
  4. 组件返回对象给对象池；

Reference

发表于 | 分类于

Introduction

  • 缓存穿透
  • 缓存雪崩
  • 缓存击穿

缓存穿透

正常情况下，我们去查询数据都是存在。那么请求去查询一条压根儿数据库中根本就不存在的数据，也就是缓存和数据库都查询不到这条数据，但是请求每次都会打到数据库上面去。这种查询不存在数据的现象我们称为缓存穿透。

缓存穿透可能引起的问题

如果有黑客会对你的系统进行攻击，拿一个不存在的id去查询数据，会产生大量的请求到数据库去查询。可能会导致你的数据库由于压力过大而宕掉。

如何解决？

1. 缓存空值

之所以会发生穿透，就是因为缓存中没有存储这些空数据的 key。从而导致每次查询都到数据库去了。那么我们就可以为这些 key 对应的值设置为 null 丢到缓存里面去。后面再出现查询这个 key 的请求的时候，直接返回 null，但是别忘了设置过期时间。

2. BloomFilter

BloomFilter 用来判断某个元素（key）是否存在于某个集合中。

这种方式在大数据场景应用比较多，比如 Hbase 中使用它去判断数据是否在磁盘上。还有在爬虫场景判断url 是否已经被爬取过。

这种方案可以加在第一种方案中，在缓存之前在加一层 BloomFilter ，在查询的时候先去 BloomFilter 去查询 key 是否存在，如果不存在就直接返回，存在再走查缓存 -> 查 DB。

小结

针对于一些恶意攻击，攻击带过来的大量 key 是不存在的，那么我们采用第一种方案就会缓存大量不存在key的数据。此时我们采用第一种方案就不合适了，我们完全可以先对使用第二种方案进行过滤掉这些 key。针对这种 key 异常多、请求重复率比较低的数据，我们就没有必要进行缓存，使用第二种方案直接过滤掉。而对于空数据的key有限的，重复率比较高的，我们则可以采用第一种方式进行缓存。

缓存雪崩

缓存雪崩的情况是说，当某一时刻发生大规模的缓存失效的情况，比如你的缓存服务宕机了，会有大量的请求进来直接打到 DB 上面。结果就是 DB 扛不住而挂掉。

如何解决？

  1. 使用集群缓存，保证缓存服务的高可用；
  2. ehcache本地缓存 + Hystrix 限流&降级，避免 MySQL 被打死；
  3. 开启Redis持久化机制，尽快恢复缓存集群；

缓存击穿

在平常高并发的系统中，大量的请求同时查询一个 key 时，此时这个 key 正好失效了，就会导致大量的请求都打到数据库上面去。这种现象我们称为缓存击穿。

缓存击穿可能引起的问题

会造成某一时刻数据库请求量过大，压力剧增。

如何解决？

上面的现象是多个线程同时去查询数据库的这条数据，那么我们可以在第一个查询数据的请求上使用一个互斥锁来锁住它。

其他的线程走到这一步拿不到锁就等着，等第一个线程查询到了数据，然后做缓存。后面的线程进来发现已经有缓存了，就直接走缓存。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public String get(key) {
    String value = redis.get(key);  
    if (value == null) { //代表缓存值过期  
        //设置3min的超时，防止del操作失败的时候，下次缓存过期一直不能load db
        if (redis.setnx(key_mutex, 1, 3 * 60) == 1) {  //代表设置成功
            value = db.get(key);
            redis.set(key, value, expire_secs);
            redis.del(key_mutex);
        } else {  
            //这个时候代表同时候的其他线程已经load db并回设到缓存了，这时候重试获取缓存值即可
            sleep(50);
            get(key);   //重试
        }
    } else {  
        return value;
    }
 }

Reference