笔记仓库

Kubernetes

2022-03-15T00:00:00+00:00

K8s基本概念

Node

一个物理节点或虚拟机

Pod

k8s的基本组件和最小单元，是container的抽象。用来运行容器，一个pod中可以运行多个容器，但通常只运行一个

Serivce

可以被附加在Pod上的静态（永久）IP，Pod和Service的生命周期是不同的，Pod停止后，Service依然存在。Service可以绑定多个Pod，起到负载均衡的作用。

Ingress

用于实现用域名的方式访问k8s内部应用

ConfigMap

来保存key-value pair配置数据

Secret

存储加密的配置数据

Volume

挂载一个存储到Pod中，可以是Pod运行的服务器（即Node）的存储，或是远程存储（不是K8s的一部分）。K8s不管理存储。

Deployment

Pod的抽象，创建Pod的蓝图，可以指定由多少个Pod副本

StatefulSet

数据库等有状态的Pod，通过StatefulSet来启动，而不是Deployment

K8s架构

K8s集群的Node分为master Node和worker Node，Wokrder Node中可以存在多个Pod。

每个Worker Node要安装三样东西：

Contaier Runtime，如Dokcer
Kublete，接受配置，并在Node中自动Pod，分配Node的资源（CPU，RAM）给Pod
Kube Proxy，在请求转发到Pod的组件，起到负载均衡的作用

Master Node

Api Server，与K8s集群交互的唯一通道
Scheduler，调度器，寻找一个用来部署Pod的Node，然后由Kublete启动Pod
Controller Manager，用来检测Pod的状态，如果Pod crash后，Controller会通知Scheduler重新调度该Pod
etdc，用来表示集群的KV对，集群所有的状态改变都存储在其中。Controller的行为依据etdc来运行 Master Node一般部署多个，所以Api Server是负载均衡的，etcd是分布式存储。

Kubectl

K8s集群的命令行工具

Kubectl基本命令

kebuectl get node.获取所有Node

kubectl get pod.获取所有pod

$ kubectl get pod
NAME                          READY   STATUS    RESTARTS   AGE
nginx-depl-5ddc44dd46-ss96b   1/1     Running   0          3h34m

[-o] output, -o wide 获取更多信息， -o yaml获得详细信息，并以yaml的形式展示

kubectl get service
kubectl edit [deploy-name]，获得deployment的配置文件。修改配置文件后，pod在列表中替换直到消失，但是replicaset中还存在，只是数量都为0
kubectl logs [pod-name]，获取Pod中应用的日志
kubectl exec -it [pod-name] – /bin/bash，在容器中打开交互式命令行
kubectl delete [deployment]，删除deployment，会连带删除deplicaset和pod
kubectl describe pod [pod-name]，获取pod的信息，用于调试

创建Deployment

kubectl create depolyment [name] –image=[image-name]，创建一个最基本的deployment，只有名称和镜像名

Replicaset

Replicaset用于管理Pod的副本，实践中，不能对这个对象作修改，

$ kubectl get replicaset
NAME                    DESIRED   CURRENT   READY   AGE
nginx-depl-5ddc44dd46   1         1         1       3h34m

K8s配置文件

Deployment Configuration

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec: # for deployment
  replicas: 2 # 部署多少个副本
  selector:
    matchLabels:
      app: nginx
  template: # 在一个配置文件中再套一层
    metadata:
      labels: # label用于识别一组资源，是一组键值对
        app: nginx
    spec: # for a pod，Pod的blueprint，
      containers:
      - name: nginx # 在Pod部署一个container
        image: nginx:1.16
        ports:
        - containerPort: 8080

Service Configuration

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector: # 在deployment和pod之间建立连接
    app: nginx
  ports:
    - protocol: TCP
      port: 80 # 请求被发往80端口
      targetPort: 8080 # pod在监听那个端口，service将请求转发到对应的pod

Secret Configuration

apiVersion: v1
kind: Secret
metadata:
  name: mysql-secret
type: Opaque
data:
  password: YWRtaW4xMjM= # base64编码

ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: mysql-configmap
data:
  database_url: mysql-service

配置文件可以定义Department、Service等。配置文件由三部分组成：

metadata。name
specification
status。自动生成，K8s用来比较期望的状态和当前状态（存储在etcd中）来做出改变

kubectl apply -f [file-name]。部署一个配置文件，一个配置文件可以被反复部署，多次部署后K8s会识别到是一次更新，如下：

$ kubectl apply -f nginx-deployment.yaml
deployment.apps/nginx-deployment created
$ kubectl apply -f nginx-deployment.yaml
deployment.apps/nginx-deployment configured

外网可访问的Service

默认创建的service分配的IP是k8s集群内部IP，所以叫internal service，通过指定type为LoadBalancer和nodePort，将其变为external service。默认的service type是ClusterIP。

apiVersion: v1
kind: Service
metadata:
  name: mysql-express-service
spec:
  selector:
    app: mysql-express # 转发到哪个Pod
  type: LoadBalancer  
  ports:
    - protocol: TCP
      port: 3333
      targetPort: 3333
      nodePort: 30000 # 对外暴露的端口

通过describe命令查看service的部署

$ kubectl describe service nginx-service
...
Port:              <unset>  80/TCP
TargetPort:        8080/TCP
Endpoints:         172.17.0.3:8080,172.17.0.4:8080 // 请求转发的目的
Session Affinity:  None
Events:            <none>

Namespace

可以认为是K8s集群中的虚拟集群。多个团队如果再同一个命名空间部署同一个name的组件，会覆盖掉另一个。不同的namespace有隔离作用。通过kubectl获取的组件都是在默认default namespace。部署component时，通过选项-n(–namespace)指定要部署到哪个namespace。或者在配置文件的metadata中指定。 Servcie可以跨命名空间共享，指定service name时，在后面加上所在的namespace即可。

apiVersion: v1
kind: ConfigMap
metadata:
  name: mysql-configmap
  namespace: other-namespace ##
data:
  database_url: mysql-service.some-namespace # 通过后缀指定

Ingress

通过暴露同一的外部访问方式，将请求转发给service。每个external service会占用一个端口，ingress可以通过域名的形式访问。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: name
spec:
  rules:
    - host: app.com # 访问的host
      http:
        paths: # 通过url定义转发规则
          - backend:
              serviceName: my-service # 转发给对应的internal service
              servicePort: 8080 # service的port

Controller

Ingress只是K8s的一层抽象，如果要让IIngress工作，必须选取一个实现，这个实现被称为Controller。Controller也是运行在K8s商上的Pod。Controller是集群中域名的entry point。

安装controller

$ kubectl addons enable ingress

这个命令会安装默认的ingress实现，即nginx-ingress-controller，并运行一个pod。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: dashboard-ingress
  namespace: kubernetes-dashboard
spec:
  rules:
  - host: dashboard.com
    http:
      paths:
      - backend:
          serviceName: kubernetes-dashboard
          servicePort: 80

Helm

K8s的包管理器，打包yaml文件，并将其分发到仓库上，能被其他用户共享。yaml文件的集合也被称为Helm Charts。

Helm可以用于构建蓝图；或者是模板，动态将文件中的placeholder进行替换。Template file存放这yaml模板，placeholder的值在value.yml中寻找。

结构

Helm的顶层是个文件夹，文件夹的名称是charts的名称。Chart.yaml包含chart的元数据，如名称、依赖、版本。Values.yaml包含template中的 value，可以有默认值并重载它。charts文件夹有chart的依赖，有其他chart文件。template文件夹包含模板文件。

mychart/
	Chart.yaml
	cahrts/
	templates/

当执行 helm install 命令时，template会从Values中填充，生产K8s能够识别的文件。

替换默认值

helm install --values=my-value.yml <cahrtname>

这个命令会将my-value.yml中的值合并到Value.yml中。

或：

helm install --set version=xxx

Release Managerment

Volumes

K8s有三种持久化数据的组件，并相互配合

Persistent Volume, pv
Persistent Volume Claim, pvc
Storage Class, sc

K8s没有开箱即用的持久化方案，需要自己配置在pod重启时保存数据。因为不知道pod何时重启，所以storage要能被所有pod访问到

pv

pv是集群中的资源，像cpu和ram一样。用来存储数据。pv由k8s配置文件创建。

pv是一个抽象概念，它必须由实际的物理存储提供实现，可以选择node的物理存储，或者aws之类的云存储。pv没有命名空间。

storageClass:

hostpath 类似docker，将node的路径挂载到pod中。但是在集群中pod可能会被调度到其他node上 ```yml apiVersion: v1 kind: PersistentVolume metadata: name: example-volume labels: type: local spec: #we use local node storage here! #kubectl get storageclass
通过kubectl get storageclass获取。k8s存储类型接口，k8s需要知道使用的何种类型的存储

storageClassName: hostpath # docker提供的 capacity: # 容量 storage: 1Gi accessModes: # 权限
- ReadWriteOnce hostPath: path: “/mnt/data” # 在host上的哪个路径 ```

pvc

pv由管理创建，开发者在应用声明他们想用到的pv，这在pvc中配置。配置会会匹配到一个具体pv，然后应用。向pv申请存储。有namespace

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: example-claim
spec:
  storageClassName: hostpath
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 50Mi # 从pv中申请50M

在pod应用：

apiVersion: v1
kind: ConfigMap
metadata:
  name: postgres-config
  labels:
    app: postgres
data:
  POSTGRES_DB: postgresdb
  POSTGRES_USER: admin
  POSTGRES_PASSWORD: admin123
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgres
spec:
  serviceName: postgres
  selector:
    matchLabels:
      app: postgres
  replicas: 1
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
        - name: postgres
          image: postgres:10.4
          imagePullPolicy: "IfNotPresent"
          ports:
          - containerPort: 5432
          envFrom:
          - configMapRef:
              name: postgres-config
          volumeMounts: # 挂载到pod哪个目录下
          - name: data # 指向volume
            mountPath: /var/lib/postgresql/data 
      volumes:
      - name: data
        persistentVolumeClaim: # 指向一个具体的pvc
          claimName: example-claim
---
apiVersion: v1
kind: Service
metadata:
  name: postgres
  labels:
    app: postgres
spec:
  selector:
    app: postgres
  ports:
    - protocol: TCP
      name: http
      port: 5432
      targetPort: 5432

应用发起存储请求时，被发送给pvc，然后pvc将请求发送给匹配的pv。找到匹配的pv后，volume会被挂载到pod上

sc

当pvc想要pv时，sc可以用来动态创建pv。

StatefulSet

StatefulSet和Deployment相似，可以有replica和storage。Deployment创建时会有个随机的名称，创建和删除pod是随机的。StatefulSet创建时要在yml指定名称，因为要有一种机制来决定那个节点是主节点，其他节点同步主节点数据，所以存储（pv）也是分开的。pod会共享volume，statefulset有自己的pv。pod没有DNS。

statefulset在启动是不会同时启动，而是会一个个启动。stateful命名规则为，[podname]-[ordinal]，ordinal会从0累加。

---
apiVersion: v1
kind: ConfigMap
metadata:
  name: redis-cluster
data:
  update-node.sh: |
    #!/bin/sh
    REDIS_NODES="/data/nodes.conf"
    sed -i -e "/myself/ s/[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}/${POD_IP}/" ${REDIS_NODES}
    exec "$@"
  redis.conf: |+
    cluster-enabled yes
    cluster-require-full-coverage no
    cluster-node-timeout 15000
    cluster-config-file /data/nodes.conf
    cluster-migration-barrier 1
    appendonly yes
    protected-mode no
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: redis-cluster
spec:
  serviceName: redis-cluster # 暴露pod
  replicas: 6
  selector:
    matchLabels:
      app: redis-cluster
  template:
    metadata:
      labels:
        app: redis-cluster
    spec:
      containers:
      - name: redis
        image: redis:5.0.1-alpine
        ports:
        - containerPort: 6379
          name: client
        - containerPort: 16379
          name: gossip
        command: ["/conf/update-node.sh", "redis-server", "/conf/redis.conf"]
        env:
        - name: POD_IP
          valueFrom:
            fieldRef:
              fieldPath: status.podIP
        volumeMounts:
        - name: conf
          mountPath: /conf
          readOnly: false
        - name: data # redis写入数据的路径
          mountPath: /data
          readOnly: false
      volumes:
      - name: conf
        configMap:
          name: redis-cluster
          defaultMode: 0755
  volumeClaimTemplates: # 通过pvc来持久化数据，为每个pod动态提供volume
  - metadata:
      name: data 
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "hostpath"
      resources:
        requests:
          storage: 50Mi # 在data这个volume里面，声明50M的存储
---
apiVersion: v1
kind: Service
metadata:
  name: redis-cluster
spec:
  clusterIP: None
  ports:
  - port: 6379
    targetPort: 6379
    name: client
  - port: 16379
    targetPort: 16379
    name: gossip
  selector:
    app: redis-cluster

Docker速成

2022-03-12T00:00:00+00:00

拉取镜像

docker pull REPOSITORY:tag。tag为版本号，默认为latest表示最新版。

运行容器

docker run REPOSITIRY。不指定参数下运行在attach mode下，terminal被阻塞。 [-d,–detach] 容器在terminal的后台运行，此时会打印容器id [-p,–publish] -p 80:8080，在主机和dokcer容器中创建桥接网络 [–name] 只指定容器name

docker stop containerId，停止一个容器。停止的容器可以使用相同的id再次启动。

docker start containerId 重启容器，重启的容器拥有docker run时所有的属性

Docker命令

docker ps

查看所有运行的容器 [-a] 显示所有容器，包括运行和停止的

docker log [id|name]

查看容器日志

docker exec [OPTIONS] CONTAINER COMMAND [ARG…]

在运行的容器中运行一个命令 docker exec -it 5af5c338dc81 /bin/bash 进入容器命令行。exit可以退出 [-it] 以交互式命令运行（interactive terminal）

Docker network

docker network ls

docker network create [name] 创建一个网络，让容器之间可以仅通过容器名称来通讯.在需要ip和端口的地方可直接用servicename替代

docker run
-p 27017:27017
-d
-e MONGO_INITDB_ROOT_USERNAME=admin
-e MONGO_INITDB_ROOT_PASSWORD=admin123
–name mongodb
–net mongo-network
mongo

docker run -d -p 8081:8081
-e ME_CONFIG_MONGODB_AUTH_USERNAME=admin
-e ME_CONFIG_MONGODB_AUTH_PASSWORD=admin123
–net mongo-network
–name mongo-express
-e ME_CONFIG_MONGO_SERVER=mongodb
-e ME_CONFIG_MONGODB_URL=”mongodb://mongodb:27017” mongo-express

Docker Compose

运行多容器应用的工具。配置文件中不用配置网络，Docker会自己处理

version: "3.9"  # optional since v1.27.0
services:
  mongodb: # name of the container
    image: mongo # image
    ports: # -p
      - 27017:27017 # HOST:CONTAINER
    environment:
      - MONGO_INITDB_ROOT_USERNAME: admin
      - MONGO_INITDB_ROOT_PASSWORD: admin123
  mongo-express:
    image: mongo-express
    ports:
      - 8081:8081
    environment:
      - ME_CONFIG_MONGODB_ADMINUSERNAME: admin
      - ME_CONFIG_MONGODB_ADMINPASSWORD: admin123
      - ME_CONFIG_MONGODB_SERVER: mongodb

docker-compose -f FILE COMMAND [-f] [COMMAND] up运行,down移除容器和network

Dockerfile

构建docker镜像的文件

FROM

所有dockerfile的第一个语句，基于其他镜像

ENV PROPERTY=VALUE

设置环境变量

RUN

执行Linux命令

COPY

将本机文件复制到镜像中

CMD

一个dockerfile只能有一个CMD命令，可以表示程序的entry point

镜像构建

在Dockerfile所在文件打开terminal

docker build -t my-app:1.0 . [t] tag

Dokcer Repository

重命名镜像

docker tag [ImageId] domain:host/url/my-app:[镜像版本号]

推送镜像

docker push fullImageName

Volumes

将物理路径挂载到docker镜像

Run挂载

docker run -v [host-directory]:[container-directory] [image] [-v] 将物理路径挂载到镜像中这种方式称为Host Volume

Anonymous Volumes

docker run -v [container-directory] [image] 由docker自动挂载到host目录中，自动创建名为/var/lib/docker/volumes/random-hash/_data

Name Volumes

docker run -v [name]:[container-directory] [image] 生产环境中最常用的

Volumes路径

/var/lib/docker/volumes

Kafka使用及原理

2022-02-20T00:00:00+00:00

常见命令

Topic

创建Topic

查看topic

$ ./kafka-topics.sh --zookeeper localhost: 2181/kafka --describe --topic topic-demo
Topic: test     TopicId: Zi5yXIXcTZuLE_MkTyC-Wg PartitionCount: 4       ReplicationFactor: 3    Configs:
        Topic: test     Partition: 0    Leader: 2       Replicas: 2,0,1 Isr: 2,0,1
        Topic: test     Partition: 1    Leader: 0       Replicas: 0,1,2 Isr: 0,1,2
        Topic: test     Partition: 2    Leader: 1       Replicas: 1,2,0 Isr: 1,2,0
        Topic: test     Partition: 3    Leader: 2       Replicas: 2,1,0 Isr: 2,1,0

[–describe] 展示主题的更多具体信息

查看所有topic

./kafka-topics.sh --list --zookeeper localhost:2181

Producer

控制台生产者

./kafka-console-producer.sh --broker-list localhost:9092 --topic test-topic

Consumer

从最后一条消息的偏移量+1开始消费

./kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic test-topic 

[–from-beginning] 从头开始消费 [–consumer-property] group.id={id} 设置消费者组。同一个消费者组中的消费者，如果订阅了相同的topic，只能有一个消费者收到消息（单播消息）。不同消费者组的消费者只能有一个消费者收到消息（多播）

查看消费者组 ./kafka-consumer-groups.sh –bootstrap-server localhost:9092 –list 查看kafka中的消费者组

./kafka-consumer-groups.sh –bootstrap-server localhost:9092 –describe –group test-group 查看组的详细信息: GROUP TOPIC PARTITION CURRENT-OFFSET LOG-END-OFFSET LAG CONSUMER-ID HOST CLIENT-ID test-group test-topic 0 29 29 0 consumer-test-group-1-ed58cfd7-73ac-48c6-8f36-cbb58c833c96 /127.0.0.1 consumer-test-group-1

./kafka-topics.sh –describe –zookeeper localhost:2181 –topic my-topic 产看消息状态

Topic: my-topic TopicId: nlRdagkNQ3-2Rfr6FEP9sA PartitionCount: 2 ReplicationFactor: 3 Configs: Topic: my-topic Partition: 0 Leader: 0 Replicas: 2,1,0 Isr: 0,1,2 Topic: my-topic Partition: 1 Leader: 0 Replicas: 0,2,1 Isr: 0,1,2

同一topic 的不同分区Leader可能不同

ps -aux

grep server1.properties

./kafka-consumer-groups.sh –bootstrap-server iot-kafka-service:9092 –describe –all-groups 查看所有消息的消费状态

同步与异步

同步发送消息是，生产者会阻塞，直到broker发送ack消息，超时时间为3秒，重试次数为3次。ack是可以设置的，

0，发送给cluster后直接返回ack，不管broker有没有收到
1，Leader收到消息，并写入log文件
-1/all，leader写入log文件，并且同步给其它follower，可以通过min.insync.replicas指定最少由多少个follower收到消息，默认为1，推荐为大于等于2，方便重新选举leader

每个生产者默认有个32m的缓冲区，消息首先被塞入缓冲区，生产者本地线程每次拉取16k的消息。如果缓冲区没有16k，10ms后自动拉取。

Polll

两次poll时间超过30s，Kafka会认为消费者消费能力不足，改消费者会被踢出消费组

消费方式

指定分区消费从头消费指定offset消费指定时间消费新的消费组启动后，默认从消费者启动后开始消费，也可指定从头开始消费，以后启动时从记录到的offset处开始消费。

Controller

当分区的Leader副本出现故障时，由controller负责选举新的分区副本。。broker在创建的时候会向zookeeper注册创建临时序号节点，谁最小谁就是controller。Topic中有个isr属性会对broker集群的状态做排序，选取排在Leader后面的broker作为新的Leader。

当isr发生变化、topic分区数增加时，由controller负责通知其他broker

When a new event is published to a topic, it is actually appended to one of the topic’s partitions.A common production setting is a replication factor of 3, i.e., there will always be three copies of your data. This replication is performed at the level of topic-partitions.

To get hands-on experience with Kafka https://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying

Kafka客户端

public class KafkaProducerAnalysis {
    public static final String brokerList = "localhost:9092";
    public static final String topic = "topic-demo";

    public static Properties initConfig(){
        Properties props = new Properties();
        props.put("bootstrap.servers", brokerList);
        props.put("key.serializer",
                "org.apache.kafka.common.serialization.StringSerializer");
        props.put("value.serializer",
                "org.apache.kafka.common.serialization.StringSerializer");
        props.put("client.id", "producer.client.id.demo");
        return props;
    }

    public static void main(String[] args) {
        Properties props = initConfig();
        KafkaProducer<String, String> producer = new KafkaProducer<>(props);
        ProducerRecord<String, String> record =
                new ProducerRecord<>(topic, "Hello, Kafka!");
        try {
            producer.send(record);
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

ProducerRecord中含有多种属性

public class ProducerRecord<K, V> {
    private final String topic; //主题
    private final Integer partition; //分区号
    private final Headers headers; //消息头部
    private final K key; //键
    private final V value; //值
    private final Long timestamp; //消息的时间戳
    //省略其他成员方法和构造方法
}

消息的键是消息的附加信息，同时也用来计算分区号。

消息发送有三种模式：

发后即忘（fire-and-forget）。只管发，其他都不管
同步（sync）
异步（async）。

要实现同步的发送方式，可以利用返回的 Future 对象实现。

try {
    producer.send(record).get();
} catch (ExecutionException | InterruptedException e) {
    e.printStackTrace();
}
// 或
try {
    Future<RecordMetadata> future = producer.send(record);
    RecordMetadata metadata = future.get();
    System.out.println(metadata.topic() + "-" +
            metadata.partition() + ":" + metadata.offset());
} catch (ExecutionException | InterruptedException e) {
    e.printStackTrace();
}

异常分为可重试异常和不可重试异常。常见的可重试异常有：NetworkException（网络异常）、LeaderNotAvailableException（eader 副本下线而新的 leader 副本选举完成之前）、UnknownTopicOrPartitionException、NotEnoughReplicasException、NotCoordinatorException 等。可重试异常可以配置retries 属性进行重试，如果重试成功则不抛异常。

异步发送可通过指定Callback的形式进行：

producer.send(record, new Callback() {
    @Override
    public void onCompletion(RecordMetadata metadata, Exception exception) {
        // 消息发送成功时，metadata 不为 null 而 exception 为 null；消息发送异常时，metadata 为 null 而 exception 不为 null。
        if (exception != null) {
            exception.printStackTrace();
        } else {
            System.out.println(metadata.topic() + "-" +
                    metadata.partition() + ":" + metadata.offset());
        }
    }
});

回调函数的调用在一个分区中也会保持和发送顺序相同的顺序调用。

消费者组

Kaka消费者

// 配置消费者客户端参数及创建相应的消费者实例。
// 订阅主题。
// 拉取消息并消费。
// 提交消费位移。
// 关闭消费者实例。
public class KafkaConsumerAnalysis {
    public static final String brokerList = "localhost:9092";
    public static final String topic = "topic-demo";
    public static final String groupId = "group.demo";
    public static final AtomicBoolean isRunning = new AtomicBoolean(true);

    public static Properties initConfig(){
        Properties props = new Properties();
        props.put("key.deserializer",
                "org.apache.kafka.common.serialization.StringDeserializer");
        props.put("value.deserializer",
                "org.apache.kafka.common.serialization.StringDeserializer");
        props.put("bootstrap.servers", brokerList);
        props.put("group.id", groupId);
        props.put("client.id", "consumer.client.id.demo");
        return props;
    }

    public static void main(String[] args) {
        Properties props = initConfig();
        KafkaConsumer<String, String> consumer = new KafkaConsumer<>(props);
        consumer.subscribe(Arrays.asList(topic)); // 多次调用以最后一次subcribe，以最后一次调用为准
        try {
            while (isRunning.get()) {
                ConsumerRecords<String, String> records = 
                    consumer.poll(Duration.ofMillis(1000));
                for (ConsumerRecord<String, String> record : records) {
                    System.out.println("topic = " + record.topic() 
                            + ", partition = "+ record.partition() 
                            + ", offset = " + record.offset());
                    System.out.println("key = " + record.key()
                            + ", value = " + record.value());
                    //do something to process record.
                }
            }
        } catch (Exception e) {
            log.error("occur exception ", e);
        } finally {
            consumer.close();
        }
    }
}

rebalance

分区所有权从一个消费者转移到另一个消费者,为消费者组具备高可用和可伸缩性提供保障，可以为我们方便的向消费者组安全地删除和添加消费者，rebalance期间，消费者组内的消费者无法消费数据（消费者组不可用）。

当分区分配给另一个消费者，消费者当前状态会丢失。比如消费者拉取消息后还没来的及提交，就发生了rebalance，这个分区被分配给另一个消费者，原来的消息会被重新消费一遍，也就是发生了重复消费。一般情况下，应尽量避免不必要的rebalance的发生。

在subscribe方法中：

subscribe(Collection<String> topics, ConsumerRebalanceListener listener)
subscribe(Pattern pattern, ConsumerRebalanceListener listener)

有ConsumerRebalanceListener参数，用来监听rebalance前后的准备和收尾工作。ConsumerRebalanceListener接口中有两个方法：

interface ConsumerRebalanceListener {
    // 会在rebalance之前和消费者停止消费之后调用，
    // 可用来处理位移提交，防止重复消费
    void onPartitionsRevoked(Collection<TopicPartition> partitions);

    // 会在rebalance之后和消费者开始消费之前调用。
    // 参数标识rebalance后的分区
    void onPartitionsAssigned(Collection<TopicPartition> partitions);
}

Map<TopicPartition, OffsetAndMetadata> currentOffsets = new HashMap<>();
consumer.subscribe(Arrays.asList(topic), new ConsumerRebalanceListener() {
    @Override
    public void onPartitionsRevoked(Collection<TopicPartition> partitions) {
        consumer.commitSync(currentOffsets);
	        currentOffsets.clear();
    }
    @Override
    public void onPartitionsAssigned(Collection<TopicPartition> partitions) {
        //do nothing.
    }
});

try {
    while (isRunning.get()) {
        ConsumerRecords<String, String> records =
                consumer.poll(Duration.ofMillis(100));
        for (ConsumerRecord<String, String> record : records) {
            //process the record.
            currentOffsets.put(
                    new TopicPartition(record.topic(), record.partition()),
                    new OffsetAndMetadata(record.offset() + 1));
        }
        consumer.commitAsync(currentOffsets, null);
    }
} finally {
    consumer.close();
}

也已通过在onPartitionsRevoked中将offset存储到数据库，然后onPartitionsAssigned时将数据取出并调用seek方法。

触发Rebalance机制的前提是消费者没有指定分区消费。

如果消费者心跳回复超过10s、或两次poll之间超过30s，Kafka会认为该消费者消费能力太弱，会将其踢出消费者组，topic的风区在消费者组中可能没有消费者消费，Kafka会将分区交给其他消费者，触发Rebalance机制。
新加消费者也会触发Rebalance机制

网络安全概述

2020-11-16T20:24:25+00:00

非对称加密

引入Alice作为发送方，Bob作为接收方。非对称加密技术要求双方公开一个用于加密报文的密钥，称为公钥（K+）。然后使用不公开的、仅双方知道的密钥（K-）进行解密。

RSA是非对称加密技术的代名词，采用模n运算，所以RSA会将报文作为一个数字来看待。RSA算法相当耗时，如果要发送大量数据，发送数据前，先用RSA再加密一个密钥（session key，Ks），然后使用对称加密技术发送数据。典型的RSA公钥长度为2048bit。

对称加密

Alice和Bob共用一个密钥加密。此处涉及如何安全地共享密钥。常见的对称加密算法有DES，AES，3DES等。

完整性与数字签名

为了防止报文中途被人篡改，通常需要通过一个Hash函数（摘要算法）对报文计算一个摘要或散列值（Hash）。即：

找到任意两个报文x、y使得H(x) = H(y)，在计算上是不可能的

常用的Hash函数有MD5（生成128比特的散列值）、SHA-1（生成160比特散列值）。

Alice发送报文时，将生成的摘要附加到原始报文中，形成扩展报文 (m, H(m))，Bob收到后计算 H(m)*，并于摘要对比。

MAC

用密钥s级联原文m形成的散列值H(m+s)称为报文鉴别码（MAC）。鉴别报文完整性和防篡改。

数字签名

为了证明报文确实是Bob发送的，需要在原报文上做特殊处理，对报文进行数字签名达到这个目的。

Bob发送明文m前，先对m生成一个摘要，并使用他的私钥对H(m)，进行加密，得到 K-(H(m))，对原文直接加密计算代价太昂贵。Alice收到报文后，对明文m进行摘要计算，得到散列结果H(m)，然后用Bob的公钥K+解密获得原摘要，然后对两个摘要做对比。

CA

这种签名方式有个缺点，就是可以在Alice的电脑上伪造Bob的公钥，所以要将公钥交给认证中心（CA）保管，由CA负责将公钥与实体绑定，并生成一个证书。证书包含公钥和公钥所有者全局唯一身份信息（IP地址、名字）。CA使用自己的私钥对Bob的公钥和和相关信息进行加密生成证书。

Bob拿到证书后，每次向Alice发送信息时，都要附上该证书，Alice收到信息后，用CA的公钥解开数字证书，拿到Bob的真实公钥。

SSL

TCP的安全增强版被称为安全套接字（SSL），SSL的版本3被称为运输层安全性（TSL），统称为SSL/TSL。

SSL需要双方通讯前交换密钥，协商对称加密算法、公钥算法、MAC。

SSL双方要生成四种密钥：用于加密会话的加密密钥E，用于加密MAC的MAC密钥M。加密的MAC实际上为：(数据, MAC密钥M, 不重复的序号)。不重复数可以防止被攻击。

$E_B$ 从Bob到Alice的会话密钥
$M_B$ 从Bob到Alice的MAC密钥
$E_A$ 从Alice到Bob的会话密钥
$M_A$ 从Alice到Bob的MAC密钥

TSL握手过程：

B: 客户发送它所支持的算法列表，和一个不重复数
A: 服务器选择一种对称算法（如AES）、公钥算法（如RSA）、MAC算法。把这些选择连同CA证书和服务器不重复数发送给客户端
B: 客户端验证证书、提取公钥，生成前主密钥（PMS），用公钥加密PMS发送给服务器
A&B: 使用相同的密钥导出函数（SSL标准定义），客户和服务器独立从PMS和不重复数中计算出主密钥（MS）。然后该MS被切分生成两个密码和MAC密钥
B: 客户发送所有握手报文的MAC
A: 服务发送所有握手报文的MAC

最后两个步骤可以防止握手被篡改。因为握手报文是明文发送的，攻击者可以从算法列表中删除一些算法强的。如果最后的MAC不一致，服务可以选择断开SSL。

发送不重复数也可以使每次使用的密钥不同。

SSH

SSH是目前较可靠，专为远程登录会话和其他网络服务提供安全性的协议。SSH指纹是服务端公钥的摘要，

SSH握手过程：

版本号协商，选择使用SSH1还是SSH2
密钥算法协商，选择公钥算法、加密算法、MAC算法
利用DH交换算法，计算出密钥
1. Bob生成公钥和密钥，并向Alice发送公钥
2. Alice利用Bob的公钥构造密钥对，将生成的公钥发送给Bob
3. Alice和Bob都用对方的公钥和自己的私钥利用算法计算出相同的密钥
4. 利用这个密钥进（session-key）行对称加密
利用密钥进行身份验证

处理密码验证的形式，还可以通过证书验证。客户端通过ssh-keygen生成密钥对，并将公钥保存在server的authorized_key文件中。

客户端发送认证请求，发送public key发送给服务端
服务端确认公钥存在，利用公钥对一个随机的256位字符串进行MD5加密，并发送给客户端
客户端用私钥进行解密，并将它和一个会话ID生成MD5值发送给服务器
服务端同样生成原文和会话ID的MD5摘要，并与客户端的进行比较

Java线程间协作

2020-01-01T00:00:00+00:00

wait/notify

Object.wait()和Object.wait(long)，以及Object.notify()和Object.notifyAll()可用于等待和通知。wait用于暂停一个线程，生命周期状态变为WAITING；notify用于唤醒一个暂停的线程。执行Object.wait的称为等待线程。Java中的任何对象都能实现等待和通知。

实现Object.wait的通用模板：

synchronized (someObject) {
    // 等待通知线程更新
    while (someCondition) {
        someObject.wait();
    }

    doActioin();
}

someObject.wait会以原子的形式使执行线程暂停，并释放其持有的someObject内部锁，此时wait调用并未返回。notify方法可以唤醒任意一个线程，被唤醒的线程需再次申请someObject对应的内部锁。被唤醒线程再次持有someObject对应的内部锁的情况下继续执行wait剩余的指令，直到wait返回。

通知线程模板

synchronized (someObject) {
    update();
    someObject.notify();
}

等待线程被唤醒后继续占有处理器，该线程可能会被其它线程占用内部锁导致上下文切换。notify方法要尽量靠近临界区结束的地方。

JVM会为每个对象维护一个入口集（EntrySet）用于存储申请该对象内部锁的线程。此外还会维护一个等待集（WaitSet）的队列，用于存储对象上的等待线程。Object.wait将当前线程暂停并释放相应内部锁的同时将调用线程存入等待集。对象的notify方法调用后，任意一个线程会被唤醒，被唤醒线程仍在等待集中，直到相应线程持有内部锁，wait会将线程从等待集中移除，接着wait方法返回。

wait/notify问题

过早唤醒。通知线程唤醒了等待在某个对象的线程，但此时等等待线程所需的条件并没有得到满足。可以利用Conditional解决。
信号丢失。等待线程没有结果条件判断直接调用wait，那么会出现一种情形：通知线程在等待线程进入临界区之前更新了共享变量，并调用了notify，然而等待线程直接调用wait，此时就没有其它线程进行通知。在需要调用notifyAll的地方调用了notify也会导致这种现象，如随机唤醒的线程使用了其它的保护条件。
欺骗性唤醒。在没有任何线程调用notify的情况下被唤醒

Thread.join(long)方法可以等待一个线程结束后继续执行,它的底层采用了wait/notify来实现。调用时，如果检测到目标线程未结束，就调用wait来暂停当前线程。JVM会在目标线程run方法结束后调用notifyAll通知所有等待线程。目标线程充当了同步对象（Object.wait），

条件变量

wait/notify过于底层，且存在过早唤醒的问题。Object.wait(long)也无法区分其返回是由于超时还是被通知线程唤醒等问题。

Conditional可以作为wait/notify的替代品来实现通知，解决了过早唤醒、区分超时等待的问题。Conditional接口的await/signal/signalAll相当于Object的wait/notify/notifyAll。

Conditional模板与wait/notify一样。

class ConditionalUsage {
    private final Lock lock = new ReentrantLock();
    private final Condition condition = lock.newCondition();
    public void action() throws InterruptException {
        lock.lock();
        try {
            while (con) {
                condition.await();
            }
            doAction();
        } finally {
            lock.unlock();
        }
    }

    public void notify() throws InterruptException {
        lock.lock();
        try {
            updateState();
            condition.signal();
        } finally {
            lock.unlock();
        }
    }
}

await/signal执行时，执行线程需持有条件变量的 显示锁 。循环语句与目标动作在同一个显示锁引导的临界区内，防止欺骗性唤醒和信号丢失。await和wait类似，暂停当前线程的同时也使当前线程释放持有的锁，这是调用还没有返回。被唤醒的等待线程继续运行后，也需要申请相应的显示锁，被唤醒线程申请到锁后，await调用才返回。

通过在应用代码层为每个保护条件建立一个条件变量来解决过早唤醒的问题，让不同的线程在不同的条件变量上等待；并让通知线程尽唤醒相应保护条件的线程。Condition在唤醒时，能够分辨是超时还是正常的signal唤醒。Condition.awaitUntil(Date)返回true，则说明是正常唤醒，可以通过返回值做进一步的动作。

CountDownLatch

CountDownLatch可以实现一个或多个线程等待其它线程完成一组特定的操作（先决操作）之后才继续运行。

CountDownLatch内部维护一个 未完成先决操作 数量的计数器。CountDownLatch.countDown()每调用一次，计数器减1。CountDownLatch.await()方法相当于一个保护方法，保护条件为“计数器值为0”。当计数器不为0时，调用await的线程被暂停，countDown()相当于通知方法，当计数器值为0时，唤醒该实例上所有等待线程。

一个CountDownLatch实例只能实现一次等待和唤醒，当计数器达到0后，继续调用countDown不会有任何作用，也不会唤醒线程；同时继续调用await不会暂停线程。

调用await和countDown时无需加锁。CountDownLatch.await(long, TimeUnit)允许设置超时时间，返回值为true说明为正常唤醒。

CyclicBarrier

CyclicBarrier用于多个线程互相等到代码执行到某个地方，这是这些线程才能继续执行。Cyclic意思是该类可以重复使用。使用CyclicBarrier的线程称为参与方（party），参与方执行执行CyclicBarrier.await()就可以实现等待。CyclicBarrier内部维护了显示锁，可以区分最后一个调用await的参与方。除了最后一个线程外的任何参与方调用await都会被暂停（WATING）。最后一个线程执行await的时候，会使得所有参与方都被唤醒，但是最后一个线程本身不会被唤醒。

CyclicBarrier(int, Runnable)允许指定一个任务，在最后一个线程执行await时、其它线程唤醒前执行该任务。

阻塞队列

JDK1.5引入了juc.BlockingQueue接口，它定义了一种线程安全队列——阻塞队列。BlockingQueue的常见实现类有ArrayBlockingQueue、LinkedBlockingQueue和SynchronousQueue。阻塞队列可按容量是否受限划分为有界队列和无界队列。有界队列由应用程序指定，无界队列最大存储容量为Integer.MAX_VALUE。使用有界队列的好处是“反压”——当消费者能力跟不上时，队列积满，生产者会被暂停。

put操作将数据入队，生产者执行的put操作对后续消费者的take操作是可见的、有序的。

ArrayBlockingQueue在内部实现时，put和take操作用的是同一把锁，可能导致锁的高争用，造成过多的上下文切换。

LinkedBlockingQueue既能做有界队列，又能做无界队列。它的优点是在内部实现时，put、take操作时用的是两把显示锁，这降低了锁争用的可能性。

SynchronousQueue是空间为1的有界队列，它的内部不维护任何存储空间。生产者执行了SynchronousQueue.put时，该生产者被暂停，知道有消费线程执行take。类似，如果消费者执行了take，它会被暂停，知道生成者执行了put。

SynchronousQueue和ArrayBlockingQueue既支持非公平调度也支持公平调度。LinkedBlockingQueue只支持非公平调度。

阻塞队列支持非阻塞调用，offer(E)和poll。offer通过返回false表示入队失败，poll通过返回null表示队列为空。

信号量

信号量Semaphore用来控制对一个资源的访问次数，Semaphore(int)用来指定一个资源能同时被访问几次。Semaphore.acquire()用来申请配额，在调用成功后会使Semaphore内部的计数器减1，当配额不足时，会使当前线程睡眠。Semaphore。release会使计数器加1，并唤醒等待队列中的一个线程。

不像锁那样，acquire/release不必配合使用。

管道

双缓冲

用两个缓冲区来实现数据的并发交换。生产者将一个缓冲区填满后，可以被消费者消费。而另一个空的、使用过的缓冲区用力啊填充新数据。即消费者消费一个填满的缓冲区，生产者填充一个缓冲区。

Java的Exchanger类用来实现消息的交换，它相当于只有两个参与者的CyclicBarrier。只有生产者和消费者都调用Exchaner.exchange(V)后，该方法调用才能返回。

public V exchange(V x) throws InterruptedException

参数x相当于缓冲区，生产者的返回值为消费者的参数（即已消费的缓冲区），消费者的返回值为生产者的参数（即已填满的缓冲区）。非常像一手交钱，一手交货。

线程中断

一个线程请（发起线程）求另一个线程（目标线程）停止其正在执行的操作。中断是发起线程发送给目标线程的一种指示，指示目标线程停止其正在执行的操作。Java为每个线程维护一个中断标记，用于表示响应的线程是否收到中断。目标线程可以通过Thread.currentThread.isInterrupted()来获取该线程的中断标记，也可以通过Thread.interrupted()来获取并重置标记。

目标现场检查中断标记后所执行的操作，被称为中断响应。目标线程对中断的响应包括：

无影响。发起线程调用目标线程的interru()方法不会对目标线程产生任何影响。这种操作包括target正在调用InputStream.read()、ReentrantLock.lock()、申请内部锁等阻塞操作
取消任务运行，中断发生时的任务被取消，但是不会影响继续运行其它任务
工作者线程停止，生命周期变更为TERMINATED

InterruptedException

Java标准库对许多中断的处理方法都是抛出InterruptedException等异常。Java标准库中有些阻塞方法也无法响应中断，如InputStream.read()、Lock.lock()以及内部锁申请。

能够对中断做出相应的标准库：

Object.wait()/Object.wait(long)/wait(long, int)
Thread.sleep(long)/sleep(long, int)
Thread.join()/join(long)/join(long, int)
BlockingQueue.take()/put(E)
Lock.lockInterruptibly()
CountDownLatch.await()、CyclicBarrier.await()、Exchanger.exchang(V)
channels.InterruptibleChannel。抛出ClosedByInterruptException

能够响应中断的方法通常在调用阻塞操作前判断中断标志位，若中断标志位为true，则抛出InterruptedException。如ReentrantLock.lockInterruptibly与ReentrantLock.lock()效果相似，但是前者能够对中断进行相应。凡是抛出InterruptedException的方法，通常会在其抛出异常前，会将当前标志位重置为false。

如果中断发生的那一刻，目标线程以及调用了阻塞方法而被暂停，那么JVM会设置目标线程会将相应的线程唤醒，并使其抛出InterruptedException。所以Jaba应用层代码可以通过对InterruptedException等异常的处理来响应中断。对InterruptedException的处理包括以下方式：

不捕获，可以在方法声明处加throw，抛给上层处理
捕获后重新抛出
捕获后中断当前线程。这种策略实际上在捕获异常后又恢复中断标志位。相当于告诉其它代码，当前保留了中断标志位，但不知如何处理

捕获异常又恢复中断标志位：

public class Foo() {
    public void bar() {
        try {
            // ...
        } catch(InterruptedException e) {
            Thread.currentThread().interrupt(); // 保留中断标记
        }
    }
}

线程停止

Java线程安全

2020-01-01T00:00:00+00:00

装饰器 Decorator

装饰器模式可以用来实现线程安全，其基本思想是为非线程安全对象创建一个相应的线程安全的包装类对象。包装对象与相应的非线程安全对象具有相同的接口，包装对象通常会借助锁。

java.util.Collections.synchronizedX，可以反会线程安全的集合，X 可以为 Map、Set、List。这些对象称为同步集合。同步对象的 Iterator 不是线程安全的，为了保障对同步集合遍历操作的线程安全性，

并发集合

juc 包引入了线程安全的集合对象，通常情况下可以作为同步集合的替代品。

非线程安全对象	线程安全对象	共同接口	遍历方式
ArrayList	CopyOnWriteArrayList	List	快照
HashSet	CopyOnWriteArraySet	Set	快照
LinkedList	ConcurrentLinkedQueue	Queue	准实时
HashMap	ConcurrentHashMap	Map	准实时
TreeMap	ConcurrentSkipListMap	StoredMap	准实时
TreeSet	ConcurrentSkipListSet	SortedSet	准实时

并发集合自身就能对其进行线程安全遍历，无需加锁。并且，对并发集合的遍历操作和对其进行的更新操作是可以由不同的线程并发执行的。并发集合在内部保障线程安全时通常不借助锁，而是用CAS操作，或对锁进行优化（粒度极小的锁）。并发集合的吞吐率要高于同步集合，同步集合会导致锁争用，从而导致上下文切换开销大。

实现线程安全的遍历通常有两种方式：快照和准实时。快照是在Iterator示例被创建的那一刻，待遍历结构内部生成的只读副本，它反映了集合某一时刻的状态。不同线程对集合进行遍历会得到不同的副本，所以无需加锁就可以实现线程安全。这种遍历返回的iterator是不支持remove的。缺点是集合比较大时，创建副本的开销会比较大。CopyOnWrite就是使用这种方式。

准实时遍历操作不针对副本，但又不借助锁来保障线程安全，从而使得遍历操作与更新操作并发进行。遍历过程中其它线程对集合进行修改，也能在遍历中反映出来。这种形式返回的Iterator支持remove操作。Concurrent集合采用这种方式。由于Iterator是被设计成一次只能有一个线程使用，所以如果多个线程要进行遍历操作，这些线程间不适宜共享一个Iterator。

ConcurrentLinkedQueue是Queue接口的线程安全的实现类，相当于LinkedList的线程安全版。其内部不使用锁，而是用CAS，因此是非阻塞的，使用时不会导致线程被暂停。ConcrrentLinkedQueue遍历是准实时的。与BlockingQueue相比，更适合更新操作和遍历操作并发的场景而BlockingQueue更适合多个线程并发更新同一队列的场景，比如消费者生产者模式。

Java同步机制

2019-12-10T00:00:00+00:00

按照Java虚拟机的实现方式，锁包括synchronize实现的内部锁，和实现Lock接口的显示锁。

Java锁对线程安全的保障：

原子性。不管是读还是写，都要获得响应的锁。
可见性。 Java平台中，获得锁隐含着刷新处理器缓存的动作，使得读线程在进入临界区之前将对线程共享变量的更新同步到处理器的高速缓存中；而锁的释放隐含这冲刷处理器的动作，使得写线程对共享的更新刷新到处理器的高速缓存中。对于引用变量，还能包装读取到最新的对象字段。数组也能包装读取到最新元素。
有序性。锁还能保障有序性，因为读线程没必要知道写线程是以什么顺序更新变量的。临界区只是保证临界区内的操作不会被重排到临界区之外。

可重入锁允许一个线程多次获得一个锁，

syncronized

java中的任何一个对象都有唯一一个与之关联的锁，称为监视器（monitor）或内部锁（intrinsic）。内部锁是一种排他锁。内部锁通过synchronized关键字实现，可以修饰代码块和方法。被synchronized修饰的方法称为同步方法。synchronized的锁是一个对象，或能够返回对象的表达式。锁可以是this。

public class Foo {
    private int serial = 0;
    public int next() {
        synchronized(this) {
            return ++serial;
        }
    }

    // 也可以这样写
    public synchronized int next() {
        return ++serial;
    }
}

一般用final和private修饰锁对象，一旦改变，会使一个同步块使用不同的锁。

private final Object LOCK = new Object();

同步静态方法相当于用当前类对象作为锁，类本身也是一个对象。

class Foo {
    public static synchronized void bar() {
        // 以当前类对象作为锁
    }

    // 等价
    public static void bar2() {
        synchronized(Foo.class) {

        }
    }
}

内部锁的获得和释放都是由虚拟机自动完成的，内部锁的使用的不会导致锁泄露，即使代码发生异常。

显式锁：Lock接口

Lock的默认实现是ReentrantLock，是可重入锁。ReentrantLock即是公平锁也是非公平锁，可以通过构造函数ReentrantLock(boolean fair)指定。公平锁适合锁持有时间较长，或申请锁平均时间较长的情况，增加了上下文切换作为代价。相关方法：

Thread.holdsLock(Object)检测当前线程是否持有指定的内部锁
ReentrantLock.isLocked检测相应的锁是否被某个线程持有
ReentrantLock.getQueueLength

读写锁

读写锁也被称为共享锁、排他锁，运行多个线程同时读取共享变量，但只允许一个线程对共享变量更新。任何线程读取共享变量的时候，其他线程无法更新改变量。一个线程更新共享变量时，其他线程无法读取、写入该共享变量。读锁对读线程共享，写锁对其他写锁和读锁排他。

读写锁适合在只读操作比写操作频繁的多、读线程持有锁的时间比较长的场景中使用。ReentrantReadWriteLock支持锁降级，即一个线程持有写锁的情况下可以继续获得相应的读锁。降级的反面是锁升级，即一个线程持有读锁的情况下，申请相应的写锁，ReentrantReadWriteLock不支持锁升级。

public interface ReadWriteLock {

    Lock readLock();

    Lock writeLock();
}

内存屏障

JVM借助内存屏障来实现处理器的刷新和冲刷，内存屏障是对处理器的抽象。内存屏障被插入到两个指令之间，作用是禁止编译器、处理器重排序，从而保障有序性。这些指令也会刷新和冲刷处理器，从而保障可见性。

内存屏障可以划分为一下几个部分：

按可见性。加载屏障和存储屏障，它们分别会刷新处理器缓存和冲刷处理器缓存。JVM会在monitorexit（释放锁的JVM指令）对应的机器码指令插入 存储屏障 ，保证了写线程在释放锁前在临界区对共享变量的更新对其他线程是可见的。相应的，JVM会在monitorenter对应的机器码指令之后的 临界区开始之前 插入加载屏障，使得读线程对应的处理器能够将写线程从对相应共享变量的更新从其他处理器同步到高处理器的高速缓存中。可见性的保障是通过读线程和写线程使用相应的屏障实现的。
按有序性，可分为获取屏障（acquire）和释放屏障（release）。获取屏障在一个 读操作之后 插入该内存屏障，作用是禁止该读操作与其后的任何读写操作之间进行重排序（如read-modify-write），相当于在进行后续操作之前要先获得共享数据的所有权。释放屏障在一个 写操作之前 插入该内存屏障，作用是禁止该写操作与其前面的任何读写操作之间进行重排序，相当于对相应的共享变量更新结束后释放所有权。JVM会在monitorenter（包含读操作）对应的机器码之后临界区之前插入获取屏障，并在临界区之后monitorexit对应的机器码之前插入释放屏障

两种屏障想三明治一样把临界区的代码包括起来，禁止临界区中任何读写操作被重排序到临界区之前，释放屏障经禁止了读写操作被重排序到临界区之后。这使得临界区的操作具有原子性，同时读线程不用知道临界区的共享变量是以何种顺序被更新的。

临界区之外的代码可能会被JIT编译进临界区内，但由于内存屏障，处理器不会将其重排序到临界区外（也不会将临界区外的指令重排到临界区内）。x86的Lokc指令前缀能够禁止其前或其后的读写指令的重排序。

volatile

volatile修饰的变量意味着每次读取和更新，都必须从高速缓存或内存中读取。因此，volatile不会被编译器分配到寄存器进行存储。

volatile是轻量级锁，保证可见性和有序性。但仅能保证写操作的原子性，而不表示赋值有原子性（如value = count + 1），而没有排他性。其次，volatile的使用不会引起上下文的切换。

对volatile变量进行写操作，会在写操作前后加上释放屏障和存储屏障，以防止对volatile写操作被重排序到前面。并且保证volatile之前的任何读写操作都会先于volatile之前被提交，即读线程看到写线程更新volatile变量时，更新volatile变量之前的内存操作对读线程是可见的，保障了有序性。存储屏障会冲刷处理器缓存，使得volatile变量和之前的任何操作对其他处理器是可见的。

public class Foo {
    private int data = 0;
    private String data2 = null;
    private volatile boolean ready = false;
    
    public void write() {
        a = 1;
        data2 = "Read";
        ready = true;
    }

    public void read() {
        if (read) {
            // do something
            // 当read时，data和data2一定初始化了。
        }
    }
}

对于volatile的读操作，JVM会在该操作前后插入加载屏障和获取屏障。加载屏障可以刷新处理器，使得读线程所在的处理将其他处理器对共享变量（volatile变量和之前的变量）的更新同步到高速缓存中，获取屏障禁止了volatile读操作之后的任何读写操作与volatile读操作进行重排序。因此对volatile读操作之后的任何操作开始之前，写线程对相关共享变量（包括volatile变量）的更新对当前线程已经可见。

volatile有序性也可从禁止重排序理解：

写volatile变量不会往前重排序
读volatile变量不会向后重排序

如果volatile修饰数组，那么只会对数组引用本身起作用，而无法对数组元素的操作起作用。可以使用如AtomicIntegerArray来实现类似效果。

volatile开销

volatile变量读写不会导致上下文切换，因此volatile的开销比锁小。volatile变量的读取开销可能比普通要高，因为每次都要从高速缓存或内存中同步，而无法在寄存器中暂存。

应用场景：

volatile变量作为标志位，避免锁开销
保障可见性。多个线程共享一个变量。其他线程在没有加锁的情况下也能看到更新
在某些情况下可以代替锁，如多个线程共享一组数据的情况下，通常要用锁来保障这组变量操作的原子性。利用volatile变量写操作的原子性，可以将这组变量包装成对象，对这组变量的更新就可以通过创建新的对象，并将引用赋给变量来实现
简易的单变量的读写锁

单例模式

双重检测

// 有问题的代码，没有加volatile
public Singleton {
    private static volatile instance;
    private Singleton() {}
    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

对象的初始化操作如一下伪代码，对象的初始化操作可以被分为如下3步，如果变量中没加volatile，就会发生将操作2重排序到操作3。其它线程会读取到一个没有初始化的对象。volatile能够禁止该变量写操作与之前的任何读写操作进行重排序，保障instance读取时实例已经初始化完毕。

objRef = allocate(Singleton.class) // 1. 分配空间
involkeConstruct(objRef); // 2. 调用构造器
instance = objRef; // 3. 将对象引用写入共享变量

CAS

许多多线程的库最终实现都会借助CAS。CAS能够将read-modift-write和check-and-act之类的操作转为原子操作。CAS是原子的if-then-act操作。CAS保障更新的原子性，但不保障可见性。如果其他线程没有修改过原子变量的值，那么多个线程修改一个原子变量时，下手最快的线程更新成功。

原子变量类基于CAS实现，一共有12个

基础类型，AtomicInteger AtomicLong AtomicBoolean
数组型，AtomicIntegerArray AtomicLongArray AtomicReferenceArray
字段更新器，AtomicIntegerFieldUpdater AtomicLongFieldUpdater AtomicReferenceFiledUpdater
引用型，AtomicReference AtomicStampedReference AtomicMarkableReference

AtomicBoolean看起来有些多余，但实际上当执行read-modify-write需要加锁操作。

public class Foo {
    private AtomicBoolean atomicBool = new AtomicBoolean(false);
    private volatile boolean bool = false;

    public void casInit() {
        if (atomicBoolean.compareAndSet(false, true)) {
            // ...
        }
    }

    public void lockInit() {
        synchronized (this) {
            if (bool) {
                return;
            }
            bool = true;
            // ...
        }
    }
}

使用atomic变量能够避免锁的开销，又避免了原子性。AtomicBoolean和AtomicReference从理解上是相似的（有条件更新）。在数组变量上即使加上volatile，也无法使对应元素的读写具有可见性和原子性，Java引入了AtomicIntegerArray等来解决。

ABA问题：对于共享变量V，一个线程在看到它的值为A的时刻，其他线程将新为B，接着在当前线程将其执行CAS的时刻又被其他线程更新为A，那么可否认为V的值没有变化过？这就是ABA问题，即共享变量的值经历了A -> B -> A的变化。

要解决ABA问题，可以共享变量进行扩展，引入版本号，每更新一次就在版本号增加1，对应的Java类为AtomicStampedReference。

AtomicIntegerFieldUpdater（Long、Reference）是字段更新器，更加底层，可理解为对CAS的封装，原子变量的其他几个类都可以用它们来实现。

对象发布与逃逸

对象发布指能够被其作用域之外的线程访问到。常见的对象发布有一下几种方法：

将对象存储到public变量中
在非private方法中返回一个对象
创建内部类，使当前对象能够被这个内部类访问，如new Runnerble()中使用”外层类名.this”的语法

对象初始化安全

static

Java中类的初始化技术是延迟加载的，一个类被虚拟机加载后，该类所有静态变量都为默认值，知道有个线程初次访问该类的任意一个静态变量，才使这个类被初始化（静态初始化块static{}被执行），类的所有变量配赋初值。

static在多线程环境下有特殊含义，能够保障一个线程在没有其它同步机制下，能够读取到读取到一个类静态变量的初始值。但仅能保障初次读取，不能保障其他线程更新的可见性。对于静态引用变量，static保障一个变量读取该变量初值时，这个引用所指的对象也初始化完毕。

final

由于重排序的作用，一个线程读取一个对象的引用时，该对象可能尚未初始化完毕，线程可能读取到该变量默认值而不是初始值。多线程环境下final关键字有特殊的作用。

当一个对象发布到其他线程时，该对象所有final字段都是初始化完毕的，而非final字段则没有这种保证。对于 引用型final字段 ，该字段所引用的对象读取时已经初始化完毕，即线程读取到该对象的各个字段都已经初始化完毕，读取时都是初始化值。

public clas Foo {
    private final Bar bar;
    private String str;
    public Foo (int x, int y, String s) {
        this.str = s;
        this.bar = new Bar(x, y);
    }

    public static Bar {
        private int x;
        private int y;
        public Bar(int x, int y) {
            this.x = x;
            this.y = y;
        }
    }
}

在JIT内联优化下，this.bar = new Bar(x, y)可能会被有编译为以下伪指令：

objRef = allocate(Foo.class); // 1
objRef.str = "xxxx"; // 2
objBar = allocate(Bar.class); // 3
objBar.x = 1; // 4
objBar.y = 2; // 5
objRef.bar = objBar; // 6

bar采用final修饰，Java会保证构造器中对该变量的初始化，以及锁引用对象的初始化被限定在操作5之前完成。而url没有采用final修饰，所以任然可能被重排序到操作5之后。

final只能保障有序性，即保障该对象对外可见的时候，final字段必然是初始化完毕的，但不保证对象本身的可见性。

Welcome to Jekyll Paper!

2018-02-11T00:00:00+00:00

Jekyll Paper is a Jekyll theme, it is designed to helping you to create your own blog by the easiest way. Now, you can learn how to use this blog by this post.

You’ll find this post in your _posts directory. Go ahead and edit it and reload the page to see your changes. You can edit this post on Github or your local repository copy.

To add new posts, simply add a file in the _posts directory that follows the convention YYYY-MM-DD-name-of-post.md and includes the necessary front matter. Take a look at the source for this post to get an idea about how it works.

Jekyll also offers powerful support for code snippets:

#include <stdio.h>

int main(int argc, char *argv[]) {
  printf("Hello World!\n");
  return 0;
}

// => prints 'Hello World!' to STDOUT.

Check out the Jekyll Paper docs or Jekyll docs for more info on how to get the most out of Jekyll. If you have questions or suggestions, you can create an issue to asking them on Jekyll Paper Issues or Jekyll Talk.

笔记仓库

Kubernetes

K8s基本概念

Node

Pod

Serivce

Ingress

ConfigMap

Secret

Volume

Deployment

StatefulSet

K8s架构

Master Node

Kubectl

Kubectl基本命令

创建Deployment

Replicaset

K8s配置文件

Deployment Configuration

Service Configuration

Secret Configuration

ConfigMap

外网可访问的Service

通过describe命令查看service的部署

Namespace

Ingress

Controller

安装controller

Helm

结构

替换默认值

Release Managerment

Volumes

pv

通过kubectl get storageclass获取。k8s存储类型接口，k8s需要知道使用的何种类型的存储

pvc

sc

StatefulSet

Docker速成

拉取镜像

运行容器

Docker命令

docker ps

docker log [id|name]

docker exec [OPTIONS] CONTAINER COMMAND [ARG…]

Docker network

Docker Compose

Dockerfile

FROM

ENV PROPERTY=VALUE

RUN

COPY

CMD

镜像构建

Dokcer Repository

登录

重命名镜像

推送镜像

Volumes

Run挂载

Anonymous Volumes

Name Volumes

Volumes路径

Kafka使用及原理

常见命令

Topic

创建Topic

查看topic

查看所有topic

Producer

控制台生产者

Consumer

同步与异步

Polll

消费方式

Controller

Kafka客户端

消费者组

rebalance