普罗米修斯

普罗米修斯介绍

Prometheus（普罗米修斯）是一套开源的监控系统，其基本原理是通过 HTTP 协议周期性抓取被监控组件的状态，不需要任何 SDK 或者其他的集成过程，其架构如图：


Prometheus 主要由以下部分组成：

  • prometheus server: 是 Prometheus 组件中的核心部分，负责实现对监控数据的获取，存储以及查询;
  • exporter: 采集端，通过 http 服务的形式保留一个 url 地址，prometheus server 通过访问该 exporter 提供的 endpoint 端点，即可获取到需要采集的监控数据。
  • AlertManager: 在 prometheus 中，支持基于 PromQL 创建告警规则，如果满足定义的规则，则会产生一条告警信息，进入 AlertManager 进行处理。可以集成邮件，微信或者通过 webhook 自定义报警。
  • Pushgateway: 由于 Prometheus 数据采集采用 pull 方式进行设置的， 内置必须保证 prometheus server 和对应的 exporter 必须通信，当网络情况无法直接满足时，可以使用 pushgateway 来进行中转，可以通过 pushgateway 将内部网络数据主动 push 到 gateway 里面去，而 prometheus 采用 pull方式拉取 pushgateway 中数据

普罗米修斯的数据存储采用的是时间序列数据(TimeSeries Data)，它是按照时间顺序记录系统、设备状态变化的数据。

默认情况下 Prometheus 会将采集的数据存储到本机的 /usr/local/prometheus/data 目录，存储数据的大小受限和扩展不便；如果只作为测试自然不需要担心这个问题，如果用于生产的话需要安装配置时序数据库influxdb。

普罗米修斯使用初体验

在 kubesphere 的安装中，普罗米修斯是配套安装的，前文介绍过kubesphere的安装教程。这里我直接使用现成的Prometheus系统。有安装需求的小伙伴建议使用k8s+helm进行安装。

KubeSphere 通过 NodePort 访问内置的 Prometheus 服务，服务类型更改为 NodePort，同时修改外部访问端口：

1
kubectl edit svc -n kubesphere-monitoring-system prometheus-k8s

访问普罗米修斯ip:port

我们可以通过这个操作页面进行一些指令操作，在指令栏输入KEY，它会有联想输入提前弹出你想要的KEY，然后点击执行按钮就能获得对应的监控数据：

metrics：

在普罗米修斯监控中，称采集存储的数据为metrics，在普罗米修斯中它是以 key/value的形式保存的。其主要类型分为以下几种：

  • Gauges: 某个监控指标的瞬时值，如内存使用量，队列的等待任务数等。
  • Counters: 计数器类型，属于累计值，如开机时常等。
  • Histogram：比例型数值，例如请求响应时间占比分布等。

每个key-value 数据还会带上标签进行归类，标签可使用正则表达式进行匹配。

关于普罗米修斯采集到的 key-value 数据 可以访问 http://ip:port/metrics url 进行查看：

以 # 号开头的部分是对采集数值的一个说明，如：

1
2
3
# HELP go_gc_cycles_automatic_gc_cycles_total Count of completed GC cycles generated by the Go runtime.
# TYPE go_gc_cycles_automatic_gc_cycles_total counter
go_gc_cycles_automatic_gc_cycles_total 77

HELP 是对这个采集数据的注释，TYPE 表示它的metrics类型为 counter。统计数据是 exporter 提供的，想要采集不同指标的数据 比如mysql 或者kafka 就要使用不同 expoerter 去收集，官方提供了不少exporter:

PQL

对于普罗米修斯的数据，我们不仅限于查看，还能进行一些函数运算：

1
2
3
4
5
6
## 查询最近2min
prometheus_http_requests_total{job="prometheus"}[2m]
## 乘法运算
prometheus_http_requests_total{job="prometheus"} offset 1m *1024
## 统计
count(node_cpu_seconds_total)

这些语句称为pql，PQL使用”#”对语法进行注释，其常用内置函数有：

  • abs: 绝对值
  • absent: 判断标签是否存在
  • ceil：取整
  • sum：求和
  • min：最小值
  • count：统计
  • avg：平均值
  • topk：排序

当然我们观察机器的一些数据指标肯定不能通过手写PQL去查看，这样就太累人了。通常我们会结合grafana进行可视化的监控。

grafana 的简介及使用：

grafana 是数据统计和展示工具，它展示数据，但不提供数据。目前Grafana 支持的数据源有：Graphite, InfluxDB, OpenTSDB, Prometheus, Elasticsearch, CloudWatch，Zabbix等。

grafana 相关概念：

  • Data Source: 数据源
  • DashBoard：仪表盘，数据展示的窗口。
  • Row：DashBoard 的基本组成单元，可以理解为数据行
  • Panel：面板，实际上就是row展示信息的方式，支持表格（table），列表（alert list），热图（Heatmap）等多种方式。
  • Query Editor：查询语句编辑器，用于编写PQL

grafana 部署我这里是采用 KubeSphere 的应用模板进行部署的，傻瓜式的安装，这里就不做太多介绍了，安装完成后界面如下：

然后导入prometheus数据源，Configuration → Data Sources → Prometheus → Select：


查看仪表盘：

当然grafana，还支持自定义仪表盘和查询统计语句，这种高定制化的需求需要对pql和 grafana 都有较深的理解

展开全文 >>

k8s-kubesphere

KubeSphere 介绍

KubeSphere是k8s控制台，ubeSphere 目前提供了工作负载管理、微服务治理、DevOps 工程、Source to Image、多租户管理、多维度监控、日志查询与收集、告警通知、服务与网络、应用管理、基础设施管理、镜像管理、应用配置密钥管理等功能模块。

kubeSphere 帮我们把诸多云原生功能集中在一起并提供了web界面。利用KubeSphere我们可以根据我们之前学习的 Jenkins docker k8s 搭建一套完整的私有云系统，极大的减少运维以及开发的工作量。具体的搭建思路我在下一节中给出，这一节我们先安装并使用KubeSphere。

kubeSphere 安装

为了简化安装，我们这里使用的是KubeKey，KubeKey安装k8s的最低配置要求是2核4G，低于这个配置使用KubeKey会安装失败。由于KubeKey会访问github。所以需要保证你的主机能联网。我们本地实验的方式可以使用前文提到过的vagrant搭建虚拟机集群。然后在vagrant中安装。也可以在云上上实验，云上实验采用按量计费的方式，阿里云收费如下，网络带宽另计费
image.png
腾讯云的：
image.png
腾讯云的服务器要便宜很多，而且阿里云要使用按量计费需要余额大于100 元，腾讯云没有这个限制，不过两家都支持余额提现。做云实验的话我建议使用腾讯云的按量计费服务器，100块钱能玩很久（它的对象存储也只要几毛钱一个月）。
阿里云和腾讯云都推出了轻量级云服务器，比普通云服务器便宜很多，这种服务器是你用多少给你分配多少，比如我买了2核4g的服务器，如果我只用了1核1g，那剩余的资源就会被系统分配出去。这种服务器做实验体验不是很好，所以没考虑，感兴趣的小伙伴可以试试这种服务器。
为了偷个懒，这次我们实验就是在腾讯云上进行（主要是本地机器网络不太好）。
执行命令：

1
2
3
export KKZONE=cn

curl -sfL https://get-kk.kubesphere.io | VERSION=v2.2.2 sh -

image.png
为 kk 添加可执行权限，并初始化本地主机：

1
2
chmod +x kk
./kk init os

image.png
接下来我们生成一个配置文件来安装k8s和kubeSphere

1
./kk create config [--with-kubernetes version] [--with-kubesphere version] [(-f | --file) path]

示例：

1
2
3
4
5
## 使用默认配置创建示例配置文件
./kk create config
## 指定要安装的 KubeSphere 版本
./kk create config --with-kubesphere v3.3.0
./kk create config --with-kubernetes v1.22.10 --with-kubesphere v3.3.0

image.png
这里建议指定版本号，因为有的机器会不支持安装高版本kubeSphere，指定版本生成配置文件会有对应提示。
image.png
config-sample.yaml示例：

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
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
apiVersion: kubekey.kubesphere.io/v1alpha2
kind: Cluster
metadata:
  name: sample
spec:
  hosts:
  - {name: node1, address: 192.168.221.128, internalAddress: 192.168.221.128, user: root, password: "root"}
  roleGroups:
    etcd:
    - node1
    control-plane: 
    - node1
    worker:
    - node1
  controlPlaneEndpoint:
    ## Internal loadbalancer for apiservers 
    # internalLoadbalancer: haproxy

    domain: lb.kubesphere.local
    address: ""
    port: 6443
  kubernetes:
    version: v1.18.6
    clusterName: cluster.local
  network:
    plugin: calico
    kubePodsCIDR: 10.233.64.0/18
    kubeServiceCIDR: 10.233.0.0/18
    ## multus support. https://github.com/k8snetworkplumbingwg/multus-cni
    multusCNI:
      enabled: false
  registry:
    plainHTTP: false
    privateRegistry: ""
    namespaceOverride: ""
    registryMirrors: []
    insecureRegistries: []
  addons: []


---
apiVersion: installer.kubesphere.io/v1alpha1
kind: ClusterConfiguration
metadata:
  name: ks-installer
  namespace: kubesphere-system
  labels:
    version: v3.0.0
spec:
  zone: ""
  local_registry: ""
  persistence:
    storageClass: ""
  authentication:
    jwtSecret: ""
  etcd:
    monitoring: true
    endpointIps: localhost
    port: 2379
    tlsEnable: true
  common:
    es:
      elasticsearchDataVolumeSize: 20Gi
      elasticsearchMasterVolumeSize: 4Gi
      elkPrefix: logstash
      logMaxAge: 7
    mysqlVolumeSize: 20Gi
    minioVolumeSize: 20Gi
    etcdVolumeSize: 20Gi
    openldapVolumeSize: 2Gi
    redisVolumSize: 2Gi
  console:
    enableMultiLogin: false  # enable/disable multi login
    port: 30880
  alerting:
    enabled: false
  auditing:
    enabled: false
  devops:
    enabled: false
    jenkinsMemoryLim: 2Gi
    jenkinsMemoryReq: 1500Mi
    jenkinsVolumeSize: 8Gi
    jenkinsJavaOpts_Xms: 512m
    jenkinsJavaOpts_Xmx: 512m
    jenkinsJavaOpts_MaxRAM: 2g
  events:
    enabled: false
    ruler:
      enabled: true
      replicas: 2
  logging:
    enabled: false
    logsidecarReplicas: 2
  metrics_server:
    enabled: true
  monitoring:
    prometheusMemoryRequest: 400Mi
    prometheusVolumeSize: 20Gi
  multicluster:
    clusterRole: none  # host | member | none
  networkpolicy:
    enabled: false
  notification:
    enabled: false
  openpitrix:
    enabled: false
  servicemesh:
    enabled: false

安装前配置：

1
2
3
4
5
6
7
8
9
10
11
12
## 指定服务器hostname
hostnamectl set-hostname master
## 关闭防火墙:
systemctl disable firewalld
## 关闭selinux:  (临时关闭 setenforce 0)
sed -i 's/enforcing/disabled/' /etc/selinux/config
## 关闭swap(临时关闭swapoff -a)
sed -ri 's/.*swap.*/#&/' /etc/fstab 

## 同步时间
yum install ntpdate -y
ntpdate time.windows.com

执行命令创建集群：

1
2
3
./kk create cluster -f config-sample.yaml
## 或者直接单机安装
./kk create cluster --with-kubesphere v3.0.0

image.png
安装过程比较耗时，中途可能出现安装失败的情况，可以使用该命令卸载再进行重装：

1
./kk delete cluster

安装成功后会有如下日志：
安装完成后执行指令：

1
kubectl get pod -A

image.png
根据日志访问网页：
image.png
image.png

kubekey 指令

  • 添加节点

kk add nodes -f config-sample.yaml

  • 删除节点

kk delete node -f config-sample.yaml

  • 删除集群

kk delete cluster
kk delete cluster [-f config-sample.yaml]

  • 集群升级

kk upgrade [–with-kubernetes version] [–with-kubesphere version]
kk upgrade [–with-kubernetes version] [–with-kubesphere version] [(-f | –file) path]

kubesphere 功能介绍

1）Kubernetes 资源管理
支持工作负载管理、镜像管理、服务与应用路由管理 (服务发现)、密钥配置管理等
image.png
2）微服务治理

  • 支持熔断、灰度发布、流量管控、限流、链路追踪、智能路由等完善的微服务治理功能，同时，支持代码无侵入的微服务治理

image.png
3）DevOps
基于 Jenkins 的可视化 CI / CD 流水线，支持从仓库 (GitHub / SVN / Git)、代码编译、镜像制作、镜像安全、推送仓库、版本发布、到定时构建的端到端流水线设置
image.png
4）监控
image.png
5）应用管理与编排
使用开源的OpenPitrix提供应用商店和应用仓库服务，提供应用全生命周期管理功能
image.png

结语

k8s系列在这一篇算是终结了，下一篇会写普罗米修斯相关的文章，然后之后按照计划就是写我的 poseidon 项目了，目前对自己的要求就是一周一更新。

展开全文 >>

一起来学redis redission

redis 的客户端有jedis、lettuce、redission；我个人比较推荐的是redission，因为它的分布式锁和缓存实在是太优秀了。 Redisson采用了基于NIO的Netty框架，封装了大家常用的集合类以及原子类、锁等工具。
本章节主要介绍redission 中重要的两个点：数据结构和锁

本章节主要介绍redission 中重要的两个点：数据结构和锁

map

基于Redis的Redisson的分布式映射结构的RMap Java对象实现了java.util.concurrent.ConcurrentMap接口和java.util.Map接口。与HashMap不同的是，RMap保持了元素的插入顺序。
在特定的场景下，映射缓存（Map）上的高度频繁的读取操作，使网络通信都被视为瓶颈时，可以使用Redisson提供的带有本地缓存功能的映射。

代码示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
RMap<String, SomeObject> map = redisson.getMap("anyMap");
SomeObject prevObject = map.put("123", new SomeObject());
SomeObject currentObject = map.putIfAbsent("323", new SomeObject());
SomeObject obj = map.remove("123");

map.fastPut("321", new SomeObject());
map.fastRemove("321");

RFuture<SomeObject> putAsyncFuture = map.putAsync("321");
RFuture<Void> fastPutAsyncFuture = map.fastPutAsync("321");

map.fastPutAsync("321", new SomeObject());
map.fastRemoveAsync("321");

map本身也是可以上锁的：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
RMap<MyKey, MyValue> map = redisson.getMap("anyMap");
MyKey k = new MyKey();
RLock keyLock = map.getLock(k);
keyLock.lock();
try {
   MyValue v = map.get(k);
   // 其他业务逻辑
} finally {
   keyLock.unlock();
}

RReadWriteLock rwLock = map.getReadWriteLock(k);
rwLock.readLock().lock();
try {
   MyValue v = map.get(k);
   // 其他业务逻辑
} finally {
   keyLock.readLock().unlock();
}

map中还有元素淘汰，本地缓存和数据分片等机制相关类：

  • 元素淘汰（Eviction） 类 – 带有元素淘汰（Eviction）机制的映射类允许针对一个映射中每个元素单独设定 有效时间 和 最长闲置时间 。

  • 本地缓存（LocalCache） 类 – 本地缓存（Local Cache）也叫就近缓存（Near Cache）。这类映射的使用主要用于在特定的场景下，映射缓存（MapCache）上的高度频繁的读取操作，使网络通信都被视为瓶颈的情况。Redisson与Redis通信的同时，还将部分数据保存在本地内存里。这样的设计的好处是它能将读取速度提高最多 45倍 。 所有同名的本地缓存共用一个订阅发布话题，所有更新和过期消息都将通过该话题共享。

  • 数据分片（Sharding） 类 – 数据分片（Sharding）类仅适用于Redis集群环境下，因此带有数据分片（Sharding）功能的映射也叫集群分布式映射。它利用分库的原理，将单一一个映射结构切分为若干个小的映射，并均匀的分布在集群中的各个槽里。这样的设计能使一个单一映射结构突破Redis自身的容量限制，让其容量随集群的扩大而增长。在扩容的同时，还能够使读写性能和元素淘汰处理能力随之成线性增长。

map 类：

Redisson的分布式的RMapCache Java对象在基于RMap的前提下实现了针对单个元素的淘汰机制，这种功能是其他两个redis客户端所不能具备的。
Redis自身并不支持散列（Hash）当中的元素淘汰，因此所有过期元素都是通过org.redisson.EvictionScheduler实例来实现定期清理的。为了保证资源的有效利用，每次运行最多清理300个过期元素。任务的启动时间将根据上次实际清理数量自动调整，间隔时间趋于1秒到1小时之间。比如该次清理时删除了300条元素，那么下次执行清理的时间将在1秒以后（最小间隔时间）。一旦该次清理数量少于上次清理数量，时间间隔将增加1.5倍。

1
2
3
4
5
6
7
8
9
10
RMapCache<String, SomeObject> map = redisson.getMapCache("anyMap");
// 有效时间 ttl = 10分钟
map.put("key1", new SomeObject(), 10, TimeUnit.MINUTES);
// 有效时间 ttl = 10分钟, 最长闲置时间 maxIdleTime = 10秒钟
map.put("key1", new SomeObject(), 10, TimeUnit.MINUTES, 10, TimeUnit.SECONDS);

// 有效时间 = 3 秒钟
map.putIfAbsent("key2", new SomeObject(), 3, TimeUnit.SECONDS);
// 有效时间 ttl = 40秒钟, 最长闲置时间 maxIdleTime = 10秒钟
map.putIfAbsent("key2", new SomeObject(), 40, TimeUnit.SECONDS, 10, TimeUnit.SECONDS);

本地缓存功能充分的利用了JVM的自身内存空间，对部分常用的元素实行就地缓存，这样的设计让读取操作的性能较分布式映射相比提高最多 45倍 。以下配置参数可以用来创建这个实例：

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
LocalCachedMapOptions options = LocalCachedMapOptions.defaults()
      // 用于淘汰清除本地缓存内的元素
      // 共有以下几种选择:
      // LFU - 统计元素的使用频率，淘汰用得最少（最不常用）的。
      // LRU - 按元素使用时间排序比较，淘汰最早（最久远）的。
      // SOFT - 元素用Java的WeakReference来保存，缓存元素通过GC过程清除。
      // WEAK - 元素用Java的SoftReference来保存, 缓存元素通过GC过程清除。
      // NONE - 永不淘汰清除缓存元素。
     .evictionPolicy(EvictionPolicy.NONE)
     // 如果缓存容量值为0表示不限制本地缓存容量大小
     .cacheSize(1000)
      // 以下选项适用于断线原因造成了未收到本地缓存更新消息的情况。
      // 断线重连的策略有以下几种：
      // CLEAR - 如果断线一段时间以后则在重新建立连接以后清空本地缓存
      // LOAD - 在服务端保存一份10分钟的作废日志
      //        如果10分钟内重新建立连接，则按照作废日志内的记录清空本地缓存的元素
      //        如果断线时间超过了这个时间，则将清空本地缓存中所有的内容
      // NONE - 默认值。断线重连时不做处理。
     .reconnectionStrategy(ReconnectionStrategy.NONE)
      // 以下选项适用于不同本地缓存之间相互保持同步的情况
      // 缓存同步策略有以下几种：
      // INVALIDATE - 默认值。当本地缓存映射的某条元素发生变动时，同时驱逐所有相同本地缓存映射内的该元素
      // UPDATE - 当本地缓存映射的某条元素发生变动时，同时更新所有相同本地缓存映射内的该元素
      // NONE - 不做任何同步处理
     .syncStrategy(SyncStrategy.INVALIDATE)
      // 每个Map本地缓存里元素的有效时间，默认毫秒为单位
     .timeToLive(10000)
      // 或者
     .timeToLive(10, TimeUnit.SECONDS)
      // 每个Map本地缓存里元素的最长闲置时间，默认毫秒为单位
     .maxIdle(10000)
      // 或者
     .maxIdle(10, TimeUnit.SECONDS);

     RLocalCachedMap<String, Integer> map = redisson.getLocalCachedMap("test", options);

String prevObject = map.put("123", 1);
String currentObject = map.putIfAbsent("323", 2);
String obj = map.remove("123");

// 在不需要旧值的情况下可以使用fast为前缀的类似方法
map.fastPut("a", 1);
map.fastPutIfAbsent("d", 32);
map.fastRemove("b");

RFuture<String> putAsyncFuture = map.putAsync("321");
RFuture<Void> fastPutAsyncFuture = map.fastPutAsync("321");

map.fastPutAsync("321", new SomeObject());
map.fastRemoveAsync("321");
// 当不再使用Map本地缓存对象的时候应该手动销毁，如果Redisson对象被关闭（shutdown）了，则不用手动销毁。
map.destroy();

RClusteredMap 分片map使用示例：

1
2
3
4
5
6
7
8
RClusteredMap<String, SomeObject> map = redisson.getClusteredMap("anyMap");

SomeObject prevObject = map.put("123", new SomeObject());
SomeObject currentObject = map.putIfAbsent("323", new SomeObject());
SomeObject obj = map.remove("123");

map.fastPut("321", new SomeObject());
map.fastRemove("321");

映射监听器（Map Listener）可以监听map的活动，代码示例：

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
RMapCache<String, Integer> map = redisson.getMapCache("myMap");
// 或
RLocalCachedMapCache<String, Integer> map = redisson.getLocalCachedMapCache("myMap", options);

int updateListener = map.addListener(new EntryUpdatedListener<Integer, Integer>() {
     @Override
     public void onUpdated(EntryEvent<Integer, Integer> event) {
          event.getKey(); // 字段名
          event.getValue() // 新值
          event.getOldValue() // 旧值
          // ...
     }
});

int createListener = map.addListener(new EntryCreatedListener<Integer, Integer>() {
     @Override
     public void onCreated(EntryEvent<Integer, Integer> event) {
          event.getKey(); // 字段名
          event.getValue() // 值
          // ...
     }
});

int expireListener = map.addListener(new EntryExpiredListener<Integer, Integer>() {
     @Override
     public void onExpired(EntryEvent<Integer, Integer> event) {
          event.getKey(); // 字段名
          event.getValue() // 值
          // ...
     }
});

int removeListener = map.addListener(new EntryRemovedListener<Integer, Integer>() {
     @Override
     public void onRemoved(EntryEvent<Integer, Integer> event) {
          event.getKey(); // 字段名
          event.getValue() // 值
          // ...
     }
});

map.removeListener(updateListener);
map.removeListener(createListener);
map.removeListener(expireListener);
map.removeListener(removeListener);

Set

代码示例：

1
2
3
RSet<SomeObject> set = redisson.getSet("anySet");
set.add(new SomeObject());
set.remove(new SomeObject());

基于Redis的Redisson的分布式RSetCache Java对象在基于RSet的前提下实现了针对单个元素的淘汰机制。和map 一样，所有过期元素都是通过org.redisson.EvictionScheduler实例来实现定期清理的。代码示例：

1
2
3
RSetCache<SomeObject> set = redisson.getSetCache("anySet");
// ttl = 10 seconds
set.add(new SomeObject(), 10, TimeUnit.SECONDS);

分布式RClusteredSet:

1
2
3
RClusteredSet<SomeObject> set = redisson.getClusteredSet("anySet");
set.add(new SomeObject());
set.remove(new SomeObject());

有序集（SortedSet):

1
2
3
4
5
6
7
8
RSortedSet<Integer> set = redisson.getSortedSet("anySet");
set.trySetComparator(new MyComparator()); // 配置元素比较器
set.add(3);
set.add(1);
set.add(2);

set.removeAsync(0);
set.addAsync(5);

计分排序集（ScoredSortedSet)是一个可以按插入时指定的元素评分排序的集合:

1
2
3
4
5
6
7
8
9
10
11
RScoredSortedSet<SomeObject> set = redisson.getScoredSortedSet("simple");

set.add(0.13, new SomeObject(a, b));
set.addAsync(0.251, new SomeObject(c, d));
set.add(0.302, new SomeObject(g, d));

set.pollFirst();
set.pollLast();

int index = set.rank(new SomeObject(g, d)); // 获取元素在集合中的位置
Double score = set.getScore(new SomeObject(g, d)); // 获取元素的评分

List

RList 示例：

1
2
3
4
RList<SomeObject> list = redisson.getList("anyList");
list.add(new SomeObject());
list.get(0);
list.remove(new SomeObject());

Queue

无界队列Queue：

1
2
3
4
RQueue<SomeObject> queue = redisson.getQueue("anyQueue");
queue.add(new SomeObject());
SomeObject obj = queue.peek();
SomeObject someObj = queue.poll();

双端队列（Deque）:

1
2
3
4
5
RDeque<SomeObject> queue = redisson.getDeque("anyDeque");
queue.addFirst(new SomeObject());
queue.addLast(new SomeObject());
SomeObject obj = queue.removeFirst();
SomeObject someObj = queue.removeLast();

阻塞队列（Blocking Queue）：

1
2
3
4
5
6
RBlockingQueue<SomeObject> queue = redisson.getBlockingQueue("anyQueue");
queue.offer(new SomeObject());

SomeObject obj = queue.peek();
SomeObject someObj = queue.poll();
SomeObject ob = queue.poll(10, TimeUnit.MINUTES);

有界阻塞队列（Bounded Blocking Queue）:

1
2
3
4
5
6
7
8
9
10
11
12
13
RBoundedBlockingQueue<SomeObject> queue = redisson.getBoundedBlockingQueue("anyQueue");
// 如果初始容量（边界）设定成功则返回`真（true）`，
// 如果初始容量（边界）已近存在则返回`假（false）`。
queue.trySetCapacity(2);

queue.offer(new SomeObject(1));
queue.offer(new SomeObject(2));
// 此时容量已满，下面代码将会被阻塞，直到有空闲为止。
queue.put(new SomeObject());

SomeObject obj = queue.peek();
SomeObject someObj = queue.poll();
SomeObject ob = queue.poll(10, TimeUnit.MINUTES);

阻塞双端队列（Blocking Deque）:

1
2
3
4
5
6
7
RBlockingDeque<Integer> deque = redisson.getBlockingDeque("anyDeque");
deque.putFirst(1);
deque.putLast(2);
Integer firstValue = queue.takeFirst();
Integer lastValue = queue.takeLast();
Integer firstValue = queue.pollFirst(10, TimeUnit.MINUTES);
Integer lastValue = queue.pollLast(3, TimeUnit.MINUTES);

阻塞公平队列（Blocking Fair Queue）：

1
2
3
4
5
6
RBlockingFairQueue queue = redisson.getBlockingFairQueue("myQueue");
queue.offer(new SomeObject());

SomeObject obj = queue.peek();
SomeObject someObj = queue.poll();
SomeObject ob = queue.poll(10, TimeUnit.MINUTES);

阻塞公平双端队列（Blocking Fair Deque）:

1
2
3
4
5
6
7
8
9
10
11
12
RBlockingFairDeque deque = redisson.getBlockingFairDeque("myDeque");
deque.offer(new SomeObject());

SomeObject firstElement = queue.peekFirst();
SomeObject firstElement = queue.pollFirst();
SomeObject firstElement = queue.pollFirst(10, TimeUnit.MINUTES);
SomeObject firstElement = queue.takeFirst();

SomeObject lastElement = queue.peekLast();
SomeObject lastElement = queue.pollLast();
SomeObject lastElement = queue.pollLast(10, TimeUnit.MINUTES);
SomeObject lastElement = queue.takeLast();

延迟队列（Delayed Queue）:

1
2
3
4
5
6
7
8
9
 RQueue<String> distinationQueue = ...
RDelayedQueue<String> delayedQueue = getDelayedQueue(distinationQueue);
// 10秒钟以后将消息发送到指定队列
delayedQueue.offer("msg1", 10, TimeUnit.SECONDS);
// 一分钟以后将消息发送到指定队列
delayedQueue.offer("msg2", 1, TimeUnit.MINUTES);

// 在该对象不再需要的情况下，应该主动销毁。仅在相关的Redisson对象也需要关闭的时候可以不用主动销毁。
delayedQueue.destroy();

优先队列（Priority Queue）,可以通过比较器（Comparator）接口来对元素排序:

1
2
3
4
5
6
7
8
9
10
 RPriorityQueue<Integer> queue = redisson.getPriorityQueue("anyQueue");
queue.trySetComparator(new MyComparator()); // 指定对象比较器
queue.add(3);
queue.add(1);
queue.add(2);

queue.removeAsync(0);
queue.addAsync(5);

queue.poll();

看门狗

如果负责储存分布式锁的Redisson节点宕机以后，而且这个锁正好处于锁住的状态时，这个锁会出现锁死的状态。为了避免这种情况的发生，Redisson内部提供了一个监控锁的看门狗，它的作用是在Redisson实例被关闭前，不断的延长锁的有效期，默认情况下，看门狗的检查锁的超时时间是30秒钟，也可以通过修改Config.lockWatchdogTimeout来另行指定。

可重入锁（Reentrant Lock）

1
2
3
 RLock lock = redisson.getLock("anyLock");
// 最常见的使用方法
lock.lock();

Redisson还通过加锁的方法提供了leaseTime的参数来指定加锁的时间。超过这个时间后锁便自动解开:

1
2
3
4
5
6
7
8
9
10
11
12
13
 // 加锁以后10秒钟自动解锁
// 无需调用unlock方法手动解锁
lock.lock(10, TimeUnit.SECONDS);

// 尝试加锁，最多等待100秒，上锁以后10秒自动解锁
boolean res = lock.tryLock(100, 10, TimeUnit.SECONDS);
if (res) {
   try {
     ...
   } finally {
       lock.unlock();
   }
}

异步执行：

1
2
3
4
5
 RLock lock = redisson.getLock("anyLock");
lock.lockAsync();
lock.lockAsync(10, TimeUnit.SECONDS);
Future<Boolean> res = lock.tryLockAsync(100, 10, TimeUnit.SECONDS);

公平锁（Fair Lock）

当多个Redisson客户端线程同时请求加锁时，优先分配给先发出请求的线程,所有请求线程会在一个队列中排队。当某个线程出现宕机，Redisson会等待5秒后继续下一个线程：

1
2
3
 RLock fairLock = redisson.getFairLock("anyLock");
// 最常见的使用方法
fairLock.lock();

联锁（MultiLock）

基于Redis的Redisson分布式联锁RedissonMultiLock对象可以将多个RLock对象关联为一个联锁，每个RLock对象实例可以来自于不同的Redisson实例:

1
2
3
4
5
6
7
8
9
10
 RLock lock1 = redissonInstance1.getLock("lock1");
RLock lock2 = redissonInstance2.getLock("lock2");
RLock lock3 = redissonInstance3.getLock("lock3");

RedissonMultiLock lock = new RedissonMultiLock(lock1, lock2, lock3);
// 同时加锁：lock1 lock2 lock3
// 所有的锁都上锁成功才算成功。
lock.lock();
...
lock.unlock();

红锁（RedLock）

红锁RedissonRedLock对象可以用来将多个RLock对象关联为一个红锁，每个RLock对象实例可以来自于不同的Redisson实例：

1
2
3
4
5
6
7
8
9
10
 RLock lock1 = redissonInstance1.getLock("lock1");
RLock lock2 = redissonInstance2.getLock("lock2");
RLock lock3 = redissonInstance3.getLock("lock3");

RedissonRedLock lock = new RedissonRedLock(lock1, lock2, lock3);
// 同时加锁：lock1 lock2 lock3
// 红锁在大部分节点上加锁成功就算成功。
lock.lock();
...
lock.unlock();

信号量（Semaphore）

同JDK中的信号量：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
RSemaphore semaphore = redisson.getSemaphore("semaphore");
semaphore.acquire();
//或
semaphore.acquireAsync();
semaphore.acquire(23);
semaphore.tryAcquire();
//或
semaphore.tryAcquireAsync();
semaphore.tryAcquire(23, TimeUnit.SECONDS);
//或
semaphore.tryAcquireAsync(23, TimeUnit.SECONDS);
semaphore.release(10);
semaphore.release();
//或
semaphore.releaseAsync();

可过期信号量，是在RSemaphore对象的基础上，为每个信号增加了一个过期时间：

1
2
3
4
5
6
RPermitExpirableSemaphore semaphore = redisson.getPermitExpirableSemaphore("mySemaphore");
String permitId = semaphore.acquire();
// 获取一个信号，有效期只有2秒钟。
String permitId = semaphore.acquire(2, TimeUnit.SECONDS);
// ...
semaphore.release(permitId);

闭锁（CountDownLatch）

同jdk中的闭锁：

1
2
3
4
5
6
7
RCountDownLatch latch = redisson.getCountDownLatch("anyCountDownLatch");
latch.trySetCount(1);
latch.await();

// 在其他线程或其他JVM里
RCountDownLatch latch = redisson.getCountDownLatch("anyCountDownLatch");
latch.countDown();

展开全文 >>

redis-持久化原理

redis持久化方式有两种，一种是RDB，一种是aof。
RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘。
AOF持久化以日志的形式记录服务器所处理的每一个写操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录。

RDB

有两个Redis命令可以用于生成RDB文件–SAVE和BGSAVE。SAVE命令会阻塞Redis服务器进程，直到RDB文件创建完毕为止，在服务器进程阻塞期间，服务器不能处理任何命令请求。

和SAVE命令直接阻塞服务器进程的做法不同，BGSAVE命令fork一个子进程，然后由子进程负责创建RDB文件，服务器进程继续处理命令请求。

创建RDB文件的实际工作由rdb.c/rdbSave函数完成，SAVE命令和BGSAVE命令会以不同的方式调用这个函数，源码：

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
/* Save the DB on disk. Return C_ERR on error, C_OK on success. */
int rdbSave(char *filename, rdbSaveInfo *rsi) {
    // 当前工作目录
    char tmpfile[256];
    char cwd[MAXPATHLEN]; /* Current working dir path for error messages. */
    FILE *fp;
    rio rdb;
    int error = 0;
    // 生成tmp文件
    snprintf(tmpfile,256,"temp-%d.rdb", (int) getpid());
    fp = fopen(tmpfile,"w");
    if (!fp) {
        char *cwdp = getcwd(cwd,MAXPATHLEN);
        serverLog(LL_WARNING,
            "Failed opening the RDB file %s (in server root dir %s) "
            "for saving: %s",
            filename,
            cwdp ? cwdp : "unknown",
            strerror(errno));
        return C_ERR;
    }
    // 初始化rio 结构
    rioInitWithFile(&rdb,fp);
    if (rdbSaveRio(&rdb,&error,RDB_SAVE_NONE,rsi) == C_ERR) {
        errno = error;
        goto werr;
    }

    /* Make sure data will not remain on the OS's output buffers */
    if (fflush(fp) == EOF) goto werr;
    if (fsync(fileno(fp)) == -1) goto werr;
    if (fclose(fp) == EOF) goto werr;

    /* Use RENAME to make sure the DB file is changed atomically only
     * if the generate DB file is ok. */
    if (rename(tmpfile,filename) == -1) {
        // 异常处理逻辑
        .... 
    }

    serverLog(LL_NOTICE,"DB saved on disk");
    // 清理数据保存记录
    server.dirty = 0;
    // 最后一次完成 SAVE 命令的时间
    server.lastsave = time(NULL);
    // 最后一次 bgsave 的状态置位 成功
    server.lastbgsave_status = C_OK;
    return C_OK;
    // 其他代码
    ....
}

它的大致流程如下：

  1. 首先打开一个临时文件，
  2. 调用 rdbSaveRio函数，将当前 Redis 的内存信息写入到这个临时文件中，
  3. 接着调用 fflush、fsync 和 fclose 接口将文件写入磁盘中，
  4. 使用 rename 将临时文件改名为 正式的 RDB 文件，
  5. 最后记录 dirty 和 lastsave等状态信息。

RDB文件保存的是二进制数据，文件结构如图所示：

RDB文件的最开头是REDIS部分，保存着“REDIS”五个字符，程序在载入RDB文件时会校验这个头数据以判断是不是RDB文件。
db_version长度为4字节，它的值是一个字符串表示的整数，这个整数记录了RDB文件的版本号。
databases部分包含着零个或任意多个数据库，以及各个数据库中的键值对数据。
EOF常量的长度为1字节，这个常量标志着RDB文件正文内容的结束，当程序读取到这个值的时候就表示所有数据已经读取完毕了。
check_sum是一个8字节长的无符号整数，保存着一个校验和，这个校验和是程序通过对REDIS、db_version、databases、EOF四个部分的内容进行计算得出的。
服务器在载入RDB文件时，会将载入数据所计算出的校验和与check_sum所记录的校验和进行对比，以此来检查RDB文件是否有出错或者损坏的情况出现。

AOF

AOF持久化是通过保存Redis服务器所执行的写命令来记录数据库状态的，类似于mysql 的binlog。
AOF持久化保存数据库状态的方法是将服务器执行的SET、SADD、RPUSH等命令保存到AOF文件中，其过程大致如下：

  1. 命令追加：当AOF持久化功能处于打开状态时，服务器在执行完一个写命令之后，会将写命令追加到服务器状态的aof_buf缓冲区的末尾；
  2. AOF文件的写入与同步：服务器每次结束一个事件循环之前，它都会调用flushAppendOnlyFile函数来判断是否将aof_buf缓冲区中的内容写入和保存到AOF文件里面

AOF也有不同的触发方案，这里简要描述以下三种触发方案：

  • always：每次发生数据修改就会立即记录到磁盘文件中，这种方案的完整性好但是IO开销很大，性能较差；
  • everysec：在每一秒中进行同步，速度有所提升。但是如果在一秒内宕机的话可能失去这一秒内的数据；
  • no：默认配置，即不使用 AOF 持久化方案。

我们看一下flushAppendOnlyFile的注释：

大致意思是解释了刷盘时机以及force参数的含义及作用。

AOF日志文件会随着redis运行变得越来越大，如果服务器宕机重启，那么载入AOF文件就会很耗时。在AOF文件中有很多记录是可以被优化掉的，比如我现在将一个数据 incr 一千次，那么就不需要去记录这1000次修改，只需要记录最后的值即可，所以就需要进行 AOF 重写。Redis 提供了bgrewriteaof指令用于对AOF日志进行重写，该指令会拉起一个子进程对内存进行进行遍历并转换为一系列redis指令，最后保存到一个日志文件中并替换掉原有AOF文件。

随着Redis的运行，AOF的日志会越来越长，如果实例宕机重启，那么重放整个AOF将会变得十分耗时，而在日志记录中，又有很多无意义的记录，比如我现在将一个数据 incr 一千次，那么就不需要去记录这1000次修改，只需要记录最后的值即可。所以就需要进行 AOF 重写。同样的也可以在redis.config中对重写机制的触发进行配置：

1
2
3
4
### 开启重写机制
no-appendfsync-on-rewrite yes
### 比上次从写后文件大小增长了100%再次触发重写
auto-aof-rewrite-percentage 100

两种持久化的优劣对比

AOF 优势：

  • AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易被人读懂， 对文件进行分析（parse）也很轻松。
  • AOF 数据持久性更好，该机制对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。

AOF 劣势：

  • 由于AOF采用的是日志记录，因此同样的数据集，AOF文件要大于RDB
  • 根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。

RDB 优势：

  • RDB 是一个非常紧凑的保存的二进制数据的文件，它保存了 Redis 在某个时间点上的数据集，极大节省了空间。
  • RDB对容灾恢复友好，可将RDB传输拷贝到其他redis服务器进行恢复
  • RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快

RDB劣势：

  • 如果业务上需要尽量避免在服务器故障时丢失数据，那么 RDB 并不适合。
  • RDB进行持久化时会fork一个子进程，在数据集比较庞大时， fork可能会非常耗时，造成服务器不响应其他请求

在进行容灾恢复时，如果使用 RDB 来恢复内存状态，可能会会丢失大量数据。
而如果只使用 AOF 效率又很低。Redis 4.0 提供了混合持久化方案，将 RDB 文件的内容和增量的 AOF日志文件存在一起。
这里的 AOF 日志不再是全量的日志，而是自 RDB 持久化开始到持久化结束这段时间发生的增量 AOF 日志，通常这部分日志很小。
当进行容灾恢复或redis重启的时候，就可以先加载RDB数据，然后AOF日志补全RDB数据以达到高性能可靠的备份恢复。

展开全文 >>

redis 数据库结构

redis数据库结构介绍

在redis源码中数据库的结构由server.h/redisDb表示，
redisDb结构的dict字典保存了数据库中的所有键值对，我们将这个字典称为键空间（key space），redisDb源码：

1
2
3
4
5
6
7
8
9
typedef struct redisDb {
    dict *dict;                 /* The keyspace for this DB */
    dict *expires;              /* Timeout of keys with a timeout set */
    dict *blocking_keys;        /* Keys with clients waiting for data (BLPOP)*/
    dict *ready_keys;           /* Blocked keys that received a PUSH */
    dict *watched_keys;         /* WATCHED keys for MULTI/EXEC CAS */
    int id;                     /* Database ID */
    long long avg_ttl;          /* Average TTL, just for stats */
} redisDb;

源码中redisDb拥有字典属性dict，字典中存储了数据库中的键，为字符串类型的redisObject。这个redisObject中的ptr属性指向值的redisObject，结构示意图：

键空间的维护

当使用Redis命令对数据库进行读写时，服务器不仅会对键空间执行指定的读写操作，还会执行一些额外的维护操作：

  1. 在读取一个键之后（读操作和写操作都要对键进行读取），服务器会根据键是否存在来更新服务器的键空间命中（hit）次数或键空间不命中（miss）次数，这两个值可以在INFO stats命令的keyspace_hits属性和keyspace_misses属性中查看。
  2. 在读取一个键之后，服务器会更新键的LRU值，关于这个值我们在上一章节已经介绍过了；
  3. 如果有客户端使用WATCH命令监视了某个键，那么服务器在对被监视的键进行修改之后，会将这个键标记为脏（dirty），从而让事务程序注意到这个键已经被修改过
  4. 如果服务器开启了数据库通知功能，那么在对键进行修改之后，服务器将按配置发送相应的数据库通知

键的过期时间

通过EXPIRE命令或者PEXPIRE命令可以设置键的过期时间，那么在数据库中这个过期时间是怎么维护的呢？redisDb结构体中有一个字典属性expires便是用来保存键的过期时间的，
我们称这个字典为过期字典。过期字典的键是一个指针，指向键空间中的键；过期字典的值是一个long类型的数，记录了过期时间的时间戳。当客户端执行PEXPIREAT命令，服务器会在数据库的过期字典中关联给定的数据库键和过期时间。

如果现在给key设置一个过期时间，在过期时间到的时候，Redis是如何清除这个key的呢？Redis 中提供了三种过期删除的策略:

  • 定时删除：在设置某个 key 的过期时间同时，我们创建一个定时器，让定时器在该过期时间到来时，立即执行对其进行删除的操作；
  • 惰性删除：当一个键值对过期的时候，只有再次用到这个键值对的时候才去检查删除这个键值对；
  • 定期删除：采样一定个数的key 判断过期比例，并删除过期键，当过期比例不达标则重新采样删除，直到达标。

Redis 中实际采用的策略是惰性删除加定期删除的组合方式，服务器会定期清除掉一部分过期的key，对于那些未清除到的过期key，会在获取这个key的时候进行判断是否过期，过期则删除。
惰性删除会带来一个问题就是当从从库获取一个过期key的时候从库是否应该删除这个key呢？如果一个主库创建的过期键值对，已经过期了，主库在进行定期删除的时候，没有及时的删除掉，这时候从库请求了这个键值对，当执行惰性删除的时候，因为是主库创建的键值对，这时候是不能在从库中删除的。从库会通过惰性删除来判断键值对的是否过期，如果过期则读不到这个键，真正的删除是当主节点触发键过期时，主节点会同步一个del命令给所有的从节点。

我们知道redis 持久化策略中包括RDB持久化功能、AOF持久化，这两种持久化对过期未删除的键处理也是有区别的。RDB持久话不会保存过期未删除的键，而AOF持久化当过期键被惰性删除或者定期删除之后，程序会向AOF文件追加一条DEL命令，来显式地记录该键已被删除。

阻塞

在 Redis 命令中，有一些命令是阻塞模式的，BRPOP, BLPOP, BRPOPLPUSH, 这些命令都有可能造成客户端的阻塞。比如向客户端发来一个blpop key命令，redis先找到对应的key的list，如果list不为空则pop一个数据返回给客户端；如果对应的list不存在或者里面没有数据，就将该key添加到redisDb 的blockling_keys的字典中，value就是想订阅该key的client链表。并将对应的客户端标记为阻塞。
如果客户端发来一个repush key value命令，先从redisDb的blocking_keys中查找是否存在对应的key，如果存在就往redisDb的ready_keys这个链表中添加该key；同时将value插入到对应的list中，并响应客户端。redis处理完客户端命令后都会遍历ready_keys和blockling_keys来筛选出需要pop出的clinet。因此，redis客户端的阻塞是通过ready_keys和blockling_keys联合来实现的，blockling_keys 记录阻塞中的key和客户端，ready_keys记录数据已准备好的key。

展开全文 >>

一起来学redis-redisObject

前文我们看过redisObject的源码：

1
2
3
4
5
6
7
8
9
typedef struct redisObject {
    unsigned type:4;
    unsigned encoding:4;
    unsigned lru:LRU_BITS; /* LRU time (relative to global lru_clock) or
                            * LFU data (least significant 8 bits frequency
                            * and most significant 16 bits access time). */
    int refcount;
    void *ptr;
} robj;

下面我们来了解redisObject相关机制

TYPE与命令多态

我们知道redis的键和值都是以redisObject的形式保存的，而键总是一个字符串对象，而值则可以是字符串对象、列表对象、哈希对象、集合对象或者有序集合对象的其中一种。我们执行TYPE指令可以查看键对应的值的属性：

1
2
redis>TYPE test
hash

这个指令就是查看redisObject中的type属性类型，前文我们也提到过对象的类型包括string，list，hash，set,zset。
我们知道del、expire、remane、type等命令是可以使用在各种类型的redisObject上的，而类似lpush、llen等指令就只能用在对应的type上，比如对string类型的redisObject使用llen 结果将会这样：

1
2
redis>llen test
"WRONGTYPE Operation against a key holding the wrong kind of value"

为了确保只有指定类型的键可以执行某些特定的命令，在执行一个类型特定的命令之前，Redis会先检查输入键的类型是否正确，然后再决定是否执行给定的命令。
在执行一个类型特定命令之前，服务器会先检查输入数据库键的值对象的type属性是否为执行命令所需的类型，如果是的话服务器就对键执行指定的命令，否则就抛出警告。

refcount

为了实现类似jvm的内存回收机制，Redis在自己的对象中添加了一个引用计数属性–refcount，通过这个值程序可以在适当的时候自动释放对象并进行内存回收。
对象的引用计数值随着redisObject生命周期的变化：

  • 在创建一个新对象时，引用计数的值会被初始化为1；
  • 当对象被一个新程序使用时，它的引用计数值会被增一；
  • 当对象不再被一个程序使用时，它的引用计数值会被减一；
  • 当对象的引用计数值变为0时，对象所占用的内存会被释放。

对象的整个生命周期可以划分为创建对象、操作对象、释放对象三个阶段。

除了用于实现引用计数内存回收机制之外，对象的引用计数属性还带有对象共享的作用。
假如 A键存储一个”1000”的整数值字符串对象，同时B键也存储了一个”1000”的整数值字符串对象，此时reids只会创建一个”1000”的整数值字符串对象，而它的引用计数会增一。
也就是说到多个key之间可以共享一个对象的时候，只会创建一个对象，而引用计数会相应的增一，另外这种优化只针对整数值字符串对象。目前来说，Redis会在初始化服务器时，创建一万个字符串对象，这些对象包含了从0到9999的所有整数值，当服务器需要用到值为0到9999的字符串对象时，服务器就会使用这些共享对象，而不是新创建对象。object refcount指令是可以查看对象的引用数的，下面我们来做一个实验验证：

1
2
3
4
5
6
7
8
9
10
11
local:0>set a1 100
"OK"

local:0>object refcount a1
"2"

local:0>set a2 100
"OK"

local:0>object refcount a1
"3"

第一次set a1 时查看引用计数是2，引用这个值对象的两个程序分别是持有这个值对象的服务器程序，以及共享这个值对象的键a1。
第二次set a2 同样的值发现对象的引用计数变成了3，和我们的理论是一致的。然后我们验证一下字符串：

1
2
3
4
5
6
7
8
9
10
11
12
local:0>set b1 xxxx
"OK"

local:0>object refcount b1
"1"

local:0>set b2 xxxx
"OK"

local:0>object refcount b2
"1"

我们发现字符串类型之间不存在对象共享，因为字符串的对象共享的验证计算成本比较高，redis出于性能考虑不对字符串类型的对象进行共享。

lru

redisObject的lru属性，该属性记录了对象最后一次被命令程序访问的时间。查看这个属性的指令为object idletime，这个命令在访问键的值对象时，不会修改值对象的lru属性：

1
2
3
4
5
local:0>object idletime b1
"556"

local:0>object idletime b1
"568"

如果redis服务器打开了maxmemory选项，并且服务器用于回收内存的算法为volatile-lru或者allkeys-lru，那么当服务器占用的内存数超过了maxmemory选项所设置的上限值时，空转时长较高的那部分键会优先被服务器释放，从而回收内存。db.c 中有一个 lookupKey 方法：

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
/* Low level key lookup API, not actually called directly from commands
 * implementations that should instead rely on lookupKeyRead(),
 * lookupKeyWrite() and lookupKeyReadWithFlags(). */
robj *lookupKey(redisDb *db, robj *key, int flags) {
    dictEntry *de = dictFind(db->dict,key->ptr);
    if (de) {
        robj *val = dictGetVal(de);

        /* Update the access time for the ageing algorithm.
         * Don't do it if we have a saving child, as this will trigger
         * a copy on write madness. */
        if (server.rdb_child_pid == -1 &&
            server.aof_child_pid == -1 &&
            !(flags & LOOKUP_NOTOUCH))
        {
            if (server.maxmemory_policy & MAXMEMORY_FLAG_LFU) {
                updateLFU(val);
            } else {
                val->lru = LRU_CLOCK();
            }
        }
        return val;
    } else {
        return NULL;
    }
}

每次按key获取一个值的时候，都会调用lookupKey函数,如果配置使用了lru模式,该函数会更新value中的lru字段为当前秒级别的时间戳。虽然记录了redisObject的时间戳，但淘汰键时肯定不能遍历比较这个lru值，
这样做计算量太大。实际上redis是这样干的：

  1. 随机选取N个key，放入一个pool中(pool的大小为16),pool中的key是按lru大小顺序排列的。
  2. 接下来每次随机选取的keylru值必须小于pool中最小的lru才会继续放入，直到将pool放满。
  3. 放满之后，每次如果有新的key需要放入，需要将pool中lru最大的一个key取出。
  4. 淘汰的时候，直接从pool中选取一个lru最小的值然后将其淘汰。

实际上redis 淘汰策略还有一个lfu算法，该算法采用的是通过记录key的访问次数来选择需要淘汰的key，感兴趣的小伙伴可以百度相关资料。

展开全文 >>

一起来学redis-数据结构

SDS

redis中没有直接使用C语言的字符串，而是自定义了一种名为简单动态字符串的抽象类型——SDS。我们下载redis源码，可以在src目录下找到一个sds.h的文件，打开这个文件查看它的部分代码：

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

typedef char *sds;

/* Note: sdshdr5 is never used, we just access the flags byte directly.
 * However is here to document the layout of type 5 SDS strings. */
struct __attribute__ ((__packed__)) sdshdr5 {
    unsigned char flags; /* 3 lsb of type, and 5 msb of string length */
    char buf[];
};
struct __attribute__ ((__packed__)) sdshdr8 {
    uint8_t len; /* used */
    uint8_t alloc; /* excluding the header and null terminator */
    unsigned char flags; /* 3 lsb of type, 5 unused bits */
    char buf[];
};
struct __attribute__ ((__packed__)) sdshdr16 {
    uint16_t len; /* used */
    uint16_t alloc; /* excluding the header and null terminator */
    unsigned char flags; /* 3 lsb of type, 5 unused bits */
    char buf[];
};
struct __attribute__ ((__packed__)) sdshdr32 {
    uint32_t len; /* used */
    uint32_t alloc; /* excluding the header and null terminator */
    unsigned char flags; /* 3 lsb of type, 5 unused bits */
    char buf[];
};

根据代码注释我们知道：

  • len 表示字符串长度
  • alloc 表示实际分配的空间
  • flags 低三位表示类型，高五位未使用
  • buf 存储的字符

因此sds示意图就是这样的：

那么redis为什么要这么设计呢，出于以下几点考虑：

  • 降低获取字符串长度的复杂度，通过获取sds的len属性就能直接获取字符串长度。
  • 避免缓冲区溢出，当拼接字符串的时候可以通过alloc属性判断是否会超出长度
  • 减少修改字符串所带来的内存重新分配次数。因为sds会预留内存空间（alloc>len）,如果修改后的字符串长度小于alloc，则不需要重新分配内存

链表

在redis 源码中链表的定义可以通过adlist.h查看：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
/* Node, List, and Iterator are the only data structures used currently. */

typedef struct listNode {
    struct listNode *prev;
    struct listNode *next;
    void *value;
} listNode;

typedef struct listIter {
    listNode *next;
    int direction;
} listIter;

typedef struct list {
    listNode *head;
    listNode *tail;
    void *(*dup)(void *ptr);
    void (*free)(void *ptr);
    int (*match)(void *ptr, void *key);
    unsigned long len;
} list;

从源码我们可以看出链表由三个结构体来维护，list \ listNode \ listIter 。list结构为链表提供了表头指针 head，表尾指针 tail，链表长度 len。redis 链表有以下特点：

  • 双端：listNode 带有prev和next属性，它们分别指向前置节点和后置节点，从而构成双端队列；
  • 有表头表尾指针：表头指针head，表尾指针tail，降低程序获得表头指针表尾指针的复杂度；
  • 有链表长度：list中属性len记录了链表长度，使其降低了获得链表长度的复杂度。

字典

字典即map，redis字典使用哈希表作为底层的实现，每个哈希表节点中保存字典中的一个键值对。在redis的源码中可以通过dict.h 查看字典的定义：

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
typedef struct dictEntry {
    void *key;
    union {
        void *val;
        uint64_t u64;
        int64_t s64;
        double d;
    } v;
    struct dictEntry *next;
} dictEntry;

typedef struct dictType {
    uint64_t (*hashFunction)(const void *key);
    void *(*keyDup)(void *privdata, const void *key);
    void *(*valDup)(void *privdata, const void *obj);
    int (*keyCompare)(void *privdata, const void *key1, const void *key2);
    void (*keyDestructor)(void *privdata, void *key);
    void (*valDestructor)(void *privdata, void *obj);
} dictType;

/* This is our hash table structure. Every dictionary has two of this as we
 * implement incremental rehashing, for the old to the new table. */
typedef struct dictht {
    dictEntry **table;
    unsigned long size;
    unsigned long sizemask;
    unsigned long used;
} dictht;

typedef struct dict {
    dictType *type;
    void *privdata;
    dictht ht[2];
    long rehashidx; /* rehashing not in progress if rehashidx == -1 */
    unsigned long iterators; /* number of iterators currently running */
} dict;

/* If safe is set to 1 this is a safe iterator, that means, you can call
 * dictAdd, dictFind, and other functions against the dictionary even while
 * iterating. Otherwise it is a non safe iterator, and only dictNext()
 * should be called while iterating. */
typedef struct dictIterator {
    dict *d;
    long index;
    int table, safe;
    dictEntry *entry, *nextEntry;
    /* unsafe iterator fingerprint for misuse detection. */
    long long fingerprint;
} dictIterator;

我们看到源码中有dictType,dictEntry,dict,dictIterator,dictht这几个结构体来维护字典结构,(7.0以后版本无dictht)。
其中dictIterator为字典的迭代器，dictEntry结构保存着一个键值对，dictEntry属性说明：

  • key保存键值对中的键；
  • v 保存键值对中的值；
  • next指向另一个哈希节点的指针。

结构体dictType 定义了一堆用于处理键值的函数，我们可以不去关心。

dictht是一个哈希表结构，它通过将哈希值相同的元素放到一个链表中来解决冲突问题，属性说明：

  • table: dictEntry节点指针数组;
  • size: 桶的数量;
  • sizemask: mask 码，用于地址索引计算;
  • used: 已有节点数量

结构体dict 包含的属性有:

  • type：是一个指向dictType结构的指针；
  • privdata: 传给类型特定函数的可选参数；
  • ht[2]: 长度为2的dictht 哈希表；
  • rehashidx：指示 rehash 是否正在进行，如果不是则为 -1；
  • iterators：当前正在使用的 iterator 的数量。

redis的hash算法使用的是MurmurHash2，具体算法细节不做介绍。随着对hash的操作其中的键值对会发生改变，这个时候为了更合理的分配空间就需要进行hash重算（rehash）。
在dict中ht属性是一个长度为2的dictht数组，当进行hash重算的时候会将ht[0]的键值对rehash到ht[1]里面。rehash这个过程不是一次性完成的，是多次渐进式地去完成的。

rehash过程：

  1. 将rehashidx置0，表示rehash工作开始.
  2. 当对字典进行增删改查时将ht[0]的键值对rehash到ht[1]
  3. 所有的键值对均rehash完成，将rehashidx置-1。

这种方式主要是为了避免集中的rehash所带来的庞大计算量。因为渐进式rehash会同时使用ht[0]和ht[1]，所以在rehash期间redis对这个字典的更新查找等操作会同时在这两个ht中进行。

跳跃表

跳跃表是一种有序数据结构，它通过在每个节点中维持多个指针指向其他节点从而实现跳跃访问其他节点，zset的底层便是跳跃表。在redis源码中server.h定义了跳跃表的结构：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
/* ZSETs use a specialized version of Skiplists */
typedef struct zskiplistNode {
    sds ele;
    double score;
    struct zskiplistNode *backward;
    struct zskiplistLevel {
        struct zskiplistNode *forward;
        unsigned int span;
    } level[];
} zskiplistNode;

typedef struct zskiplist {
    struct zskiplistNode *header, *tail;
    unsigned long length;
    int level;
} zskiplist;

typedef struct zset {
    dict *dict;
    zskiplist *zsl;
} zset;

我们看到zset 是由 dict(集合)和zskiplist（跳表）组成，zskiplist又包含了如下属性：

  • header表头节点
  • tail表尾节点
  • length跳跃表中节点数量
  • level 层数最大的节点的层数

其中 header 和 tail 是结构体zskiplistNode的指针，这个结构体便是跳表的节点，它有如下属性：

  • ele：成员对象；
  • score：分值，用来排序；
  • backward：后退指针，用于从表尾向表头遍历
  • level：数组，节点的层，包含forward（前进指针，用于表头向表尾遍历），span（跨度，用于记录两个节点之间的距离）

跳表的层可以包含多个元素，每个元素都包含指向一个节点的指针用于快速访问其他节点，比如程序访问节点1，节点的层包含了节点4的层，那么就可以跳跃到节点四，而不是一直遍历到节点4。

对象

redis 使用对象来表示数据库中的键值，当我们在redis数据库中创建一个键值对时，至少会生成两个对象，用于表示key和value。redis对象源码：

1
2
3
4
5
6
7
8
9
typedef struct redisObject {
    unsigned type:4;
    unsigned encoding:4;
    unsigned lru:LRU_BITS; /* LRU time (relative to global lru_clock) or
                            * LFU data (least significant 8 bits frequency
                            * and most significant 16 bits access time). */
    int refcount;
    void *ptr;
} robj;

属性说明：

  • type：对象的类型，包括string，list，hash，set,zset
  • encoding：编码，表示该对象使用了什么结构作为底层实现，包括 skiplist,linklist,ht等
  • refcount：引用计数。它允许robj对象在某些情况下被共享
  • lru: 做LRU替换算法用
  • ptr: 数据指针。指向真正的数据。

redis 命令的多态，内存回收，内存共享，内存淘汰策略等特性都涉及到 redisObject，下一章节将单独讲解相关特性，感谢阅读。

展开全文 >>

k8s之vagrant

本地开发集群新方案 Virtualbox+Vagrant

vagrant 相对于 vmware 而言更轻量级，操作更简便移植性更强，如果我们需要学习k8s或者搭建一些集群的话建议使用 Virtualbox+Vagrant。
Vagrant 是创建虚拟机的工具，Virtualbox 是vagrant 管理工具，而且这两个软件是开源的，不需要我去付费或者破解。

环境准备

vagrant 下载地址：https://www.vagrantup.com
virtualbox 下载地址：https://www.virtualbox.org/wiki/Downloads

下载安装完成后，我们还需要下载vagrant镜像
镜像下载地址：https://app.vagrantup.com/boxes/search

打开cmd 窗口，添加本地镜像：

1
2
3
4
5
6
7
vagrant box add --name 镜像名称 E:data/centos7.box

## 查看所有镜像
vagrant box list 

## 初始化Vagrantfile
vagarnt init 镜像名称

执行 vagarnt init 指令会根据镜像在当前文件夹生成一个Vagrantfile文件，这个文件是创建虚拟机的配置文件。

打开 virtualbox，管理->常规->默认虚拟电脑位置，设置虚拟机存储文件夹。

打开cmd 输入 ipconfig 查看VirtualBox 的虚拟网卡ip:

1
2
3
4
5
以太网适配器 VirtualBox Host-Only Network:

   连接特定的 DNS 后缀 . . . . . . . :
   本地链接 IPv6 地址. . . . . . . . : fe80::85e5:a582:5c5a:bb5b%15
   IPv4 地址 . . . . . . . . . . . . : 192.168.56.1

修改 Vagrantfile文件，指定其虚拟机的内网ip，需要和虚拟网卡一个网段:

1
2
### 配置位置可文件中搜索该配置项，有相应的提示
  config.vm.network "private_network", ip: "192.168.56.10"

在 Vagrantfile所在文件夹打开powershell或者cmd 执行指令vagrant up 启动一个虚拟机。

待虚拟机启动完成后执行 vagrant ssh 进入虚拟机，该虚拟机的root默认密码为vagrant，进入时的账号也是vagrant:

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

PS E:\vagrant\cent1> vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Clearing any previously set forwarded ports...
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
    default: Adapter 2: hostonly
==> default: Forwarding ports...
    default: 22 (guest) => 2222 (host) (adapter 1)
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2222
    default: SSH username: vagrant
    default: SSH auth method: private key
==> default: Machine booted and ready!
==> default: Checking for guest additions in VM...
    default: No guest additions were detected on the base box for this VM! Guest
    default: additions are required for forwarded ports, shared folders, host only
    default: networking, and more. If SSH fails on this machine, please install
    default: the guest additions and repackage the box to continue.
    default:
    default: This is not an error message; everything may continue to work properly,
    default: in which case you may ignore this message.
==> default: Configuring and enabling network interfaces...
==> default: Rsyncing folder: /cygdrive/e/vagrant/cent1/ => /vagrant
==> default: Machine already provisioned. Run `vagrant provision` or use the `--provision`
==> default: flag to force provisioning. Provisioners marked to run always will still run.
PS E:\vagrant\cent1> vagrant ssh
[vagrant@localhost ~]$ whoami
vagrant
[vagrant@localhost ~]$ ls /
bin   dev  home  lib64  mnt  proc  run   srv       sys  usr      var
boot  etc  lib   media  opt  root  sbin  swapfile  tmp  vagrant
[vagrant@localhost ~]$

多机启动

我们在搭建一些环境时往往需要启动多台虚拟机，接下来我们将介绍如何创建多台虚拟机并进行相关的配置。

我们修改Vagrantfile 内容：

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
Vagrant.configure("2") do |config| 
   (1..3).each do |i| 
       
      #定义节点变量 
      config.vm.define "node#{i}" do |node| 
      
      # box配置 
      node.vm.box = "centos7" 
 
      # 设置虚拟机的主机名 
      node.vm.hostname = "node#{i}" 
 
      # 设置虚拟机的IP 
      node.vm.network "private_network", ip: "192.168.56.#{10+i}" 
 
      # 设置主机与虚拟机的共享目录 
      #node.vm.synced_folder "/Users/meetmax", "/home/vagrant/code" 
      node.vm.synced_folder "E:/volum/data", "/share", create:true, owner: "root", group: "root"
      # VirtaulBox相关配置 
      node.vm.provider "virtualbox" do |v| 
 
          # 设置虚拟机的名称 
          v.name = "node#{i}" 
 
          # 设置虚拟机的内存大小 
          v.memory = 2048 
 
          # 设置虚拟机的CPU个数 
          v.cpus = 2 
      end 
  end 
end 
end

执行 vagrant up 启动node1,node2,node3 三台虚拟机，在启动过程中可能会报挂载失败的错误：

1
2
3
4
5
6
7
8
9
node1: /share => E:/vagrant/data
Vagrant was unable to mount VirtualBox shared folders. This is usually
because the filesystem "vboxsf" is not available. This filesystem is
made available via the VirtualBox Guest Additions and kernel module.
Please verify that these guest additions are properly installed in the
guest. This is not a bug in Vagrant and is usually caused by a faulty
Vagrant box. For context, the command attempted was:

mount -t vboxsf -o uid=0,gid=0,_netdev share /share

安装插件可以解决（如果还报错则卸载插件，换一个更低版本的）：

1
2
3
4
5
6
7
8
9
10
11
## 安装插件
vagrant plugin install vagrant-vbguest

## 卸载插件
vagrant plugin uninstall vagrant-vbguest

## 安装指定版本插件
vagrant plugin install vagrant-vbguest --plugin-version 0.21

## 插件安装过程中可能出现联网失败的情况，可以修改下载国内镜像安装
vagrant plugin install vagrant-vbguest --plugin-clean-sources --plugin-source https://gems.ruby-china.com/

执行 vagrant status 查看虚拟机运行状态，也可以直接在virtualbox 界面上查看，在下次启动虚拟机的时候就不需要再cmd窗口执行vagrant up指令，直接在virtualbox界面上选择启动方式。
进入虚拟机的指令：

1
vagrant ssh '虚拟机名称'

虚拟机初始化配置

在我们虚拟机启动后，其中dns 服务器地址是有问题的，我们希望在创建虚拟机的时候，进行一些基础的配置，我们可以在Vagrantfile 中添加脚本实现这些配置：

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
Vagrant.configure("2") do |config| 
    (1..3).each do |i| 
       
        #定义节点变量 
        config.vm.define "node#{i}" do |node| 
      
        # box配置 
        node.vm.box = "centos7" 
 
        # 设置虚拟机的主机名 
        node.vm.hostname = "node#{i}" 
 
        # 设置虚拟机的IP 
        node.vm.network "private_network", ip: "192.168.56.#{10+i}" 
 
        # 设置主机与虚拟机的共享目录 
        #node.vm.synced_folder "E:\volum\data", "/share", create:true, owner: "root", group: "root"
        # VirtaulBox相关配置 
        node.vm.provider "virtualbox" do |v| 
 
          # 设置虚拟机的名称 
          v.name = "node#{i}" 
 
          # 设置虚拟机的内存大小 
          v.memory = 2048 
 
          # 设置虚拟机的CPU个数 
          v.cpus = 2 
        end
        node.vm.provision "shell", inline: <<-SHELL
            eh=$(nmcli connection show|awk -F "  " '{print $1}'|grep -v NAME|head -1)
            nmcli con mod "$eh" ipv4.dns "223.5.5.5"
            nmcli con up "$eh"
        SHELL
        end 
    end 
end

在示例中，我通过配置项node.vm.provision "shell" 编写脚本设置了dns 服务器ip。通过这个方式我们可以实现预装docker等操作。
我们还可以指定外部脚本，配置示例：

1
config.vm.provision "shell", path: "script.sh"

当然我们还可以制作自己的box 实现一键创建虚拟机。
首先我们在原来的虚拟机中安装好软件并修改相关配置配置文件，然后清除掉private_network的网络规则：

1
sudo rm -f /etc/udev/rule.d/70-persistent-net.rules

检查 /etc/ssh/sshd_config文件PasswordAuthentication no 是否被注释掉，没有注释掉的话无法通过 vagrant ssh 登录。

然后执行指令：

1
vagrant package node1

在当前文件夹下得到一个 package.box 。

vagrant package 极大的增强了虚拟机的可移植性，在一定程度上降低了我们的学习成本。

备注

vagrant 常用指令速查表：

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
# 查看box 
vagrant box list

# 添加box
vagrant box add --name path

# 移除box
vagrant box remove xxx

# 初始化 Vagrantfile
vagrant init xxx

# 启动虚拟机
vagrant up [name]

# ssh 连接虚拟机
vagrant ssh

# 重新加载虚拟机
vagrant reload

# 删除虚拟机
vagrant destroy

# 打包虚拟机为镜像
vagrant package 

# 查看虚拟机状态
vagrant status
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
  nmcli connection show
  
  nmcli con mod "System eth0" ipv4.dns "223.5.5.5 223.6.6.6"
  
  sudo nmcli con up "System eth0"

  sudo yum install wget
  sudo yum update -y
  sudo yum install docker -y
   sudo mv /etc/yum.repos.d/CentOS-Base.repo CentOS-Base.repo.back
   sudo wget -O /etc/yum.repos.d/CentOS-Base.repo https://mirrors.aliyun.com/repo/Centos-7.repo

   yum clean all

yum makecache

sudo rm -f /etc/udev/rule.d/70-persistent-net.rules
sudo systemctl enable docker
sudo vi /etc/docker/daemon.json
 "registry-mirrors": ["https://b9pmyelo.mirror.aliyuncs.com"]

展开全文 >>

k8s基础

Kubernetes中概念的简要概述

  • Cluster : 集群是指由Kubernetes使用一系列的物理机、虚拟机和其他基础资源来运行你的应用程序。
  • Node : 运行着Kubernetes的物理机或虚拟机，并且pod可以在其上面被调度。
  • Pod : k8s的最小调度单元，一个pod 可以包含多个容器，k8s无法直接操作容器，只能操作pod
  • Label : 一个label是一个被附加到资源上的键/值对，譬如附加到一个Pod上，为它传递一个用户自定的并且可识别的属性.Label还可以被应用来组织和选择子网中的资源
  • selector:是一个通过匹配labels来定义资源之间关系得表达式，例如为一个负载均衡的service指定所目标Pod.
  • Deployment: 控制pod生命周期的pod控制器
  • Service : 一个service定义了访问pod的方式，比如固定的IP地址和与其相对应的DNS名之间的关系。
  • Volume: 目录或者文件夹
  • Namespace : 命名空间，起到资源分组he隔离的作用

kubernetes集群由master、node构成。其中master包含组件：

  • API Server：暴露k8s api 的服务
  • Scheduler：调度器，按照预定的调度策略将 Pod 调度到相应的 node 节点上。
  • ControllerManager：负责维护集群的状态，比如程序部署安排、故障检测、自动扩展和滚动更新等。
  • Etcd：数据库，负责存储集群中各种资源对象的信息。

node 节点包含组件：

  • Kubelet：维护容器的生命周期，即通过控制 Docker ，来创建、更新、销毁容器。
  • KubeProxy：提供集群内部的服务发现和负载均衡。
  • Docker：容器。

window下搭建k8s环境

搭建k8s开发环境有三种，一种是通过docker desktop + Minikube 来直接在你的电脑上搭建，这种搭建方式存在的问题比较多，很多功能不支持，不建议使用。
另外一种方式是通过Docker Desktop安装k8s，这种k8s是单机版的，master 和node 是同一个节点也就是本机，这种方式安装的k8s基本上能满足我们的学习需求，初期学习阶段可以使用这种安装方式。
还有就是通过前文介绍 vagrant 制作box 然后创建集群安装，这种安装方式是最完整也是最麻烦的。
现在先介绍第二种安装方式，第二种方式是把k8s 镜像拉取下来并运行容器，但因为国内网络的问题，镜像依赖拉不下来，我们可以上github 拉阿里云的k8s-for-docker-desktop 到本地安装。

1
2
3
4
5
git clone https://github.com/AliyunContainerService/k8s-for-docker-desktop.git
cd k8s-for-docker-desktop

// 执行脚本安装K8S相关镜像（确认k8s-for-docker-desktop文件夹下的images中的k8s和本地安装的docker中需要的k8s版本保持一致）
./load_images.sh

需要注意git tag 是不是和你的 docker中的k8s版本保持一致

然后打开你的docker desktop，勾选k8s:

等docker 重启后就安装完成了，打开命令行窗口执行指令，验证是否安装成功：

1
kubectl cluster-info

第三种安装方式需要kubeadm 来进行集群安装，k8s集群可以一主多从或者多主多从，这里我搭建的是一主多从集群。

安装步骤：

  1. 制作自己的box并配置好Vagrantfile，box中需要安装docker，更新yum源等，最好安装一些基本工具与telnet，然后启动虚拟机

  2. 禁用selinux，禁用swap分区 ，selinux是linux系统下的一个安全服务，如果不关闭它，在安装集群中会产生各种各样的奇葩问题，swap分区指的是虚拟内存分区，
    它的作用是物理内存使用完，之后将磁盘空间虚拟成内存来使用，启用swap设备会对系统的性能产生非常负面的影响

  3. 修改linux的内核参数

1
2
3
4
5
6
7
8
9
10
11
12
# 修改linux的内核采纳数，添加网桥过滤和地址转发功能
# 编辑/etc/sysctl.d/kubernetes.conf文件，添加如下配置：
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1

# 重新加载配置
[root@master ~]# sysctl -p
# 加载网桥过滤模块
[root@master ~]# modprobe br_netfilter
# 查看网桥过滤模块是否加载成功
[root@master ~]# lsmod | grep br_netfilter
  1. 安装Kubernetes组件
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# 1、由于kubernetes的镜像在国外，速度比较慢，这里切换成国内的镜像源
# 2、编辑/etc/yum.repos.d/kubernetes.repo,添加下面的配置
[kubernetes]
name=Kubernetes
baseurl=http://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgchech=0
repo_gpgcheck=0
gpgkey=http://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg
			http://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg

# 3、安装kubeadm、kubelet和kubectl
[root@master ~]# yum install --setopt=obsoletes=0 kubeadm-1.17.4-0 kubelet-1.17.4-0 kubectl-1.17.4-0 -y

# 4、配置kubelet的cgroup
#编辑/etc/sysconfig/kubelet, 添加下面的配置
KUBELET_CGROUP_ARGS="--cgroup-driver=systemd"
KUBE_PROXY_MODE="ipvs"

# 5、设置kubelet开机自启
[root@master ~]# systemctl enable kubelet
  1. 准备集群镜像,利用kubeadm部署k8s的Master节点：
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    # 在安装kubernetes集群之前，必须要提前准备好集群需要的镜像，所需镜像可以通过下面命令查看
    [root@master ~]# kubeadm config images list

    # 由于默认拉取镜像地址k8s.gcr.io国内无法访问，这里需要指定阿里云镜像仓库地址
    kubeadm init \
      --apiserver-advertise-address=局域网ip \
      --image-repository registry.aliyuncs.com/google_containers \
      --kubernetes-version v1.18.0 \
      --service-cidr=-service 的CIDR\
      --pod-network-cidr=Pod 网络的 CIDR

  2. 配置node，当第五步执行完成，kubeadm 会输出一个指令，将这句指令复制到node节点上执行：
1
2
kubeadm join 192.168.18.1:8080 --token xxx \
    --discovery-token-ca-cert-hash xxx
  1. 在master 节点上执行指令，验证安装：
1
kubectl get nodes

namespace

命名空间在k8s中的主要作用是资源隔离，可以将多个 pod 放入同一namespace中，实现对一组pod资源的管理。
k8s 在集群启动后，会默认创建几个namespace ,可以通过指令kubectl get ns 查看：

1
2
3
4
5
6
7
8
C:\Users\Administrator>kubectl get ns
NAME                   STATUS   AGE
default                Active   34d
kube-node-lease        Active   34d
kube-public            Active   34d
kube-system            Active   34d
kubernetes-dashboard   Active   34d

如果我们创建pod的时候未指定namespace,则会默认划分到 default 命名空间中，kube-node-lease 用于维护节点之间的心跳，kube-public 公共资源的命名空间，可以被所有人访问，kube-system k8s的系统资源命名空间。
查看命名空间指令：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
kubectl get pods -n kube-system 

### 控制台返回

NAME                                     READY   STATUS    RESTARTS         AGE
coredns-78fcd69978-7df2r                 1/1     Running   41 (18m ago)     34d
coredns-78fcd69978-cwwmp                 1/1     Running   41 (18m ago)     34d
etcd-docker-desktop                      1/1     Running   41 (18m ago)     34d
kube-apiserver-docker-desktop            1/1     Running   41 (18m ago)     34d
kube-controller-manager-docker-desktop   1/1     Running   41 (18m ago)     34d
kube-proxy-5hfwt                         1/1     Running   41 (18m ago)     34d
kube-scheduler-docker-desktop            1/1     Running   41 (18m ago)     34d
storage-provisioner                      1/1     Running   81 (17m ago)     34d
vpnkit-controller                        1/1     Running   1728 (17m ago)   34d

namespace 相关指令：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
### 查看 
kubectl get ns

### 查看某一个
kubectl get ns default

### 查看详情 
kubectl describe ns default

### 创建
kubectl create ns dev

### 删除 
kubectl delete ns dev

在namespace 属性中 status 的状态包括 active Terminating（正在删除），resource quota 属性限制了 ns的资源，limitRange resource 限制了 ns 下 pod的资源

我们还可以以配置文件的形式创建namespace，创建ns-dev.yaml:

1
2
3
4
5
apiVersion: v1
kind: Namespace
metadata:
  name: dev

执行对应的创建或删除命令：

1
2
3
kubectl create -f ns-dev.yaml
kubectl delete -f ns-dev.yaml

pod

pod 是k8s集群进行部署管理的最小单元，一个pod中可以有一个或者多个容器，pod是对容器的封装。k8s 在集群启动后，集群中的各个组件都是以pod的方式运行的。可以通过以下命令查看：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
kubectl get pod -n kube-system [-o wide]

### 控制台返回
C:\Users\Administrator>kubectl get pod -n kube-system
NAME                                     READY   STATUS    RESTARTS           AGE
coredns-78fcd69978-7df2r                 1/1     Running   43 (70m ago)       35d
coredns-78fcd69978-cwwmp                 1/1     Running   43 (70m ago)       35d
etcd-docker-desktop                      1/1     Running   43 (70m ago)       35d
kube-apiserver-docker-desktop            1/1     Running   43 (70m ago)       35d
kube-controller-manager-docker-desktop   1/1     Running   43 (70m ago)       35d
kube-proxy-5hfwt                         1/1     Running   43 (70m ago)       35d
kube-scheduler-docker-desktop            1/1     Running   43 (70m ago)       35d
storage-provisioner                      1/1     Running   85 (69m ago)       35d
vpnkit-controller                        1/1     Running   1770 (9m43s ago)   35d

pod相关指令：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
### 运行一个pod 
kubectl run nginx --image=nginx:1.17.1 --port=80 --namespace dev

### 查看
kubectl get pod -n kube-system -o wide
kubectl describe pod nginx-xxxx -n dev

## 删除
kubectl delete pod nginx-xxxx -n dev

## 删除pod 控制器 当pod 绑定pod 控制器的时候，直接删除pod后，pod控制器会重建pod 因此需要删除对应的pod控制器
kubectl get deployment -n dev

### 删除pod 控制器
kubectl delete deployment nginx -n dev

通过配置文件创建pod:

1
2
3
4
5
6
7
8
9
10
11
12
13
apiVersion: v1
kind: Pod
metadata:
  name: nginx
  namespace: dev
spec:
  containers:
  - image: nginx:latest
    name: pod
    ports:
    - name: nginx-port
      containerPort: 80
      protocol: TCP

然后就可以执行对应的创建和删除命令了：

创建：kubectl create -f pod-nginx.yaml

删除：kubectl delete -f pod-nginx.yaml

label

Label是kubernetes系统中的一个重要概念。它的作用就是在资源上添加标识，用来对它们进行区分和选择。

Label的特点：

  • 一个Label会以key/value键值对的形式附加到各种对象上，如Node、Pod、Service等等
  • 一个资源对象可以定义任意数量的Label ，同一个Label也可以被添加到任意数量的资源对象上去
  • Label通常在资源对象定义时确定，当然也可以在对象创建后动态添加或者删除

可以通过Label实现资源的多维度分组，以便灵活、方便地进行资源分配、调度、配置、部署等管理工作。

一些常用的Label 示例如下：

  • 版本标签：”version”:”release”, “version”:”stable”……
  • 环境标签：”environment”:”dev”，”environment”:”test”，”environment”:”pro”
  • 架构标签：”tier”:”frontend”，”tier”:”backend”

打标签命令

1
2
3
4
5
6
7
8
9
10
kubectl get pod -n dev --show-labels
kubectl label pod nginx -n dev version=1.0 
kubectl label pod nginx -n dev version=2.0 --overwrite
kubectl label pod -l "version=2.0" -n dev

## 删除标签 
kubectl label pod nginx -n dev version-

# pod 更新
kubectl apply -f nginx.yaml

配置文件打标签

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
apiVersion: v1
kind: Pod
metadata:
  name: nginx
  namespace: dev
  labels:
    version: "3.0" 
    env: "test"
spec:
  containers:
  - image: nginx:latest
    name: pod
    ports:
    - name: nginx-port
      containerPort: 80
      protocol: TCP

在pod的yaml 中指定标签然后通过指令：

1
kubectl apply -f nginx.yaml

完成更新

deployment

在kubernetes中，Pod是最小的控制单元，但是kubernetes很少直接控制Pod，一般都是通过Pod控制器来完成的。Pod控制器用于pod的管理，确保pod资源符合预期的状态，当pod的资源出现故障时，会尝试进行重启或重建pod。

在kubernetes中Pod控制器的种类有很多，本章节只介绍一种：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
65
## 查看deployment pod
kubectl get deployment,pods -n dev
# 命令格式: kubectl create deployment 名称  [参数] 
# --image  指定pod的镜像
# --port   指定端口
# --replicas  指定创建pod数量
# --namespace  指定namespace
[root@master ~]# kubectl run nginx --image=nginx:latest --port=80 --replicas=3 -n dev
deployment.apps/nginx created

# 查看创建的Pod
[root@master ~]# kubectl get pods -n dev
NAME                     READY   STATUS    RESTARTS   AGE
nginx-5ff7956ff6-6k8cb   1/1     Running   0          19s
nginx-5ff7956ff6-jxfjt   1/1     Running   0          19s
nginx-5ff7956ff6-v6jqw   1/1     Running   0          19s

# 查看deployment的信息
[root@master ~]# kubectl get deploy -n dev
NAME    READY   UP-TO-DATE   AVAILABLE   AGE
nginx   3/3     3            3           2m42s

# UP-TO-DATE：成功升级的副本数量
# AVAILABLE：可用副本的数量
[root@master ~]# kubectl get deploy -n dev -o wide
NAME    READY UP-TO-DATE  AVAILABLE   AGE     CONTAINERS   IMAGES              SELECTOR
nginx   3/3     3         3           2m51s   nginx        nginx:latest        run=nginx

# 查看deployment的详细信息
[root@master ~]# kubectl describe deploy nginx -n dev
Name:                   nginx
Namespace:              dev
CreationTimestamp:      Wed, 08 May 2021 11:14:14 +0800
Labels:                 run=nginx
Annotations:            deployment.kubernetes.io/revision: 1
Selector:               run=nginx
Replicas:               3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:  run=nginx
  Containers:
   nginx:
    Image:        nginx:latest
    Port:         80/TCP
    Host Port:    0/TCP
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      True    MinimumReplicasAvailable
  Progressing    True    NewReplicaSetAvailable
OldReplicaSets:  <none>
NewReplicaSet:   nginx-5ff7956ff6 (3/3 replicas created)
Events:
  Type    Reason             Age    From                   Message
  ----    ------             ----   ----                   -------
  Normal  ScalingReplicaSet  5m43s  deployment-controller  Scaled up replicaset nginx-5ff7956ff6 to 3
  
# 删除 
[root@master ~]# kubectl delete deploy nginx -n dev
deployment.apps "nginx" deleted

配置文件创建：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  namespace: dev
spec:
  replicas: 3
  selector:
    matchLabels:
      run: nginx
  template:
    metadata:
      labels:
        run: nginx
    spec:
      containers:
      - image: nginx:latest
        name: nginx
        ports:
        - containerPort: 80
          protocol: TCP

service

通过上节课的学习，已经能够利用Deployment来创建一组Pod来提供具有高可用性的服务。

虽然每个Pod都会分配一个单独的Pod IP，然而却存在如下两问题：

  • Pod IP 会随着Pod的重建产生变化
  • Pod IP 仅仅是集群内可见的虚拟IP，外部无法访问

这样对于访问这个服务带来了难度。因此，kubernetes设计了Service来解决这个问题。

Service可以看作是一组同类Pod对外的访问接口。借助Service，应用可以方便地实现服务发现和负载均衡。

1
2
3
4
5
6
7
8
9
# 暴露Service
[root@master ~]# kubectl expose deploy nginx --name=svc-nginx1 --type=ClusterIP --port=80 --target-port=80 -n dev
service/svc-nginx1 exposed

# 查看service
[root@master ~]# kubectl get svc svc-nginx1 -n dev -o wide
NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE     SELECTOR
svc-nginx1   ClusterIP   10.109.179.231   <none>        80/TCP    3m51s   run=nginx

展开全文 >>

jenkins-4

jenkins 邮件通知及sonarqube 插件

邮件通知

在实际项目中往往需要在流水线执行过程中发送通知邮件到相应的开发运维人员的邮箱中，jenkins 可以通过插件 Email Extension Plugin 进行相关配置。
进入jenkins系统设置中找到email 相关配置：

配置内容包括邮箱服务器（参考 spring 发送邮件功能），邮箱后缀等，jenkins 旁边的问号图标都有相关配置项说明，需要注意的是jenkins 内置了一些变量，可查看 Content Token Reference 项。完成基本的邮件配置完成后，还需要再流水线中配置发送邮件相关信息

pipeline post

展开全文 >>

k8s 系列-docker

认识docker

docker是Docker.inc 公司开源的一个基于LXC技术之上构建Container容器引擎技术，Docker基于容器技术的轻量级虚拟化解决方案，实现一次交付到处运行。
docker实现程序集装箱的概念，把我们需要交付的内容集装聚合成一个文件（镜像文件）直接交付。

docker 基本原理

docker 架构图：

从架构图中我们可以看出，docker有三大核心，包括容器，仓库，镜像

  • 镜像（image）：文件的层次结构，以及包含如何运行容器的元数据

  • 容器（container）：容器是镜像创建的运行实例，它可以被启动、开始、停止、删除。每个容器都是相互隔离的、保证安全的平台。可以把容器看作是一个简易版的linux环境，Docker利用容器来运行应用

  • 仓库（repository）：仓库是集中存放镜像文件的场所，仓库注册服务器上往往存放着多个仓库，每个仓库中又保存了很多镜像文件，每个镜像文件有着不同的标签。

    docker 具有如下特性：

  • 文件系统隔离：每个进程容器运行在完全独立的根文件系统中

  • 资源限制：每个进程容器运行在自己的网络命名空间中，拥有自己的虚拟接口和ip地址等

  • 写时复制：由于镜像采用层式文件系统，所以采用写时复制方式创建镜像的根文件系统，这让部署变得极其快捷，并且节省内存和硬盘空间

  • 日志记录：docker会收集和记录每个进程容器的标准流，用于实时检索或批量检索。不消耗本地io

  • 变更管理：容器文件系统的变更可以提交到新的镜像中，并可以重复使用以创建更多容器。

  • 交互式shell：docker可以分配一个虚拟终端并关联到任何容器的标准输入上。

  • namespace隔离：每个进程容器运行在自己的网络命名空间里，拥有自己的虚拟接口和ip地址等

docker 工作流程图：

docker 工作流程大体分为三步：

  • build：制作镜像，镜像如同一个集装箱，封装了包括文件，运行环境等资源
  • Ship: 运输镜像，将制作好的镜像上传到仓库中，以便拉取
  • Run: 运行镜像，通过镜像创建一个容器

docker容器及镜像结构：

Docker 支持通过扩展现有镜像，创建新的镜像，新镜像是从 base 镜像一层一层叠加生成的，每新增一个应用，就会叠加一层镜像。
镜像分层的好处就是共享资源，比如说有多个镜像都从相同的 base 镜像构建而来，那么 Docker 只需在磁盘上保存一份 base 镜像，
同时内存中也只需加载一份 base 镜像，就可以为所有容器服务了。

当容器启动时，一个新的可写层被加载到镜像的顶部，这一层通常被称作“容器层”，“容器层”之下的都叫“镜像层”。
所有对容器的添加、删除、还是修改文件都只会发生在容器层中。
只有容器层是可写的，容器层下面的所有镜像层都是只读的。

dockers基础操作

docker 原理我们基本普及了，接下来我们进入实战环节。
接下来我们将在windows操作系统上安装docker desktop，需要注意的地方就是windows系统不能是家庭版的，需要开启虚拟化，需要安装WSL2。
具体的流程我就不介绍了，网上能找到比较多的例子

docker 安装完成之后，我们可以运行一个hello world 镜像测试：

1
2
docker run hello-world

命令行窗口输出拉取镜像运行的日志，接下来对镜像和容器进行查看删除等操作：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
## 查看正在运行的容器
docker ps

## 查看所有容器
docker ps -a 

## 查看镜像
docker images

## 删除镜像

docker rm 容器id

## 删除镜像
docker rmi 镜像id

## 拉取远程仓库镜像
docker pull nginx

## 进入容器
docker exec -it 镜像id /bin/bash

docker 实战

接下来我们创建一个springboot应用并制作成镜像，maven依赖：

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
<dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter</artifactId>
        </dependency>
      
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
      
  </dependencies>
    <build>
        <plugins>
            <plugin>
                <groupId>com.spotify</groupId>
                <artifactId>dockerfile-maven-plugin</artifactId>
                <version>1.3.6</version>
                <configuration>
                    <repository>${project.artifactId}</repository>
                    <buildArgs>
                        <JAR_FILE>target/${project.build.finalName}.jar</JAR_FILE>
                    </buildArgs>
                    <tag>${project.version}</tag>
                </configuration>
            </plugin>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>
        </plugins>
    </build>

然后在pom文件的同级目录下创建 Dockerfile:

1
2
3
4
FROM openjdk:8-jdk-alpine
ARG JAR_FILE
COPY ${JAR_FILE} app.jar
ENTRYPOINT ["java","-jar","/app.jar"]

dockerfile-maven-plugin 是制作镜像的maven插件，插件和build默认绑定，执行build阶段运行该插件，push绑定到deploy阶段。

而dockerfile是制作镜像的描述文件。
Dockerfile是一个文本文件，其内包含了一条条的指令(Instruction)，用于构建镜像。每一条指令构建一层镜像，因此每一条指令的内容，就是描述该层镜像应当如何构建。
Dockerfile参数说明：

在我们执行 mvn package指令时会在命令行输出整个docker镜像的制作过程，并在后续能在docker中通过docker images 查看该镜像。
制作好的镜像只是存在我们的本地中，我们可以推到远程仓库到其他机器上运行，而几大云平台都提供了免费的远程私有仓库，比如阿里云效和腾讯云coding。
后续如果有时间会出Jenkins+docker+springboot的详细教程介绍如何一键远程部署我们的应用。

展开全文 >>

jenkins-3 Ansible和Jenkins

什么是Ansible

ansible是一个基于python的自动化运维工具，实现了批量系统配置、批量程序部署、批量运行命令等功能。ansible包括部署和使用简单、默认使用ssh协议、轻量级等特点。

ansible 架构：

https://www.cnblogs.com/keerya/p/7987886.html

懒得写

jenkins 内置四种构建触发器：

  • 触发远程构建
  • 其他工程构建后触发
  • 定时构建
  • 轮询scm

此外还可以通过安装插件通过git hook 自动触发构建

触发远程构建方式

我们可以通过访问jenkins 提供的链接触发jenkins流水线进行构建，如图所示：

配置好令牌后访问地址：

1
http://localhost:9901/job/test2/build?token=test

再控制台上就能看到一次构建记录

其他工程构建后触发

当其他流水线执行后，触发当前流水线执行，如图所示：

从图中我们能看到它的触发规则有四种

定时构建

即Build periodically，它通过cron表达式定时执行我们的流水线，如图所示：

点击标题旁边的问号图标，Jenkins会给予相关的说明和示例，我们照着示例去配置即可，配置示例：

1
2
3
4
5
6
7
8
9
10
# Every fifteen minutes (perhaps at :07, :22, :37, :52):
H/15 * * * *
# Every ten minutes in the first half of every hour (three times, perhaps at :04, :14, :24):
H(0-29)/10 * * * *
# Once every two hours at 45 minutes past the hour starting at 9:45 AM and finishing at 3:45 PM every weekday:
45 9-16/2 * * 1-5
# Once in every two hour slot between 8 AM and 4 PM every weekday (perhaps at 9:38 AM, 11:38 AM, 1:38 PM, 3:38 PM):
H H(8-15)/2 * * 1-5
# Once a day on the 1st and 15th of every month except December:
H H 1,15 1-11 *

轮询scm

定时去扫描流水中配置的代码仓库，检测是否有变更，如果代码有变更则触发流水线执行，我们需要配置轮询规则，配置方式和定时构建一样：

git hook 自动触发构建

以github 为例，当github 发生代码提交的时候，github向jenkin 发送构建请求以执行流水线。

在github 上配置token并设置webhook:
登录github 访问链接https://github.com/settings/tokens，点击Generate new token,配置权限 repo,admin:repo_hook：

点击保存，获取 token,保存好这个token

在github对应的代码仓库中选择设置–>webhooks

在jenkins中安装github 插件，我们需要对插件进行一些配置以实现相关功能，配置界面如图所示：

填写 API URL为https://api.github.com
点击添加按钮，类型选择Secret Text

Secret 填token，其余随意。
然后在流水线的构建触发器中勾选GitHub hook trigger for GITScm polling 就ok拉：

展开全文 >>

jenkins-2 pipeline

pipeline 的hello world

pipeline是部署流水线，它支持脚本和声明式语法，能够比较高自由度的构建jenkins任务.个人推荐使用这种方式去构建jenkins。

Jenkins 1.x只能通过界面手动配置来配置描述过程，想要配置一些复杂度高的任务，只能选择自由风格的项目，通过选项等操作进行配置，让jenkins可以下载代码、编译构建、然后部署到远程服务器上，这样显然是不方便管理和移植的。

pipeline的功能由pipeline插件提供，我们可以创建一个jenkinsfile来申明一个任务。接下来我们创建一个最简单的pipeline。登录jenkins,点击创建item:


在流水线中选择hello world 生成代码：

以上便是一个最简单的流水线。点击build now，jenkins任务开始执行，运行完成后点击查看执行记录：

在console output 中可以看到运行记录：

为了提高流水线的复用性以及便于流水线代码的管理，更多的是将pipeline的脚本在远程仓库，当我们修改了远程仓库的流水线脚本，jenkins就会加载到最新的脚本执行。
在流水线配置中选择pipeline script from SCM:

按照提示配置好脚本仓库地址，访问仓库的凭证，流水线脚本文件的名称（默认是Jenkinsfile），分支（默认是master）等。配置完成后在仓库中添加文件Jenkinsfile把脚本粘贴过去并push，
最后执行任务，发现执行成功。通过这个特性，我们可以把我们的流水线脚本和项目代码本身放到一个仓库中管理，达到多版本控制并和代码版本统一的效果。
如果我们编写jenkinsfile需要语法提示相关的编辑器，可以使用jenkins官方提供的vscode插件Jenkins Pipeline Linter Connector。使用idea Groovy 也能提示部分语法。
idea 设置jenkinsfile 语法提示方法 settings > editor > File Types > Groovy 新增一列Jenkinsfile:

pipeline 语法介绍

jenkins pipeline有2种语法：脚本式（Scripted）语法和声明式（Declar-ative）语法。pipeline插件从2.5版本开始同时支持两种语法，官方推荐的是使用申明式语法，在这里也只对申明式语法进行介绍。
申明式语法demo:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
pipeline {
    agent any

    stages {
        stage('pull') {
            steps {
                echo '拉取代码'
            }
        }
		
		stage('build') {
            steps {
                echo '构建代码'
            }
        }
    }
}

声明式语法中，以下结构是必须的，缺少就会报错：

  • pipeline：固定语法，代表整条流水线
  • agent：指定流水线在哪执行，默认any即可，也可以指定在docker、虚拟机等等里执行
  • stages：流水线阶段集合节点，该节点中至少有一个stage
  • stage：流水线的阶段节点，每个阶段中至少包含一个steps
  • steps：执行步骤集合，每个集合至少包含一个step。
  • step: 执行步骤。

pipeline 实战

接下来我们编译一个本地项目，流水线脚本示例：

1
2
3
4
5
6
7
8
9
10
11
12
pipeline {
    agent any
    stages {
        
        stage('Build') {
            steps {
                bat 'mvn -Dmaven.repo.local=E:/data/maven -Dmaven.multiModuleProjectDirectory=E:/Temp/git_jenkins/xxx -f E:/Temp/git_jenkins/xxx/pom.xml -Dmaven.test.skip=true  package'
                
            }
        }
    }
}

前文提到过，jenkins会给每个任务在workspacedir下创建文件夹作为运行环境，接下来我们验证通过git将代码下载到这个文件夹下然后打包。流水线脚本：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
pipeline {
    agent any
    
    stages {
        
        stage("check out"){
             steps {
                git  credentialsId: 'a5b41362-6e47-406a-82e0-067aeb896ecf', url: 'git@github.com:muggle0/poseidon.git',branch: "master"
            }
        }
        
        stage('Build') {
            steps {
                bat 'mvn -Dmaven.repo.local=E:/data/maven  -f ./poseidon-parent/pom.xml -Dmaven.test.skip=true  package'
                
            }
        }
    }
}

我配置的workspace 路径是’E:\Temp\jenkins\workspace’，任务名称是 test，看Jenkins 执行指令就能看到相关信息：

打开这个文件夹看看是什么情况：

步骤check out把我github上的项目拉到这个工作目录下了，而Build则是对项目进行了编译，然后我们可以在target目录找到编译好的jar包，在实际项目中我们可以通过指令将这个jar推到远程服务器上去，或者可以做成docker镜像，推到docker仓库，在远程执行docker指令把这个镜像跑起来，maven插件dockerfile-maven-plugin 是可以直接通过一个dockerfile 文件将项目打成一个镜像的。而jenkins 插件SSH Pipeline Steps可以远程执行shell 脚本，这样整个流程就串通起来了。这个插件的github地址： https://github.com/jenkinsci/ssh-steps-plugin#pipeline-steps。

插件脚本示例：

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
stage('部署镜像') {
    ansiColor('xterm') {
        def sshServer = [:]
        sshServer.name = "server-1"
        sshServer.host = "127.0.0.1"
        sshServer.port = 22
        sshServer.allowAnyHosts = true
        withCredentials([usernamePassword(credentialsId: 'ServiceServer', passwordVariable: 'password', usernameVariable: 'userName')]) {
            remote.user = "${userName}"
            remote.password = "${password}"
        }
        docker.withRegistry(REGISTRY_URL, REGISTRY_CREDENTIALS_ID) {
            def imgName = "${REGISTRY_DOMAIN}/${DOCKER_NAMESPACE}/${project_name}:${tagName}";

            for (item in ipList.tokenize(',')) {
                // 更新或下载镜像
                sshCommand remote: sshServer, command: "docker pull ${imgName}"
                try {
                    // 停止容器
                    sshCommand remote: sshServer, command: "docker stop ${project_name}"
                    // 删除容器
                    sshCommand remote: sshServer, command: "docker rm -f ${project_name}"
                } catch (ex) {
                }
                // 启动容器
                sshCommand remote: sshServer, command: "docker run -d --name ${project_name} -e TZ=Asia/Shanghai ${imgName}"
            }
        }
    }
}

到这里，我们基本上已经掌握了jenkins的基本使用，可以完成将项目下载，编译部署等功能。接下来文章我们会学习一些jenkins的更复杂用法。

展开全文 >>

jenkins-1 安装与配置

Jenkins 介绍

Jenkins是一款开源 CI&CD 软件，用于自动化各种任务，包括构建、测试和部署软件，CI&CD:

  • 持续集成：持续集成可以帮助开发人员更加频繁地将代码更改合并到目标分支
  • 持续交付：持续交付的目标是拥有一个可随时部署到生产环境的代码库
  • 持续部署：可以自动将应用发布到生产环境

Jenkins 安装与demo

jenkins 有2种部署方式，war包直接启动和tomcat方式启动。推荐采用tomcat方式启动，方便进行日志查看和管理。启动jenkins并访问 `http://127.0.0.1:8080/jenkins

`，初始密码保持在initialAdminPassword 文件中，初始化过程会要求安装插件，选择推荐插件，若安装失败可在左上角/右上角找到跳过，进行跳过。因为Jenkins插件默认下载地址是国外，会很容易出错，后续可以更换为国内镜像仓库再进行插件安装。完成初始化过程后，进入界面修改插件代理，manage plugins——>高级页签：

URL填：https://mirrors.tuna.tsinghua.edu.cn/jenkins/updates/update-center.json 然后保存，在重试装插件，插件就能装成功了。接下来，我们配置凭据，git等通用配置。

manage jenkins -> global tool configuration ：

如图所示，你可以选择让jenkins为你安装git,也可以配置机器上已安装好的git，jdk和maven同理。

manage jenkins -> manage Credentials 配置凭证：

这个凭据就是你的ssh私钥，我们拉取github或者gitlab上的代码的时候都会在自己账号上配置一个公钥，然后我们就能通过ssh拉取代码了，这个私钥就是用来拉取远程代码用的。

jenkins会有一个workspace文件夹，这个文件夹下会根据流水线创建对应的文件夹并在对应的文件夹下进行编译运行脚本。我们可以修改它的默认路径，重启jenkins生效，首先找到jenkins配置文件路径，manage jenkins->configure System:

然后在该文件夹下找到对应的配置文件 config.xml：

最后修改配置项workspaceDir并重启：

到此，Jenkins的基本安装配置已经完成，下一章节我们会介绍pipeline，并用pipe编译一个项目，感谢阅读

展开全文 >>

fiddler使用教程

之前我做过一款 chrome代理插件——poseidon-chrome-proxy，这个插件的功能是通过一些配置将浏览器中的请求代理到你配置的服务器上去。这款插件的局限性是只能使用在谷歌浏览器中，而且无法代理https请求，这是因为谷歌浏览器限制了pac脚本对https请求的代理；不仅如此，该插件还存在dns污染的问题，虽然可以通过清除浏览器缓存来解决，但是也是比较糟心。最近项目中恰好遇到了需要对https进行代理的需求，经过我的研究，最终找到了一个比较满意的解决方案，它就是fiddler。

fiddler 介绍

fiddler 是一款专门用于抓取http请求的抓包工具，当启动该工具时，pc端的请求会先被代理到该工具再转发到服务器，因此我们就可以在请求转发前对请求的协议，请求头，路径，请求内容等信息进行修改。而且通过该工具你还能记录某个请求的数据并进行回放或打断点，相比较代理插件，不仅适用范围更广，调试bug也更方便。

使用指南

官方下载地址：https://www.telerik.com/download/fiddler/fiddler4，安装完成后我们进行一些配置:
点击 winConfig,勾选要代理的应用
test

点击 rules:

2

勾选 hide connects，隐藏连接信息，这些信息对我们来说是不需要去关注的。

点击 filters, 勾选 use filters ,配置我们需要调试的域名，我这里配置的是 www.baidu.com；该配置会过滤掉无关的域名，使其不会在左侧列表中显示。

fiddlerScript

fiddlerScript 是这个工具的重头戏，如图所示，该脚本中包含多个方法：
3

我们可以通过编辑这个脚本实现对请求和响应数据的修改，其语法使用的是javascript。编辑完脚本后需要点击编辑器左上角的 save script 按钮脚本才能生效。
FiddlerScript 中的主要方法包括：

  • OnBeforeRequest ：在这个方法中修改Request的内容
  • OnBeforeResponse：在这个方法中修改Response的内容
  • OnExecAction：在Fiddler界面中左下方的QuickExec Box 中输入指令，如果你的脚本处理了指定的命令，则返回true,否则返回false。
  • OnBoot：程序启动时调用该方法
  • OnShutdown：程序关闭时调用该方法

一些修改请求数据的示例,

修改cookie:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
static function OnBeforeRequest(oSession: Session) 
{ 
     if (oSession.HostnameIs('www.example.com') && 
          oSession.uriContains('pagewithCookie') && 
oSession.oRequest.headers.Contains("Cookie")) 
     { 

     var sCookie = oSession.oRequest["Cookie"]; 

     //  用replace方法或者正则表达式的方法去操作cookie的string
     sCookie = sCookie.Replace("cookieName=", "ignoreme="); 

     oSession.oRequest["Cookie"] = sCookie; 
    }

修改 requestbody:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
static function OnBeforeRequest(oSession: Session) 
{ 
    if(oSession.uriContains("http://www.cnblogs.com/TankXiao/"))
    {
        // 获取Request 中的body字符串
        var strBody=oSession.GetRequestBodyAsString();
        // 用正则表达式或者replace方法去修改string
        strBody=strBody.replace("1111","2222");
        // 弹个对话框检查下修改后的body               
        FiddlerObject.alert(strBody);
        // 将修改后的body，重新写回Request中
        oSession.utilSetRequestBody(strBody);
    }
}

修改请求路径：

1
2
3
4
5
6
7
8
9
10
11
static function OnBeforeRequest(oSession: Session) 
{ 
    if (  (oSession.url.indexOf('/test')>-1)) {   
        oSession.url = oSession.url.Replace('www.baidu.com', '127.0.0.1:8080'); 
    }
    
    if (  (oSession.url.indexOf("/test")>-1)) {  
            oSession.fullUrl= oSession.fullUrl.Replace('https://www.baidu.com', 'http://127.0.0.1:8080'); 
        }
}

debug

点击rules-> automatic breakpoint ->before requests 设置全局断点：
4
然后我们用浏览器发起一个请求，再观察fiddler:
5

此时该请求上会有一个 “T” 字形的标记，这个就是进入了断点，我们点击这个请求。在右侧界面可以观察并修改这个请求的数据，包括请求头，请求url，请求体等。修改完成后按上方的 “GO” 按钮执行。然后在右下方就会展示响应信息，如果我们打了 “after Responses” 则会进入断点。

避坑指南

  • 因为fiddler 需要修改pc端的代理，所以如果当代理被其他应用修改，可能会导致fiddler无法代理http请求，可以检查电脑的 “代理服务器设置” 是否指向 fiddler的端口（默认8888）；
  • 如果工具一直弹出 “The system proxy was changed” 提示，则是有程序在后台修改代理设置，一般一些vpn或者浏览器代理插件会干这种事情，可暂时把vpn或者插件关闭，也可以通过进程检查工具进行检查（windows 可使用 processmonitor 搜索 ProxyEnable 定位是什么程序修改了代理）；
  • 修改代理脚本前，最好对脚本进行备份。
  • 清除电脑上的根证书，WIN+R快捷键，输入：certmgr.msc， 然后回车，查找所有fiddler证书，然后删除。（https://www.cnblogs.com/ql70me/p/10345976.html）
  • “The system proxy was changed” 的另外一种解决方案，进入到Fiddler–>Rules–>Customize Rules ：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
  ## 在main()方法上方添加

static function DoReattach(o: Object, ea: EventArgs)
 {
    ScheduledTasks.ScheduleWork("reattach", 1000, innerReattach);
 }
 
 static function innerReattach()
 {
    FiddlerApplication.UI.actAttachProxy();
 }
 
 static function OnRetire()
 {
    FiddlerApplication.oProxy.remove_DetachedUnexpectedly(DoReattach);
 }

### 在main()方法中添加
FiddlerApplication.oProxy.add_DetachedUnexpectedly(DoReattach);

展开全文 >>

idea使用指南

插件推荐

  • .ignore: ignore文件提示与语法高亮插件
  • arthas idea: arthas 插件
  • camelcase: 大小写与驼峰转换插件
  • checkstyle-idea: 代码检测插件
  • cmdsupport: 脚本执行插件
  • git Commit template: commit 模板插件
  • gson format: json 转对象插件
  • ideavim：vim插件
  • key promoter x : 快捷键提示插件
  • lombok: lombok插件
  • maven helper: maven 帮助插件
  • save action: 代码保存触发一些操作
  • sonarlint: sonar 插件
  • translation: 翻译插件

idea 代码提示

  1. 配置模板注释示例(settings 搜 template 找到 file and code templates )：

1
2
3
4
5
6
7
8
9
10
11
#if (${PACKAGE_NAME} && ${PACKAGE_NAME} != "")package ${PACKAGE_NAME};#end
#parse("File Header.java")

/**
 * Description 
 * Date ${DATE} 
 * Created by ${USER}
 */
public class ${NAME} {
}

  1. 后缀代码提示（settings 搜 post 找到postfix completion 在java栏下加后缀）：

.link:

1
2
after:
List<$EXPR$> =new LinkList<>();

.list:

1
List<$EXPR$>  $END$=new ArrayList<>();

.strmap

1
Map<String,$EXPR$> $END$=new HashMap<>();
  1. live template
1
2
3
4
5
6
/error:
LOGGER.error("==========> [$END$]");
/info
LOGGER.info("==========> [$END$]");
/log
private static final Logger LOGGER = LoggerFactory.getLogger($classname$.class);
  1. todo 设置，settings 搜todo，可以自定义标签，以便对代码进行归档:
1
\b(tag)\b.*

优化配置

  1. maven:

maven->runner:

1
-Dmaven.test.skip=true

Thread count:

带C指定核数，不带C指定线程数

  1. checkStyle 版本选定8.1:
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
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
<?xml version="1.0"?>
<!DOCTYPE module PUBLIC
          "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN"
          "https://checkstyle.org/dtds/configuration_1_3.dtd">



<module name = "Checker">


  <!-- 检查property文件中是否有相同的key -->
  <module name="Translation"/>
  <!-- 文件长度不超过1500行 -->
  <module name="FileLength">
    <property name="max" value="1500"/>
  </module>



  <!-- 检查文件中是否含有'\t' -->
  <module name="FileTabCharacter"/>

  <module name="RegexpSingleline">
    <property name="format" value="\s+$"/>
    <property name="minimum" value="0"/>
    <property name="maximum" value="0"/>
    <property name="message" value="Line has trailing spaces."/>
  </module>



  <module name="TreeWalker">

    <!-- 单行长度   -->
    <module name="LineLength">
      <property name="max" value="140" />
    </module>
    <!--  检查sout输出   -->
    <module name="Regexp">
      <property name="format" value="System\.out\.println"/>
      <property name="illegalPattern" value="true"/>
      <property name="message" value="不要使用 sout 输出"/>
    </module>

    <!--   print检查   -->
    <module name="Regexp">
      <property name="format" value="printStackTrace"/>
      <property name="illegalPattern" value="true"/>
      <property name="message" value="不要使用 printStackTrace 输出"/>
    </module>
    <!-- 检查方法和构造函数的javadoc -->
    <module name="JavadocMethod">
      <property name="tokens" value="METHOD_DEF" />
    </module>
    <!-- 检查类和接口的javadoc。默认不检查author和version tags -->
    <module name="JavadocType"/>

    <!-- 检查javadoc的格式 -->
	<module name="JavadocStyle">
      <property name="checkFirstSentence" value="false"/>
    </module>
    <!-- 检查TODO:注释 -->
    <module name="TodoComment"/>
    <!-- 命名检查 -->
    <!-- 局部的final变量，包括catch中的参数的检查 -->
    <module name="LocalFinalVariableName" />

	<!-- 检查switch语句是否有default -->
    <module name="MissingSwitchDefault"/>
    <!-- 检查是否有过度复杂的布尔表达式 -->
    <module name="SimplifyBooleanExpression"/>
    <!-- 检查是否有过于复杂的布尔返回代码段 -->
    <module name="SimplifyBooleanReturn"/>
    <!-- 检查类是否为扩展设计l -->
    <!-- <module name="DesignForExtension"/> -->
    <!-- 检查只有private构造函数的类是否声明为final -->
    <module name="FinalClass"/>
    <!-- 检查工具类是否有putblic的构造器 -->
    <module name="HideUtilityClassConstructor"/>
    <!-- 检查接口是否仅定义类型 -->
    <module name="InterfaceIsType"/>
    <!-- 检查类成员的可见度 -->
    <module name="VisibilityModifier"/>


    <!-- 检查分隔符周围是否有空白 -->
    <module name="WhitespaceAround"/>
    <!-- 检查修饰符的顺序是否遵照java语言规范，默认public、protected、private、abstract、static、final、transient、volatile、synchronized、native、strictfp -->
    <module name="ModifierOrder"/>
    <!-- 检查接口和annotation中是否有多余修饰符，如接口方法不必使用public -->
    <module name="RedundantModifier"/>
    <!-- 检查是否有嵌套代码块 -->
    <module name="AvoidNestedBlocks"/>
    <!-- 检查是否有空代码块 -->
    <module name="EmptyBlock"/>
    <!-- 检查左大括号位置 -->
    <module name="LeftCurly"/>
    <!-- 检查代码块是否缺失{} -->
    <module name="NeedBraces"/>
    <!-- 检查右大括号位置 -->
    <module name="RightCurly"/>
    <!-- 检查是否在同一行初始化 -->
    <!-- <module name="AvoidInlineConditionals"/> -->
    <!-- 检查空的代码段 -->
    <module name="EmptyStatement"/>
    <!-- 检查在重写了equals方法后是否重写了hashCode方法 -->
    <module name="EqualsHashCode"/>
    <!-- 检查局部变量或参数是否隐藏了类中的变量 -->
    <module name="HiddenField">
      <property name="tokens" value="VARIABLE_DEF"/>
    </module>
    <!-- 检查是否使用工厂方法实例化 -->
    <module name="IllegalInstantiation"/>
    <!-- 检查子表达式中是否有赋值操作 -->
    <module name="InnerAssignment"/>
    <!-- 检查是否有"魔术"数字 -->
    <module name="MagicNumber">
      <property name="ignoreNumbers" value="0, 1"/>
      <property name="ignoreAnnotation" value="true"/>
    </module>



	<!-- 方法名后跟左圆括号"(" -->
    <module name="MethodParamPad" />
    <!-- 在类型转换时，不允许左圆括号右边有空格，也不允许与右圆括号左边有空格 -->
    <module name="TypecastParenPad" />
    <!-- Iterator -->
    <!-- <module name="EmptyForIteratorPad"/> -->
    <!-- 检查尖括号 -->
    <!-- <module name="GenericWhitespace"/> -->
    <!-- 检查在某个特定关键字之后应保留空格 -->
    <module name="NoWhitespaceAfter"/>
    <!-- 检查在某个特定关键字之前应保留空格 -->
    <module name="NoWhitespaceBefore"/>
    <!-- 操作符换行策略检查 -->
    <module name="OperatorWrap"/>
    <!-- 圆括号空白 -->
    <module name="ParenPad"/>
    <!-- 检查分隔符是否在空白之后 -->
    <module name="WhitespaceAfter"/>


	<!-- 方法不超过150行 -->
    <module name="MethodLength">
      <property name="tokens" value="METHOD_DEF" />
      <property name="max" value="150" />
    </module>
    <!-- 方法的参数个数不超过5个。 并且不对构造方法进行检查-->
    <module name="ParameterNumber">
      <property name="max" value="10" />
      <property name="ignoreOverriddenMethods" value="true"/>
      <property name="tokens" value="METHOD_DEF" />
    </module>


	<!-- 局部的非final型的变量，包括catch中的参数的检查 -->
    <module name="LocalVariableName" />
    <!-- 包名的检查（只允许小写字母），默认^[a-z]+(\.[a-zA-Z_][a-zA-Z_0-9_]*)*$ -->
    <module name="PackageName">
      <property name="format" value="^[a-z]+(\.[a-z][a-z0-9]*)*$" />
      <message key="name.invalidPattern" value="包名 ''{0}'' 要符合 ''{1}''格式."/>
    </module>
    <!-- 仅仅是static型的变量（不包括static final型）的检查 -->
    <module name="StaticVariableName" />
    <!-- Class或Interface名检查，默认^[A-Z][a-zA-Z0-9]*$-->
    <module name="TypeName">
      <property name="severity" value="warning"/>
      <message key="name.invalidPattern" value="名称 ''{0}'' 要符合 ''{1}''格式."/>
    </module>
    <!-- 非static型变量的检查 -->
    <module name="MemberName" />
    <!-- 方法名的检查 -->
    <module name="MethodName" />
    <!-- 方法的参数名 -->
    <module name="ParameterName " />
    <!-- 常量名的检查（只允许大写），默认^[A-Z][A-Z0-9]*(_[A-Z0-9]+)*$ -->
    <module name="ConstantName" />
    <!-- 检查数组类型定义的样式 -->
    <module name="ArrayTypeStyle"/>
    <!-- 检查方法名、构造函数、catch块的参数是否是final的 -->
    <!-- <module name="FinalParameters"/> -->
    <!-- 检查long型定义是否有大写的“L” -->
    <module name="UpperEll"/>
    <!-- 避免使用* -->
    <module name="AvoidStarImport"/>
    <!-- 检查是否从非法的包中导入了类 -->
    <module name="IllegalImport"/>
    <!-- 检查是否导入了多余的包 -->
    <module name="RedundantImport"/>
    <!-- 没用的import检查，比如：1.没有被用到2.重复的3.import java.lang的4.import 与该类在同一个package的 -->
    <module name="UnusedImports" />

  </module>


</module>
  1. 字体等优化：






展开全文 >>

linux 小结

linux 基本命令

  1. 目录操作
  • mkdir 创建文件夹
  • mkdir -p 递归创建目录
  • 创建多个目录 mkdir [-p] a b c
  • touch a b c 创建文件
  • rm -r 递归 -f 强制删除
  • cp -r 递归 复制 cp -r a/ b/
  • mv 移动（重命名）
  • ls （ll=ls -l）
  1. 压缩
  • gzip a.txt a.txt.gz
  • gunzip a.txt.gz
  • tar -c 创建 -x 解包 -v 可视化解压过程 -f 文件名 -z 压缩为gz -J xz格式
  1. 输出重定向
1
2
> 标准输出重定向 覆盖输出
>> 追加输出重定向
  1. 查看文件
  • cat -n 显示行号
  • tac
  • head 查看文件前n行 默认10 head -n xxx.txt
  • wc -l 行数 -w 单词数 -c char
1
2
3
4
5
6
7
8
9
10
## 从第3行开始显示，显示接下来10行内容: 
cat filename | tail -n +3 | head -n +10

## 过滤 -A 后n行 -B 前n行
cat test.log |grep 'xxx' -A10 -B10
## 按日期查日志
sed -n "/2022-01-14 15:05:55/,/2022-01-14 15:15:55/p" test.log
## 统计行数
wc -l file

  1. 磁盘操作
  • 查询子级目录的大小 du -h --max-depth=1 /
  • 查询磁盘情况 df -h /
  • find -type ( d 文件夹 f 文件) -name: find / -name root -type d find / -name test.log
  1. 日期
  • date date “+%F” date “+%F %T”
  • timedatectl
  • ntpdate
  1. 管道

管道一般用于过滤， A|b 命令A的正确输出作为命令B的操作对象

grep 取出含有搜寻内容的行 -v 反选，：

1
2
## tail 出有关键字的日志并输出后10行
tail -f -n200 test.log|grep '出账' -A10
  1. 其他
  • killall
  • ifconfig
  • netstat -tnlp net状态
  • top 后 M 内存排序 P cpu 排序
  1. linux 运行级别
  • systemctl poweroff 关机
  • systemctl rescue 单用户模式
  • systemctl isolate multi-user.target 命令模式
  • systemctl get-default
  1. nohup
    nohup命令用于不挂断地运行命令（关闭当前session不会中断改程序，只能通过kill等命令删除）.
1
2
3
4
5
# 将错误输出 标准输出丢弃
nohup test.jar >/dev/null 2>&1 &

# 将错误输出输出到屏幕，标准输出丢弃
nohup test.jar >/dev/null 2>&1 &
  1. 计划任务

  • at 一次性计划任务

  • systemctl status atd

  • at now +1minutes

  • cron 周期性计划任务

  • crond

  • crontable

使用crontable 创建任务后任务会记录到/var/sponl/cron里面去
执行日志保存到/var/log/cron中

1
2
##  这里，我们在每天早上 8 点整执行 find 命令；该命令会在 /home/s/coredump 目录下寻找 search 用户创建的普通 7 天前的文件，然后删除
 0 8 * * * find /home/s/coredump -user search -type f -mtime +7 -delete
  1. 文件传输

scp [-P22 端口号] local_file remote_username@remote_ip:remote_file 

1
sudo scp -o xxx xxx.jar root@192.168.1.1:/home/test
  1. 日志
  • rsyslog -linux 日志系统 /etc/rsyslog.conf
  • 日志切割 cronolog
  1. 网络设定
  • nmcli
  • 网络配置文件 :/etc/sysconfig/network-scripts/
  • nmcli device status 查看网络连接
  • nmcli device show 查看网络设备

shell

  1. #!/bin/sh是指此脚本使用/bin/sh来解释执行，#!是特殊的表示符，其后面根的是此解释此脚本的shell的路径。

  2. 变量

  • var1=”xxx”
  • $0 表示获取当前执行的shell脚本文件名，$n 表示获取当前执行的shell脚本的第n个参数值 $# 获取当前shell命令行中参数的总个数，$? 表示获取执行上一个指令的返回值（0为成功，非0为失败）
  • 变量截取 ${变量名:起始位置:截取长度}
  1. 表达式
  • test 条件表达式
  • [ 条件表达式 ]
  • 命令1 && 命令2 短路判断（如果命令1执行成功，那么我才执行命令2）
  • -f 表示是否是文件， -d 表示是否是目录，-x表示是否可执行
  1. 循环和条件分支
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
if [ 条件 ]
then
  	指令
fi

if [ 条件 ]
then
  	指令1
else
 	指令2
fi

if [ 条件 ]
then
  	指令1
elif [ 条件2 ]
then
 	指令2
else
 	指令3
fi

case 变量名 in
   值1)
      指令1
         ;;
   ...
   值n)
 	   指令n
         ;;
esac

for 值 in 列表
do
   执行语句
done

while 条件
do
   执行语句
done

continue	跳出当前循环
exit		退出程序
  1. 函数
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
#!/bin/bash
# 函数使用场景一：执行频繁的命令
dayin(){
  echo "wo de mingzi shi  111"
}
dayin

#!/bin/bash
# 函数的使用场景二
dayin(){
  echo "wo de mingzi shi $1"
}
dayin 111

#!/bin/bash
# 函数传参演示
# 定义传参数函数
dayin(){
  echo "wode mignzi shi $1"
}
# 函数传参
dayin $1

#!/bin/bash
# 函数的使用场景二
canshu = "$1"
dayin(){
  echo "wo de mingzi shi $1"
}
dayin "${canshu}"

systemctl

用于配置开机自启动或者挂掉重启

配置示例：

1
2
3
4
5
6
7
8
9
10
11
12
[Unit]
Description=mongodb
After=network.target remote-fs.target nss-lookup.target

[Service]
Type=forking
ExecStart=/xx
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/xxx
PrivateTmp=true
Restart=always
RestartSec=5

其中配置 Restart=always 和 RestartSec=5 可在进程挂了之后重启,systemctl daemon-reload 重新加载配置。

Type：定义启动时的进程行为。它有以下几种值。

  • Type=simple：默认值，执行ExecStart指定的命令，启动主进程
  • Type=forking：以 fork 方式从父进程创建子进程，创建后父进程会立即退出
  • Type=oneshot：一次性进程，Systemd 会等当前服务退出，再继续往下执行
  • Type=dbus：当前服务通过D-Bus启动
  • Type=notify：当前服务启动完毕，会通知Systemd，再继续往下执行
  • Type=idle：若有其他任务执行完毕，当前服务才会运行

展开全文 >>

sentinel 规则配置及使用

sentinel 增加规则的方式 包括三种，数据源加载，代码加载，控制台加载；每一类流控规则我都会从这三个方面去说明如何使用。

流量控制

流量控制是通过监控应用流量的qps或者并发线程数是否达到阈值来保护应用的一种手段，避免应用被瞬时的流量高峰冲垮，从而保障系统的高可用。

流量控制的方式：

  • 并发线程数流控：通过控制并发线程数来保证访问资源的流量不超过某个阈值
  • qps流控：通过控制资源的qps来达到流控的目的，qps相比较于并发线程数流控效果更为直观。

流量控制的相关概念：

  • resource：资源名称，资源可以是一个代码块或者方法
  • count: 限流阈值
  • grade: 限流阈值类型
  • limitApp: 流控针对的调用来源，若为default则不区划来源，在分布式系统中该参数有用
  • strategy: 限流策略
  • controlBehavior: 流控行为，包括直接拒绝，warm up ,排队等待。直接拒接就是超出阈值，直接拒绝后面的请求；warm up 是让系统预热一段时间，
    它的阈值并不是一开始就是设定值，会随着qps 或线程数的增加而慢慢提高到设定值；排队等待是请求过多时，让请求匀速的进入后台进行处理。采用漏斗算法，
    控制流量设置超时时间，超时的则将请求抛弃，返回错误信息

流控规则代码方式配置示例：

1
2
3
4
5
6
7
8
9

FlowRule rule1 = new FlowRule();
rule1.setResource("test.hello");
rule1.setGrade(RuleConstant.FLOW_GRADE_QPS);
// 每秒调用最大次数为 1 次
rule1.setCount(1);
List<FlowRule> rules = new ArrayList<>();
// 将控制规则载入到 Sentinel
FlowRuleManager.loadRules(rules);

流控规则控制台配置示例：

流控规则数据源json示例：

1
[{"clusterConfig":{"acquireRefuseStrategy":0,"clientOfflineTime":2000,"fallbackToLocalWhenFail":true,"resourceTimeout":2000,"resourceTimeoutStrategy":0,"sampleCount":10,"strategy":0,"thresholdType":0,"windowIntervalMs":1000},"clusterMode":false,"controlBehavior":0,"count":1.0,"grade":1,"limitApp":"default","maxQueueingTimeMs":500,"resource":"test","strategy":0,"warmUpPeriodSec":10}]

降级规则

熔断降级会在调用链路中当某个资源指数超出阈值时对这个资源的调用进行熔断，在熔断时间窗口内所有调用都快速失败调用降级方法，直到熔断恢复；
降级熔断和流控规则的区别是在超出阈值后的时间窗内所有的调用都会被降级，直到熔断恢复。

熔断降级相关概念：

  • resource：资源名称，资源可以是一个代码块或者方法
  • count: 熔断阈值
  • grade: 熔断阈值类型(秒级RT/秒级异常比例/分钟级异常数)
  • timeWindow: 降级的时间，单位秒
  • rtSlowRequestAmount: RT模式下1秒内连续多少个请求的平均RT超出阈值才能触发熔断
  • minRequestAmount: 异常熔断触发的最小请求数，请求数小于该值时即使异常比例超过阈值也不会熔断

熔断降级策略：

  • 秒级RT（默认）：在1秒内进入的n个响应中，如果最终的平均响应时间超过了阈值，那么在接下来的timeWindow 时间内会自动熔断降级接下来的响应。
  • 秒级异常比例：当每秒请求数超过n个，且异常请求的比例超过阈值，那么在接下来的timeWindow 时间内会自动熔断降级接下来的响应。
  • 分钟级异常数：当一分钟内请求的数量超过阈值后会熔断，因为统计时长是一分钟，当timeWindow降级熔断时间小于一分钟，当降级熔断结束后可能仍超过异常阈值继续进入熔断降级状态

降级熔断代码配置

1
2
3
4
5
6
7
8
9
10
11
DegradeRule rule = new DegradeRule();
List<DegradeRule> rules1=new ArrayList<>();
//资源名称
rule.setResource("test.hello");
// 熔断平均响应时间阈值
rule.setCount(0.01);
// 秒级RT
rule.setGrade(RuleConstant.DEGRADE_GRADE_RT);
rule.setTimeWindow(10);
rules1.add(rule);
DegradeRuleManager.loadRules(rules1);

流控规则控制台配置示例：

热点规则

热点规则是对热点数据进行限流，支持对特定参数和参数的值限流。热点限流会统计参数中的热点参数，并根据配置的限流阈值与模式对包含热点参数的资源进行限流。
Sentinel利用LRU策略统计最近最常访问的热点参数，结合令牌桶算法来进行参数级别的流控。

热点规则的概念：

  • resource：资源名称，资源可以是一个代码块或者方法
  • count: 熔断阈值
  • grade: 熔断阈值类型(秒级RT/秒级异常比例/分钟级异常数)
  • durationInSec: 统计窗口时间长度（单位为秒，默认1S） 默认1S
  • controlBehavior: 流控效果（支持快速失败和匀速排队模式，默认快速失败）
  • maxQueueingTimeMs: 最大排队等待时长（仅在匀速排队模式生效）
  • paramIdx: 热点参数的索引，必填，对应 SphU.entry(xxx, args) 中的参数索引位置
  • paramFlowItemList: 参数例外项，可以针对指定的参数值单独设置限流阈值，不受前面 count 阈值的限制。仅支持基本类型和字符串类型

热点规则代码配置

1
2
3
4
5
6
7
8
9
ParamFlowRule paramFlowRule = new ParamFlowRule("resourceName")
        .setParamIdx(0)
        .setCount(5);
// 单独设置限流 QPS，设置param 参数限流规则
ParamFlowItem item = new ParamFlowItem().setObject("param")
        .setClassType(int.class.getName())
        .setCount(10);
paramFlowRule.setParamFlowItemList(Collections.singletonList(item));
ParamFlowRuleManager.loadRules(Collections.singletonList(paramFlowRule));

流控规则控制台配置示例：

系统规则

系统规则限流是从整体维度上去进行流控，结合应用的load,cpu使用率,总体平均RT,入口QPS和并发线程数等几个维度的监控指标来对总体的流量进行限流，在系统稳定的前提下保证系统的吞吐量

系统规则模式：

  • load 自适应: 当系统负载高于某个阈值，就禁止或者减少流量的进入，当load 开始好转，则恢复流量的进入，通过读取操作系统参数 load1 来判断，仅对类unix系统生效。
  • cpu 使用率: 当cpu 使用率超过阈值开始限流
  • 平均RT: 当系统平均响应时间超过阈值开始限流
  • 并发线程数: 当并发线程数超过阈值开始限流
  • 入口qps: 当系统入口qps超过阈值开始限流

系统规则的概念

  • highestSystemLoad: 负载触发值
  • avgRt: 平均响应时间
  • qps: 应用入口qps
  • highestCpuUsage: cpu使用率

系统规则配置代码示例：

因为系统规则只对入口规则进行限定,所以需要将资源通过注解配置 @SentinelResource(entryType = EntryType.IN) 来指定为入口资源

1
2
3
4
5
6
7
8
9
10
11
12
13
14
// 指定资源为入口资源
@GetMapping("/test3")
@SentinelResource(entryType = EntryType.IN)
public String test3(){
    return ">>>>>>>>";
}

SystemRule systemRule = new SystemRule();
systemRule.setHighestCpuUsage(0.8);
systemRule.setAvgRt(10);  
systemRule.setQps(10);   
systemRule.setMaxThread(10);  
systemRule.setHighestSystemLoad(2.5);   
SystemRuleManager.loadRules(Collections.singletonList(systemRule));

授权规则

授权规则的作用是根据调用来源来拦截调用资源的请求，当不符合放行规则的请求过来就会被拒绝掉。

授权规则的概念

  • resource: 资源名
  • limitApp: 请求来源，对应的黑名单或者白名单；
  • qps: 应用入口qps
  • strategy: 限制模式，分黑名单模式（authority_black），白名单模式（authority_white 默认）

授权规则代码配置示例：

1
2
3
4
5
AuthorityRule authorityRule = new AuthorityRule();
authorityRule.setStrategy(RuleConstant.AUTHORITY_BLACK);
authorityRule.setLimitApp("127.0.0.1");
authorityRule.setResource("test.hello");
AuthorityRuleManager.loadRules(Collections.singletonList(authorityRule));

这里 limitApp 我设置的是 请求来源的ip 地址，这个ip地址是要我们手动去通过 ContextUtil.enter(resourceName, origin) 来设置的。

1
2
3
4
5
6
7
public class MyInterceptor implements HandlerInterceptor {
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        ContextUtil.enter("test.hello",  request.getHeader("x-forwarded-for"));
        return true;
    }
}

spring web 拦截适配

前文提到过 sentinel-spring-webmvc-adapter 依赖会提供一个将拦截器 SentinelWebInterceptor, 源码为：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
protected String getResourceName(HttpServletRequest request) {
    Object resourceNameObject = request.getAttribute(HandlerMapping.BEST_MATCHING_PATTERN_ATTRIBUTE);
    if (resourceNameObject != null && resourceNameObject instanceof String) {
        String resourceName = (String)resourceNameObject;
        UrlCleaner urlCleaner = this.config.getUrlCleaner();
        if (urlCleaner != null) {
            resourceName = urlCleaner.clean(resourceName);
        }

        if (StringUtil.isNotEmpty(resourceName) && this.config.isHttpMethodSpecify()) {
            resourceName = request.getMethod().toUpperCase() + ":" + resourceName;
        }

        return resourceName;
    } else {
        return null;
    }
}

它会解析一个请求为的请求地址为一个资源名，然后在sentinel控制台上就能看到各个请求的流控数据。但它没有提供请求适配各类流控规则的相关代码，
我们想要无缝的通过请求去适配各种流控规则还需要引入依赖：

1
2
3
4
5
<dependency>
    <groupId>com.alibaba.csp</groupId>
    <artifactId>sentinel-web-servlet</artifactId>
    <version>1.8.1</version>
</dependency>

然后注册一个过滤器：

1
2
3
4
5
6
7
8
9
10
11

@Bean
public FilterRegistrationBean sentinelFilterRegistration() {
    FilterRegistrationBean<Filter> registration = new FilterRegistrationBean<>();
    registration.setFilter(new CommonFilter());
    registration.addUrlPatterns("/*");
    registration.setName("sentinelFilter");
    registration.setOrder(1);

    return registration;
}

接入 filter 之后，所有访问的 Web URL 就会被自动统计为 Sentinel 的资源，可以针对单个 URL 维度进行流控。
若希望区分不同 HTTP Method，可以调用 CommonFilter.init(FilterConfig filterConfig) 方法将 HTTP_METHOD_SPECIFY 这个 init parameter 设为 true，给每个 URL 资源加上前缀，比如 GET:/foo
这个包中一个重要类是 WebCallbackManager 许多限流配置都需要使用到这个类的api。

设置限流处理器：

1
2
3
4
5
6
WebCallbackManager.setUrlBlockHandler((request, response, e) -> {
    PrintWriter writer = response.getWriter();
    writer.println(">>>>");
    writer.close();
});

设置url清洗器：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
WebCallbackManager.setUrlCleaner(new UrlCleaner() {
    @Override
    public String clean(String originUrl) {
        if (originUrl == null || originUrl.isEmpty()) {
            return originUrl;
        }
        // 比如将满足 /foo/{id} 的 URL 都归到 /foo/*
        if (originUrl.startsWith("/foo/")) {
            return "/foo/*";
        }
        // 不希望统计 *.ico 的资源文件，可以将其转换为 empty string (since 1.6.3)
        if (originUrl.endsWith(".ico")) {
            return "";
        }
        return originUrl;
    }
});

设置请求来源名称，通过该配置我们在授权规则中就不需要通过ContextUtil.enter(resourceName, origin) 设置，而是通过一个自定义
的RequestOriginParser 直接指定请求的来源，也就是授权规则中的 limitApp:

1
2
3
WebCallbackManager.setRequestOriginParser(request -> {
    return request.getHeader("x-forwarded-for");
});

展开全文 >>

sentinel 持久化

我们之前配置的流控规则都是存储在应用的内存中的，这种方式明显无法满足我们实际开发的需求，一旦项目被重启，流控规则就被初始化了，需要我们再次去重新配置，因此规则的持久化就显得很有必要了。

本节会介绍几类主流持久化方式并对自定义持久化做介绍

文件持久化

文件持久化是通过 sentinel spi 扩展点来加载本地文件中的持久化数据到内存中，它依赖接口 InitFunc，对于非spring项目这种方式可以很便捷的实现
文件持久化。

实现文件持久化首先要自定义一个类并实现InitFunc 接口：

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

public class MyflieInitFunc implements InitFunc {
    @Override
    public void init() throws Exception {
        URL resource = MyflieInitFunc.class.getClassLoader().getResource("");
        File file = new File(resource.getPath()+"/config/flow.json");
        File fileParent = file.getParentFile();
        if(!fileParent.exists()){
            fileParent.mkdirs();
        }
        if (!file.exists()){
            file.createNewFile();
        }
        ReadableDataSource<String, List<FlowRule>> flowReadDataSource = new FileRefreshableDataSource<>(
            resource.getPath()+"/config/flow.json",
            source -> JSON.parseObject(
                source,
                new TypeReference<List<FlowRule>>() {
                }
            ));
        FlowRuleManager.register2Property(flowReadDataSource.getProperty());
        WritableDataSource<List<FlowRule>> flowWriteDataSource = new FileWritableDataSource<>(
            resource.getPath()+"/config/flow.json",
            t->JSON.toJSONString(t)
        );
        WritableDataSourceRegistry.registerFlowDataSource(flowWriteDataSource);
    }
}

然后在resources 文件夹下新建文件 META-INF\services\com.alibaba.csp.sentinel.init.InitFunc
内容为MyflieInitFunc 的类路径：

1
com.muggle.sentinel.config.MyflieInitFunc

完成以上步骤后，文件持久化的方式就配置完成了。

InitFunc 的资源初始化方法 init() 并不是在项目启动的时候调用的，而是在首次产生流控数据的时候调用的，
也就是说它是一个懒加载的方法。
在文件持久化配置中，FileRefreshableDataSource , FileWritableDataSource , FlowRuleManager 这三个类是有必要去熟识的。

  • FlowRuleManager 流控规则管理器，用于对流控规则的加载和管理，每类规则都有对应的管理器，后文会介绍。
  • FileRefreshableDataSource 流控规则读取及刷新的类，该类配置到sentinel中后会定时拉取流控文件中的流控规则
  • FileWritableDataSource 流控规则写入类，当我们在控制台编辑新的流控规则后，控制台会将规则推送给应用，应用接收到推送的规则后，
    会通过该类将数据写入流控文件中

FlowRuleManager 源码分析

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

public class FlowRuleManager {
    private static final AtomicReference<Map<String, List<FlowRule>>> flowRules = new AtomicReference();
    private static final FlowRuleManager.FlowPropertyListener LISTENER = new FlowRuleManager.FlowPropertyListener();
    private static SentinelProperty<List<FlowRule>> currentProperty = new DynamicSentinelProperty();
    private static final ScheduledExecutorService SCHEDULER = Executors.newScheduledThreadPool(1, new NamedThreadFactory("sentinel-metrics-record-task", true));
     
    public static List<FlowRule> getRules() {
       
        List<FlowRule> rules = new ArrayList();
        Iterator var1 = ((Map)flowRules.get()).entrySet().iterator();

        while(var1.hasNext()) {
            Entry<String, List<FlowRule>> entry = (Entry)var1.next();
            rules.addAll((Collection)entry.getValue());
        }

        return rules;
    }
    
    public static void loadRules(List<FlowRule> rules){
         currentProperty.updateValue(rules);
    }
    
     public static boolean hasConfig(String resource) {
         return ((Map)flowRules.get()).containsKey(resource);
    }
}

该类的静态属性包括 流控规则数组 flowRules ，用于监控流控规则更新的监听器LISTENER , 轮询监听流控配置的线程池SCHEDULER,sentinel 配置类currentProperty.
而它几个api也很明了，就是对流控规则的增删改查。

FileRefreshableDataSource 源码分析

FileRefreshableDataSource 继承了AutoRefreshDataSource,而AutoRefreshDataSource 中有一个线程池 service 用于拉取 文件中存储的规则
以及拉取间隔 recommendRefreshMs .
：

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

public abstract class AutoRefreshDataSource<S, T> extends AbstractDataSource<S, T> {
    private ScheduledExecutorService service;
    protected long recommendRefreshMs = 3000L;

    public AutoRefreshDataSource(Converter<S, T> configParser) {
        super(configParser);
        this.startTimerService();
    }
......
     private void startTimerService() {
            this.service = Executors.newScheduledThreadPool(1, new NamedThreadFactory("sentinel-datasource-auto-refresh-task", true));
            this.service.scheduleAtFixedRate(new Runnable() {
                public void run() {
                    try {
                        if (!AutoRefreshDataSource.this.isModified()) {
                            return;
                        }
    
                        T newValue = AutoRefreshDataSource.this.loadConfig();
                        AutoRefreshDataSource.this.getProperty().updateValue(newValue);
                    } catch (Throwable var2) {
                        RecordLog.info("loadConfig exception", var2);
                    }
    
                }
            }, this.recommendRefreshMs, this.recommendRefreshMs, TimeUnit.MILLISECONDS);
        }

}

我们重点关注 startTimerService 这个方法,这个方法是在构造器里面调用的，也就是说当你new 一个 FileRefreshableDataSource 时就会调用该方法

该方法就是通过线程池定时调用isModified 方法判断配置是否更新过，如果更新了就同步更新到父类属性 SentinelProperty 中，代码对应:

1
AutoRefreshDataSource.this.getProperty().updateValue(newValue)

不难判读出，父类抽象类的property 属性才是真正的获取规则提供拦截判断的关键属性。后文也会用到这个知识点，这里记一下。

我们可以看一下 FileRefreshableDataSource 构造函数：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

public FileRefreshableDataSource(File file, Converter<String, T> configParser) throws FileNotFoundException {
       this(file, configParser, 3000L, 1048576, DEFAULT_CHAR_SET);
   }

   public FileRefreshableDataSource(String fileName, Converter<String, T> configParser) throws FileNotFoundException {
       this(new File(fileName), configParser, 3000L, 1048576, DEFAULT_CHAR_SET);
   }

   public FileRefreshableDataSource(File file, Converter<String, T> configParser, int bufSize) throws FileNotFoundException {
       this(file, configParser, 3000L, bufSize, DEFAULT_CHAR_SET);
   }

   public FileRefreshableDataSource(File file, Converter<String, T> configParser, Charset charset) throws FileNotFoundException {
       this(file, configParser, 3000L, 1048576, charset);
   }

   public FileRefreshableDataSource(File file, Converter<String, T> configParser, long recommendRefreshMs, int bufSize, Charset charset)

不难看出，如果在 new FileRefreshableDataSource 时不指定刷新间隔就取默认值 3000 毫秒。

FileWritableDataSource 源码分析

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

public class FileWritableDataSource<T> implements WritableDataSource<T> {
    private static final Charset DEFAULT_CHARSET = Charset.forName("UTF-8");
    private final Converter<T, String> configEncoder;
    private final File file;
    private final Charset charset;
    private final Lock lock;
    
    public void write(T value) throws Exception {
        this.lock.lock();
        try {
            String convertResult = (String)this.configEncoder.convert(value);
            FileOutputStream outputStream = null;

            try {
                outputStream = new FileOutputStream(this.file);
                byte[] bytesArray = convertResult.getBytes(this.charset);
                RecordLog.info("[FileWritableDataSource] Writing to file {}: {}", new Object[]{this.file, convertResult});
                outputStream.write(bytesArray);
                outputStream.flush();
            } finally {
                if (outputStream != null) {
                    try {
                        outputStream.close();
                    } catch (Exception var16) {
                    }
                }

            }
        } finally {
            this.lock.unlock();
        }
    }
}

代码结构也很了然，一个数据转换器，一个 file 一个lock ,当框架调用 write 方法时上锁并往 file中写配置。

分析得差不多了，让我们看看实战效果吧；

首先启动项目和控制台，然后在控制台上配置一个流控规则，可以观察到项目规则存储文件中多了点内容：
2

文件中新增的数据：

1
[{"clusterConfig":{"acquireRefuseStrategy":0,"clientOfflineTime":2000,"fallbackToLocalWhenFail":true,"resourceTimeout":2000,"resourceTimeoutStrategy":0,"sampleCount":10,"strategy":0,"thresholdType":0,"windowIntervalMs":1000},"clusterMode":false,"controlBehavior":0,"count":1.0,"grade":1,"limitApp":"default","maxQueueingTimeMs":500,"resource":"test","strategy":0,"warmUpPeriodSec":10}]

我们重启项目和控制台规则也不会丢失，规则持久化生效。

通过分析我们知道，这种持久化方式是一种拉模式，胜在配置简单，不需要外部数据源就能完成流控数据的持久化。由于规则是用 FileRefreshableDataSource 定时更新的，所以规则更新会有延迟。
如果FileRefreshableDataSource定时时间过大，可能长时间延迟；如果FileRefreshableDataSource过小，又会影响性能；
因为规则存储在本地文件，如果需要迁移微服务，那么需要把规则文件一起迁移，否则规则会丢失。

文件持久化能应付我们需求的大部分场景，但对于微服务而言是不那么满足要求的；
因为文件持久化就必定要求我们在服务器上提供一个用于存储配置文件的文件夹，而微服务项目大部分情况是容器部署，这就让文件持久化显得不那么好用了。

为此，官方提供了自定义的持久化maven依赖：

1
2
3
4
5
<dependency>
    <groupId>com.alibaba.csp</groupId>
    <artifactId>sentinel-datasource-extension</artifactId>
</dependency>

以及在这个依赖的基础上开发的以CONSUL NACOS REDIS 作为数据源的maven 依赖：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
<dependency>
    <artifactId>sentinel-datasource-consul</artifactId>
    <groupId>com.alibaba.csp</groupId>
</dependency>
<dependency>
    <artifactId>sentinel-datasource-redis</artifactId>
    <groupId>com.alibaba.csp</groupId>
</dependency>

<dependency>
    <artifactId>sentinel-datasource-nacos</artifactId>
    <groupId>com.alibaba.csp</groupId>
</dependency>

nacos持久化

以上三种种持久化不同于文件持久化，它们是推模式的，而且迁移部署起来更为方便，符合微服务的特性。接下来我们就以nacos持久化为例来学习一下这种方式是怎么配置的。

首先引入 nacos 相关依赖依赖：

1
2
3
4
5

<dependency>
    <artifactId>sentinel-datasource-nacos</artifactId>
    <groupId>com.alibaba.csp</groupId>
</dependency>

然后通过FlowRuleManager 注册数据源就ok了

1
2
3
4
ReadableDataSource<String, List<FlowRule>> flowRuleDataSource = new NacosDataSource<>(remoteAddress, groupId, dataId,
    source -> JSON.parseObject(source, new TypeReference<List<FlowRule>>() {
    }));
FlowRuleManager.register2Property(flowRuleDataSource.getProperty());

remoteAddress 是nacos 的地址； groupId和dataId均为nacos配置中心的属性，在创建配置项的时候由使用者自定义，如图为在nacos创建配置项的截图：

3

启动nacos，启动我们的项目和控制台，然后修改nacos中的配置项，就能再控制台上观测到规则变化，nacos中存储的规则也是json,我们可以把文件持久化教程中产生json
复制进去，这里就不在赘述。

这种模式是推模式，优点是这种方式有更好的实时性和一致性保证。因为我们和文件持久化比起来少注册了一个与FileWritableDataSource 对应的类，
也就是说应用中更新的规则不能反写到nacos,只能通过nacos读取到配置；因此我们在控制台上修改的规则也不会持久化到nacos中。这样设计是合理的，因为nacos作为
配置中心不应该允许应用去反写自己的配置。

源码分析

因为文件持久化分析了一部分源码，因此这里不会对源码分析太多，只简单的介绍它是如何去读取到配置的。

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

public class NacosDataSource<T> extends AbstractDataSource<String, T> {

    private static final int DEFAULT_TIMEOUT = 3000;
    private final ExecutorService pool;
    private final Listener configListener;
    private final String groupId;
    private final String dataId;
    private final Properties properties;
    private ConfigService configService;

    public NacosDataSource(final Properties properties, final String groupId, final String dataId, Converter<String, T> parser) {
        super(parser);
        this.pool = new ThreadPoolExecutor(1, 1, 0L, TimeUnit.MILLISECONDS, new ArrayBlockingQueue(1), new NamedThreadFactory("sentinel-nacos-ds-update"), new DiscardOldestPolicy());
        this.configService = null;
        if (!StringUtil.isBlank(groupId) && !StringUtil.isBlank(dataId)) {
            AssertUtil.notNull(properties, "Nacos properties must not be null, you could put some keys from PropertyKeyConst");
            this.groupId = groupId;
            this.dataId = dataId;
            this.properties = properties;
            this.configListener = new Listener() {
                public Executor getExecutor() {
                    return NacosDataSource.this.pool;
                }

                public void receiveConfigInfo(String configInfo) {
                    RecordLog.info("[NacosDataSource] New property value received for (properties: {}) (dataId: {}, groupId: {}): {}", new Object[]{properties, dataId, groupId, configInfo});
                    T newValue = NacosDataSource.this.parser.convert(configInfo);
                    NacosDataSource.this.getProperty().updateValue(newValue);
                }
            };
            this.initNacosListener();
            this.loadInitialConfig();
        } else {
            throw new IllegalArgumentException(String.format("Bad argument: groupId=[%s], dataId=[%s]", groupId, dataId));
        }
    }
}

我们看它的构造方法，创建了一个线程池，然后通过这个线程池 new 了一个nacos的Listener，Listener是一个监听器，initNacosListener() 方法是将监听器
注册到 nacos的configService 里面，通过这个监听器去监听nacos的配置变化，当配置发生更新的时候，调用监听器的 receiveConfigInfo 方法：

1
2
3
4
5
6
public void receiveConfigInfo(String configInfo) {
    RecordLog.info("[NacosDataSource] New property value received for (properties: {}) (dataId: {}, groupId: {}): {}", new Object[]{properties, dataId, groupId, configInfo});
    T newValue = NacosDataSource.this.parser.convert(configInfo);
    NacosDataSource.this.getProperty().updateValue(newValue);
}

前面分析文件持久话我们就分析过，配置最终要被更新到父类的property 属性里面，再这里我们也看到了同样的代码。

展开全文 >>

流控组件-sentinel

sentinel介绍

sentinel 是阿里开源的流量控制，熔断降级，系统负载保护的一个Java组件；

Sentinel 分为两个部分:
核心库（Java 客户端）不依赖任何框架/库，能够运行于所有 Java 运行时环境，同时对 Dubbo / Spring Cloud 等框架也有较好的支持。
控制台（Dashboard）基于 Spring Boot 开发，打包后可以直接运行，不需要额外的 Tomcat 等应用容器。

sentinel 官方文档点击这里

快速开始

我们这里还是以springboot 项目写一个demo，创建完成springboot 项目之后pom中引入依赖：

1
2
3
4
5
<dependency>
    <groupId>com.alibaba.csp</groupId>
    <artifactId>sentinel-core</artifactId>
    <version>1.8.1</version>
</dependency>

然后定义流控规则并加载到内存：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

@Configuration
public class SentileConfig {


    @PostConstruct
    private void initRules() throws Exception {
        FlowRule rule1 = new FlowRule();
        rule1.setResource("test.hello");
        rule1.setGrade(RuleConstant.FLOW_GRADE_QPS);
        rule1.setCount(1);   // 每秒调用最大次数为 1 次
        List<FlowRule> rules = new ArrayList<>();
        rules.add(rule1);
        // 将控制规则载入到 Sentinel
        com.alibaba.csp.sentinel.slots.block.flow.FlowRuleManager.loadRules(rules);
    }
}

然后创建 controller 并定义资源：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

@RestController
public class TestController {
   

    @GetMapping("/test0")
    public String test0(){
        try {
            Entry resourceName = SphU.entry("test.hello");
            return resourceName.toString();
        } catch (BlockException e) {
            e.printStackTrace();
            return "error";
        }
    }
}

然后我们启动项目并访问 http://localhost:8081/test0 然后不断的刷新，就会发现如果刷新频率超过一秒就会返回error 否则会返回一个时间戳。
这里这些类的api和源码我们先不介绍，只对其功能先做一个大致的体验。

接下来我们继续引入依赖：

1
2
3
4
5
<dependency>
    <groupId>com.alibaba.csp</groupId>
    <artifactId>sentinel-annotation-aspectj</artifactId>
    <version>1.8.1</version>
</dependency>

同时注入一个切面到springboot 中去：

1
2
3
4
5
@Bean
public SentinelResourceAspect sentinelResourceAspect() {
    return new SentinelResourceAspect();
}

这个时候我们就可以通过注解去做流量控制了，写一个接口测试一下：

1
2
3
4
5
6
@GetMapping("/test")
@SentinelResource(value = "test.hello")
public String test(){
    return "success";
}

同样通过浏览器访问这个接口并不断刷新，会发现会频率过快的时候会返回 springboot 的错误页面，这是因为当aop切面会抛出 BlockException，当没有对应的
异常处理器的时候springboot就会返回默认错误页面。这个时候我们有两种方式处理我们超出访问频率的时候的逻辑。

第一种，加降级方法：

1
2
3
4
5
6
7
8
9
10
@GetMapping("/test")
   @SentinelResource(value = "test.hello",fallback = "testFallback")
   public String test(){
       return "success";
   }
   
   public String testFallback() {
       return "xxx";
   }

第二种，加BlockException异常处理器：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

@ControllerAdvice
public class ExceptionHandlerConfig {

    private Logger logger = LoggerFactory.getLogger(this.getClass());

    @ExceptionHandler(BlockException.class)
    @ResponseBody
    public ResultWrapper sentinelBlockHandler(BlockException e) {
        logger.warn("Blocked by Sentinel: {}", e.getRule());
        // Return the customized result.
        return "error";
    }
}

对所有controller 层做流控

sentinel 还提供了 spring-mvc 的拦截器，配置该拦截器你可以对你项目的所有所有请求进行流控管理，首先我们需要引入依赖：

1
2
3
4
5
<dependency>
    <groupId>com.alibaba.csp</groupId>
    <artifactId>sentinel-spring-webmvc-adapter</artifactId>
    <version>1.8.1</version>
</dependency>

然后注入一个sentinel 的拦截器：

1
2
3
4
5
6
7
8
9
10
11
12
@Configuration
public class SimpleWebmvcConfig implements WebMvcConfigurer {
    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        // 注冊sentinel 拦截器
        SentinelWebMvcConfig config = new SentinelWebMvcConfig();
        config.setHttpMethodSpecify(true);
        config.setWebContextUnify(true);
        config.setBlockExceptionHandler(new SimpleBlockExceptionHandler());
        registry.addInterceptor(new SentinelWebInterceptor(config)).addPathPatterns("/**");
    }
}

代码中 SimpleBlockExceptionHandler 是自定义流控异常处理器，作用是处理流控异常 BlockException 源码如下：

1
2
3
4
5
6
7
8
9
10
11

public class SimpleBlockExceptionHandler implements BlockExceptionHandler {
    @Override
    public void handle(HttpServletRequest httpServletRequest, HttpServletResponse httpServletResponse, BlockException e) throws Exception {
        httpServletResponse.setContentType("application/json");
        PrintWriter out = httpServletResponse.getWriter();
        out.print("{\"code\":500}");
        out.flush();
        out.close();
    }
}

SentinelWebMvcConfig 是流控配置类，通过其属性命名就不难猜出其作用 isHttpMethodSpecify 是否区分请求方式；
isWebContextUnify是否使用统一web上下文； UrlCleaner 是url清理器，作用是对url进行整理

接入控制台

sentinel 为我们提供了一个控制台应用，通过这个控制台我们可以直观的看到流控数据，动态的修改流控规则，下面让我们看看如何接入控制台。

首先引入依赖：

1
2
3
4
5
<dependency>
    <groupId>com.alibaba.csp</groupId>
    <artifactId>sentinel-transport-simple-http</artifactId>
    <version>1.8.1</version>
</dependency>

这个依赖sentinel连接 控制端的通讯包。

然后添加配置：

1
csp.sentinel.dashboard.server=localhost:8080

注意，因为这个配置项不是属于 springboot的 所以不能添加在application中，要通过 -D 的方式在jvm启动的时候添加这个配置项。

再去 sentinel的github 下载 控制台jar包 ，启动该jar包；访问8080 端口，
登录账号密码和密码都是 sentinel。这个控制台实际上是一个springboot应用，启动端口和账号密码都可以通过application 修改。
接下来，启动我们自己的应用，并访问一些接口，我们就能再界面上看到监控数据：
sentinel-dashboard

通过控制台我们可以监控流量，管理流控降级等规则，这些规则都是存储在我们程序应用的内存中的，因此我们还需要学会这些规则的配置使用及其持久化。

sentinel 官方还提供了 springcloud 的包，可以让我们很方便的在 spring cloud 项目中使用sentinel，springcloud 中使用 sentinel和 springboot
中使用sentinel方式差不多，只是多了一个链路调用；因此我们要先学会了如何在 springboot中使用它。

展开全文 >>

kafka+spring boot

前文介绍了 kafka 的相关特性和原理，这一节我们将学习怎么在springboot中使用kafka；

首先导入依赖

1
2
3
4
<dependency>
   <groupId>org.springframework.kafka</groupId>
   <artifactId>spring-kafka</artifactId>
</dependency>
more >>

展开全文 >>

开发小计

接手项目的一次采坑

springboot 有读取外部配置文件的方法，如下优先级：

  • 第一种是在jar包的同一目录下建一个config文件夹，然后把配置文件放到这个文件夹下。
  • 第二种是直接把配置文件放到jar包的同级目录。
  • 第三种在classpath下建一个config文件夹，然后把配置文件放进去。
  • 第四种是在classpath下直接放配置文件。

myisam 将整数型索引设置可为null的索引时会被变成可变索引

1、方式一
java -jar x.jar a b c 通过main(String[] args ) ,传入到args

2、方式二
java -jar x.jar -Da=111 -Db=222 -Dc=3333 通过 System.getProperty(“a”); 方式获取。作为环境变量

3、方式三
java -jar x.jar –a=111 –b=2222 是springboot支持的写法，可以通过@Value(“${a}”） 获取

maven dockerfile 打包

1
mvn package org.springframework.boot:spring-boot-maven-plugin:2.3.5.RELEASE:build-info dockerfile:build

指定settings

1
2

mvn install --settings /xxx/settings.xml

安装本地jar

mvn install:install-file -DgroupId=com.baidu -DartifactId=ueditor -Dversion=1.0.0 -Dpackaging=jar -Dfile=ueditor-1.1.2.jar

1
2
3
4
5
6
7
-Dfile=/Users/lcc/IdeaProjects/dubhe-node/dubhe-node-provider/lib/ring/release/tdh-5.2/hadoop-annotations-2.7.2-transwarp-5.2.0.jar   
-DgroupId=org.apache.hadoop  
-DartifactId=hadoop-annotations 
-Dversion=hadoop-2.7.2-transwarp-5.2.0-SNAPSHOT 
-Durl=http://xxxx/repository/maven-snapshots/ 
-Dpackaging=jar 
-DrepositoryId=snapshots

maven 推包到远程

1
mvn -s "D:\data\maven\settings.xml" deploy:deploy-file -Dfile=libs/xxx.jar -DgroupId=com.qcloud -DartifactId=xxx -Dversion=1.1.1.Alpha -Dpackaging=jar -Durl=https://mirrors.cloud.xxx/maven-public/ -DrepositoryId=aaa

docker

当 dockerfile-maven-plugin 插件版本冲突的时候 会报一个莫名其妙的异常：

1
2
3
no String-argument constructor/factory method to deserialize from String value ('xxx')
[ERROR]  at [Source: N/A; line: -1, column: -1] (through reference chain: java.util.LinkedHashMap["xxx"])

DOCKER_HOST:

1
tcp://127.0.0.1:2375

设置之后报错：

1
No connection could be made because the target machine actively refused it.

原因：需要给2375端口加上守护进程

勾选 expose daemon on tcp://…….tls

nohup java -jar xxxx.jar >/dev/null 2>&1&

kafka +zk 的一个坑

配置文件中 listeners=PLAINTEXT:host 配置的地址是注册地址，也就是和客户端同一网络环境的地址，否则客户端无法找到kafka
zk中新特性(zookeeper 3.5 AdminServer) 占用8080端口，改log位置需要修改脚本

openjdk的两种包

一种是带devel 命名的，有tools,否则只有jre

mysql 清除表碎片

https://blog.csdn.net/weixin_34151001/article/details/113191032

mysql> alter table 表名 engine=InnoDB

mysql>optimize table test.t1;

展开全文 >>

kafka事务

kafka 的事务是从0.11 版本开始支持的，kafka 的事务是基于 Exactly Once 语义的，它能保证生产或消费消息在跨分区和会话的情况下要么全部成功要么全部失败

生产者事务

当生产者投递一条事务性的消息时，会先获取一个 transactionID ，并将Producer 获得的PID 和 transactionID 绑定，当 Producer 重启，Producer
会根据当前事务的 transactionID 获取对应的PID。
kafka 管理事务是通过其组件 Transaction Coordinator 来实现的，这个组件管理每个事务的状态，Producer 可以通过transactionID 从这个组件中获得
对应事务的状态，该组件还会将事务状态持久化到kafka一个内部的 Topic 中。
生产者事务的场景：
一批消息写入 a、b、c 三个分区，如果 ab写入成功而c失败，那么kafka就会根据事务的状态对消息进行回滚，将ab写入的消息剔除掉并通知 Producer 投递消息失败。

消费者事务

消费者事务的一致性比较弱，只能够保证消费者消费消息是精准一次的（有且只有一次）。消费者有一个参数 islation.level，这个参数指定的是事务的隔离级别。
它的默认值是 read_uncommitted（未提交读），意思是消费者可以消费未commit的消息。当参数设置为 read_committed，则消费者不能消费到未commit的消息。

事务的使用场景

kafka事务主要是为了保证数据的一致性，现列举如下几个场景供读者参考：

  • producer发的多条消息组成一个事务，这些消息需要对consumer同时可见或者同时不可见；
  • producer可能会给多个topic发送消息，需要保证消息要么全部发送成功要么全部发送失败（操作的原子性）；
  • 消费者 消费一个topic，然后做处理再发到另一个topic，这个消费和转发的动作应该在同一事物中；
  • 如果下游消费者只有等上游消息事务提交以后才能读到，当吞吐量大的时候就会有问题，因此有了 read committed和read uncommitted两种事务隔离级别

展开全文 >>

聊一聊代码规范

代码混乱的常见问题

很多时候我们项目迭代到后期，项目会变得很混乱，往往只有少数人能知道某段代码是干嘛的和该如何去改，或者是干脆谁都不知道，只能靠通过注释去猜测这段代码可能的作用。原因有可能是因为团队内部的人事变动，导致原先写这段代码的人不再管理这段代码了，并且代码写的实在是屎没人捋的清。往往我们称这类代码为“祖传代码”，就像祖宗传下来的代码一样，没人懂没人敢动。祖传代码一多，这个项目就变成了屎一样，开发人员再这基础上迭代就如同屎海翻腾，恶心别人也恶心自己。这是一个很可怕的恶心循环，我们如何去避免这种事情发生呢？先让我们分析下这类代码的通病

代码又臭又长

我见过最长的方法是5000多行，那段代码没人敢动，只敢往下加 if else，每次需要改这段代码的开发都战战兢兢，生怕出现什么莫名其妙的bug。java 可是一门面向对象的语言，一个方法里面有5000多行可以说是很可恶的事情了。我想一开始代码长度可能没这么夸张，是什么导致这种结果的？一个是当初写这段代码的人本身写的是直来直去的方法，一堆if else ；后面迭代的开发，面对这么长的代码瞬间失去了从头读到尾的耐心，直接继续在后面加 if else 迭代，最后这个方法就变成了一个缝合怪一样的玩意。

好的 sql 可以很大程度上简化代码的复杂程度，但是太过复杂sql 本身就会给后来的开发人员造成阅读困难，结果又是变成一条无人敢动的祖传代码，我想这应该是不少公司极度抵制存储过程的原因之一。当然不少银行应用开发还是大量使用存储过程，存储过程有用武之地的，但是一个又臭又长的存储过程就等着变成祖传代码吧。当年我见到一个60多个join的sql，看到第一眼就惊为天人从此难以忘怀，当然那段sql也成了没人敢去动的代码了。

代码逻辑不明所以

代码逻辑不明所以是我们开发很容易去犯的毛病，是一个不致命却烦人的毛病。在代码上的体现是，逻辑判断写的比较反人类各种双重否定是肯定，不把你绕晕不罢休。或者是写起代码来东一榔头西一棒槌，让人不知道你想干嘛。导致这个的原因有可能是开发人员在需求理解上出现偏差，做到后面发现不对劲，再回去改又不大可能了，只能硬着头皮往下写，结果就是代码弯弯绕绕；还有很重要的锅是在产品经理，任意变更需求，想一出是一出，开发人员无奈只能跟着想一出写一出。还用可能是开发人员方法或者类命名太艺术了，什么四川方言拼音这种没有十年脑血栓想不出的命名咱就不说了。就说那种国产凌凌漆式的无厘头命名——这看上去是个刮胡刀实际上是个吹风机，就这种不知道让人说什么好。

规划代码的核心思想

吐槽了一堆代码规范问题，接下来我们说说如何去规范我们的代码以及如何做到就算开发人员更换了，或者项目转手给他人了，仍然可以让后面的开发可以无碍的去阅读代码修改代码。当然各个公司/团队都有自己的一套代码规范，比如项目的结构、代码命名风格、代码格式等等。不同团队有不同的风格，但核心思想是大同小异的。接下来我就我个人的开发经验来分享一下一些代码规范的思想。

花叶论

就我个人而言，这个理论是我代码规范中最浅显也是最核心的思想，只要稍微动动脑子就能想出这个思路出来。或许我们做业务开发的时候，大部分都在写crud，感觉似乎这部分代码没什么规范好说的，其实不然。对一段业务代码而言，我们可以将其分为四类：

  • 数据校验
  • 业务逻辑
  • 数据转换
  • 数据库交互（查询与持久化）

大部分时候我们最关心的是逻辑判断相关的代码，其次是数据库交互，对于远程调用的方法，我们就视其为一个普通的方法以简化模型，方法调用算业务逻辑部分的代码，对于读代码的人而言基本上不关心数据校验和数据的转换（DTO转VO等）。因此，代码应该分出一个主次，应该尽量把主逻辑给凸显出来，最好一眼看去就能让人明白这个方法或者这个类干了啥，步骤是什么样的。对于那些不重要但必要的代码我称其为叶，对于那些主要的代码我称其为花。叶是为了衬托花的，因此我们应该将那些叶子代码精简或者隐藏起来。

隐藏叶子代码，突出主干逻辑的一些手法

1）Converter（转换器）

大部分时候我们使用 bean 拷贝使用的是 BeanUtils 这个类来完成，然而一些稍微复杂的实体转换，这个类就无法胜任了，这个时候我们只能手动的 get set ,往往就是这些get set 方法掩盖了主干逻辑，让代码结构不清晰。因此我建议在你的业务逻辑代码中引入 1）Converter 这个角色来专门负责数据的传递与转换。

2）manager 层

无论我们使用的持久层框架是哪一种，jpa 或者 mybatis 我觉得我们都应该对持久层的部分方法进行简单封装一下，这也是阿里规范里面提倡的。这样做好处是明显的，我们做一个查询时往往要 set 一些查询条件或者对查询结果进行一些简单的判断，往往这类操作在业务代码可能有比较高的重复性。如果把这些代码放到业务逻辑代码里面，少量还好，多了的话就显得很臃肿了。如果把这种代码移到manager层里面去，不仅主业务逻辑代码不会被干扰，还能提高一定的代码复用率。

3）方法简单封装
假设我们一个方法要完成一端逻辑要分成三大步，而每一个步骤又分成几个小步骤，那我们就可以将这个方法拆分成三个方法，然后在这三个方法里面完成各自的步骤。这手法是很简单的，想必大家都能想到，但是我这里要介绍的是简化复杂方法封装的神器——函数式编程，我这里指的函数式编程不仅仅是 stream 流和 lambda 表达式的使用。函数式编程封装适用的场景是：整个流程比较固定，但是某几个步骤变化是不确定的。我们可以去看看 java.util.function 这个包的源码，你会发现这个包下面全是接口，这些接口被称为函数式接口。这些函数式接口总体上分为四类：

  • Function 类型：传入一个bean 返回另外一个bean
  • Consumer 类型：传入一个bean 无返回值
  • Predicate 类型：传入一个bean 返回布尔值
  • Supplier 类型：没有入参，有出参

以 Consumer 的使用为例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public User getUser(Consumer<User> consumer){
    User user=new User();
    consumer.accept(user);
    user=userMapper.getUser(user);
    return user;
}

public void doSomething1(){
    User user=getUser(user->{user.setId(1L)});
}

public void doSomething2(){
    User user=getUser(user->{user.setName("xxx")});
}

函数式编程的想象空间很大，使用的得当必定会简化你的代码，提高代码复用率。但是在多线程中使用函数式要留意数据的可见性问题。

日志和注释的一些个人经验

1）日志

首先我们要明白日志是给人看的，你加这段日志时要考虑清楚，有没有人会去查这段日志，这段日志有没有用。然后我们查阅日志的时候，一般会通过关键词去搜索；因此我们打的日志一定要有关键词，而且这个关键词不要和其他日志重复，不要过长，便于搜索才是王道。大部分情况我们查看日志都是为了追溯bug，那么一个基本原则就是能通过日志分析出业务逻辑或者流程的走向，对此我建议打日志的地方：

  • 数据更新：我们有必要知道写库的数据是不是正确的数据；
  • 条件分支：便于我们分析业务走的哪一条逻辑；
  • 批量写库：打上数据量大小的日志，便于我们分析性能瓶颈。

并不是所有的这些地方都应该打上日志，有的时候我们可能只需要通过一两条日志就能分析出整个流程的问题点在哪，这个时候其他的日志就显得多余了。还有我们打完日志之后应该在本地环境追溯一下，看看这些日志自己是否能读懂，是否有必要，是否少了重要参数。

2）注释

最基本的两个注释——类注释，方法注释相关规范阿里开发手册上就有，我这里就不复述了，我分享下我写注释的个人习惯。
方法注释上除了基本的注释，我还会将产品需求的原文贴重要的部分上去再写上日期，这样做的好处是让别人明白产品需求要求干啥这个方法该干啥，而且产品经理偷偷改需求你还能有追查的根据，有个小本本偷偷记录他的罪行。

代码注释我分享一个我偷师来的小技巧：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
pulic void test(){
    /** 1. 从excel 获取 vo*/
    Workbook workBook = getWorkBook(wookbookStream);
    //获取成员信息
    Sheet userSheet = workBook.getSheetAt(3);
     Map<String, UserVO> userVOMap = getUserForExcel(file, userSheet);
    // 获取项目vo
    Sheet projectSheet = workBook.getSheetAt(0);
    ProjectVO projectVO = getProjectForExcel(file, isInsert, userVOMap);
    // 获取任务vo
    Sheet taskSheet = workBook.getSheetAt(1);
    Map<String, TaskVO> taskVOMap = getTaskListForExcel(file, taskSheet, userVOMap);
    /** 2. 插入数据 */
    if (isInsert.get()){
        ......
    }
   /** 3.写入异常信息 */
    if (!isInsert.get()) {
        .....
    }
}

如你所见，对于主干的步骤 我用 /** 1. */ /** 2. */ javadoc的注释来标注了，而普通的注释我用 // 标注，因为idea 在纯黑主题下会给 /** 这样的注释配上绿色，会比较显眼。我通过这种方式来强调我代码那些是花，哪些是叶子。当然这种方式实际上是不大符合代码规范的，小伙伴们理性取舍，这种手法未必好。

六大基本原则

对于面向对象的的语言，六大基本是很重要的开发准则，但似乎大部分人在写代码的时候都不大在意这个，这也是导致一个方法变得又臭又长的一个重要原因之一。对于类的复杂度我们应该遵循单一职责原则——一个类或者方法承担的职责越多，它被复用的可能性就越小，重构或者修改起来就会变得困难重重，我们应该尽量让一个方法只去做一件事情。

对于许多代码我们只要通过一些简单的手法就能很好的提高其扩展性，比如通过接口去实现类与类之间的协作就能提前解决掉许多未知隐患，而且运用得当的情况下还能满足开闭原则与里氏替换原则，其实service层的设计就有那么点味道了，而且spring的特性也支持接口注入List和map，然而许多开发多年的同学都不知道这个特性，这个特性在许多场景下可以提高代码的扩展性，众所周知，map可以减少代码的 if else 分支。

方法命名 ‘潜规则’

很多时候，好的方法命名本身就是对代码的一种注释，我这里好的方法命名是指大家约定俗成的命名规则。如果你多留心各个开源框架的代码都会发现一些特定的命名规则。阿里开发手册里面也列举不少命名前缀与后缀的规范，其实各个团队可以根据自己的实际情况规定一些命名规则，降低团队内部的代码阅读的成本。关于我的文章 设计模式杂谈

介绍过部分命名规则，感兴趣的小伙伴可以去看看。

代码提交及版本控制

正确代码提交日志格式可以帮助开发人员及时的缕清代码的修改历史，从而快速的定位问题。以git为例，我们大部分人提交日志就是几个字而已，当然你能够通过日志去定位到自己的修改历史的话，这样做也没什么大问题，但是对于团队而言，你的修改日志要让别人能看懂就得按一定的格式来写了。Git Commit message的 Angular规范中定义的 commit message 格式有3个内容：

  • Header Header部分有3个字段： type(必需), scope(可选), subject(必需)
  • Body 部分是对本次 commit 的详细描述，可以分成多行。
  • Footer不常用，可为空 包括不兼容变动、关闭issue。

这里由于篇幅问题不细说，感兴趣的小伙伴可以百度查查资料。我们团队不一定要按照这么严格的规则来，但是可以制定一个类似的规范来管理提交日志。

对于团队而言，gitflow 是一个很不错的开发流程。可以很大程度上管理好我们的分支代码，避免团队的人由于误操作而导致某个重要分支出现问题。下面贴出gitflow 流程图，对于其具体内容同样不会介绍太多，感兴趣小伙伴去百度吧

xxx

帮助代码规范的工具

本节主要介绍提高代码质量的idea插件和框架，当然大名鼎鼎的 阿里代码规范插件咱就不介绍了，想必大家多少了解。不过本人感觉这个插件并不适合一些团队，一是感觉这个规范太过严格，对开发人员素质要求太高，二是有的团队有自己的规范规则，而且有可能和阿里规范冲突，不适用于这个插件。下面介绍的插件可能不适合一些小伙伴。我列举出来大家自己寻思吧。

mapstruct

对于我而言是很喜欢这个东西的，这个框架解决的问题其实就是我上文提到的花叶论中的 “数据转换” 的问题。其实不少公司也有类似的概念——定义一个工具类作用是将 DO转VO 或者 VO转DTO等，一般这类类都是以 converter 结尾。而mapstruct这个框架通过编译期生成字节码来自动的生成bean的转换类。我们想将一个bean的数据赋值给另外一个bean只需要去定义接口即可。这样既减轻了开发人员的工作量还将无意义的get和set方法从逻辑代码块中剔除出去。这个框架的缺点是字节码缓存问题，用过类似自动生成字节码工具的小伙伴应该知道——mapstruct 是根据接口去自动生成类的，当我们更新了接口的时候，这个类有可能没重新生成，当然这只有用idea调试的时候才会有的问题，所以也不必太担心。

checkStyle

idea checkStyle 插件可以通过自定义配置文件来统一团队的代码风格和代码规范，降低团队的交流成本，一般配合 save actions Reborn 食用更佳。关于checkStyle的配置文件网上也不少，这里也不贴出来占篇幅了。

git flow

前文提到过git flow 给团队带来的好处，idea也有对应的插件——git Flow Integration，可以通过这个插件来规范我们的流程：

gitflow插件

开发新功能选择 start Feature 拉取分支，修复bug 选择 Start Bugfix 拉取分支，等等。此外还有 push on finish等功能，小伙伴如果感兴趣可以百度。

Git Commit Template

这个主要是用来规范git commit 的一个idea插件小工具了，github上也有类似的开源插件。团队内部也可以自己开发一个类似插件，比较简单，成本也不高。

代码规范的一些个人看法就聊到这了，喜欢的小伙伴可以分享一下哦。

展开全文 >>

kafka 系列——kafka原理浅解

kafka 原理

消息队列一般包含两种模式，一种是点对点的模式，一种是发布订阅的模式。前文提到过 kafka 是一款基于发布订阅的消息队列。
那么kafka是怎么去发布消息，怎么去保存消息，订阅消息的呢？首先我们从kafka的发布订阅模型开始分析。

more >>

展开全文 >>

rabbitMQ 结合 springboot 使用 三

ListenerContainer 的使用

在消费端，我们的消费监听器是运行在 监听器容器之中的（ ListenerContainer ），springboot 给我们提供了两个监听器容器 SimpleMessageListenerContainer 和 DirectMessageListenerContainer 在配置文件中凡是以 spring.rabbitmq.listener.simple 开头的就是对第一个容器的配置，以 spring.rabbitmq.listener.direct 开头的是对第二个容器的配置。其实这两个容器类让我很费劲；首先官方文档并没有说哪个是默认的容器，似乎两个都能用；其次，它说这个容器默认是单例模式的，但它又提供了工厂方法，而且我们看 @RabbitListener 注解源码：

more >>

展开全文 >>

rabbitMQ简介

前文我们学习了 MQ的相关知识，现在我们来学习一下实现了AMQP协议的 rabbitMQ 中间件。rabbitMQ 是使用 erlang 语言编写的中间件（erlang之父 19年4月去世的，很伟大一个程序员）。

more >>

展开全文 >>

MQ简介

mq 就是消息队列（Message Queue）。想必大家对队列的数据结构已经很熟悉了，消息队列可以简单理解为：把要传输的数据放在队列中，mq 就是存放和发送消息的这么一个队列中间件。在消息队列中，把数据放到消息队列的角色叫做 生产者，从消息队列中消费获取数据的叫做 消费者。

那么消息队列有哪些使用场景呢? 六字真言：异步削峰解耦。

more >>

展开全文 >>

rabbitMQ安装与配置

对 rabbitMQ 我们已经有了初步的了解，现在我们来安装 rabbitMQ 来进行一些操作。因为大部分人的操作系统都是windows 而且作者本人使用的也windows系统。所以这里只介绍在windows上安装rabbitMQ。mac用户自行解决（仇富脸）。

more >>

展开全文 >>

java-code

操作码介绍

我们都知在Java中我们的类会被编译成字节码然后放到虚拟机中去执行，字节码里面的内容其实我们也是可以去“阅读”的，方法就是通过 jdk自带的工具翻译成操作码。在操作码中我们能看到一些我们平时看不到的关于java的秘密。

Java虚拟机的指令由一个字节长度的的数字以及跟随其后的零至多个代表此操作所需的参数构成。即：Java指令 = 操作码 + 操作数。Java虚拟机本身是采用面向操作数栈而不是寄存器的架构，所以大多数的指令都不包含操作数，只有一个操作码。通过阅读操作码我们能直观的看到一些方法的执行过程。

more >>

展开全文 >>

jvm 调优指南

1.调优参数

java -Xmx3550m -Xms3550m -Xmn2g -Xss128k

-Xmx3550m：设置JVM最大可用内存为3550M。

-Xms3550m：设置JVM促使内存为3550m。此值可以设置与-Xmx相同，以避免每次垃圾回收完成后JVM重新分配内存。

-Xmn2g：设置年轻代大小为2G。整个JVM内存大小=年轻代大小 + 年老代大小 + 持久代大小。持久代一般固定大小为64m，所以增大年轻代后，将会减小年老代大小。此值对系统性能影响较大，Sun官方推荐配置为整个堆的3/8。

-Xss128k：设置每个线程的堆栈大小。JDK5.0以后每个线程堆栈大小为1M，以前每个线程堆栈大小为256K。更具应用的线程所需内存大小进行调整。在相同物理内存下，减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的，不能无限生成，经验值在3000~5000左右。

java -Xmx3550m -Xms3550m -Xss128k -XX:NewRatio=4 -XX:SurvivorRatio=4 -XX:MaxPermSize=16m -XX:MaxTenuringThreshold=0

-XX:NewRatio=4:设置年轻代（包括Eden和两个Survivor区）与年老代的比值（除去持久代）。设置为4，则年轻代与年老代所占比值为1：4，年轻代占整个堆栈的1/5
-XX:SurvivorRatio=4：设置年轻代中Eden区与Survivor区的大小比值。设置为4，则两个Survivor区与一个Eden区的比值为2:4，一个Survivor区占整个年轻代的1/6

-XX:MaxPermSize=16m:设置持久代大小为16m。

-XX:MaxTenuringThreshold=0：设置垃圾最大年龄。如果设置为0的话，则年轻代对象不经过Survivor区，直接进入年老代。对于年老代比较多的应用，可以提高效率。如果将此值设置为一个较大值，则年轻代对象会在Survivor区进行多次复制，这样可以增加对象再年轻代的存活时间，增加在年轻代即被回收的概论。

JVM提供了大量命令行参数，打印信息，供调试使用。主要有以下一些：
-XX:+PrintGC
输出形式：[GC 118250K->113543K(130112K), 0.0094143 secs]
[Full GC 121376K->10414K(130112K), 0.0650971 secs]

-XX:+PrintGCDetails

-XX:+PrintGCTimeStamps -XX:+PrintGC：PrintGCTimeStamps可与上面两个混合使用

-XX:+PrintGCApplicationConcurrentTime:打印每次垃圾回收前，程序未中断的执行时间。可与上面混合使用

-XX:+PrintGCApplicationStoppedTime：打印垃圾回收期间程序暂停的时间。可与上面混合使用

-XX:PrintHeapAtGC:打印GC前后的详细堆栈信息

2 调优工具

一、jps：虚拟机进程状况工具

二、jstat：虚拟机统计信息监视工具

三、jmap：Java内存印象工具

四、jhat：虚拟机堆转储快照分析工具

五、jstack：Java堆栈跟踪工具

六、jinfo：Java配置信息工具

集成式的VisualVM和jConsole

展开全文 >>

tcc推导

事件的起因

最近在做一个项目，这个项目很有特点——它是一个分布式项目但是它却未使用分布式事务。我分析其事务机制和缺陷时，突然灵感一来，于是有了这篇文章。

spring事务传播行为

在讨论分布式事务之前，我们先把spring事务传播机制过一遍，文章参考自事务传播行为详解 这位大佬写的很用心，文末评论区还讲到了一个关于spring事务的一个很重要的特性。spring事务传播行为有七种：

事务传播行为类型 说明
PROPAGATION_REQUIRED 如果当前没有事务，就新建一个事务，如果已经存在一个事务中，加入到这个事务中。这是最常见的选择。
PROPAGATION_SUPPORTS 支持当前事务，如果当前没有事务，就以非事务方式执行。
PROPAGATION_MANDATORY 使用当前的事务，如果当前没有事务，就抛出异常。
PROPAGATION_REQUIRES_NEW 新建事务，如果当前存在事务，把当前事务挂起。
PROPAGATION_NOT_SUPPORTED 以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。
PROPAGATION_NEVER 以非事务方式执行，如果当前存在事务，则抛出异常。
PROPAGATION_NESTED 如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，则执行与PROPAGATION_REQUIRED类似的操作。

为了大家便于理解方便阅读我对原文做了总结，在这里我们讲三种事务的场景：

  • 包含性事务：外部事务包含了内部事务组成一个统一的事务（REQUIRED）
  • 挂起性事务：外部事务和内部事务只是在一起执行，互不影响（REQUIRES_NEW）
  • 嵌套性事务：外部事务影响内部事务，内部事务不影响外部事务 （NESTED）

下面根据参考文章中的例子来一一说明

包含性事务

代码示例：

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
   
@Transactional(propagation = Propagation.REQUIRED)
public void test1(){
    User1 user1=new User1();
    user1.setName("张三");
    user1Service.addRequired(user1);
    
    User2 user2=new User2();
    user2.setName("李四");
    user2Service.addRequired(user2);
    
    throw new RuntimeException();
}

   
@Transactional(propagation = Propagation.REQUIRED)
public void test2(){
    User1 user1=new User1();
    user1.setName("张三");
    user1Service.addRequired(user1);
    
    User2 user2=new User2();
    user2.setName("李四");
    user2Service.addRequiredException(user2);
}

@Transactional

public void test3(){
    User1 user1=new User1();
    user1.setName("张三");
    user1Service.addRequired(user1);
    
    User2 user2=new User2();
    user2.setName("李四");
    try {
        user2Service.addRequiredException(user2);
    } catch (Exception e) {
        System.out.println("方法回滚");
    }
}

上述代码中user1Service.addRequired(user1) 是一个 “正常” 的 insert 事务，user2Service.addRequiredException(user2) 是一个抛异常的事务。这三个方法都会发生回滚。以test3() 为例， user1Service.addRequired(user1)正常提交后外部的事务（test3() 所在的事务 ）发生了回滚，这个事务也会跟着回滚，这便是包含关系。

挂起性事务

挂起性事务，是外部事务和内部事务互不干扰，两者只能通过抛出异常来交互（后面分布式项目分析中就是和这种事务一样）。示例：

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
@Transactional(propagation = Propagation.REQUIRED)
public void test1(){
    User1 user1=new User1();
    user1.setName("张三");
    user1Service.addRequired(user1);
    
    User2 user2=new User2();
    user2.setName("李四");
    user2Service.addRequiresNew(user2);
    
    User2 user3=new User2();
    user3.setName("王五");
    user2Service.addRequiresNewException(user3);
}

@Transactional(propagation = Propagation.REQUIRED)
public void test2(){
    User1 user1=new User1();
    user1.setName("张三");
    user1Service.addRequired(user1);
    
    User2 user2=new User2();
    user2.setName("李四");
    user2Service.addRequiresNew(user2);
    User2 user3=new User2();
    user3.setName("王五");
    try {
        user2Service.addRequiresNewException(user3);
    } catch (Exception e) {
        System.out.println("回滚");
    }
}

上述代码中 user1Service.addRequired(user1) 和外部事务是包含关系；user2Service.addRequiresNew(user2) 是挂起事务；user2Service.addRequiresNewException(user3) 是挂起并将会执行失败的事务。test1 方法中由于外部事务是包含事务，因此user2Service.addRequiresNewException 异常会导致 user1Service.addRequired 回滚 而由于user2Service.addRequiresNew 是挂起事务它不会回滚。在test2 中由于 test2 捕获了异常所以不会触发外部事务的回滚，user1Service.addRequired 和 user2Service.addRequiresNew 均能执行成功；但是要注意一个情况，假如 user2Service.addRequiresNewException(user3) 这个方法加了包含性事务的注解（既 @Transactional(propagation = Propagation.REQUIRED) ） 的情况下，虽然在外部事务中try catch 了，但其方法本身所在的事务发生了回滚，该子事务回滚之后会将整个事务标记位记为rollbackOnly,当外部事务发现事务被标记为 rollbackOnly 时不会提交，而是回滚。

嵌套性事务

该事务如果内部事务回滚，不会触发外部事务的回滚，但外部事务的回滚会导致内部事务回滚。下面看示例：

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
@Transactional
public void test1(){
    User1 user1=new User1();
    user1.setName("张三");
    user1Service.addNested(user1);
    
    User2 user2=new User2();
    user2.setName("李四");
    user2Service.addNested(user2);
    throw new RuntimeException();
}


@Transactional
public void test2(){
    User1 user1=new User1();
    user1.setName("张三");
    user1Service.addNested(user1);
    
    User2 user2=new User2();
    user2.setName("李四");
    try {
        user2Service.addNestedException(user2);
    } catch (Exception e) {
        System.out.println("方法回滚");
    }
}

在test1 中外部事务回滚，导致嵌套事务回滚，user1Service.addNested 和 user2Service.addNested(user2); 均回滚了，在test2 中，user2Service.addNestedException(user2) 这个嵌套事务回滚了，但外部事务不会回滚 因此 user1Service.addNested(user1)不会回滚。在挂起性事务中我们提到rollbackOnly标志位，在test2里也是一样，如果
user2Service.addNestedException(user2) 是一个抛异常的包含性事务，其外部事务也会回滚，既 user1Service.addNested 会回滚。

spring事务总结

为了下文能便于理解，我们先做个简单的总结，其实spring事务按顺序排下来就分四种情况：

  1. 无事务，禁止外部使用事务
  2. 内部事务和外部事务互相影响
  3. 外部事务影响内部事务，但是内部事务不影响外部事务
  4. 外部事务和内部事务互不影响

分布式系统中的事务

假设我们在分布式系统中使用普通的本地事务会怎么样呢（作者运气比较好，不需要假设，实际场景就是）？ 下面我们来分析一段伪代码

1
2
3
4
5
6
7
8
9
10
11

@Transactional
public void test1(){
    rpcService.update();
    localService.update();
    if（“业务逻辑判断”）{
         throw new RuntimeException();
    }
    
}

rpcService.update() 是一个更新数据库的rpc方法，localService.update() 是一个更新数据库的本地方法。为了简化模型，我们认为两个方法操作的是同一个数据库。这个方法执行会发生什么呢？很明显，这里相当于一个挂起性事务，rpcService都夸虚拟机了，自然不会被本地spring的事务所管控，相当于两个事务放在一起互不相干。该方法将会导致，rpcService.update()写入脏数据，而 localService.update() 会回滚，这是很糟糕的情况。如果rpcService.update() 抛出异常还好，还能让事务回滚，要是正常执行就完犊子了。我们要怎么去避免呢？最笨的办法是 我们调用rpc的service时只执行查询语句。所有更新数据库的操作全部在本地执行。但这种方式不是任何情况都适用，有的时候我们不得不去 rpc update。那么在没有引入分布式中间件的时候怎么去实现一个分布式事务？一种方式是通过 mysql的 XA 分布式事务机制，这种方式缺点也是很明显的，首先 XA 在5.6以上版本才适用，其次它很耗资源。我们考虑一下有没有通过代码或者结构设计的方式来实现数据一致。我们可以要 rpcService.update() 的事务卡在那不commit，等localService.update() commit 了再让它commit，这样又有问题了，如果卡住 rpcService.update() 的事务那么，这个方法就会阻塞，只能开启异步线程来让它在后台挂起，异步又会导致该方法必须是void的，这又是很难做到的事情——必须要所有rpc方法都无返回值。

tcc的产生

上面几种思路貌似都不是很理想，虽然能实现但效果必定不会很好，有没有别的办法？我们回过头来分析开始那段伪代码，这段代码存在的问题是如果本地方法回滚了，rpc的方法会产生脏数据。那如果脏数据能在后续步骤清除并且这部分脏数据不会影响正常业务呢？我可以在本地方法rollback的时候清除它，而且正常的业务代码也不会被它影响。我们都知道不少企业在设计数据库的时候，对数据的删除不是使用物理删除，而是使用逻辑删除，被逻辑删除的数据也不会影响正常业务的运行，而被删除的数据实际上还保存在数据库，只是将删除标识标记为1,表示已删除。

基于上述原理，我们可以整个逻辑提交这个概念——在数据库中专门准备一个字段commited 0 表示虽然写入库，但是未被commit 属于“脏数据”，1 是已经commited 可以被业务代码读写的数据。那上面的代码也要改一下：

1
2
3
4
5
6
7
8
9
10
11
12
13
@Transactional
    public void test1(){
        rpcService.updateNotCommit();
        localService.update();
        if("业务逻辑正确，可以commit"){
            rpcService.commit();
        }else(){
            System.out.print("业务错误，需要回滚")
            rpcService.rollBack();
            throw new RuntimeException();
        }
       
    }

上述设计方式，似乎解决了我们的问题，但只是理想状态下不会出错；不理想的状态下，可能发生网络波动，rpcService.rollBack() 请求未抵达抛出异常，那么数据库里面会堆积不少脏数据，虽然对业务没影响，但是很影响性能。而且如果有多个commit，比如这样：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
@Transactional
    public void test1(){
        rpcService.updateNotCommit0();
        rpcService.updateNotCommit1();
        rpcService.updateNotCommit2();
        localService.update();
        if("业务逻辑正确，可以commit"){
            rpcService.commit0();
            rpcService.commit1();
            rpcService.commit2();
        }else(){
            System.out.print("业务错误，需要回滚")
            rpcService.rollBack();
            throw new RuntimeException();
        }
       
    }

假设rpcService.commit2() 发生网络波动，未发出请求抛出异常，那么会发生commit0 成功 commit1 成功，本地事务失败，commit2失败。这样就又产生影响业务的脏数据了。这种情况证明办？我们需要一个机制来能在commit或者rollback请求未发送出去的时候去重试，保证能够发送请求出去。因此我们要保证 commit 或者 rollback 不能抛异常，并且能够去请求失败的时候重试。重试很好实现，做一个标志位和计数器当请求成功的时候改变标志位状态，计数器计数重试次数，超过次数就通过某种机制来通知到运维人员需要去检查什么地方出了问题，手动对数据提交或者回滚。

推导到这一步好像这个思路要做的事情还比较多了，而且这个功能通用性也挺强，要不整成中间件吧，这个中间件有重试机制，错误通知机制；物理commit，逻辑commit ，逻辑rollback的请求接口。对于这三个接口的注册方法我们可以用注解或者实现接口的方式，通过aop来获取其注册到这个中间件的接口。然后我们需要使用分布式事务的时候先从中间件拿到这个事务的三个接口，而事务的执行方提供这三个接口。

嗯，这个套路研究到这里好像还蛮牛掰的，要不咱们取个响亮点的名字吧——就叫TCC好了

展开全文 >>

设计模式-责任链模式

责任链（Chain of Responsibility）模式的定义：为了避免请求发送者与多个请求处理者耦合在一起，将所有请求的处理者通过前一对象记住其下一个对象的引用而连成一条链；当有请求发生时，可将请求沿着这条链传递，直到有对象处理它为止。

责任链模式也叫职责链模式。

在责任链模式中，客户只需要将请求发送到责任链上即可，无须关心请求的处理细节和请求的传递过程，所以责任链将请求的发送者和请求的处理者解耦了。

more >>

展开全文 >>

设计模式-命令模式

当我们的代码中”方法的请求者” 和 “方法的实现者” 之间存在较为紧密的耦合的时候，这段代码的后续维护会变得很困难。如果我们想对方法进行回滚 撤销等操作的话就会很困难；使用命名模式可解决这一问题。

在现实生活中，这样的例子也很多，例如，电视机遥控器（命令发送者）通过按钮（具体命令）来遥控电视机（命令接收者），还有计算机键盘上的“功能键”等。

more >>

展开全文 >>

设计模式-策略模式

策略（Strategy）模式的定义：该模式定义了一系列算法，并将每个算法封装起来，使它们可以相互替换，且算法的变化不会影响使用算法的客户。策略模式属于对象行为模式，它通过对算法进行封装，把使用算法的责任和算法的实现分割开来，并委派给不同的对象对这些算法进行管理。策略模式有以下优点：

  • 多重条件语句不易维护，而使用策略模式可以避免使用多重条件语句。
  • 策略模式提供了一系列的可供重用的算法族，恰当使用继承可以把算法族的公共代码转移到父类里面，从而避免重复的代码。
  • 策略模式可以提供相同行为的不同实现，客户可以根据不同时间或空间要求选择不同的。
  • 策略模式提供了对开闭原则的完美支持，可以在不修改原代码的情况下，灵活增加新算法。
  • 策略模式把算法的使用放到环境类中，而算法的实现移到具体策略类中，实现了二者的分离。
more >>

展开全文 >>

设计模式-代理模式（proxy）

代理模式的定义：由于某些原因需要给某对象提供一个代理以控制对该对象的访问。这时，访问对象不适合或者不能直接引用目标对象，代理对象作为访问对象和目标对象之间的中介。

代理模式的主要优点有：
代理模式在客户端与目标对象之间起到一个中介作用和保护目标对象的作用；
代理对象可以扩展目标对象的功能；
代理模式能将客户端与目标对象分离，在一定程度上降低了系统的耦合度；

其主要缺点是：
在客户端和目标对象之间增加一个代理对象，会造成请求处理速度变慢；
增加了系统的复杂度；

more >>

展开全文 >>

设计模式-组合模式（Composite）

组合（Composite）模式的定义：有时又叫作部分-整体模式，它是一种将对象组合成树状的层次结构的模式，用来表示“部分-整体”的关系。组合模式使得客户端代码可以一致地处理单个对象和组合对象，无须关心自己处理的是单个对象，还是组合对象，这简化了客户端代码；

more >>

展开全文 >>

设计模式-装饰器模式（Decorator）

装饰器（Decorator）模式指在不改变现有对象结构的情况下，动态地给该对象增加一些职责（即增加其额外功能）的模式，它属于对象结构型模式。采用装饰模式扩展对象的功能比采用继承方式更加灵活；可以设计出多个不同的具体装饰类，创造出多个不同行为的组合。但是装饰模式增加了许多子类，如果过度使用会使程序变得很复杂。

more >>

展开全文 >>

设计模式—建造者模式(Builder)

建造者模式(Builder)是一步一步创建一个复杂的对象，它允许用户只通过指定复杂对象的类型和内容就可以构建它们，用户不需要知道内部的具体构建细节。建造者模式属于对象创建型模式。我们获得一个对象的时候不是直接new这个对象出来，而是对其建造者进行属性设置，然后建造者在根据设置建造出各个对象出来。建造者模式又可以称为生成器模式。

more >>

展开全文 >>

设计模式—门面模式

门面（Facade）模式的定义：是一种通过为多个复杂的子系统提供一个一致的接口，而使这些子系统更加容易被访问的模式。该模式对外有一个统一接口，外部应用程序不用关心内部子系统的具体的细节，这样会大大降低应用程序的复杂度，提高了程序的可维护性。

门面模式又被称作外观模式，这个模式特点很鲜明，在生活中我们就能找到不少例子。比如110，我们生活中遇到困难或者危险等一系列问题，我们都是直接打110找警察同志，然后由公安局统一处理，对应不同的情况再细化到公安的各个部门去处理。

more >>

展开全文 >>

设计模式——单例模式

单例模式 （Singleton Pattern）使用的比较多，比如我们的 controller 和 service 都是单例的，但是其和标准的单例模式是有区别的。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。这种模式涉及到一个单一的类，该类负责创建自己的对象，同时确保只有单个对象被创建。这个类提供了一种访问其唯一的对象的方式，可以直接访问，不需要实例化该类的对象。

more >>

展开全文 >>

鸟瞰MYSQL

作者: muggle

1 mysql 架构

mysql分为server层和存储引擎

1.1 server层

  • 连接器：管理连接权限验证
  • 查询缓存：命中缓存直接换回查询结果
  • 分析器：分析语法
  • 优化器：生成执行计划，选择索引
  • 执行器：操作索引返回结果
more >>

展开全文 >>

设计模式-适配器

适配器模式(Adapter Pattern) ：将一个接口转换成客户希望的另一个接口，适配器模式使接口不兼容的那些类可以一起工作，其别名为包装器(Wrapper)。适配器模式既可以作为类结构型模式，也可以作为对象结构型模式。

模式结构

适配器模式包含如下角色：

  • Target：目标抽象类
  • Adapter：适配器类
  • Adaptee：适配者类
  • Client：客户类
more >>

展开全文 >>

设计模式——桥接模式

桥接模式(Bridge Pattern)：将抽象部分与它的实现部分分离，使它们都可以独立地变化。它是一种对象结构型模式，又称为柄体(Handle and Body)模式或接口(Interface)模式。

设想如果要绘制矩形、圆形、椭圆、正方形，我们至少需要4个形状类，但是如果绘制的图形需要具有不同的颜色，如红色、绿色、蓝色等，此时至少有如下两种设计方案：

  1. 为每一种形状都提供一套各种颜色的版本。
  2. 根据实际需要对形状和颜色进行组合

对于有两个变化维度（即两个变化的原因）的系统，采用第二种方案来进行设计系统中类的个数更少，且系统扩展更为方便。第二种方案即是桥接模式的应用。桥接模式将继承关系转换为关联关系，从而降低了类与类之间的耦合，减少了代码编写量。对于有两个变化维度（即两个变化的原因）的系统，采用桥接模式开发更为方便简洁。桥接模式将继承关系转换为关联关系，从而降低了类与类之间的耦合，减少了代码编写量。

more >>

展开全文 >>

设计模式——三个工厂模式

简单工厂模式

简单工厂模式(Simple Factory Pattern)：又称为静态工厂方法(Static Factory Method)模式，它属于类创建型模式。在简单工厂模式中，可以根据参数的不同返回不同类的实例。简单工厂模式专门定义一个类来负责创建其他类的实例，被创建的实例通常都具有共同的父类。

模式结构

简单工厂模式包含如下角色：

  • Factory：工厂角色，工厂角色负责实现创建所有实例的内部逻辑
  • Product：抽象产品角色，抽象产品角色是所创建的所有对象的父类，负责描述所有实例所共有的公共接口
  • ConcreteProduct：具体产品角色，具体产品角色是创建目标，所有创建的对象都充当这个角色的某个具体类的实例。

源码导读

1
2
3
4
5
6
7
8
9
 public static void main(String[] args) {
        // 资源加载
        ClassPathResource classPathResource = new ClassPathResource("spring-bean.xml");
        // XmlBeanFactory 加载资源并解析注册bean
        BeanFactory beanFactory = new XmlBeanFactory(classPathResource);
        // BeanFactory.getBean();
        UserBean userBean = (UserBean) beanFactory.getBean("userBean");
        System.out.println(userBean.getName());
}

这个XmlBeanFactory便可以看做是一个稍微变形的简单工厂，getBean()方法便是获取产品的实例方法，userBean便是我们的产品。如果我们以后遇到与spring中XmlBeanFactory类似场景我们便可依瓢画葫芦写出一个漂亮的简单工厂。

工厂方法模式

也叫虚拟构造器(Virtual Constructor)模式或者多态工厂(Polymorphic Factory)模式，它属于类创建型模式。在工厂方法模式中，工厂父类负责定义创建产品对象的公共接口，而工厂子类则负责生成具体的产品对象，这样做的目的是将产品类的实例化操作延迟到工厂子类中完成，即通过工厂子类来确定究竟应该实例化哪一个具体产品类。

模式结构

工厂方法模式包含如下角色：

  • Product：抽象产品
  • ConcreteProduct：具体产品
  • Factory：抽象工厂
  • ConcreteFactory：具体工厂

源码导读

java.util.Collection接口中定义了一个抽象的iterator()方法，该方法就是一个工厂方法。
我们来看看ArrayList中的iterator()实现

1
2
3
@NotNull public Iterator<E> iterator() {
    return new ArrayList.Itr();
}

它new了一个ArrayList的内部类Itr 然后将其返回，Itr：

1
2
3
4
5
6
7
8
9
10
11
private class Itr implements Iterator<E> {
        int cursor;
        int lastRet = -1;
        int expectedModCount;

        Itr() {
            this.expectedModCount = ArrayList.this.modCount;
        }
   ......
   ......
}

这里ArrayList对Iterator来说就是一个工厂类，它的iterator()方法便是生产Iterator的工厂方法。

抽象工厂

抽象工厂模式(Abstract Factory Pattern)：提供一个创建一系列相关或相互依赖对象的接口，而无须指定它们具体的类。抽象工厂模式又称为Kit模式，属于对象创建型模式。

模式结构

抽象工厂模式包含如下角色：

  • AbstractFactory：抽象工厂
  • ConcreteFactory：具体工厂
  • AbstractProduct：抽象产品
  • Product：具体产品

源码导读

我们可以看到 抽象工厂和工厂方法的区别是——抽象多了生产相关联产品的其他方法。可以理解为对工厂方法的一个升级，我们来看HashMap这个类：

1
2
3
HashMap<Object, Object> objectHashMap = new HashMap<>();
Set<Map.Entry<Object, Object>> entries = 		     objectHashMap.entrySet();
Collection<Object> values = objectHashMap.values();

这里HashMap 就是抽象工厂，它的values()和entrySet()就是两个工厂方法，Collection<Object>和Set<Map.Entry<Object, Object>>是产品。注意：抽象工厂中抽象的含义是对产品的抽象，不再是某个产品，而是某系列产品，工厂模式类命名一般以factory结尾。

展开全文 >>

zookeeper 浅解

从官网 https://apache.org/dist/zookeeper/zookeeper-3.5.5/ 上下载zk(注意windows也是下载 tar.gz后解压)，./conf下有个zoo_sample.cfg 复制到同目录下改名为zoo.cfg，在目录下新建data和log文件夹，修改zoo.cfg中的 dataDir 和 dataLogDir为 data和log的路径。现在启动zk，在bin目录下有个zkServer.cmd，运行启动。启动ZK客户端对ZK进行简单的读写操作，在bin目录下打开cmd，运行：

more >>

展开全文 >>

git 指令速查

基本配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
### 初始化git 仓库
git init

### 设置git 全局变量
git config --global user.name"ssss"

### 将文件纳入 git 管理
git add README.md

### 提交
git commit -m "first commit"

### git 添加远程仓库
git remote add origin https://github.com/xxx

###  将本地的master分支推送到origin主机，同时指定origin为默认主机，后面就可以不加任何参数使用git push了
git push -u origin master

查看

1
2
3
4
5
6
7
8
9
10
11
12
### 查看分支
git checkout master

### 查看commit
git checkout commitid

### 切换远程分支
git checkout -b dev origin/dev   

### 查看本地分支关联的远程分支
git branch -vv

覆盖/撤回

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
### 对受保护分支无法使用强推，强推解决多仓库不同源问题
git push 远程仓库名 本地分支:远程仓库名 --force

### git revert是用一次新的commit来回滚之前的commit，git reset是直接删除指定的commit 。
### git reset --hard --mixed(default) --soft 分别覆盖3个、2个、1个位置的代码，--mixed（默认的参数）只会保留working copy里的代码

git reset --hard HEAD^

### 强制push ,会覆盖其他提交记录 慎用
git push -f 

### 强制pull

git pull origin master --allow-unrelated-histories

其他

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
### 多仓库远程推送
git push origin local:remote

### 对于提交错误但未push的commit 可以使用idea 的undo commit 进行回滚

### 合并
git merge dev 

### 删除本地的远程仓库地址
git remote rm origin 

### 删除远程分支
git push origin --delete dev 

### 选择合并（摘樱桃）
git cherry-pick <commit_id>

git subtree

git subtree 是在当前仓库下创建子目录，适用于多仓库间公共代码的维护

1
2
3
4
5
6
7
8
9
### 添加子仓库
git subtree add --prefix LibraryC libraryc master 

### 拉取子仓库代码

git subtree pull --prefix LibraryC libraryc master

### 提交子仓库代码
git subtree push --prefix LibraryC libraryc master

HEAD的含义：代表当前仓库最新版本。HEAD^ 和HEAD~的意义和区别HEAD^+数字表示当前提交的父提交。具体是第几个父提交共同过^+数字指定，HEAD^1第一个父提交，该语法只能用于合并(merge)的提交记录，因为一个通过合并产生的commit对象才有多个父提交。HEAD~(等同于HEAD^,注意没有加数字)表当前提交的上一个提交。
如果想获取一个提交的第几个父提交使用HEAD^+数字,想获取一个提交的上几个提交使用HEAD~。HEAD^和HEAD~或HEAD^^和HEAD~~并没有区别，只有HEAD^+数字才和HEAD~有区别。

展开全文 >>

spi和jar

今天介绍两个大家每天都在用但是却很少去了解它的知识点：spi和jar运行机制，废话不多说，开始正题

spi

是Java提供的一套用来被第三方实现或者扩展的API，它可以用来启用框架扩展和替换组件。spi机制是这样的：读取META-INF/services/目录下的元信息，然后ServiceLoader根据信息加载对应的类，你可以在自己的代码中使用这个被加载的类。要使用Java SPI，需要遵循如下约定：

more >>

展开全文 >>

gradle+idea 快速上手

gradle介绍

Gradle是一个构建工具，定位和maven一样，用于管理项目依赖和构建项目。和maven比起来的优势是：语法更灵活，更方便管理项目（个人很讨厌XML）。

gradle具有以下特点：

  • 按约定声明构建和建设；
  • 强大的支持多工程的构建；
  • 强大的依赖管理（基于Apache Ivy），提供最大的便利去构建工程；
  • 全力支持已有的 Maven 或者Ivy仓库基础建设；
  • 支持传递性依赖管理；
  • 基于groovy脚本构建，groovy简单易学；
  • 具有广泛的领域模型支持构建；
  • 易迁移；
  • 自由和开放源码；
more >>

展开全文 >>

注解及其反射机制

注解相关知识

元注解

  1. @Retention：生命周期，RetentionPolicy.SOURCE 注解只在源码阶段保留，RetentionPolicy.CLASS 注解只被保留到编译进行的时候，它并不会被加载到 JVM中，RetentionPolicy.RUNTIME 注解可以保留到程序运行的时候
  2. @Documented：作用是能够将注解中的元素包含到 Javadoc 中去。
  3. @Target：指定了注解运用的地方。ElementType.ANNOTATION_TYPE 可以给一个注解进行注解，ElementType.CONSTRUCTOR 可以给构造方法，ElementType.FIELD 可以给属性，ElementType.LOCAL_VARIABLE 可以给局部变量，ElementType.METHOD 可以给方法，ElementType.PACKAGE 可以给一个包，ElementType.PARAMETER 可以给一个方法内的参数，ElementType.TYPE 可以给一个类型进行注解，比如类、接口、枚举
  4. @Inherited：一个超类被 @Inherited 注解过的注解进行注解的话，那么如果它的子类没有被任何注解应用的话，那么这个子类就继承了超类的注解。
  5. @Repeatable ：可重复注解

注解的属性

注解的属性也叫做成员变量。注解只有成员变量，没有方法。注解的成员变量在注解的定义中以“无形参的方法”形式来声明，其方法名定义了该成员变量的名字，其返回值定义了该成员变量的类型。

1
2
3
4
5
6
7
8
9
10
11
12
public class BootStaterTestApplicationTests {
    @Test
    public void contextLoads() {
        @muggle(test = "ss")
        String test="ss";
    }
}

@Target(ElementType.LOCAL_VARIABLE)
@interface muggle{
    String test();
}

解中属性可以有默认值，默认值需要用 default 关键值指定。

1
2
3
4
@Target(ElementType.LOCAL_VARIABLE)
@interface muggle{
    String test()default "test";
}

一些缺省写法略

反射获取注解

类注解

1
2
3
4
5
6
7
test test = new test();
      Class<? extends com.muggle.bootstatertest.test> aClass = test.getClass();
      Class<Muggle> muggleClass = Muggle.class;
      boolean annotationPresent = aClass.isAnnotationPresent(muggleClass);
      System.out.println(annotationPresent);
      Annotation[] annotations = aClass.getAnnotations();
      Muggle annotation = aClass.getAnnotation(Muggle.class);

属性注解

1
2
Field[] fields = aClass.getFields();
Annotation[] annotations1 = fields[0].getAnnotations();

方法注解

1
2
3
Method[] methods = aClass.getMethods();
Method[] declaredMethod = aClass.getDeclaredMethods();
Annotation[] declaredAnnotations = methods[0].getDeclaredAnnotations();

展开全文 >>

grpc+springboot+gradle学习笔记

前言

前段时间写了一篇关于nacos的文章，本人还是很期待nacos成长起来的。nacos在其官方文档里面说nacos未来会支持grpc，正好我对grpc也抱有极大兴趣，于是基于springboot和gradle做了一个小demo对它们进行了整合，初步研究了一下，期待nacos成熟起来，组成一套Spring Cloud+gradle+nacos+grpc+sentinel的完全体。这篇博客的目的是知识储备，并不是讨论解决开发中某些问题。

正文

弄了一天，得到一个结论，gradle+grpc+git subtree 不是目前的我能驾驭的，弃文；等对gradle足够熟练再回来弄。

展开全文 >>

java动态代理

什么是代理

   代理是一种软件设计模式，这种设计模式不直接访问被代理对象，而访问被代理对象的方法，详尽的解释可参考《java设计模式之禅》，里面的解释还是很通俗的。给个《java设计模式之禅》下载地址：https://pan.baidu.com/s/1GdFmZSx67HjKl_OhkwjqNg

   在JDK中提供了实现动态代理模式的机制，cglib也是一个用于实现动态代理的框架，在这里我介绍jdk自带的动态代理机制是如何使用的。先上代码再慢慢解释：

1
2
3
4
5
// 定义一个接口，接口中只有一个抽象方法，这个方法便是将要被代理的方法
public interface Subject {
  String test(String string);
}

1
2
3
4
5
6
7
8
9
// 定义 一个类实现这个方法，方法里写上自己的逻辑。
public class SubjectImpl implements Subject {

  @Override
  public String test(String string) {
      String test=string+string;
      return test;
  }
}
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
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;
import java.lang.reflect.Proxy;
// 定义一个代理类，这个代理必须要实现invocaHandler 接口，用以指定这个类为一个代理类
public class MyProxy implements InvocationHandler {
    private Object target;
    public MyProxy( Object target){
        this.target=target;
    }
    // 实现 invoke方法，这个方法将是后面代码中实际执行的方法
    @Override
    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        System.out.println("开始执行动态代理");
        Object result=method.invoke(target,args);
        return  result;
    }
    // Proxy类为反射机制中的一个类，用于获得代理对象
    public <T> T getProxy(){
      /* newProxyInstance方法的参数解释：
      ** 被代理对象的类加载器：target.getClass().getClassLoader()
      ** 被代理的方法：target.getClass().getInterfaces()
      **代理对象：this
      */
        return (T) Proxy.newProxyInstance(target.getClass().getClassLoader(),target.getClass().getInterfaces(),this);
    }
}
1
2
3
4
5
6
7
8
public static void main(String[] args) {
        // 创建一个被代理对象
       Subject subject=new SubjectImpl();
       // 创建一个代理对象
       Subject proxy=new MyProxy(subject).getProxy();
       // 调用代理的方法
       System.out.println(proxy.test("test"));
   }

输出结果：

1
2
3
开始执行动态代理
testtest

   我们知道spring 的AOP是通过动态代理实现的,现在让我们好好分析一下动态代理，示例中定义了一个接口 Subject，一个继承接口的SubjectImpl类,一个实现了InvocationHandler的MyProxy类，并调用了Proxy.newProxyInstance方法。Subject定义了将要被代理执行的方法，SubjectImpl是被代理的类（雇主），MyProxy类是代理执行的类（跑腿的），它的invoke(Object proxy, Method method, Object[] args)方法便是实际被执行的方法，它的第一个参数proxy作用：

  • 可以使用反射获取代理对象的信息（也就是proxy.getClass().getName()）
  • 可以将代理对象返回以进行连续调用，这就是proxy存在的目的，因为this并不是代理对象(MyProxy虽然是代理的类，但代理对象是 Proxy.newProxyInstance方法生成的。)。

method 是被代理的方法类型对象，args是方法的参数数组。通过Proxy.newProxyInstance生成代理类后就可以执行其中的代理方法了。

   如果我们直接执行SubjectImpl.test()方法则只返回一个字符串，但使用动态代理我们可以在方法执行前和执行后加上自己的逻辑，这样大大提高了代码的复用性；想一想，如果你写了一堆方法，方法里很多代码是一样的，这样的代码是不是很丑？好，现在你把重复的代码单独抽出来做一个方法，但这样你的每个方法都被写死了，和那个公共的方法耦合在一起，这样很不灵活。如果我突然想一部分方法的公共方法是a(),一部分方法的公共方法是b(),那改起来很麻烦，扩展性很差。使用动态代理就很好的解决了这个问题，被代理对象可以任意指定，代理的逻辑可以任意实现，二者互相独立互不影响，并且可以由客户端任意进行组合，这就是所谓的动态。

展开全文 >>

jvm系列之对象引用分析

java 引用介绍

在JDK 1.2以前的版本中，若一个对象不被任何变量引用，那么程序就无法再使用这个对象。对象引用被划分成简单的两种状态：可用和不可用。从JDK 1.2版本以后，对象的引用被划分为4种级别，从而使程序能更加灵活地控制对象的生命周期，引用的强度由高到低为：强、软、弱、虚引用。

对象生命周期：在JVM运行空间中，对象的整个生命周期大致可以分为7个阶段：创建阶段（Creation）、应用阶段（Using）、不可视阶段（Invisible）、不可到达阶段（Unreachable）、可收集阶段（Collected）、终结阶段（Finalized）与释放阶段（Free）。上面的这7个阶段，构成了 JVM中对象的完整的生命周期。

more >>

展开全文 >>

spring笔记

分为20个模块

core container

core beans context expression language

image.png

image.png

spring

  1. 读取bean的配置信息
  2. 根据配置信息实例化一个bean
  3. 调用实例化后的实例

beanFactory

bean被当做一种资源，各个factory完成对bean的增删改查，注入读取，初始化等功能

inputStreamSource 封装inputstream

factoryBean :

spring的标准实例化bean的流程是在xml中提供配置信息然后读取配置信息。factoryBean通过实现接口的方式实例化bean（java代码配置bean信息）

demo

image.png

单例在spring同一个容器中只会被创建一次，后续直接从单例缓存中获取

循环依赖

objectFactory

singletonFactory

  1. 检查缓存是否已经加载过
  2. 若没加载就记录下来

创建bean

  1. classname
  2. 检查override
  3. 检查bean是否已经存在
  4. 创建bean

实例化前置处理器

实例化后置处理器

循环依赖

检查是否循环依赖

循环依赖会导致内存溢出

构造器循环依赖

image.png

支持用户扩展

SpringMVC流程

1、 用户发送请求至前端控制器DispatcherServlet。

2、 DispatcherServlet收到请求调用HandlerMapping处理器映射器。

3、 处理器映射器找到具体的处理器(可以根据xml配置、注解进行查找)，生成处理器对象及处理器拦截器(如果有则生成)一并返回给DispatcherServlet。

4、 DispatcherServlet调用HandlerAdapter处理器适配器。

5、 HandlerAdapter经过适配调用具体的处理器(Controller，也叫后端控制器)。

6、 Controller执行完成返回ModelAndView。

7、 HandlerAdapter将controller执行结果ModelAndView返回给DispatcherServlet。

8、 DispatcherServlet将ModelAndView传给ViewReslover视图解析器。

9、 ViewReslover解析后返回具体View。

10、DispatcherServlet根据View进行渲染视图（即将模型数据填充至视图中）。

11、 DispatcherServlet响应用户。

组件： 1、前端控制器DispatcherServlet（不需要工程师开发）,由框架提供 作用：接收请求，响应结果，相当于转发器，中央处理器。有了dispatcherServlet减少了其它组件之间的耦合度。 用户请求到达前端控制器，它就相当于mvc模式中的c，dispatcherServlet是整个流程控制的中心，由它调用其它组件处理用户的请求，dispatcherServlet的存在降低了组件之间的耦合性。

2、处理器映射器HandlerMapping(不需要工程师开发),由框架提供 作用：根据请求的url查找Handler HandlerMapping负责根据用户请求找到Handler即处理器，springmvc提供了不同的映射器实现不同的映射方式，例如：配置文件方式，实现接口方式，注解方式等。

3、处理器适配器HandlerAdapter 作用：按照特定规则（HandlerAdapter要求的规则）去执行Handler 通过HandlerAdapter对处理器进行执行，这是适配器模式的应用，通过扩展适配器可以对更多类型的处理器进行执行。

4、处理器Handler(需要工程师开发) 注意：编写Handler时按照HandlerAdapter的要求去做，这样适配器才可以去正确执行Handler Handler 是继DispatcherServlet前端控制器的后端控制器，在DispatcherServlet的控制下Handler对具体的用户请求进行处理。 由于Handler涉及到具体的用户业务请求，所以一般情况需要工程师根据业务需求开发Handler。

5、视图解析器View resolver(不需要工程师开发),由框架提供 作用：进行视图解析，根据逻辑视图名解析成真正的视图（view） View Resolver负责将处理结果生成View视图，View Resolver首先根据逻辑视图名解析成物理视图名即具体的页面地址，再生成View视图对象，最后对View进行渲染将处理结果通过页面展示给用户。 springmvc框架提供了很多的View视图类型，包括：jstlView、freemarkerView、pdfView等。 一般情况下需要通过页面标签或页面模版技术将模型数据通过页面展示给用户，需要由工程师根据业务需求开发具体的页面。

6、视图View(需要工程师开发jsp…) View是一个接口，实现类支持不同的View类型（jsp、freemarker、pdf…）

核心架构的具体流程步骤如下： 1、首先用户发送请求——>DispatcherServlet，前端控制器收到请求后自己不进行处理，而是委托给其他的解析器进行处理，作为统一访问点，进行全局的流程控制； 2、DispatcherServlet——>HandlerMapping， HandlerMapping 将会把请求映射为HandlerExecutionChain 对象（包含一个Handler 处理器（页面控制器）对象、多个HandlerInterceptor 拦截器）对象，通过这种策略模式，很容易添加新的映射策略； 3、DispatcherServlet——>HandlerAdapter，HandlerAdapter 将会把处理器包装为适配器，从而支持多种类型的处理器，即适配器设计模式的应用，从而很容易支持很多类型的处理器； 4、HandlerAdapter——>处理器功能处理方法的调用，HandlerAdapter 将会根据适配的结果调用真正的处理器的功能处理方法，完成功能处理；并返回一个ModelAndView 对象（包含模型数据、逻辑视图名）； 5、ModelAndView的逻辑视图名——> ViewResolver， ViewResolver 将把逻辑视图名解析为具体的View，通过这种策略模式，很容易更换其他视图技术； 6、View——>渲染，View会根据传进来的Model模型数据进行渲染，此处的Model实际是一个Map数据结构，因此很容易支持其他视图技术； 7、返回控制权给DispatcherServlet，由DispatcherServlet返回响应给用户，到此一个流程结束。

下边两个组件通常情况下需要开发：

Handler：处理器，即后端控制器用controller表示。

View：视图，即展示给用户的界面，视图中通常需要标签语言展示模型数据。

WebApplicationContext

ServletContext

ApplicationContext

问：

我们可以通过

ApplicationContext ap = new ClassPathXmlApplicationContext(“applicationContext.xml”);

得到一个spring容器，那么在传统ssm项目中是如何。。知道了

spring bean的生命周期

实例化bean对象(通过构造方法或者工厂方法)

设置对象属性(setter等)（依赖注入）

如果Bean实现了BeanNameAware接口，工厂调用Bean的setBeanName()方法传递Bean的ID。（和下面的一条均属于检查Aware接口）

如果Bean实现了BeanFactoryAware接口，工厂调用setBeanFactory()方法传入工厂自身

将Bean实例传递给Bean的前置处理器的postProcessBeforeInitialization(Object bean, String beanname)方法

调用Bean的初始化方法

将Bean实例传递给Bean的后置处理器的postProcessAfterInitialization(Object bean, String beanname)方法

使用Bean

容器关闭之前，调用Bean的销毁方法

展开全文 >>

redis笔记

redis基础知识

客户端与服务端的通讯协议是建立在TCP协议之上构建的；

redis序列化协议 resp

  • 状态回复（status reply）的第一个字节是 "+"
  • 错误回复（error reply）的第一个字节是 "-"
  • 整数回复（integer reply）的第一个字节是 ":"
  • 批量回复（bulk reply）的第一个字节是 "$"
  • 多条批量回复（multi bulk reply）的第一个字节是 "*"
more >>

展开全文 >>

git subtree多项目合并试验

说明

git subtree可将多个git项目合并在一起，可解决protobuf更新的问题；

打包maven私有仓库也可行，但是maven私有仓库不适合频繁更新，而protobuf更新会很频繁。

测试

1
2
3
4
5
6
7
8
9
10
11
12
13

git clone一个新项目

git remote add <name> <url> 添加一个远程仓库

git subtree add --prefix=<dir> <name> master --squash

git push 会把子仓库的文件提交，合情合理

# 更新子仓库的方法

git subtree push --prefix=<dir> <name> master

more >>

展开全文 >>

windows使用技巧

每次开机都启动一堆软件，很麻烦，该肿么办？

写个批处理文件 步骤（这里以启动微信为例 ）：

  1. 新建一个文本文档
  2. 输入以下命令：

start “xx” “xxx”

xx 代表程序名称，可以随便起；xxx代表你想启动的程序的位置 获取程序位置的方法：

more >>

展开全文 >>

leetcode刷题记录

这篇博客会记录我的一些刷题心得

参考：leetcode答案

两数之和

给定一个整数数组 nums 和一个目标值 target，请你在该数组中找出和为目标值的那 两个 整数，并返回他们的数组下标。

你可以假设每种输入只会对应一个答案。但是，你不能重复利用这个数组中同样的元素。

more >>

展开全文 >>

springCloud学习笔记——配置高可用Eureka

CAP 定理

原文链接 http://www.ruanyifeng.com/blog/2018/07/cap.html

分布式系统的最大难点，就是各个节点的状态如何同步。CAP 定理是这方面的基本定理，也是理解分布式系统的起点。

  • Consistency 中文叫做”一致性”。意思是，写操作之后的读操作，必须返回该值。

  • Availability Availability 中文叫做”可用性”，意思是只要收到用户的请求，服务器就必须给出回应。

  • Partition tolerance 中文叫做”分区容错”。大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区（partition）。分区容错的意思是，区间通信可能失败。

    这三个指标不可能同时做到，一般来说，分区容错无法避免，因此可以认为 CAP 的 P 总是成立。CAP 定理告诉我们，剩下的 C 和 A 无法同时做到。对于Eureka而言，其是满足AP的。

more >>

展开全文 >>

nio学习笔记

作者：muggle

nio介绍

传统的IO又称BIO，即阻塞式IO，NIO就是非阻塞IO了，而NIO在jdk1.7后又进行了升级成为nio.2也就是aio；
Java IO的各种流是阻塞的。这意味着，当一个线程调用read()或 write()时，该线程被阻塞，直到有一些数据被读取，或数据完全写入。该线程在此期间不能再干任何事情了。 Java NIO的非阻塞模式，使一个线程从某通道发送请求读取数据，但是它仅能得到目前可用的数据，如果目前没有数据可用时，就什么都不会获取。而不是保持线程阻塞，所以直至数据变的可以读取之前，该线程可以继续做其他的事情。 非阻塞写也是如此。一个线程请求写入一些数据到某通道，但不需要等待它完全写入，这个线程同时可以去做别的事情。 线程通常将非阻塞IO的空闲时间用于在其它通道上执行IO操作，所以一个单独的线程现在可以管理多个输入和输出通道（channel）。

more >>

展开全文 >>

springcloud-Eureka

作者：muggle

服务治理

服务治理是微服务架构中最为核心和基础的模块。它主要用来实现各个微服务实例的自动化注册与发现。随着服务的越来越多，越来越杂，服务之间的调用会越来越复杂，越来越难以管理。而当某个服务发生了变化，或者由于压力性能问题，多部署了几台服务，怎么让服务的消费者知晓变化，就显得很重要了。不然就会存在调用的服务其实已经下线了，但调用者不知道等异常情况。这个时候有个服务组件去统一治理就相当重要了。Eureka便是服务治理的组件。

more >>

展开全文 >>

设计模式笔记-大纲

作者：muggle

设计模式的分类

创建型模式

共五种：

  • 工厂方法模式
  • 抽象工厂模式
  • 单例模式
  • 建造者模式
  • 原型模式

结构型模式

共七种：

  • 适配器模式
  • 装饰器模式
  • 代理模式
  • 外观模式
  • 桥接模式
  • 组合模式
  • 享元模式

行为型模式

共十一种：

  • 策略模式

  • 模板方法模式

  • 观察者模式

  • 迭代子模式

  • 责任链模式

  • 命令模式

  • 备忘录模式

  • 状态模式

  • 访问者模式

  • 中介者模式

  • 解释器模式

    设计原则

设计模式的最终目的是为了实现代码设计的六大基本原则的，我们在使用设计模式的时候千万要记住这一点，不用为了使用设计模式而去强行套设计模式

单一职责原则

不要存在多于一个导致类变更的原因，也就是说每个类应该实现单一的职责，如若不然，就应该把类拆分。

当需求变化时，将通过更改职责相关的类来体现。如果一个类拥有多于一个的职责，则多个职责耦合在一起，会有多于一个原因来导致这个类发生变化。一个职责的变化可能会影响到其他的职责，另外，把多个职责耦合在一起，影响复用性。

单一职责原则解决的问题：

  • 降低类的复杂度；
  • 提高类的可读性，提高系统的可维护性；
  • 降低变更引起的风险（降低对其他功能的影响）。

里氏替换原则

任何基类可以出现的地方，子类一定可以出现。

只有当子类可以替换掉父类， 代码功能不受到影响时，父类才能真正被复用， 而子类也能够在父类的基础上增加新的行为；从而达到代码复用与扩展的目的；里氏替换原则中，子类对父类的方法尽量不要重写和重载。因为父类代表了定义好的结构，通过这个规范的接口与外界交互，子类不应该随便破坏它。

里氏替换原则解决的问题：

  • 增强程序的健壮性， 版本升级时也可以保持非常好的兼容性。
  • 提高代码复用率

依赖倒置原则

这个是开闭原则的基础，具体内容：面向接口编程，依赖于抽象而不依赖于具体。写代码时用到具体类时，不与具体类交互，而与具体类的上层接口交互。

开闭原则

对于引用的模块尽量去扩展，而不是去修改它，也就是所谓的对扩展开放对修改关闭。开闭原则是面向对象的可复用设计的第一块基石，它是最重要的面向对象设计原则，抽象化是开闭原则的关键。

接口隔离原则

接口隔离原则(Interface Segregation Principle, ISP)：使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。 根据接口隔离原则，当一个接口太大时，我们需要将它分割成一些更细小的接口，使用该接口的客户端仅需知道与之相关的方法即可

迪米特原则

一个类应该对自己需要耦合或调用的类知道得最少，类的内部如何实现、如何复杂都与调用者或者依赖者没关系，调用者或者依赖者只需要知道他需要的方法即可，其他的我一概不关心。类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。

设计模式解析

首先允许我提一点建议，有不少设计模式的教程喜欢拿生活中一些事物举例子，比如什么什么奥迪汽车，宝马，汽车工厂这种。这种方式确实能让人更加直观的的体会到一个设计模式的用法和作用，但是我以前这样学的后果就是——看啥都像设计模式，想往设计模式里面套又套不出个所以然来。实际上有的设计模式结构是由好几个角色组成，该如何去写怎么命名都是确定的有理有据的，你光记住生活中的一个例子然后平时写代码去套这个例子，你会有种无从下手的感觉。我们应该把每个设计模式的使用场景结构都记住，但是这样死记难记不说，还很难做到活学活用。我的的建议是结合源码去记，这样你能根据源码中的例子依瓢画葫芦写出自己想要的设计模式出来，我接下来对设计模式的讲解也是结合源码进行讲解的。

然后，我个人建议是能不用设计模式的地方就不用设计模式。并不是因为设计模式不好，一个设计得好的设计模式确实可以减少我们工作量和代码维护成本，但是一个设计不好的设计模式使用起来代价巨大。要知道设计模式的最终目的是减少我们的工作量，不要为了设计模式而设计模式。一个垃圾的设计模式的缺点：代码维护成本翻倍，因为会凭空多了好多莫名其妙的类；代码读不懂，你设计模式用的乱七八糟，别人只会感觉你的代码毫无逻辑，绕来绕去。

一个好的设计模式，首先要用对场景，然后命名要规范，要让别人一看命名就知道你用的什么设计模式，然后根据设计模式去找相关联的类，这样别人脑海里才能形成一个脉络，有点没法按设计模式规范命名的地方也请加上注释，不然让别人猜你的代码写了些啥，用的啥设计模式吗？

展开全文 >>

jvm基础篇五之类加载机制

muggle

1.类的生命周期

   类从被加载到虚拟机内存中内存中开始，到卸载出内存为止，它的整个生命周期包括：加载（loading）、验证（verification）、准备（preparation）、解析（resolution）、初始化（initialization）、使用（using）卸载（unloading）七个阶段。其中验证、准备、解析三个阶段统称为连接（linking）。

2.加载

   加载是类加载机制的第一个阶段，在这个阶段，虚拟机做了三件事情：

  • 通过类的全限定名来获取定义此类的二进制字节流；
  • 将这个字节流所代表的静态存储结构转换为方法区的运行时数据结构
  • 在内存中生成一个代表这个类的Class对象，作为方法区这个类的各种数据的访问入口

   加载阶段完成后，虚拟机外部的二进制字节流就按照虚拟机所需的格式存储在方法区之中，方法区中的数据存储格式由虚拟机实现自行定义；然后在内存中实例化一个Class类的对象，加载阶段和连接阶段的部分内容是交叉进行的，加载阶段尚未完成，连接阶段可能已经开始了。

3.验证

   验证是连接阶段的第一步，这一阶段目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。从整体上来看，验证阶段包括以下四个动作：文件格式验证、元数据验证、字节码验证、符号引用验证。

4.准备

   准备阶段是正式为类变量分配内存并设置类变量初始值得阶段，这些变量所使用的内存都将在方法区中进行分配。这个阶段中有两个容易产生混淆的概念——1.这个时候进行内存分配的仅包括类变量（被static修饰的变量），而不包括实例变量，2.这里初始值是数据类型的零值，假设一个类变量定义为 ：

1
public static int value=2;

那变量value在准备阶段的值为0而不是2.

5.解析

   解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。

6.初始化

   类初始化阶段是类加载过程的最后一步，前面的类加载过程中，除了在加载阶段可以通过自定义类加载器参与之外，其余动作都是虚拟机控制的。到了初始化阶段，才真正的执行java代码。初始化阶段是执行类构造器()方法的过程。

   想要使用一个类，必须对其进行初始化，但初始化过程不是必然执行的；jvm规范中规定有且只有以下五种情况必须对类进行初始化：

  • 遇到new、getstatic、putstatic、invokestatic这四个字节码指令的时候，如果类没有进行初始化，则需要先触发其初始化。生成这四条指令最常见的java代码场景是：使用new创建对象、读取或者设置一个类的静态字段（不包括值已在常量池中的情况）、调用一个类的静态方法的时候；
  • 使用java反射机制的时候，如果类没初始化需要先初始化；
  • 当初始化一个类的时候，如果发现其父类还未初始化，则需要先初始化父类。
  • 当虚拟机启动时，用户需要指定一个要执行的主类，虚拟机会先初始化那个类。

以上五种情况称为对一个类进行主动引用；其他引用类的方式都不会触发初始化，称为被动引用。下面举一个被动引用的例子：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
public class TestClassloading {
    static {
        System.out.println("父类被初始化");
    }
    public static int number=111;
}

public class SubClass extends TestClassloading {
    static {
        System.out.println("子类被初始化");
    }
}

public class Main {
    public static void main(String[] args) {
        System.out.println(SubClass.number);
    }
}

输出结果：

1
2
父类被初始化
111

显然，子类没有被初始化，这里SubClass.number为被动引用，不会对子类初始化。

7.类加载器

   通过一个类的全限定名来获取描述此类的二进制字节流这个动作被放到虚拟机外部区实现，以便让应用程序自己决定如何去获取所需的类，实现这个动作的代码模块称为类加载器。对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在java虚拟机中的唯一性，每一个类加载器都拥有一个独立的类名称空间。也就是说比较两个类是否相等必须要类加载器和类都相等。
   从java虚拟机的角度来讲，只存在两种不同的类加载器：一种是启动类加载器，这个类加载器是虚拟机的一部分；另一种就是java代码实现的独立于虚拟机外部的类加载器，这种类加载器继承类抽象类java.lang.TestClassloader。

   类加载器还有一个很重要的概念就是双亲委派模型——在类加载器工作的时候是多个类加载器一起工作的它们包括：扩展类加载器，应用程序类加载器，启动类加载器，自定义类加载器。类加载器的层次图如图：

类加载器层次结构

   双亲委派模型的工作流程是如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求交给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都会被交给启动类加载器，当父类反馈无法加载这个类的时候，子类才会进行加载。

展开全文 >>

jvm基础篇四之垃圾收集算法

1 标记-清除算法

标记-清除算法是最基础的算法，算法分为标记和清除两个阶段，首先标记出要清除的对象，在标记完后统一回收所有被标记的对象，标记方式为j《jvm系列之垃圾收集器》里面所提到的。这种算法标记和清除两个过程效率都不高；并且在标记清除后，内存空间变得很零散，产生大量内存碎片。当需要分配一个比较大的对象时有可能会导致找不到足够大的内存。 more >>

展开全文 >>

jvm基础篇三之垃圾收集器

垃圾收集器介绍

   java内存在运行时被分为多个区域，其中程序计数器、虚拟机栈、本地方法栈三个区域随线程生成和销毁；每一个栈帧中分配多少内存基本上是在类结构确定下来时就已知的，在这几个区域内就不需要过多考虑回收问题，因为方法结束或者线程结束时，内存自然就跟着回收了。而堆区就不一样了，我们只有在程序运行的时候才能知道哪些对象会被创建，这部分内存是动态分配的，垃圾收集器主要关注的也就是这部分内存。

more >>

展开全文 >>

jvm基础篇二之对象

作者：muggle

对象的创建

   在语言层面上，创建一个对象通常是通过new关键字来创建，在虚拟机中遇到一条new指令时，首先将去检查这个指令的参数是否能在常量池中定位到一个类的符号引用，并且检查这个符号引用代表的类是否已被加载、解析和初始化过；如果没有的话就会先加载这个类；类加载检查完后，虚拟机将会为新生对象分配内存。对象所需内存的大小在类加载完成后便可完全确定，在堆中为对象划分一块内存出来。

   虚拟机给对象分配内存的方式有两种——“指针碰撞”的方式和“空闲列表”的方式。如果java堆内存是绝对规整的，所有用过的内存放在一边，未使用的内存放在另一边，中间放一个指针作为指示器，那分配内存就只是把指针向未使用区域挪一段与对象大小相等的距离；这种分配方式叫指针碰撞式，如图1所示。

more >>

展开全文 >>

jvm基础篇一之内存区域

作者：muggle

运行时数据区域

   想要了解jvm，那对其内存分配管理的学习是必不可少的；java虚拟机在执行java程序的时候会把它所管理的内存划分成若干数据区域。这些区域有着不同的功能、用途、创建/销毁时间。java虚拟机所分配管理的内存区域如图1所示

程序计数器

   程序计数器是一块比较小的内存空间，它可以看做是当前线程所执行的字节码的执行位置的指针。在虚拟机中字节码，解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的指令；虚拟机完成分支、循环、跳转、异常处理、线程恢复等功能都需要依靠它。
   我们知道jvm多线程是通过线程的轮流切换并分配处理器执行时间的的方式来实现的，在任何时刻，一个处理器都只会执行一条线程中的指令。为了使线程被切换后能恢复到正确的执行位置，每条线程的程序计数器都应该是独立的，各条线程之间的计数器互不干涉，独立存储————程序计数器的内存区域为线程私有的内存。

   如果线程正在执行的是java方法，这个计数器记录的是正在执行的虚拟机字节码指令的地址；如果执行的是Native方法，这个计数器的值则为空。此内存区域是唯一一个在jvm规范中没有规定任何OutOfMemoryerror情况的区域

more >>

展开全文 >>

多线程编程进阶篇

作者：muggle

锁优化

减小锁持有时间

减小锁的持有时间可有效的减少锁的竞争。如果线程持有锁的时间越长，那么锁的竞争程度就会越激烈。因此，应尽可能减少线程对某个锁的占有时间，进而减少线程间互斥的可能。

减少锁持有时间的方法有：

  • 进行条件判断，只对必要的情况进行加锁，而不是整个方法加锁；
  • 减少加锁代码的行数，只对必要的步骤加锁。
more >>

展开全文 >>

多线程编程基础第二篇

作者：muggle

扩展

cas(比较替换)：无锁策略的一种实现方式，过程为获取到变量旧值（每个线程都有一份变量值的副本），和变量目前的新值做比较，如果一样证明变量没被其他线程修改过，这个线程就可以更新这个变量，否则不能更新；通俗的说就是通过不加锁的方式来修改共享资源并同时保证安全性。

使用cas的话对于属性变量不能再用传统的int ,long等；要使用原子类代替原先的数据类型操作，比如AtomicBoolean，AtomicInteger，AtomicInteger等。

java线程锁的分类与实现

以下分类是从多个同角度来划分，而不是以某一标准来划分，请注意

  • 阻塞锁：当一个线程获得锁，其他线程就会被阻塞挂起，直到抢占到锁才继续执行，这样会导致CPU切换上下文，切换上下文对CPU而言是很耗费时间的
  • 非阻塞锁：当一个线程获得锁，其他线程直接跳过锁资源相关的代码继续执行，就是非阻塞锁
  • 自旋锁：当一个线程获得锁，其他线程则在不停进行空循环，直到抢到锁，这样做的好处是避免了上下文切换
  • 可重入锁：也叫做递归锁，当一个线程外层函数获得锁之后 ，内层递归函数仍然可以该锁的相关代码，不受影响。
  • 互斥锁：互斥锁保证了某一时刻只能有一个线程占有该资源。
  • 读写锁：将代码功能分为读和写，读不互斥，写互斥；
  • 公平锁/非公平锁：公平锁就是在等待队列里排最前面的的先获得锁，非公平锁就是谁抢到谁用；
  • 重量级锁/轻量级锁/偏向锁：使用操作系统“Mutex Lock”功能来实现锁机制的叫重量级锁，因为这种锁成本高；轻量级锁是对重量级锁的优化，提高性能；偏向锁是对轻量级锁的优化，在无多线程竞争的情况下尽量减少不必要的轻量级锁执行路径。
more >>

展开全文 >>

多线程编程基础第一篇

作者：muggle

java并发相关概念

同步和异步

同步和异步通常来形容一次方法的调用。同步方法一旦开始，调用者必须等到方法结束才能执行后续动作；异步方法则是在调用该方法后不必等到该方法执行完就能执行后面的代码，该方法会在另一个线程异步执行，异步方法总是伴随着回调，通过回调来获得异步方法的执行结果；

并发和并行

很多人都将并发与并行混淆在一起，它们虽然都可以表示两个或者多个任务一起执行，但执行过程上是有区别的。并发是多个任务交替执行，多任务之间还是串行的；而并行是多个任务同时执行，和并发有本质区别。
对计算机而言，如果系统内只有一个cpu，而使用多进程或者多线程执行任务，那么这种情况下多线程或者多进程就是并行执行，并行只可能出现在多核系统中。当然，对java程序而言，我们不必去关心程序是并行还是并发。

more >>

展开全文 >>

博客搭建新司机指南

作者：muggle

准备工作

安装hexo并创建一个博客项目

在安装hexo之前请确保安装了git 和node.js

打开cmd，输入

1
npm install -g hexo-cli

创建一个名为blog的博客项目

1
2
3
$ hexo init blog
$ cd blog
$ npm install

新建完成后，指定文件夹的目录如下：

1
2
3
4
5
6
7
8
.
├── _config.yml
├── package.json
├── scaffolds
├── source
|   ├── _drafts
|   └── _posts
└── themes

配置

可以在 _config.yml 中修改大部分的配置。配置参数说明：

参数 描述
title 网站标题
subtitle 网站副标题
description 网站描述
author 您的名字
language 网站使用的语言
timezone 网站时区。Hexo 默认使用您电脑的时区。时区列表。比如说：America/New_York, Japan, 和 UTC 。

撸博客

新建文章并查看效果

在项目文件夹下打开cmd 执行

1
hexo new "test"

test 为你的文件名，在source文件下的_posts 文件夹里有一个test.md；用markdown编辑器打开，就能写博客辣。

在这个md文件头部有一个title的属性，就是你的博客名，还可以在该头部配置日期等属性，这个文件最上方以 --- 分隔的区域叫Front-matter。以下是一些预先定义的参数，您可在模板中使用这些参数值并加以利用。

参数 描述 默认值
layout 布局
title 标题
date 建立日期 文件建立日期
updated 更新日期 文件更新日期
comments 开启文章的评论功能 true
tags 标签（不适用于分页）
categories 分类（不适用于分页）
permalink 覆盖文章网址

写完文章保存后，在原来打开的命令窗口 运行

1
hexo g

这个指令是构建静态页面，它会在项目下生成一个public文件夹，里面就是我们hexo g得到博客静态页面，运行

1
hexo s

将代码部署到本地，访问http://localhost:4000/可以查看你的博客效果

上传

博客上传之前需要在github上建立一个仓库，仓库名称要为用户名.github.io，因为我们博客就算基于gitpages来搭建的，所以我们要按照github的要求来命名。

创建成功之后，修改 hexo 的 _config.yml 文件，配置 GitHub 地址，如下：

1
2
3
4
deploy:  
	type: git  
	repo: 仓库地址  
	branch: master

配置完成运行

1
hexo d

完成部署，这个时候可以访问 用户名.github.io这个网址来查看自己的博客

hexo命令一览

1
$ hexo init [folder]

新建一个网站。如果没有设置 folder ，Hexo 默认在目前的文件夹建立网站。

new

1
$ hexo new [layout] <title>

新建一篇文章。如果没有设置 layout 的话，默认使用 _config.yml 中的 default_layout 参数代替。如果标题包含空格的话，请使用引号括起来。

1
$ hexo new "post title with whitespace"

generate

1
$ hexo generate

生成静态文件。

选项 描述
-d, --deploy 文件生成后立即部署网站
-w, --watch 监视文件变动

该命令可以简写为

1
$ hexo g

publish

1
$ hexo publish [layout] <filename>

发表草稿。

server

1
$ hexo server

启动服务器。默认情况下，访问网址为： http://localhost:4000/。

选项 描述
-p, --port 重设端口
-s, --static 只使用静态文件
-l, --log 启动日记记录，使用覆盖记录格式

deploy

1
$ hexo deploy

部署网站。

参数 描述
-g, --generate 部署之前预先生成静态文件

该命令可以简写为：

1
$ hexo d

render

1
$ hexo render <file1> [file2] ...

渲染文件。

参数 描述
-o, --output 设置输出路径

migrate

1
$ hexo migrate <type>

从其他博客系统 迁移内容。

clean

1
$ hexo clean

清除缓存文件 (db.json) 和已生成的静态文件 (public)。

在某些情况（尤其是更换主题后），如果发现您对站点的更改无论如何也不生效，您可能需要运行该命令。

list

1
$ hexo list <type>

列出网站资料。

version

1
$ hexo version

显示 Hexo 版本。

选项

安全模式

1
$ hexo --safe

在安全模式下，不会载入插件和脚本。当您在安装新插件遭遇问题时，可以尝试以安全模式重新执行。

调试模式

1
$ hexo --debug

在终端中显示调试信息并记录到 debug.log。当您碰到问题时，可以尝试用调试模式重新执行一次，并 提交调试信息到 GitHub。

简洁模式

1
$ hexo --silent

隐藏终端信息。

自定义配置文件的路径

1
$ hexo --config custom.yml

自定义配置文件的路径，执行后将不再使用 _config.yml。

显示草稿

1
$ hexo --draft

显示 source/_drafts 文件夹中的草稿文章。

自定义 CWD

1
$ hexo --cwd /path/to/cwd

自定义当前工作目录（Current working directory）的路径。

进阶

换主题

下载主题到./themes目录下，修改 hexo 的 _config.yml 文件的theme属性为你的主题名就ok了，下面推荐几个hexo主题

换域名

首先申请一个域名，然后在博客所在目录下的 source 目录中，创建一个 CNAME 文件，文件内容就是你的域名，然后执行 hexo d 命令将这个文件上传到 GitHub就可以了；域名换好后需要配置域名解析。

附

markdown 语法一览

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
# 这是一级标题
## 这是二级标题
### 这是三级标题
#### 这是四级标题
##### 这是五级标题
###### 这是六级标题
**这是加粗的文字**
*这是倾斜的文字*
***这是斜体加粗的文字***
~~ 这是加删除线的文字~~
> 这是引用的内容
三个或者三个以上的 - 或者 *为分割线
![图片alt](图片地址 ''图片title'')
[超链接名](超链接地址 "超链接title")
    
- 列表内容
+ 列表内容
* 列表内容
注意：- + * 跟内容之间都要有一个空格

1.列表内容
2.列表内容
3.列表内容

注意：序号跟内容之间要有空格

表头|表头|表头
---|:--:|---:
内容|内容|内容
内容|内容|内容
`代码内容`
​```
代码内容
​```

markdown文档编辑器Typora

百度Typora 下载安装好之后点 文件>偏好设置>勾选自动保存，这样就不怕忘记保存而文档丢失了；

快捷键：

  • 标题：ctrl+数字
  • 表格：ctrl+t
  • 生成目录：[TOC]按回车
  • 选中一整行：ctrl+l
  • 选中单词：ctrl+d
  • 选中相同格式的文字：ctrl+e
  • 跳转到文章开头：ctrl+home
  • 跳转到文章结尾：ctrl+end
  • 搜索：ctrl+f
  • 替换：ctrl+h
  • 引用：输入>之后输入空格
  • 代码块：ctrl+alt+f
  • 加粗：ctrl+b
  • 倾斜：ctrl+i
  • 下划线：ctrl+u
  • 删除线：alt+shift+5
  • 插入图片：直接拖动到指定位置即可或者ctrl+shift+i
  • 插入链接：ctrl + k

左下角有一个 O 和 </>的符号 O表示打开侧边栏 </>查看文档源代码；

可去官网下载好主题之后点 文件>偏好设置>打开主题文件夹将解压好的主题相关文件复制粘贴到该目录下（一般是一个 主题名称文件夹 和一个 主题名称.css文件）之后重启编辑器 然后点 主题可看见安装好的主题。

展开全文 >>

springSecurity深度解析第二版

作者：muggle

前言

由于第一版排版实在太过糟糕，而且很多细节没交代清楚，所以决定写第二版；这一版争取将排版设计得清晰明了一点，以方便读者阅读。

security原理分析

springSecurity过滤器链

springSecurity 采用的是责任链的设计模式，它有一条很长的过滤器链。现在对这条过滤器链的各个进行说明

  1. WebAsyncManagerIntegrationFilter：将Security上下文与Spring Web中用于处理异步请求映射的 WebAsyncManager 进行集成。

  2. SecurityContextPersistenceFilter：在每次请求处理之前将该请求相关的安全上下文信息加载到SecurityContextHolder中，然后在该次请求处理完成之后，将SecurityContextHolder中关于这次请求的信息存储到一个“仓储”中，然后将SecurityContextHolder中的信息清除
    例如在Session中维护一个用户的安全信息就是这个过滤器处理的。

  3. HeaderWriterFilter：用于将头信息加入响应中

  4. CsrfFilter：用于处理跨站请求伪造

  5. LogoutFilter：用于处理退出登录

  6. UsernamePasswordAuthenticationFilter：用于处理基于表单的登录请求，从表单中获取用户名和密码。默认情况下处理来自“/login”的请求。从表单中获取用户名和密码时，默认使用的表单name值为“username”和“password”，这两个值可以通过设置这个过滤器的usernameParameter 和 passwordParameter 两个参数的值进行修改。

  7. DefaultLoginPageGeneratingFilter：如果没有配置登录页面，那系统初始化时就会配置这个过滤器，并且用于在需要进行登录时生成一个登录表单页面。

  8. BasicAuthenticationFilter：检测和处理http basic认证

  9. RequestCacheAwareFilter：用来处理请求的缓存

  10. SecurityContextHolderAwareRequestFilter：主要是包装请求对象request

  11. AnonymousAuthenticationFilter：检测SecurityContextHolder中是否存在Authentication对象，如果不存在为其提供一个匿名Authentication

  12. SessionManagementFilter：管理session的过滤器

  13. ExceptionTranslationFilter：处理 AccessDeniedException 和 AuthenticationException 异常

  14. FilterSecurityInterceptor：可以看做过滤器链的出口

  15. RememberMeAuthenticationFilter：当用户没有登录而直接访问资源时, 从cookie里找出用户的信息, 如果Spring Security能够识别出用户提供的remember me cookie, 用户将不必填写用户名和密码, 而是直接登录进入系统，该过滤器默认不开启。

springSecurity 流程图

上一版是通过debug的方法告诉读者springSecurity的一个执行过程，发现反而把问题搞复杂了，这一版我决定画一个流程图来说明其执行过程，只要把springSecurity的执行过程弄明白了，这个框架就会变得很简单

more >>

展开全文 >>

在vscode中编写markdown

作者：muggle

为什么要markdown

  markdown语法学习成本低，而且非常方便排版，如果你经常写文章，那么你就很有必要掌握markdown了，而且在vscode中编写markdown也非常方便，只需掌握几个快捷键，安装几个插件就能极大的提高你的写作效率。

插件安装使用

使用设置相关

ctr+shift+x 输入markdown preview enhanced下载安装，
安装好之后新建 .md文件就能愉快的写文章了，这里对markdown语法就不做介绍了，比较简单；
说一下插件怎么使用
ctrl+shift+v 打开预览，按F1或者ctr+shift+p输入Markdown Preview Enhanced: Customize Css 可改预览样式；对于一些常用的代码段还可以在vsocde中设置代码段快捷键，一键生成代码或文字。

more >>

展开全文 >>

security-oauth2学习笔记

作者：muggle

oauth2 相关概念

文章参考理解OAuth 2.0

oauth2 角色关系

在oauth2中分为以下几个角色：Resource server、Authorization server、Resource Owner、application。

Resource server:资源服务器

Authorization server:认证服务器

Resource Owner:资源拥有者

application:第三方应用

oauth2的一次请求流程为：

第三方应用获取认证token 向认证服务器认证，认证服务器通过认证后第三方应用便可向资源服务器拿资源；第三方应用的获取资源的范围由资源拥有者授权。

显然由流程可知，oauth2要保证以下几点：
1.token的有效期和更新方式要可控，安全性要好
2.用户授权第三方应用要可以控制授权范围

more >>

展开全文 >>

springSecurity深度解析

作者：muggle

从一个基础的springsecurity开始，进行代码跟踪分析其原理

springsecurity是一个典型的责任链模式；我们先新建一个springboot项目，进行最基本的springsecurity配置，然后debug;我这里使用的开发工具是idea.建议大家也使用idea来进行日常开发。好了话不多说，开始：

第一步

新建springboot项目 maven依赖：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
<dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-security</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.springframework.security</groupId>
            <artifactId>spring-security-test</artifactId>
            <scope>test</scope>
        </dependency>
    </dependencies>

启动项目，控制台上会输出这样一段字符串：

1
2
3
4
2019-04-11 09:47:40.388  INFO 16716 --- [           main] .s.s.UserDetailsServiceAutoConfiguration :

Using generated security password: a6d55bc6-49fb-4241-a5ae-527e5e644731

more >>

展开全文 >>

netty学习笔记第一篇

作者：muggle

netty框架代码很猛（读源码有益身心健康），学习起来也比较难；在阅读这篇文章我假设你有了一定nio基础，tcp网络协议基础，否则不建议阅读。

关于netty的学习视频我推荐B站张龙的教学视频，讲的很不错。学netty之前先学会用，然后在去看他的原理这样学起来会轻松不少。

more >>

展开全文 >>

logback深度使用

作者：muggle

Logback是由log4j创始人设计的另一个开源日志组件,分为三个模块：

  1. logback-core：其它两个模块的基础模块

  2. logback-classic：它是log4j的一个改良版本，同时它完整实现了slf4j API使你可以很方便地更换成其它日志系统如log4j或JDK14 Logging

  3. logback-access：访问模块与Servlet容器集成提供通过Http来访问日志的功能
    在springboot中我们通过xml配置来操作logback

more >>

展开全文 >>

草稿箱 

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
/*
    * 第一个问题：虽然被包装过的list是线程安全的，但返回的list获得的Iterator仍然是线程不安全的，所以仍然要用Synchronized代码块包裹起来。

至于第二个问题，其实上面的文章链接也有提到, 大意是：与其所有（多线程）要用到该list都加上Synchronized修饰，还不如直接使用安全的collection更聪明。

也就是说，如果不使用Iterator迭代器的话，使用了安全的collection以后，其实我们不需要再用Synchronized代码块修饰了，这样使用上更方便。

反过来说，使用Iterator迭代器的话，似乎也没必要用Collections.synchronizedList的方法来包装了——反正都是必须要使用Synchronized代码块包起来的。

所以总的来说，Collections.synchronizedXX这种做法，适合不需要使用Iterator、对性能要求也不高的情况。
    *
    * */



/*
*
*  这就是所谓的线程安全的类，在多线程中一样会有问题，那这是为什么呢。后来在一篇博文当中看到了说Vector的contains方法和remove方法之前不具备原子性，这点给了提示。
*  我现在认为出错的原因是在get和remove之间并没有在以上环境中做到同步，比方说，一个线程的get（2）操作发生时，正好遇到了remove操作的正在进行，这时get（2）这个操作就会阻塞，
*  等待remove操作释放锁之后去操作。如果这时候remove操作的正好是remov（2）这个操作，等到去get的时候，这个元素已经没有了，get自然就只能是空欢喜一场。
    这里原因找到了，就该说解决办法了，在说解决办法之前，可能还会困惑，说好的线程安全呢，
    我的理解是，线程安全并不代表使用安全，在实际使用时还是需要考虑当前环境中是否会出现问题的。那么问题来了，java提供线程安全的某些类的意义在哪里呢，反正还是会出问题。
    这就显得比较鸡肋了，但是也不能说没有意义，毕竟写程序还是要独立思考的。
    解决办法就比较简单了，在两个线程的run方法里加上synchronized (testVector)，这样就会使得读取、删除线程中只会有一个对testVector进行操作，也就不会有上述情况出现。
    从这个错误来看的话，编程一定要谨慎，使用到的技术一定要深入了解，不能说不出问题，但是在出了问题之后能找出原因并解决，
    如果没有这个把握就不要轻易去使用，尤其在正式项目中，可能会让你欲哭无泪啊！

* */

队列

  • deque 双端对列
  • queue 阻塞队列 ArrayBlockingQueue ：一个由数组支持的有界队列。LinkedBlockingQueue ：一个由链接节点支持的可选有界队列。DelayQueue ：一个由优先级堆支持的、基于时间的调度队列。
  • PriorityQueue 和 ConcurrentLinkedQueue 非阻塞队列

展开全文 >>

接口幂等性问题

在数学里，幂等有两种主要的定义：在某二元运算下，幂等元素是指被自己重复运算(或对于函数是为复合)的结果等于它自己的元素。如，乘法运算下，0和1符合的自乘运算符和幂等，即s*s=s某一元运算为幂等的时，其作用在任一元素两次后会和其作用一次的结果相同。例如，高斯符号便是幂等的，即f(f(x))=f(x)在计算机中，表示对同一个过程应用相同的参数多次和应用一次产生的效果是一样，这样的过程即被称为满足幂等性在分布式和前后端分离的的项目中，对于restful风格的接口，我们需要保证其接口的幂等性，说白了就是就是一个接口被反复调用不会影响最终结果；为什么呢，因为前后端分离的项目可能会发生这样的场景：前端发出一个请求，但这个请求被阻塞了，然后其重试机制再次发起请求，而恰好此时被阻塞的那个请求又好了，那么这个时候，会对后端发起连续两次请求；对于 get，put,delete 都没问题，连续的两次或者三次都不会影响请求处理结果，但post就有问题了；它会往数据库插入两条数据。

more >>

展开全文 >>

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

90后有梦想的狗子<br>java工程师<br>公众号：六个核弹<br>喜欢就关注我吧