RPC核心原理和实战 —— 基础篇

发表于 2020-02-19 | 分类于 rpc

别老想着怎么用好RPC框架，你得多花时间琢磨原理

引言

1、为什么要学习 RPC？

只要涉及网络通信，我们就有可能使用RPC。

在我看来，RPC 是解决分布式系统通信问题的一大利器。分布式系统中的网络通信一般都会采用四层的 TCP 协议或七层的 HTTP 协议，在我的了解中，前者占大多数，这主要得益于 TCP 协议的稳定性和高效性。网络通信说起来简单，但实际上是一个非常复杂的过程，这个过程主要包括：对端节点的查找、网络连接的建立、传输数据的编码解码以及网络连接的管理等等，每一项都很复杂。

2、如何学习 RPC？

逐步深入

使用 RPC 就可以像调用本地一样发起远程调用，用它可以解决通信问题，这时候我们肯定要去学序列化、编解码以及网络传输这些内容。
把这些内容掌握后，你就会发现，原来这些只是 RPC 的基础，RPC 还有更吸引人的点，它真正强大的地方是它的治理功能，比如连接管理、健康检测、负载均衡、优雅启停机、异常重试、业务分组以及熔断限流等等。突然间，你会感觉自己走进了一个新世界，这些内容会成为你今后学习 RPC 的重点和难点。
对 RPC 活学活用，学会提升 RPC 的性能以及它在分布式环境下如何定位问题等等

1、核心原理：能否画张图解释RPC通信流程？

1.1、什么是RPC？

RPC 的全称是 Remote Procedure Call，即远程过程调用。简单解读字面上的意思，远程肯定是指要跨机器而非本机，所以需要用到网络编程才能实现。

RPC 的作用就是体现在这样两个方面：

屏蔽远程调用跟本地调用的区别，让我们感觉就是调用项目内的方法；
隐藏底层网络通信的复杂性，让我们更专注于业务逻辑；

1.2、RPC通信流程

1)、一个完成的RPC会涉及哪些步骤呢？

TCP通信：RPC 是一个远程调用，那肯定就需要通过网络来传输数据，并且 RPC 常用于业务系统之间的数据交互，需要保证其可靠性，所以 RPC 一般默认采用 TCP 来传输。
序列化：网络传输的数据必须是二进制数据，但调用方请求的出入参数都是对象。对象是肯定没法直接在网络中传输的，需要提前把它转成可传输的二进制，并且要求转换算法是可逆的，这个过程我们一般叫做“序列化”。
协议：在这里我们可以想想高速公路，它上面有很多出口，为了让司机清楚地知道从哪里出去，管理部门会在路上建立很多指示牌，并在指示牌上标明下一个出口是哪里、还有多远。那回到数据包识别这个场景，我们是不是也可以建立一些“指示牌”，并在上面标明数据包的类型和长度，这样就可以正确的解析数据了。确实可以，并且我们把数据格式的约定内容叫做“协议”。大多数的协议会分成两部分，分别是数据头和消息体。数据头一般用于身份识别，包括协议标识、数据大小、请求类型、序列化类型等信息；消息体主要是请求的业务参数信息和扩展属性等
反序列化：根据协议格式，服务提供方就可以正确地从二进制数据中分割出不同的请求来，同时根据请求类型和序列化类型，把二进制的消息体逆向还原成请求对象。这个过程叫作“反序列化”。
执行：服务提供方再根据反序列化出来的请求对象找到对应的实现类，完成真正的方法调用，然后把执行结果序列化后，回写到对应的 TCP 通道里面。调用方获取到应答的数据包后，再反序列化成应答对象，这样调用方就完成了一次 RPC 调用

2)、上述构成一个完成的RPC吗？

缺点：对于研发人员来说，这样做需要掌握太多的RPC底层细节，需要手动写代码去构造请求、调用徐磊好、并进行网络调用，整个API非常不友好；

如何简单 API，屏蔽 RPC 细节？

如果你了解 Spring，一定对其 AOP 技术很佩服，其核心是采用动态代理的技术，通过字节码增强对方法进行拦截增强，以便于增加需要的额外处理逻辑。其实这个技术也可以应用到 RPC 场景来解决我们刚才面临的问题。

由服务提供者给出业务接口声明，在调用方的程序里面，RPC 框架根据调用的服务接口提前生成动态代理实现类，并通过依赖注入等技术注入到声明了该接口的相关业务逻辑里面。该代理实现类会拦截所有的方法调用，在提供的方法处理逻辑里面完成一整套的远程调用，并把远程调用结果返回给调用方，这样调用方在调用远程方法的时候就获得了像调用本地接口一样的体验。

到这里，一个简单版本的 RPC 框架就实现了。我把整个流程都画出来了，供你参考：

1.3、RPC在架构中的位置

RPC是解决应用间通信的一种方式；

RPC 框架能够帮助我们解决系统拆分后的通信问题，并且能让我们像调用本地一样去调用远程方法。利用 RPC 我们不仅可以很方便地将应用架构从“单体”演进成“微服务化”，而且还能解决实际开发过程中的效率低下、系统耦合等问题，这样可以使得我们的系统架构整体清晰、健壮，应用可运维度增强。

当然 RPC 不仅可以用来解决通信问题，它还被用在了很多其他场景，比如：发 MQ、分布式缓存、数据库等。下图是我之前开发的一个应用架构图：

1.4、总结

本讲我主要讲了下 RPC 的原理，RPC 就是提供一种透明调用机制，让使用者不必显式地区分本地调用和远程调用。RPC 虽然可以帮助开发者屏蔽远程调用跟本地调用的区别，但毕竟涉及到远程网络通信，所以这里还是有很多使用上的区别，比如：

调用过程中超时了怎么处理业务？
什么场景下最适合使用 RPC？
什么时候才需要考虑开启压缩？

无论你是一个初级开发者还是高级开发者，RPC 都应该是你日常开发过程中绕不开的一个话题，所以作为软件开发者的我们，真的很有必要详细地了解 RPC 实现细节。只有这样，才能帮助我们更好地在日常工作中使用 RPC。课后思考

2、RPC协议：怎么设计可扩展向后兼容的协议？

一提到协议，你最先想到的可能是 TCP 协议、UDP 协议等等；

那 HTTP 协议跟 RPC 协议又有什么关系呢？看起来他俩好像不搭边，但他们有一个共性就是都属于应用层协议；

我们今天要讲的 RPC 协议就是围绕应用层协议展开的。我们可以先了解下 HTTP 协议，我们先看看它的协议格式是什么样子的。回想一下我们在浏览器里面输入一个 URL 会发生什么？抛开 DNS 解析暂且不谈，浏览器收到命令后会封装一个请求，并把请求发送到 DNS 解析出来的 IP 上，通过抓包工具我们可以抓到请求的数据包，如下图所示：

2.1、协议的作用

看完 HTTP 协议之后，你可能会有一个疑问，我们为什么需要协议这个东西呢？没有协议就不能通信吗？

我们知道只有二进制才能在网络中传输，所以 RPC 请求在发送到网络中之前，他需要把方法调用的请求参数转成二进制；转成二进制后，写入本地 Socket 中，然后被网卡发送到网络设备中。

但在传输过程中，RPC 并不会把请求参数的所有二进制数据整体一下子发送到对端机器上，中间可能会拆分成好几个数据包，也可能会合并其他请求的数据包（合并的前提是同一个 TCP 连接上的数据），至于怎么拆分合并，这其中的细节会涉及到系统参数配置和 TCP 窗口大小。对于服务提供方应用来说，他会从 TCP 通道里面收到很多的二进制数据，那这时候怎么识别出哪些二进制是第一个请求的呢？

所以呢，为了避免语义不一致的事情发生，我们就需要在发送请求的时候设定一个边界，然后在收到请求的时候按照这个设定的边界进行数据分割。这个边界语义的表达，就是我们所说的协议。

2.2、如何设计协议？

有了现成的 HTTP 协议，为啥不直接用，还要为 RPC 设计私有协议呢？

这还要从 RPC 的作用说起，相对于 HTTP 的用处，RPC 更多的是负责应用间的通信，所以性能要求相对更高。但 HTTP 协议的数据包大小相对请求数据本身要大很多，又需要加入很多无用的内容，比如换行符号、回车符等；还有一个更重要的原因是，HTTP 协议属于无状态协议，客户端无法对请求和响应进行关联，每次请求都需要重新建立连接，响应完成后再关闭连接。因此，对于要求高性能的 RPC 来说，HTTP 协议基本很难满足需求，所以 RPC 会选择设计更紧凑的私有协议。

那怎么设计一个私有 RPC 协议呢？

消息边界：消息长度，实现消息间正确断句

在协议头里面，我们除了会放协议长度、序列化方式，还会放一些像协议标示、消息 ID、消息类型这样的参数，而协议体一般只放请求接口方法、请求的业务参数值和一些扩展属性。这样一个完整的 RPC 协议大概就出来了，协议头是由一堆固定的长度参数组成，而协议体是根据请求接口和参数构造的，长度属于可变的，具体协议如下图所示：

2.3、可扩展的协议

刚才讲的协议属于定长协议头，那也就是说往后就不能再往协议头里加新参数了，如果加参数就会导致线上兼容问题。举个具体例子，假设你设计了一个 88Bit 的协议头，其中协议长度占用 32bit，然后你为了加入新功能，在协议头里面加了 2bit，并且放到协议头的最后。升级后的应用，会用新的协议发出请求，然而没有升级的应用收到的请求后，还是按照 88bit 读取协议头，新加的 2 个 bit 会当作协议体前 2 个 bit 数据读出来，但原本的协议体最后 2 个 bit 会被丢弃了，这样就会导致协议体的数据是错的。

可能你会想：“那我把参数加在不定长的协议体里面行不行？而且刚才你也说了，协议体里面会放一些扩展属性。”

没错，协议体里面是可以加新的参数，但这里有一个关键点，就是协议体里面的内容都是经过序列化出来的，也就是说你要获取到你参数的值，就必须把整个协议体里面的数据经过反序列化出来。但在某些场景下，这样做的代价有点高啊！

比如说，服务提供方收到一个过期请求，这个过期是说服务提供方收到的这个请求的时间大于调用方发送的时间和配置的超时时间，既然已经过期，就没有必要接着处理，直接返回一个超时就好了。那要实现这个功能，就要在协议里面传递这个配置的超时时间，那如果之前协议里面没有加超时时间参数的话，我们现在把这个超时时间加到协议体里面是不是就有点重了呢？显然，会加重 CPU 的消耗。

所以为了保证能平滑地升级改造前后的协议，我们有必要设计一种支持可扩展的协议。其关键在于让协议头支持可扩展，扩展后协议头的长度就不能定长了。那要实现读取不定长的协议头里面的内容，在这之前肯定需要一个固定的地方读取长度，所以我们需要一个固定的写入协议头的长度。整体协议就变成了三部分内容：固定部分、协议头内容、协议体内容，前两部分我们还是可以统称为“协议头”，具体协议如下：

最后，我想说，设计一个简单的 RPC 协议并不难，难的就是怎么去设计一个可“升级”的协议。不仅要让我们在扩展新特性的时候能做到向下兼容，而且要尽可能地减少资源损耗，所以我们协议的结构不仅要支持协议体的扩展，还要做到协议头也能扩展。上述这种设计方法来源于我多年的线上经验，可以说做好扩展性是至关重要的，期待这个协议模版能帮你避掉一些坑。

3、序列化：对象怎么在网络中传输

那么承接上一讲的一个重点，今天我会讲解下 RPC 框架中的序列化。要知道，在不同的场景下合理地选择序列化方式，对提升 RPC 框架整体的稳定性和性能是至关重要的

3.1、为什么需要序列化？

网络传输的数据必须是二进制数据，但调用方请求的出入参数都是对象。对象是不能直接在网络中传输的，所以我们需要提前把它转成可传输的二进制

总结来说，序列化就是将对象转换成二进制数据的过程，而反序列就是反过来将二进制转换为对象的过程。

那么 RPC 框架为什么需要序列化呢？还是请你回想下 RPC 的通信流程：

不妨借用个例子帮助你理解，比如发快递，我们要发一个需要自行组装的物件。发件人发之前，会把物件拆开装箱，这就好比序列化；这时候快递员来了，不能磕碰呀，那就要打包，这就好比将序列化后的数据进行编码，封装成一个固定格式的协议；过了两天，收件人收到包裹了，就会拆箱将物件拼接好，这就好比是协议解码和反序列化。

所以现在你清楚了吗？因为网络传输的数据必须是二进制数据，所以在 RPC 调用中，对入参对象与返回值对象进行序列化与反序列化是一个必须的过程。

3.2、有哪些常用的序列化

1)、JDK原生序列化

JDK 自带的序列化机制对使用者而言是非常简单的。序列化具体的实现是由 ObjectOutputStream 完成的，而反序列化的具体实现是由 ObjectInputStream 完成的。

那么 JDK 的序列化过程是怎样完成的呢？我们看下下面这张图：

序列化过程就是在读取对象数据的时候，不断加入一些特殊分隔符，这些特殊分隔符用于在反序列化过程中截断用。

头部数据用来声明序列化协议、序列化版本，用于高低版本向后兼容
对象数据主要包括类名、签名、属性名、属性类型及属性值，当然还有开头结尾等数据，除了属性值属于真正的对象值，其他都是为了反序列化用的元数据
存在对象引用、继承的情况下，就是递归遍历“写对象”逻辑

2)、JSON

一种文本型序列化框架。无论是前台 Web 用 Ajax 调用、用磁盘存储文本类型的数据，还是基于 HTTP 协议的 RPC 框架通信，都会选择 JSON 格式。

但用 JSON 进行序列化有这样两个问题，你需要格外注意：

JSON 进行序列化的额外空间开销比较大，对于大数据量服务这意味着需要巨大的内存和磁盘开销；
JSON 没有类型，但像 Java 这种强类型语言，需要通过反射统一解决，所以性能不会太好。

所以如果 RPC 框架选用 JSON 序列化，服务提供者与服务调用者之间传输的数据量要相对较小，否则将严重影响性能。

3)、Hessian

Hessian 是动态类型、二进制、紧凑的，并且可跨语言移植的一种序列化框架。Hessian 协议要比 JDK、JSON 更加紧凑，性能上要比 JDK、JSON 序列化高效很多，而且生成的字节数也更小。

Student student = new Student();
student.setNo(101);
student.setName("HESSIAN");

//把student对象转化为byte数组
ByteArrayOutputStream bos = new ByteArrayOutputStream();
Hessian2Output output = new Hessian2Output(bos);
output.writeObject(student);
output.flushBuffer();
byte[] data = bos.toByteArray();
bos.close();

//把刚才序列化出来的byte数组转化为student对象
ByteArrayInputStream bis = new ByteArrayInputStream(data);
Hessian2Input input = new Hessian2Input(bis);
Student deStudent = (Student) input.readObject();
input.close();

System.out.println(deStudent);

相对于 JDK、JSON，由于 Hessian 更加高效，生成的字节数更小，有非常好的兼容性和稳定性，所以 Hessian 更加适合作为 RPC 框架远程通信的序列化协议。

但 Hessian 本身也有问题，官方版本对 Java 里面一些常见对象的类型不支持，比如：

Linked 系列，LinkedHashMap、LinkedHashSet 等，但是可以通过扩展 CollectionDeserializer 类修复；
Locale 类，可以通过扩展 ContextSerializerFactory 类修复；
Byte/Short 反序列化的时候变成 Integer。以上这些情况，你在实践时需要格外注意。

4)、Protobuf

Protobuf 是 Google 公司内部的混合语言数据标准，是一种轻便、高效的结构化数据存储格式，可以用于结构化数据序列化，支持 Java、Python、C++、Go 等语言。Protobuf 使用的时候需要定义 IDL（Interface description language），然后使用不同语言的 IDL 编译器，生成序列化工具类，它的优点是：

序列化后体积相比 JSON、Hessian 小很多；
IDL 能清晰地描述语义，所以足以帮助并保证应用程序之间的类型不会丢失，无需类似 XML 解析器；
序列化反序列化速度很快，不需要通过反射获取类型；
消息格式升级和兼容性不错，可以做到向后兼容


/**
 *
 * // IDl 文件格式
 * synax = "proto3";
 * option java_package = "com.test";
 * option java_outer_classname = "StudentProtobuf";
 *
 * message StudentMsg {
 * //序号
 * int32 no = 1;
 * //姓名
 * string name = 2;
 * }
 * 
 */
 
StudentProtobuf.StudentMsg.Builder builder = StudentProtobuf.StudentMsg.newBuilder();
builder.setNo(103);
builder.setName("protobuf");

//把student对象转化为byte数组
StudentProtobuf.StudentMsg msg = builder.build();
byte[] data = msg.toByteArray();

//把刚才序列化出来的byte数组转化为student对象
StudentProtobuf.StudentMsg deStudent = StudentProtobuf.StudentMsg.parseFrom(data);

System.out.println(deStudent);

Protobuf 非常高效，但是对于具有反射和动态能力的语言来说，这样用起来很费劲，这一点就不如 Hessian，比如用 Java 的话，这个预编译过程不是必须的，可以考虑使用 Protostuff。

Protostuff 不需要依赖 IDL 文件，可以直接对 Java 领域对象进行反 / 序列化操作，在效率上跟 Protobuf 差不多，生成的二进制格式和 Protobuf 是完全相同的，可以说是一个 Java 版本的 Protobuf 序列化框架。但在使用过程中，我遇到过一些不支持的情况，也同步给你：

不支持 null；
ProtoStuff 不支持单纯的 Map、List 集合对象，需要包在对象里面。

3.3、RPC框架中如何选择序列化

我刚刚简单地介绍了几种最常见的序列化协议，其实远不止这几种，还有 Message pack、kryo 等。那么面对这么多的序列化协议，在 RPC 框架中我们该如何选择呢？

性能和效率
空间开销
序列化协议的通用性和兼容性（版本升级后的兼容性是否很好，是否支持更多的对象类型，是否是跨平台、跨语言的）
安全性（序列化存在安全漏洞，那么线上的服务就很可能被入侵）
易于调试

我们首选的还是 Hessian 与 Protobuf，因为他们在性能、时间开销、空间开销、通用性、兼容性和安全性上，都满足了我们的要求。其中 Hessian 在使用上更加方便，在对象的兼容性上更好；Protobuf 则更加高效，通用性上更有优势。

3.4、RPC框架在使用时要注意哪些问题？

对象构造得过于复杂：属性很多，并且存在多层的嵌套

对象过于庞大：我经常遇到业务过来咨询，为啥他们的 RPC 请求经常超时，排查后发现他们的入参对象非常得大

用序列化框架不支持的类作为入参类：比如 Hessian 框架，他天然是不支持 LinkHashMap、LinkedHashSet 等，而且大多数情况下最好不要使用第三方集合类，Guava 中的集合类，很多开源的序列化框架都是优先支持编程语言原生的对象。因此如果入参是集合类，应尽量选用原生的、最为常用的集合类，如 HashMap、ArrayList

对象有复杂的继承关系：大多数序列化框架在序列化对象时都会将对象的属性一一进行序列化，当有继承关系时，会不停地寻找父类，遍历属性

3.5、总结

在使用 RPC 框架的过程中，我们构造入参、返回值对象，主要记住以下几点：

对象要尽量简单，没有太多的依赖关系，属性不要太多，尽量高内聚；
入参对象与返回值对象体积不要太大，更不要传太大的集合；
尽量使用简单的、常用的、开发语言原生的对象，尤其是集合类；
对象不要有复杂的继承关系，最好不要有父子类的情况。

arthas手册

发表于 2020-01-13 | 分类于 java ， jvm ， arthas

官方文档：https://alibaba.github.io/arthas/

下载安装

https://alibaba.github.io/arthas/manual-install.html

下载

https://maven.aliyun.com/repository/public/com/taobao/arthas/arthas-packaging/3.x.x/arthas-packaging-3.x.x-bin.zip

解压

启动

1	java -jar arthas-boot.jar

查看dashboard

[arthas@14628]$ dashboard

查看线程

[arthas@14628]$ thread

// 拿到最忙的3个线程

[arthas@14628]$ thread -n 3

dump内存数据

[arthas@14628]$ heapdump d:/data/dump.hprof

jhat分析dump文件

jhat d:/data/dump.hprof

生成一个web，通过浏览器访问

MAT分析dump文件

如何向rocketmq提交pr

发表于 2020-01-13 | 分类于 github

1、fork仓库到自己账号下

官方仓库：https://github.com/apache/rocketmq

2、clone代码到本地

$ cd /d/github
# 测试是否可以连接
$ ssh -T git@github.com
$ cd ~/.ssh
$ ssh-keygen -t rsa

将公钥添加到 github

github -> Settings -> SSH and GPG keys -> New SSH key

再测试一下

1 2	$ ssh -T git@github.com Hi carlo-z! You've successfully authenticated, but GitHub does not provide shell access.

clone 代码

1	$ git clone git@github.com:carlo-z/rocketmq.git

查看仓库状态，提示现在是 master 分支

$ cd rocketmq/

$ git status
On branch master
Your branch is up to date with 'origin/master'

用git remote -v命令，可以看到此时只与自己的远程仓库建立了连接

1
2
3

$ git remote -v
origin  git@github.com:carlo-z/rocketmq.git (fetch)
origin  git@github.com:carlo-z/rocketmq.git (push)

3、与官方仓库建立连接

$ git remote add upstream https://github.com/apache/rocketmq.git


$ git remote -v
origin  git@github.com:carlo-z/rocketmq.git (fetch)
origin  git@github.com:carlo-z/rocketmq.git (push)
upstream        https://github.com/apache/rocketmq.git (fetch)
upstream        https://github.com/apache/rocketmq.git (push)

再用git remote -v可以看到已经与官方仓库建立了连接

4、创建新分支用于修改

接着上面的运行命令：git checkout -b rocketmq-read，这个命令的意思是创建一个叫 rocketmq-read 的分支，运行这个命令后bash将自动切换到新的分支下

1 2	$ git checkout -b rocketmq-read Switched to a new branch 'rocketmq-read'

修改代码

提交

5、提交pr

然后点Create pull request

写好名字，写好说明，提交，就OK啦。

6、后期同步代码

所以每次提交pr前，都要先从做代码同步。过程如下：

先fetch

1	$ git fetch upstream

再 rebase

1	$ git rebase upstream/master

再 push master

1	$ git push origin master

push完后，远程仓库便可看到你的branch版本和master分支一致了，否则这个位置会显示与master相差了多少次commit。

Service Mesh 初体验

发表于 2020-01-02 | 分类于 service-mesh

来源：https://developer.aliyun.com/article/723524

前言

计算机软件技术发展到现在，软件架构的演进无不朝着让开发者能够更加轻松快捷地构建大型复杂应用的方向发展。容器技术最初是为了解决运行环境的不一致问题而产生的，随着不断地发展，围绕容器技术衍生出来越来越多的新方向。

最近几年，云计算领域不断地出现很多新的软件架构模式，其中有一些很热门的概念名词如：云原生、函数计算、Serverless、ServiceMesh等等，而本文将初窥一下ServiceMesh的面纱。下面结合自己的理解尽量以通俗的话进行叙述。

背景和定义

微服务及服务治理

在微服务之前的软件开发中，往往通过一个应用的方式将所有的模块都包括进去，并一起编译、打包、部署、运维。这种方式存在很多问题，由于单个应用包含的东西太多，其中某个模块出现问题或者需要更新那么整个应用就需要重新部署。这种方式给开发和运维带来了很大的麻烦。随着应用的逐渐复杂，单个应用涉及的东西就会越来越多，慢慢地大家发现了其中很多的缺点，开始对服务进行划分，将一个大的应用按照不同的维度进行划分从而产生很多个小的应用，各应用之间会形成一个调用关系，每个小的应用由不同的开发负责，大家各自部署和运维，这样微服务就出现了。

由于微服务中各应用部署在不同的机器上，服务之间需要进行通信和协调，相比单个应用来说会麻烦很多。在同一个应用内不同方法之间的调用由于在相同的内存中，在代码编译打包时已经进行了链接，因此调用是可寻址且快速的。微服务下不同服务之间的调用涉及到不同进程或者机器之间的通信，一般需要通过第三方中间件的方式作为中介和协调，由于种种这些，面向微服务出现了很多中间件包括服务治理的框架。通过服务治理工具可以管理其接入的所有应用，使得服务之间的通信和协调更加简单高效。

容器及容器编排

最初容器技术是为了解决应用运行环境不一致的问题而出现的，避免在本地环境或者测试环境能够跑通，等发到生产环境却出现问题。通过容器将程序及其依赖一起打包到镜像中去，将程序的镜像在任何安装并运行了容器软件的机器上启动若干的容器，每个容器就是应用运行时的实例，这些实例一般拥有完全相同的运行环境和参数。使得不管在任何机器上应用都可以表现出一样的效果。这给开发、测试、运维带来了极大的便利，不再需要为不同机器上构建相同的运行环境而头大。且镜像可以Push到镜像仓库，这使得应用可以进行很方便的迁移和部署。Docker就是一个应用广泛的容器技术。目前越来越多的应用以微服务的方式并通过容器进行部署，给了软件开发极大的活力。

与微服务和服务治理的关系类似，越来越多的应用通过容器进行部署，使得集群上的容器数量急剧增加，通过人工的管理和运维这些容器已经变得很艰难且低效，为了解决诸多容器及容器之间的关系出现了很多编排工具，容器编排工具能够管理容器的整个生命周期。如Docker官方出的docker-compose和docker swarm，这两个工具能实现批量容器的启动和编排，但功能较为简单，不足以支撑大型的容器集群。Google基于内部大量的容器管理经验，开源出了Kubernetes项目，Kubernetes（K8S）是针对Google集群上每周亿级别的容器而设计的，具有很强大的容器编排能力和丰富的功能。K8S通过定义了很多资源，这些资源以声明式的方式进行创建，可以通过JSON或者YAML文件表示一个资源，K8S支持多种容器，但主流的是Docker容器，K8S提供了容器接入的相关标准，只要容器实现了该标准就可以被K8S所编排。由于K8S的功能较多，不在此一一叙述，有兴趣可以参考官方文档或者ATA上搜索相关文章。

当某个公司的应用已经完全微服务化后，选择以容器的方式部署应用，此时可以在集群上部署K8S，通过K8S提供的能力进行应用容器的管理，运维可以也可以面向K8S进行工作。由于K8S是目前使用最广泛的容器编排工具，因此成为了容器编排的一个标准了，目前集团内部也有自己的容器和容器编排工具。

面向以K8S为代表的容器管理方式衍生出了一些新的技术。

云原生

最近两年云原生被炒的很火，可以在各处看到很多大佬对云原生的高谈阔论，下面直接抛出CNCF对云原生的定义：

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。
这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

在我看来，通过微服务的方式开发应用，以容器进行部署，使用K8S等容器编排工具进行容器集群的管理，使得开发运维都面向K8S，这就是云原生。云原生可以方便的构建应用，并对应用进行完整的监控，以及在应用针对不同流量时能进行快速的扩容和缩容。如下图：

云原生主要包括四个部分:

微服务
容器
持续集成和交付
DevOps

PS：总是觉得云原生这个叫法太抽象了，很难让人通过名字想到这是个啥东西。

ServiceMesh的定义

前面讲了微服务、容器、容器编排、云原生等，其实就是为了得出什么是ServiceMesh，自己总结了一下：SeviceMesh是云原生下的微服务治理方案。

当我们通过微服务的方式将应用以容器的形式部署在K8S上后，服务之间调用和治理其实有新的方案，可以不需要依赖传统的微服务治理框架。ServiceMesh通过对每个应用在其Pod中启动一个Sidecar（边车）实现对应用的透明代理，所有出入应用的流量都先经过该应用的Sidecar，服务之间的调用转变成了Sidecar之间的调用，服务的治理转变成了对Sidecar的治理。在ServiceMesh中Sidecar是透明的，开发无感知的，之前一直觉得奇怪，总觉得一个应用要让别人发现它从而调用它，总得引入一些库然后进行主动的服务注册，不然啥都不做，别人咋知道这个应用的存在，为什么在ServiceMesh中就可以省去这些，做到对开发者完全地透明呢？这个的实现依赖于容器编排工具，通过K8S进行应用的持续集成和交付时，在启动应用Pod后，其实已经通过Yaml文件的形式向K8S注册了自己的服务以及声明了服务之间的关系，ServiceMesh通过和K8S进行通信获取集群上所有的服务信息，通过K8S这个中间者实现了对开发者的透明。如下图所示，是ServiceMesh的一个基本结构，包括数据平面和控制平面。

这种方式存在很多好处，我们可以发现在这种模式下应用的语言其实不会对整个服务治理过程有什么影响，对于ServiceMesh来说，它只关心Pod或者说是Pod中的容器实例，并不需要在乎容器中应用的实现语言是啥，Sidecar和其负责的容器在同一个Pod中。这样ServiceMesh就可以实现跨语言，这也是目前很多传统的服务治理框架的一大缺点，而且采用传统的服务治理，需要对应用引入大量的依赖，这样就会造成依赖之间的各种冲突，集团通过Pandora对应用的各种依赖进行隔离。再者传统的服务治理门槛较高，需要开发者对整个架构有一定的了解，且发现问题排查较为麻烦。这也造成了开发和运维之间的界限不清，在ServiceMesh中开发只需要交付代码，运维可以基于K8S去维护整个容器集群。

发展现状

通过目前查阅的资料来看，ServiceMesh一词最早出现在2016年，最近两年被炒的很火，蚂蚁金服已经有了自己的一套完整的ServiceMesh服务框架–SofaMesh，集团很多团队也在进行相应的跟进。

从历史发展的路线来看，程序的开发方式经历了很多的变化，但总的方向是变得越来越简单了，现在我们在集团内进行开发，可以很简单的构建一个支撑较大QPS的服务，这得益于集团的整个技术体系的完整和丰富以及强大的技术积淀。

我们下面来看看应用开发到底经历了啥？

发展历史

主机直接阶段

如上图，这一阶段应该是最古老的阶段，两台机器通过网线直接连接，一个应用包含了你能想到的所有的功能，包括两台机器的连接管理，这时还没有网络的概念，毕竟只能和通过网线直接连接在一起的机器进行通信。

网络层的出现

如上图，随着技术的发展，网络层出现了，机器可以和通过网络连接的其他所有机器进行通信，不再限制于必须要网线直连两台机器。

集成到应用程序内部的流量控制

如上图，由于每个应用所在环境和机器配置不一样，接受流量的能力也不相同，当A应用发送的流量大于了B应用的接受能力时，那么无法接收的数据包必定会被丢弃，这时就需要对流量进行控制，最开始流量的控制需要应用自己去实现，网络层只负责接收应用下发的数据包并进行传输。

流量控制转移到网络层

如上图，慢慢地大家发应用中的网络流量控制是可以转移到网络层的，所以网络层中的流量控制出现了，我想大概就是指TCP的流量控制吧，这样还能保证可靠的网络通信。

应用程序的中集成服务发现和断路器

如上图，开发者通过在自己的代码模块中实现服务发现和断路器。

专门用于服务发现和断路器的软件包/库

如上图，开发者通过引用第三方依赖去实现服务发现和断路器。

出现了专门用于服务发现和断路器的开源软件

如上图，基于各种中间件去实现服务发现和断路器。

ServiceMesh出现

最终到了现在，ServiceMesh大法诞生，进一步解放了生产力，提高了软件整个生命周期的效率。

ServiceMesh市场竞争

虽然直到2017年底，ServiceMesh才开始较大规模被世人了解，这场微服务市场之争也才显现，但是其实ServiceMesh这股微服务的新势力，早在 2016年初就开始萌芽：

2016年1月，离开Twitter的基础设施工程师William Morgan和Oliver Gould，在github上发布了Linkerd 0.0.7版本，业界第一个ServiceMesh项目就此诞生。Linkerd基于Twitter的Finagle开源项目，大量重用了Finagle的类库，但是实现了通用性，成为了业界第一个ServiceMesh项目。而Envoy是第二个ServiceMesh项目，两者的开发时间差不多，在2017年都相继成为CNCF项目。2017年5月24日，Istio 0.1 release版本发布，Google和IBM高调宣讲，社区反响热烈，很多公司在这时就纷纷站队表示支持Istio。Linkerd的风光瞬间被盖过，从意气风发的少年一夜之间变成过气网红。当然，从产品成熟度上来说，linkerd作为业界仅有的两个生产级ServiceMesh实现之一，暂时还可以在Istio成熟前继续保持市场。但是，随着Istio的稳步推进和日益成熟，外加第二代ServiceMesh的天然优势，Istio取代第一代的Linkerd只是个时间问题。自从在2016年决定委身于Istio之后，Envoy就开始了一条波澜不惊的平稳发展之路，和Linkerd的跌宕起伏完全不同。在功能方面，由于定位在数据平面，因此Envoy无需考虑太多，很多工作在Istio的控制平面完成就好，Envoy从此专心于将数据平面做好，完善各种细节。在市场方面，Envoy和Linkerd性质不同，不存在生存和发展的战略选择，也没有正面对抗生死大敌的巨大压力。

从Google和IBM联手决定推出Istio开始，Istio就注定永远处于风头浪尖，无论成败，Istio面世之后，赞誉不断，尤其是ServiceMesh技术的爱好者，可以说是为之一振：以新一代ServiceMesh之名横空出世的Istio，对比Linkerd，优势明显。同时产品路线图上有一大堆令人眼花缭乱的功能。假以时日，如果Istio能顺利地完成开发，稳定可靠，那么这会是一个非常美好、值得憧憬的大事件，

Istio介绍

Istio是目前最热的ServiceMesh开源项目，Istio主要分为两个部分：数据平面和控制平面。Istio实现了云原生下的微服务治理，能实现服务发现，流量控制，监控安全等。Istio通过在一个Pod里启动一个应用和Sidecar方式实现透明代理。Istio是一个拓展性较高的框架，其不仅可以支持K8S，还可以支持其他如Mesos等资源调度器。如下图所示，为Istio的整体架构：

逻辑上分为数据平面（上图中的上半部分）和控制平面（上图中的下半部分）。
数据平面由一组以 Sidecar 方式部署的智能代理（Envoy）组成。这些代理可以调节和控制微服务及 Mixer 之间所有的网络通信。
控制平面负责管理和配置代理来路由流量。此外控制平面配置 Mixer 以实施策略和收集遥测数据。
Pilot是整个架构中的抽象层，将对接K8S等资源调度器的步骤进行抽象并以适配器的形式展现，并和用户以及Sidecar交互。
Galley负责资源配置为验证。
Citadel用于生成身份，及密钥和证书管理
核心功能包括流量控制、安全控制、可观测性、多平台支持、可定制化。

Mixer

Mixer同样是一个可拓展的模块，其负责遥感数据的采集以及集成了一些后端服务（BAAS），Sidecar会不断向Mixer报告自己的流量情况，Mixer对流量情况进行汇总，以可视化的形式展现，此外Sidecar可以调用Mixer提供的一些后端服务能力，例如鉴权、登录、日志等等，Mixer通过适配器的方式对接各种后端服务。

In-process Adapter形式

之前版本的Isito采用这种将后端服务适配器集成在Mixer内部的形式，这种方式会有一个问题，就是某个后端服务适配器出现问题即会影响整个Mixer模块，但由于适配器和Mixer集成在一起，在同一个进程内，方法的调用会很快。

Out-of-process Adapter形式

目前版本的Istio将Adapter移到Mixer外部，这样可以实现Mixer与Adapter的解耦，当Adapter出现问题并不会影响Mixer，但这种方式同样也存在问题，即Adapter在Mixer外，是两个不同的进程，二者之间的调用是通过RPC的方式，这种方式比同进程内部的方法调用会慢很多，因此性能会受到影响。

Pilot

Envoy API负责和Envoy的通讯, 主要是发送服务发现信息和流量控制规则给Envoy。
Abstract Model 是 Pilot 定义的服务的抽象模型, 以从特定平台细节中解耦, 为跨平台提供基础。
Platform Adapter则是这个抽象模型的实现版本, 用于对接外部的不同平台如k8s/mesos等。
Rules API提供接口给外部调用以管理 Pilot, 包括命令行工具Istioctl以及未来可能出现的第三方管理界面。

Galley

Galley 原来仅负责进行配置验证, 1.1 后升级为整个控制面的配置管理中心, 除了继续提供配置验证功能外, Galley还负责配置的管理和分发, Galley 使用网格配置协议(Mesh Configuration Protocol) 和其他组件进行配置的交互.

Istio 创造了50多个CRD, 其复杂度可见一斑, 所以有人说面向k8s编程近似于面向yaml编程.早期的Galley 仅仅负责对配置进行运行时验证, Istio 控制面各个组件各自去list/watch 各自关注的配置。越来越多且复杂的配置给Istio用户带来了诸多不便, 主要体现在:

配置的缺乏统一管理, 组件各自订阅, 缺乏统一回滚机制, 配置问题难以定位。
配置可复用度低, 比如在1.1之前, 每个Mixer adpater 就需要定义个新的CRD。
配置的隔离, ACL 控制, 一致性, 抽象程度, 序列化等等问题都还不太令人满意

随着Istio功能的演进, 可预见的Istio CRD数量还会继续增加, 社区计划将Galley 强化为Istio配置控制层, Galley 除了继续提供配置验证功能外, 还将提供配置管理流水线, 包括输入, 转换, 分发, 以及适合Istio控制面的配置分发协议(MCP)。

Citadel

将服务拆分为微服务之后，在带来各种好处的同时，在安全方面也带来了比单体时代更多的需求，毕竟不同功能模块之间的调用方式从原来单体架构中的方法调用变成了微服务之间的远程调用：

加密：为了不泄露信息，为了抵御中间人攻击，需要对服务间通讯进行加密。
访问控制：不是每个服务都容许被任意访问，因此需要提供灵活的访问控制，如双向 TLS 和细粒度的访问策略。
审计：如果需要审核系统中哪些用户做了什么，则需要提供审计功能。

Citadel 是 Istio 中负责安全性的组件，但是 Citadel 需要和其他多个组件配合才能完成工作：

Citadel：用于密钥管理和证书管理，下发到Envoy等负责通讯转发的组件。
Envoy：使用从Citadel下发而来的密钥和证书，实现服务间通讯的安全，注意在应用和Envoy之间是走Localhost，通常不用加密。
Pilot：将授权策略和安全命名信息分发给Envoy。
Mixer：负责管理授权，完成审计等。

Istio支持的安全类功能有：

流量加密：加密服务间的通讯流量。
身份认证：通过内置身份和凭证管理可以提供强大的服务间和最终用户身份验证，包括传输身份认证和来源身份认证，支持双向TLS。
授权和鉴权：提供基于角色的访问控制（RBAC），提供命名空间级别，服务级别和方法级别的访问控制。

作者信息：彭家浩，花名毅忻，阿里巴巴淘系技术部开发工程师，热爱云计算。

sonarqube-8.3 安装

发表于 2019-12-25 | 分类于 devops

版本要求

https://docs.sonarqube.org/latest/requirements/requirements/

安装PostgreSQL

docker pull postgres
docker run --name postgres -e POSTGRES_USER=sonar -e POSTGRES_PASSWORD=sonar -p 5432:5432 -d postgres
firewall-cmd --permanent --add-port=5432/tcp
firewall-cmd --reload
firewall-cmd --list-all
docker exec -it postgres /bin/bash

修改host

vi /etc/hosts
10.1.171.41  dev.mypostgres.com

C:\Windows\System32\drivers\etc\
hosts
10.1.171.41  dev.mypostgres.com

通过Navicat for Postgres连接

dev.mypostgres.com

5432

sonar/sonar

安装jdk11

$ vi /etc/profile
export JAVA_HOME=/data/components/jdk-11.0.7
export PATH=$JAVA_HOME/bin:$PATH
export CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar

$ source /etc/profile
$ java -version
java version "11.0.7" 2020-04-14 LTS
Java(TM) SE Runtime Environment 18.9 (build 11.0.7+8-LTS)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.7+8-LTS, mixed mode)

SonarQube安装配置

使用zip安装

下载zip文件（http://www.sonarqube.org/downloads/）

1
2
3

unzip sonarqube-8.3.1.34397.zip
ln -s /data/sonarqube-8.3.1.34397 /data/sonarqube
cd /data/sonarqube

设置DB

在pg中建立数据库

create database sonar;
create user sonar;
atler user sonar with password 'sonar';
alter role sonar createdb;alter role sonar superuser;alter role sonar createrole;
alter database sonar owner to sonar

vi /data/sonarqube/conf/sonar.properties

# DATABASE
sonar.jdbc.username=sonar
sonar.jdbc.password=sonar
sonar.jdbc.url=jdbc:postgresql://dev.mypostgres.com:5432/sonar

sonar.jdbc.maxActive=60
sonar.jdbc.maxIdle=5
sonar.jdbc.minIdle=2
sonar.jdbc.maxWait=5000
sonar.jdbc.minEvictableIdleTimeMillis=600000
sonar.jdbc.timeBetweenEvictionRunsMillis=30000

# sonar.sorceEncoding=UTF-8

添加JDBC驱动程序

已经提供了支持的数据库（Oracle除外）的驱动程序。不要更换提供的驱动程序；他们是唯一受支持的。

/data/sonarqube/lib/jdbc
(base) [root@dev-10-1-171-41 jdbc]# ll
total 12
drwxr-xr-x 2 root root 4096 May  7 13:41 h2
drwxr-xr-x 2 root root 4096 May  7 13:41 mssql
drwxr-xr-x 2 root root 4096 May  7 13:41 postgresql

oracle 数据库需要单独添加驱动，其他数据库已经默认提供

/data/sonarqube/extensions/jdbc-driver
(base) [root@dev-10-1-171-41 jdbc-driver]# ll
total 4
drwxr-xr-x 2 root root 4096 May  7 13:22 oracle

配置Elasticsearch存储路径

默认情况下，Elasticsearch数据存储在$ SONARQUBE-HOME / data中，但不建议将其用于生产实例。相反，您应该将此数据存储在其他位置，最好是在具有快速I / O的专用卷中。除了保持可接受的性能外，这样做还可以简化SonarQube的升级。

1
2
3

vi /data/sonarqube/conf/sonar.properties
#sonar.path.data=/var/sonarqube/data
#sonar.path.temp=/var/sonarqube/temp

特别配置jdk路径

1 2	vi /data/sonarqube/conf/wrapper.conf wrapper.java.command=/data/components/jdk-11.0.7/bin/java

linux系统参数优化

vi /etc/sysctl.d/99-sonarqube.conf（或/etc/sysctl.conf文件）
vm.max_map_count=262144
fs.file-max=65536

sysctl -w vm.max_map_count=262144
sysctl -w fs.file-max=65536
ulimit -n 65536

sysctl vm.max_map_count 
sysctl fs.file-max 
ulimit -n

启动Web服务器

vi /data/sonarqube/conf/sonar.properties
sonar.web.host=0.0.0.0
sonar.web.port=9011
sonar.web.context=

firewall-cmd --permanent --add-port=9011/tcp
firewall-cmd --reload
firewall-cmd --list-all

sonar不能使用root启动

1
2
3

useradd sonar
passwd sonar
chown -R sonar:sonar /data/sonarqube/

su - sonar
/data/sonarqube/bin/linux-x86-64/sonar.sh start
/data/sonarqube/bin/linux-x86-64/sonar.sh restart

jps -l

设置域名

vi /etc/hosts
10.1.171.41  dev.mysonar.com
echo '10.1.171.41  dev.mysonar.com' >> /etc/hosts

C:\Windows\System32\drivers\etc\
hosts
10.1.171.41  dev.mysonar.com

访问：

http://dev.mysonar.com:9011/

默认账号：admin/admin

安装中文插件

install -> restart

使用systemd管理启动

SonarScanner安装配置

文档：https://docs.sonarqube.org/latest/analysis/scan/sonarscanner/

下载zip包安装

1
2
3

$ unzip sonar-scanner-cli-4.3.0.2102-linux.zip
$ ln -s /data/downloads/sonar-scanner-4.3.0.2102-linux /data/sonar-scanner
$ ln -s /data/sonar-scanner/bin/sonar-scanner /usr/bin/sonar-scanner

配置

1
2
3

$ vi /data/sonar-scanner/conf/sonar-scanner.properties
sonar.host.url=http://dev.mysonar.com:9011
sonar.sourceEncoding=UTF-8

扫描maven工程示例

$ cd /data/components/leancloud-proxy
$ vi sonar-project.properties
sonar.projectKey=leancloud-proxy
sonar.projectName=leancloud-proxy
sonar.projectVersion=1.0
sonar.sources=./
sonar.language=java
sonar.sources=src
sonar.java.binaries=target
sonar.sourceEncoding=UTF-8
sonar.dynamicAnalysis=false
sonar.scm.disabled=true
sonar.scm.provider=svn
sonar.host.url=http://dev.mysonar.com:9011

执行扫描

1	$ sonar-scanner

http://dev.mysonar.com:9011/projects

扫描php工程示例

$ cd /data/public_html
$ vi sonar-project.properties
sonar.projectKey=php-trunk
sonar.projectName=php-trunk
sonar.projectVersion=1.0
sonar.sources=./
sonar.language=php
sonar.sourceEncoding=UTF-8
sonar.dynamicAnalysis=false
sonar.scm.disabled=true
sonar.scm.provider=svn
sonar.host.url=http://dev.mysonar.com:9011

1	$ sonar-scanner

http://dev.mysonar.com:9011/projects

jenkins + SonarScanner

安装SonarQube Scanner插件

Jenkins → 系统管理 → 管理插件 → 可选插件 → 🔍SonarQueue Scanner

安装以后重启

配置SonarQube

首先，在SonarQube中生成一个Token（PS：用token代替输入用户名和密码）

1	bb6ad69138f3607af1082565551846a5b23eb310

然后，在Jenkins中配置连接sonarqube服务器的地址，这里用到的token就是刚才在sonarqube中创建的那个token

系统设置

最后，配置全局工具配置

创建任务

sonar.projectKey=php-trunk
sonar.projectName=php-trunk
sonar.projectVersion=1.0
sonar.sources=$WORKSPACE
sonar.language=php
sonar.sourceEncoding=UTF-8
sonar.dynamicAnalysis=false
sonar.scm.disabled=true
sonar.scm.provider=svn
sonar.host.url=http://dev.mysonar.com:9011

开始构建任务

centos7 下 rocketmq 单机版安装

发表于 2019-12-01 | 分类于 rocketmq

文档：http://rocketmq.apache.org/docs/quick-start/

先决条件

假定已安装以下软件：

建议使用64位操作系统，建议使用Linux / Unix / Mac；
64位JDK 1.8+;
Maven 3.2.x;
Git;
适用于Broker服务器的4g +可用磁盘

下载安装

[root@centos7cz ~]# cd /data/download/
[root@centos7cz download]# wget http://mirror.bit.edu.cn/apache/rocketmq/4.6.0/rocketmq-all-4.6.0-bin-release.zip
[root@centos7cz download]# mkdir -p /data/tools/
[root@centos7cz download]# unzip rocketmq-all-4.6.0-bin-release.zip -d /data/tools
[root@centos7cz download]# tar -zxf rocketmq-all-4.6.0.tar.gz  -C /data/tools
[root@centos7cz download]# cd /data/tools/
[root@centos7cz tools]# mv rocketmq-all-4.6.0-bin-release/ rocketmq-all-4.6.0
[root@centos7cz tools]# cd rocketmq-all-4.6.0/
[root@centos7cz rocketmq-all-4.6.0]# ll
total 40
drwxr-xr-x. 2 root root    83 Nov 20 11:04 benchmark
drwxr-xr-x. 3 root root  4096 Aug 19 15:31 bin
drwxr-xr-x. 6 root root   211 Aug  6 16:23 conf
drwxr-xr-x. 2 root root  4096 Nov 20 11:04 lib
-rw-r--r--. 1 root root 17336 Aug  6 16:23 LICENSE
-rw-r--r--. 1 root root  1338 Aug  6 16:23 NOTICE
-rw-r--r--. 1 root root  4225 Nov  1 16:54 README.md
[root@centos7cz rocketmq-all-4.6.0]#

启动和关闭

# 安装nohup
[root@centos7cz ~]# yum install coreutils -y

[root@centos7cz ~]# mkdir -p /data/tools/rocketmq-all-4.6.0/logs/

NameSrv

[root@centos7cz ~]# cd /data/tools/rocketmq-all-4.6.0

[root@centos7cz rocketmq-all-4.6.0]# nohup sh /data/tools/rocketmq-all-4.6.0/bin/mqnamesrv > /data/tools/rocketmq-all-4.6.0/logs/namesrv.log 2>&1 &

[root@centos7cz rocketmq-all-4.6.0]# tail -f /data/tools/rocketmq-all-4.6.0/logs/namesrv.log

[root@centos7cz rocketmq-all-4.6.0]# /data/tools/rocketmq-all-4.6.0/bin/mqshutdown namesrv

Broker

[root@centos7cz ~]# cd /data/tools/rocketmq-all-4.6.0

[root@centos7cz rocketmq-all-4.6.0]# nohup sh /data/tools/rocketmq-all-4.6.0/bin/mqbroker > /data/tools/rocketmq-all-4.6.0/logs/broker.log 2>&1 &

[root@centos7cz rocketmq-all-4.6.0]# tail -f /data/tools/rocketmq-all-4.6.0/logs/broker.log

[root@centos7cz rocketmq-all-4.6.0]# /data/tools/rocketmq-all-4.6.0/bin/mqshutdown broker

收发消息

[root@centos7cz ~]# cd /data/tools/rocketmq-all-4.6.0

[root@centos7cz rocketmq-all-4.6.0]# export NAMESRV_ADDR=localhost:9876

[root@centos7cz rocketmq-all-4.6.0]# sh bin/tools.sh org.apache.rocketmq.example.quickstart.Producer

[root@centos7cz rocketmq-all-4.6.0]# sh bin/tools.sh org.apache.rocketmq.example.quickstart.Consumer

TPC,TPCC,TPMC(数据库性能衡量指标)

发表于 2019-11-20 | 分类于 mysql

第一章什么是TPC和tpmC?

1 TPC

TPC(Transaction Processing Performance Council，事务处理性能委员会)是由数10家会员公司创建的非盈利组织，总部设在美国。该组织对全世界开放，但迄今为止，绝大多数会员都是美、日、西欧的大公司。TPC的成员主要是计算机软硬件厂家，而非计算机用户，它的功能是制定商务应用基准程序(Benchmark)的标准规范、性能和价格度量，并管理测试结果的发布。

TPC的出版物是开放的，可以通过网络获取(http://www.tpc.org)。TPC不给出基准程序的代码，而只给出基准程序的标准规范(Standard Specification)。任何厂家或其它测试者都可以根据规范，最优地构造出自己的系统(测试平台和测试程序)。为保证测试结果的客观性，被测试者(通常是厂家)必须提交给TPC一套完整的报告(Full Disclosure Report)，包括被测系统的详细配置、分类价格和包含五年维护费用在内的总价格。该报告必须由TPC授权的审核员核实(TPC本身并不做审计)。现在全球只有几个审核员，全部在美国。

TPC已经推出了四套基准程序，被称为TPC－A、TPC－B、TPC－C和TPC－D。其中A和B已经过时，不再使用了。TPC－C是在线事务处理(OLTP)的基准程序，TPC－D是决策支持(Decision Support) 的基准程序。TPC即将推TPC－E，作为大型企业(Enterprise)信息服务的基准程序。

2 tpmC

tpmC值在国内外被广泛用于衡量计算机系统的事务处理能力。但究竟什么是tpmC值呢?作者曾向一些用户、推销人员乃至某些国外大公司的技术人员问过这个问题，但回答的精确度与tpmC值的流行程度远非相称。tpmC这一度量也常被误写为TPM或TPMC。

TPC-C模拟一个批发商的货物管理环境。该批发公司有N个仓库，每个仓库供应10个地区，其中每个地区为3000名顾客服务。在每个仓库中有10个终端，每一个终端用于一个地区。在运行时，10×N个终端操作员向公司的数据库发出5类请求。由于一个仓库中不可能存储公司所有的货物，有一些请求必须发往其它仓库，因此，数据库在逻辑上是分布的。N是一个可变参数，测试者可以随意改变N，以获得最佳测试效果。

TPC-C使用三种性能和价格度量，其中性能由TPC-C吞吐率衡量，单位是tpmC。tpm是transactions per minute的简称；C指TPC中的C基准程序。它的定义是每分钟内系统处理的新订单个数。要注意的是，在处理新订单的同时，系统还要按表1的要求处理其它4类事务请求。从表1可以看出，新订单请求不可能超出全部事务请求的45％，因此，当一个系统的性能为1000tpmC时，它每分钟实际处理的请求数是2000多个。价格是指系统的总价格，单位是美元，而价格性能比则定义为总价格÷性能，单位是＄/tpmC。

tpmC定义: TPC-C的吞吐量，按有效TPC-C配置期间每分钟处理的平均交易次数测量，至少要运行12分钟。

（吞吐量测试结果以比特/秒或字节/秒表示。）

第二章 TPCC

1 基准测试

TPCC值被广泛用于衡量C/S环境下,由服务器和客户端构筑的整体系统的性能,它由事物处理性能委员会（TPC，Transaction Processing Corp）制定,TPC为非赢利性国际组织。

TPCC值可以反映出系统的性能价格比。TPCC测试系统每分钟处理的任务数,单位为tpm,(transactions per minute)。系统的总体价格(单位为美元)除以TPCC值,就可以衡量出系统的性价比,系统的性价比值越大,系统的性价比越好。

需要注意的是,TPC-C值描述的是C/S整体系统的性能,它与系统的服务器和客户机的性能都有关系,也就是说,同样的服务器配置不同的客户端将会影响TPCC值,任何厂商和测试者都可以根据TPC提供的测试规范构造出自己最优的系统,当然测试的结果要经过TPC审核。

2 性能测试指标介绍

TPC-C

作为一家非盈利性机构，事务处理性能委员会（TPC）负责定义诸如TPC-C、TPC-H和TPC-W基准测试之类的事务处理与数据库性能基准测试，并依据这些基准测试项目发布客观性能数据。TPC基准测试采用极为严格的运行环境，并且必须在独立审计机构监督下进行。委员会成员包括大多数主要数据库产品厂商以及服务器硬件系统供应商。

相关企业参与TPC基准测试以期在规定运行环境中获得客观性能验证，并通过应用测试过程中所使用的技术开发出更加强健且更具伸缩性的软件产品及硬件设备。

TPC-C是一种旨在衡量联机事务处理（OLTP）系统性能与可伸缩性的行业标准基准测试项目。这种基准测试项目将对包括查询、更新及队列式小批量事务在内的广泛数据库功能进行测试。许多IT专业人员将TPC-C视为衡量“真实”OLTP系统性能的有效指示器。

TPC-C基准测试针对一种模拟订单录入与销售环境测量每分钟商业事务（tpmC）吞吐量。特别值得一提的是，它将专门测量系统在同时执行其它四种事务类型（如支付、订单状态更新、交付及证券级变更）时每分钟所生成的新增订单事务数量。独立审计机构将负责对基准测试结果进行公证，同时，TPC将出据一份全面彻底的测试报告。这份测试报告可以从TPC Web站点(http://www.tpc.org)上获得。

3 TPC-C规范概要

TPC-C是专门针对联机交易处理系统（OLTP系统）的，一般情况下我们也把这类系统称为业务处理系统。

TPC-C测试规范中模拟了一个比较复杂并具有代表意义的OLTP应用环境:假设有一个大型商品批发商，它拥有若干个分布在不同区域的商品库；每个仓库负责为10个销售点供货；每个销售点为3000个客户提供服务；每个客户平均一个订单有10项产品;所有订单中约1%的产品在其直接所属的仓库中没有存货，需要由其他区域的仓库来供货。同时，每个仓库都要维护公司销售的100000种商品的库存记录。

该系统需要处理的交易为以下几种：

New-Order：客户输入一笔新的订货交易；

Payment:更新客户账户余额以反映其支付状况;

Delivery:发货(模拟批处理交易);

Order-Status:查询客户最近交易的状态；

Stock-Level:查询仓库库存状况，以便能够及时补货。

对于前四种类型的交易，要求响应时间在5秒以内；对于库存状况查询交易，要求响应时间在20秒以内。

4评测指标

TPC-C测试规范经过两年的研制，于1992年7月发布。几乎所有在OLTP市场提供软硬件平台的厂商都发布了相应的TPC-C测试结果，随着计算机技术的不断发展，这些测试结果也在不断刷新。

TPC-C的测试结果主要有两个指标：

①流量指标(Throughput，简称tpmC)

按照TPC的定义，流量指标描述了系统在执行Payment、Order-status、Delivery、Stock-Level这四种交易的同时，每分钟可以处理多少个New-Order交易。所有交易的响应时间必须满足TPC-C测试规范的要求。

流量指标值越大越好！

②性价比(Price/Performance，简称Price/tpmC)

即测试系统价格（指在美国的报价）与流量指标的比值。

性价比越大越好！

第三章（TPCC）如何衡量计算机系统的性能和价格

在系统选型时，我们一定不要忘记我们是为特定用户环境中的特定应用选择系统。切忌为了“与国际接轨”而盲目套用“国际通用”的东西。在性能评价领域，越是通用的度量常常越是不准确的。据我所知，美国的一些大用户从不相信任何“国际通用”的度量，而是花相当精力，比如预算的5％，使用自己的应用来测试系统，决定选型。在使用任何一种性能和价格度量时，一定要弄明白该度量的定义，以及它是在什么系统配置和运行环境下得到的，如何解释它的意义等。下面我们由好到差讨论三种方式。

1在真实环境中运行实际应用

最理想的方式是搞一个试点，要求制造商或系统集成商配合将系统(含平台、软件和操作流程)在一个实际用户点真正试运行一段时间。这样，用户不仅能看到实际性能，也能观察到系统是否稳定可靠、使用是否方便、服务是否周到、配置是否足够、全部价格是否合理。如果一个部门需要购买一批同类的系统，这种方式应列为首选，因为它不仅最精确、稳妥，也常常最有效率，用户还可先租一套系统作为试点。用这种方式得到的度量值常常具有很明确和实际的含义。

2使用用户定义的基准程序

如果由于某种原因第一种方式不可行，用户可以定义一组含有自己实际应用环境特征的应用基准程序。我举两个例子：近年来，由于R/3软件是应用层软件，SAP公司的基准程序获得了越来越多国外企业的认可；中国税务总局最近也开发了自己的基准程序，以帮助税务系统进行计算机选型。这种方式在中国尤其重要，因为中国的信息系统有其特殊性。

3使用通用基准程序

如果第1种和第2种方式都不行，则使用如TPC-C之类的通用基准程序，这是不得已的一种近似方法。因此，tpmC值只能用作参考。我们应当注意以下几点：

①实际应用是否与基准程序相符

绝大多数基准程序都是在美国制订的，而中国的企事业单位与美国的运作方式常常不一样(恐怕也不应该或不可能一样)。在使用TPC－C时，我们应该清楚地知道：我的应用是否符合批发商模式?事务请求是否与表1近似?对响应时间的要求是否满足表1?如果都不是，则tpmC值的参考价值就不太大了。

②TPC度量的解释

TPC基准程序是用来测系统而不是测主机的，厂家肯定要充分优化他们的被测系统。此处的“系统”包括主机、外设(如硬盘或RAID)、主机端操作系统、数据库软件、客户端计算机及其操作系统、数据库软件和网络连接等。在很多厂家的TPC测试系统中，主机的价格只是系统总价格的1/4或更小，而硬盘的价格有可能占到总价格的1/3以上，因为TPC－C要求被测系统必须保存180天的事务记录。如果同样的主机被用到用户的环境中，厂家报的tpmC值就意义不大，因为用户的实际系统与厂家原来用于TPC测试的系统大不一样。当同样的主机用在不同的系统中时，tpmC值可能有相当大的变化，现在很多用户还没有意识到这一点。

我举一个例子。假设用户希望购买一批同类系统，每一系统至少需要1GB的内存和50GB的硬盘。厂家A、B、C 各报了三个价格相当的系统，tpmC值分别为3000、2800、2600。用户是否应该选厂家A的产品呢?答案是：不一定。厂家用于测试tpmC值的系统与实际提供给用户的系统配置大不一样。tpmC最低的厂家C提供给用户的系统反而有可能性能最好，不论是以实际系统的tpmC值还是以用户的实际应用性能来衡量。

③TPC测试的成本

TPC－C和TPC－D都是很复杂的基准程序，做一个严格的测试是很消耗资源的，厂家当然不会说出他们花费了多少钱和时间。但据国外知情人士透露，一个厂家做第一个TPC－C测试需要几十万到上百万美元的资金和半年左右的时间投入。因此，很多TPC的度量值都是估计的。由于计算机系统换代频繁，如果用户一定要用通过审核的度量值，就必须多等待半年时间，因此而不能用最先进的系统。中国的厂家通过审核的时间则更长。

综上所述，我们对中国用户(尤其是大用户)在计算机系统的选型方面有如下建议：

最好建立一个真实的试点，因为实际应用环境是检验计算机系统的最好标准。

中国的行业应该建立符合自己实际应用的基准程序和测试标准。中国税务总局的做法值得提倡。国家有关部门应该建立独立的测试中心，制定跨行业、符合中国企事业运作模式的性能测试标准。

“国际通用”的度量可以作为参考值，而不应作为必要条件。尤其是一定要弄清这些流行度量有什么含义，是在什么样的系统环境中测得的，以及基准程序是否符合企业真实的业务流程和运作模式。

第四章 TPCC计算原则

1建议

不管是TPC-C还是SPECjbb2000，计算结果都只能作为一个横向比较的参考。在实际应用中，决定系统性能的因素除了硬件、系统软件外，与应用软件的设计也是有很大关系的，此外，基于系统可扩展性的考虑，更多时候也倾向于一次性的采购。
从长远考虑，以政府信息化主管部门的角度考虑，建立一套评估机制是非常有用的，这其中包括：
1、通过对各单位业务系统运行情况的调查，进行历史数据的收集分析，按分类建立基准指标库。收集的信息包括：服务器的配置、并发用户数（每天业务量）、CPU负荷等；
2、由厂商定期提供基准值，更新基准指标库；
有了基准指标库的信息参照，不仅可以用于评估项目建设方案中服务器选型，也可以对各部门进行系统架构设计的优化提供指导。如以下是一些指导原则：
1、数据库服务器选型：采购两台相同配置的小型机，进行虚拟分区和并行处理，以提高系统资源的利用率；日后扩容时采取垂直扩展的方式进行升级；
2、应用服务器：采用负载均衡的方式提高并发处理能力，一般可配置2台以上，每台的硬件配置完全可以不同，应首先考虑使用旧的数据库服务器（利旧），如需采购新的服务器，应采用水平扩展的方式逐步升级；
3、 WEB服务器，可以考虑采用刀片服务器，提高扩展性和可管理性。

2参考：某项目计算实例

参考1

为了方便计算数据库服务器的造型，我们约定：
“ 系统同时在线用户数为1500人（U1）；
“ 平均每个用户每分钟发出2次业务请求（N1）；
“ 系统发出的业务请求中，更新、查询、统计各占1/3；
“ 平均每次更新业务产生3个事务（T1）；
“ 平均每次查询业务产生8个事务（T2）；
“ 平均每次统计业务产生13个事务（T3）；
“ 一天内忙时的处理量为平均值的5倍；
“ 经验系数为1.6；(实际工程经验)
“ 考虑服务器保留30％的冗余；
服务器需要的处理能力为：
TPC-C=U1N1（T1+T2+T3）/33经验系数/冗余系数
则应用服务器的处理性能估算为：
TPC-C= 15002（3+8+13）/351.6/0.7= 274,285 tpmC

数据库服务器关系到整个系统的稳定运行，考虑到高可靠性和高可用性，并注重设备的可扩展性和性价比，系统将配置两台TPC-C值不小于28万的高性能数据库服务器。

参考2

以单台服务器性能进行计算，即确保单台服务器工作的时候可以满足系统正常运行的需要；

假设每天有1万人次来窗口办理业务，每人次办理一项业务。即以每日1万笔前台交易为例进行\综合系数**的推导：

\1. 假设每月前台交易数（未来5年内的设计指标）为220,000 （有些业务在月初、月末的处理量比较高，按月统计可以平衡此项差异）;
\2. 每日前台交易数=220000/22=10,000 ，即每日 1万笔；
\3. 忙时处理能力：每日交易的80%在4个小时内完成，即1000080%/4=2000（笔/小时）
\4. 峰值处理能力：20002=4000（笔/小时），即峰值处理能力为每小时4000笔，或 67笔/分，假设业务人员同时在线为100人，即每人每分钟处理0.7笔）
\5. 假设每笔交易对应数据库事务数=20（这个是不是有点夸张了，有这么复杂的交易，TPC的标准交易都不算简单了吧，这只能说明数据库设计的有问题，按这样，支付宝咋弄），基准TPC指标值对应的比例=8，cpu保留30%的处理能力冗余，计算值与公布值（最优值）的偏差经验值为4 （这几个参数估算的依据不足，更多的是经验值）

则 tpmC值为：
tpmC= 672084/(1-30%)= 61257[颠峰处理能力时（笔/分）每笔交易对应数据库事务数基准TPC指标值对应的比例计算值与公布值（最优值）的偏差经验值/（1- cpu保留30%的处理能力冗余）
倒算出综合系数 = 61257/10000=6.1
即数据库服务器tpmC= ***每日前台交易数 \ 6.1**** （实际计算值应不高于该值）
应用服务器的 tpmC = 数据库服务器 tpmC *50% （一般）

应用服务器的 tpmC = tpmC *70%

某单位要建立一个系统，设计容量是 2008 年要达到 1500 万客户的规模，在花费巨资（将近 100 M $）建设起此系统后，运行只有几个月，客户量也只达到几十万，厂商就说此系统容量不够，要花数 M $ 要扩容，并声称不是拍脑袋是，按 TPCC 计算的结果 …

以前只大致了解 TPCC 指标的一些情况，平常也就看看 By Performace 和　By Price/Performace 的 Top 10 列表，了解一下各厂商的实力和产品的情况，这次对 TPCC 进行了一下深入了解，发现了一些容易被厂商搞猫腻的地方。

TPCC 简单的来说，就是事务处理性能委员会 TPC 组织针对联机数据库应用系统（OLTP）制定的一个综合性能考评指标，它模拟了一个批发商的货物管理环境，有标准的数据库结构（Schema），可以很容易的扩展，在此系统中，主要有五类交易：

\1. 新订单（New-Order）

\2. 支付（Payment ） 43%（最小比例）

\3. 订单查询（Order-Status） 4%（最小比例）

\4. 交付（Delivery） 4%（最小比例）

\5. 库存查询（Stock-Level） 4%（最小比例）

因为 TPCC 指标值主要是衡量“新订单”交易的数量，所以厂商都会趋向于增加新订单交易的数量，这样并不满足实际的应用场景，所以 TPCC 的规范中指定了后四种交易数量的最小比例，这样意味着 “新订单” 的数量最多只能占到45%（这个 45% 不知出于什么原因，在很多 TPCC 的指标介绍中并没有提及）。

这就说明了：如果一台机器有 1000 tpm (Transactions per Minute)，那么它实际上处理的交易（请求）为 1000/45% = 2222 ，而实际上大多数厂商在面对用户估算应用系统需要多少个 TPCC 的服务器的时候，是计算所有交易量的，这样带来的评估结果是用户至少买比实际需要大一倍性能容量的机器，获得利益的谁呢？当然是服务器厂商，越高 TPCC 值的机器，价格越高，性价比也一般要偏小。

此外，服务器厂商还容易在以下方面愚弄客户：

１、交易复杂度（用户的一个交易约等于多少个 TPCC 的标准交易），某国际著名的服务器厂商建议此值取 10 - 20 ，这个值也忒大了点，在 TPCC 的场景，交易也不是很简单的，和实际的应用交易差别并不是很大。

2、按一些峰值指标来计算性能，实际上，这些峰值只是在极少数情况下出现，所以在计算时，应乘以 80% 的系数。

3、预留容量，很多厂商建议预留容量，甚至达到一半，这有点过份，在实际容量要求增高的时候，可以通过服务器的横向扩展来纵向扩展来满足应用要求，何必为未来五年的要求，要在眼下一下子要做全部的硬件投资呢？何况硬件的价格在不断下降呢。

具体情况具体分析，还得按中国国情来实测，国际标准有时不适合我们。
而且这个标准好多年了，现在很少在纵向扩展上花心思了，都注重横向扩展，按成本购置小机，尽量优化小机的数据库性能，得出TPCM值，然后对数据库进行横向扩展（虽然横向扩展有诸多问题，但是还是要扩展），利用集群提高整体的TPS

centos7.5下对mysql5.6基准测试

发表于 2019-11-18 | 分类于 mysql

一、测试环境准备

操作系统：centos7.5
处理器：Intel 8核 Current Speed: 2000 MHz， Max Speed: 2000 MHz，三级缓存
内存：16G
磁盘：100G SSD
数据库：mysql 5.6.28
sysbench：1.0.18

二、测试工具

1、sysbench

安装文档： https://github.com/akopytov/sysbench#installing-from-binary-packages

1
2
3

# centos7.5使用官方镜像安装
curl -s https://packagecloud.io/install/repositories/akopytov/sysbench/script.rpm.sh | sudo bash
sudo yum -y install sysbench

帮助：

[root@10-10-135-172 benchmark]# sysbench --help

[root@10-10-135-172 benchmark]# sysbench fileio help
sysbench 1.0.18 (using bundled LuaJIT 2.1.0-beta2)

fileio options:
  --file-num=N                  number of files to create [128]
  --file-block-size=N           block size to use in all IO operations [16384]
  --file-total-size=SIZE        total size of files to create [2G]
  --file-test-mode=STRING       test mode {seqwr, seqrewr, seqrd, rndrd, rndwr, rndrw}
  --file-io-mode=STRING         file operations mode {sync,async,mmap} [sync]
  --file-async-backlog=N        number of asynchronous operatons to queue per thread [128]
  --file-extra-flags=[LIST,...] list of additional flags to use to open files {sync,dsync,direct} []
  --file-fsync-freq=N           do fsync() after this number of requests (0 - don't use fsync()) [100]
  --file-fsync-all[=on|off]     do fsync() after each write operation [off]
  --file-fsync-end[=on|off]     do fsync() at the end of test [on]
  --file-fsync-mode=STRING      which method to use for synchronization {fsync, fdatasync} [fsync]
  --file-merged-requests=N      merge at most this number of IO requests if possible (0 - don't merge) [0]
  --file-rw-ratio=N             reads/writes ratio for combined test [1.5]

2、tpcc-mysql

github： https://github.com/Percona-Lab/tpcc-mysql

mkdir -p /var/lib/mysql/benchmark
cd /var/lib/mysql/benchmark
wget https://github.com/Percona-Lab/tpcc-mysql/archive/master.zip -O tpcc-mysql.zip
unzip -d ./ tpcc-mysql.zip
cd /var/lib/mysql/benchmark/tpcc-mysql-master/src
yum install mysql-devel
make

编译完成后，生成 tpcc_load tpcc_start：

三、测试目标

处理器性能
内存性能
磁盘顺序读写，随机读写性能
mysql 吞吐量，响应时间

四、测试步骤

1、准备获取系统性能和状态的脚本

vi /root/benchmark/1-collect-system-status.sh

#!/bin/sh

mkdir -p status_data

INTERVAL=5
PREFIX=./status_data/$INTERVAL-sec-status
RUNFILE=/root/benchmark/running

mysql -uroot -p123456 -e 'SHOW GLOBAL VARIABLES' >> mysql-variables
while test -e $RUNFILE; do
    tfile=$(date +%F_%I)
    sleep=$(date +%s.%N | awk "{print $INTERVAL - (\$1 % $INTERVAL)}")
    sleep $sleep
    ts="$(date +"TS %s.%N %F %T")"
    loadavg="$(uptime)"
    echo "$ts $loadavg" >> $PREFIX-${tfile}-status
    mysql -uroot -p123456 -e 'SHOW GLOBAL STATUS' >> $PREFIX-${tfile}-status &
    echo "$ts $loadavg" >> $PREFIX-${tfile}-innodbstatus
    mysql -uroot -p123456 -e 'SHOW GLOBAL STATUS\G' >> $PREFIX-${tfile}-innodbstatus &
    echo "$ts $loadavg" >> $PREFIX-${tfile}-processlist
    mysql -uroot -p123456 -e 'SHOW FULL PROCESSLIST\G' >> $PREFIX-${tfile}-processlist &
    echo $ts
done
echo Exiting because $RUNFILE does not exist.

分析收集到的数据

vi /root/benchmark/2-system-status-analyzer.sh

#!/bin/bash

awk '
    BEGIN {
        printf "#ts date time load QPS";
        fmt = " %.2f";
    }
    /^TS/ {
        ts      = substr($2, 1, index($2, ".") - 1);
        load    = NF -2;
        diff    = ts - prev_ts;
        prev_ts = ts;
        printf "\n%s %s %s %s", ts, $3, $4, substr($load, 1, length($load) - 1);
    }
    /Queries/ {
        printf fmt, ($2-Queries)/diff;
        Queries=$2
    }
' "$@"

用法示例

1	sh 2-system-status-analyzer.sh status_data/5-sec-status-2019-11-19_10-status

2、使用sysbench服务器性能测试

1)、cpu测试

计算20000个素数。8核cpu，分别测试 1，4，8，12 线程时的 CPU表现

1	sysbench --test=cpu --threads=1 --cpu-max-prime=20000 run

1	sysbench --test=cpu --threads=4 --cpu-max-prime=20000 run

1	sysbench --test=cpu --threads=8 --cpu-max-prime=20000 run

结论：随着线程数增加，计算能力线性增加；

1	sysbench --test=cpu --threads=12 --cpu-max-prime=20000 run

结论：当线程数超过cpu核数之后，随着线程数增加，计算能力不再增加，甚至略微下降，这是因为线程上下文切换以后的时间损耗；

2)、文件I/O测试

① 准备30G的数据

1	sysbench --test=fileio --file-total-size=30G prepare

② 运行阶段

seqwr：顺序写入

1	sysbench --test=fileio --file-test-mode=seqwr --file-total-size=30G --time=60 run

结论：可以看到，顺序写的过程中 CPU占用很低，但是 buff、cache、block out、in、cs(上下文切换)都很高，这是因为 linux 写磁盘用了页缓存和 DMA。

seqrewr：顺序重写

1	sysbench --test=fileio --file-test-mode=seqrewr --file-total-size=30G --time=60 run

seqrd：顺序读取

1	sysbench --test=fileio --file-test-mode=seqrd --file-total-size=30G --time=60 run

rndrd：随机读取

1	sysbench --test=fileio --file-test-mode=rndrd --file-total-size=30G --time=60 run

结论： SSD是没有寻道时间的，但是随机读（46.95MiB/s）仍然比顺序读（184.46MiB/s）要慢很多

rndwr：随机写入

1	sysbench --test=fileio --file-test-mode=rndwr --file-total-size=30G --time=60 run

随机写（26.25MiB/s）更慢了，顺序写的速度有138.38MiB/s

rndrw：混合随机读/写

1	sysbench --test=fileio --file-test-mode=rndrw --file-total-size=30G --time=60 run

混合随机读写的速度更是龟速，然而我们平时业务场景中使用最多的就是这种情况，所以一定要注意，能顺序写的，一定不随机写

③ 清除数据

sysbench –test=fileio –file-total-size=30G cleanup

3)、内存测试

测试8K顺序分配

1	sysbench --test=memory --memory-access-mode=seq --memory-block-size=8K --memory-total-size=100G --threads=12 --events=10000 run

结论：可以看到 CPU 占用极高，内存写入速度为 10138.32 MiB / sec

测试8K随机分配

1	sysbench --test=memory --memory-access-mode=rnd --memory-block-size=8K --memory-total-size=100G --threads=12 --events=10000 run

结论：cpu占用极高，随机分配速度为 1381.41 MiB / sec，只有顺序分配的 1/7 左右，内存都有顺序写都有差距。

3、sysbench对mysql进行OLTP测试

1	sysbench /usr/share/sysbench/oltp_read_write.lua help

1) 、新建数据库 sbtest

1	mysqladmin create sbtest -uroot -p

2) 、运行状态收集脚本

1	sh /root/benchmark/1-collect-system-status.sh

3)、准备1百万条数据

可以在/usr/share/sysbench/中找到需要使用的lua脚本：

# 开始插入数据
sysbench /usr/share/sysbench/oltp_read_write.lua --threads=64 --time=600 --histogram=on --mysql-host=10.10.135.172 --mysql-port=3306 --mysql-db=sbtest --mysql-user=root --mysql-password=123456 --table-size=10000000 prepare

# 关键参数说明：
--threads=64           测试时使用的线程数
--time=600             测试时间
--histogram=on         在报告中是否输出关于延迟的直方图，建议开启
--table_size=10000000  数据表的大小

4)、运行压测程序

1	sysbench /usr/share/sysbench/oltp_read_write.lua --threads=64 --time=600 --histogram=on --mysql-host=10.10.135.172 --mysql-port=3306 --mysql-db=sbtest --mysql-user=root --table-size=10000000 run

总事务数：820388
每秒事务数：1367.22 per sec
总查询数：16407760
每秒查询数：27344.47 per sec

请求分布直方图

[root@10-10-135-172 benchmark]#  sysbench /usr/share/sysbench/oltp_read_write.lua --threads=64 --time=600 --histogram=on --mysql-host=10.10.135.172 --mysql-port=3306 --mysql-db=sbtest --mysql-user=root --table-size=10000000 run
sysbench 1.0.18 (using bundled LuaJIT 2.1.0-beta2)

Running the test with following options:
Number of threads: 64
Initializing random number generator from current time


Initializing worker threads...

Threads started!

 Latency histogram (values are in milliseconds)
       value  ------------- distribution ------------- count
       4.329 |                                         64
       4.407 |*****                                    1030
       4.487 |****************                         3445
       4.569 |**************************               5587
       4.652 |****************************             5867
       4.737 |*************************                5250
       4.823 |********************                     4190
       4.910 |****************                         3476
       4.999 |**************                           2922
       5.090 |************                             2605
       5.183 |***********                              2329
       5.277 |*********                                1991
       5.373 |*********                                1813
       5.470 |********                                 1600
       5.570 |*******                                  1476
       5.671 |******                                   1279
       5.774 |******                                   1178
       5.879 |*****                                    1043
       5.986 |*****                                    974
       6.095 |****                                     924
       6.205 |****                                     843
       6.318 |****                                     768
       6.433 |****                                     786
       6.550 |****                                     839
       6.669 |****                                     943
       6.790 |*****                                    1012
       6.913 |*****                                    1126
       7.039 |******                                   1171
       7.167 |******                                   1310
       7.297 |******                                   1305
       7.430 |******                                   1291
       7.565 |*****                                    1167
       7.702 |*****                                    1072
       7.842 |*****                                    1066
       7.985 |*****                                    1051
       8.130 |*****                                    1102
       8.277 |*****                                    1081
       8.428 |*****                                    1120
       8.581 |*****                                    1129
       8.737 |******                                   1244
       8.895 |*******                                  1444
       9.057 |********                                 1692
       9.222 |*********                                1984
       9.389 |**********                               2161
       9.560 |**********                               2057
       9.734 |*********                                1944
       9.910 |*********                                1930
      10.090 |********                                 1773
      10.274 |********                                 1753
      10.460 |********                                 1698
      10.651 |********                                 1605
      10.844 |*******                                  1553
      11.041 |********                                 1601
      11.242 |********                                 1636
      11.446 |********                                 1649
      11.654 |********                                 1667
      11.866 |********                                 1673
      12.081 |********                                 1733
      12.301 |*********                                1821
      12.524 |*********                                1838
      12.752 |*********                                1844
      12.984 |**********                               2031
      13.219 |*********                                1978
      13.460 |**********                               2206
      13.704 |************                             2449
      13.953 |*************                            2681
      14.207 |*************                            2675
      14.465 |*************                            2744
      14.728 |*************                            2694
      14.995 |*************                            2667
      15.268 |************                             2652
      15.545 |************                             2650
      15.828 |*************                            2671
      16.115 |************                             2644
      16.408 |*************                            2757
      16.706 |*************                            2760
      17.010 |*************                            2845
      17.319 |**************                           2933
      17.633 |***************                          3217
      17.954 |***************                          3105
      18.280 |****************                         3294
      18.612 |*****************                        3587
      18.950 |*****************                        3704
      19.295 |******************                       3845
      19.645 |******************                       3763
      20.002 |******************                       3743
      20.366 |******************                       3852
      20.736 |******************                       3763
      21.112 |******************                       3891
      21.496 |*******************                      4076
      21.886 |*******************                      4108
      22.284 |********************                     4191
      22.689 |*********************                    4400
      23.101 |**********************                   4702
      23.521 |***********************                  4863
      23.948 |************************                 5072
      24.384 |************************                 5043
      24.827 |*************************                5224
      25.278 |************************                 5196
      25.737 |*************************                5285
      26.205 |**************************               5442
      26.681 |**************************               5452
      27.165 |***************************              5727
      27.659 |****************************             5867
      28.162 |*****************************            6097
      28.673 |******************************           6367
      29.194 |******************************           6414
      29.725 |******************************           6441
      30.265 |*******************************          6512
      30.815 |*******************************          6479
      31.375 |********************************         6828
      31.945 |********************************         6876
      32.525 |**********************************       7128
      33.116 |**********************************       7241
      33.718 |***********************************      7372
      34.330 |************************************     7548
      34.954 |************************************     7653
      35.589 |*************************************    7788
      36.236 |*************************************    7808
      36.894 |*************************************    7910
      37.565 |**************************************   8106
      38.247 |***************************************  8177
      38.942 |***************************************  8311
      39.650 |**************************************** 8451
      40.370 |**************************************   8058
      41.104 |***************************************  8309
      41.851 |***************************************  8260
      42.611 |**************************************** 8481
      43.385 |**************************************** 8493
      44.173 |**************************************** 8478
      44.976 |**************************************** 8394
      45.793 |***************************************  8369
      46.625 |**************************************** 8398
      47.472 |**************************************** 8459
      48.335 |**************************************** 8455
      49.213 |**************************************** 8446
      50.107 |***************************************  8245
      51.018 |***************************************  8215
      51.945 |***************************************  8215
      52.889 |**************************************   8087
      53.850 |**************************************   8119
      54.828 |**************************************   8043
      55.824 |*************************************    7959
      56.839 |**************************************   8043
      57.871 |************************************     7746
      58.923 |************************************     7650
      59.993 |***********************************      7522
      61.083 |***********************************      7535
      62.193 |**********************************       7250
      63.323 |**********************************       7254
      64.474 |**********************************       7118
      65.645 |*********************************        6983
      66.838 |********************************         6868
      68.053 |********************************         6890
      69.289 |*******************************          6688
      70.548 |*******************************          6530
      71.830 |******************************           6437
      73.135 |*****************************            6127
      74.464 |******************************           6278
      75.817 |****************************             5952
      77.194 |***************************              5767
      78.597 |**************************               5581
      80.025 |**************************               5522
      81.479 |*************************                5374
      82.959 |*************************                5217
      84.467 |***********************                  4957
      86.002 |***********************                  4947
      87.564 |**********************                   4767
      89.155 |**********************                   4673
      90.775 |*********************                    4499
      92.424 |*********************                    4358
      94.104 |********************                     4230
      95.814 |*******************                      4021
      97.555 |******************                       3871
      99.327 |******************                       3750
     101.132 |*****************                        3665
     102.969 |****************                         3465
     104.840 |****************                         3322
     106.745 |***************                          3286
     108.685 |**************                           3019
     110.659 |**************                           2963
     112.670 |*************                            2707
     114.717 |*************                            2712
     116.802 |************                             2528
     118.924 |***********                              2379
     121.085 |***********                              2269
     123.285 |**********                               2138
     125.525 |**********                               2105
     127.805 |*********                                1861
     130.128 |*********                                1820
     132.492 |********                                 1735
     134.899 |*******                                  1575
     137.350 |*******                                  1502
     139.846 |*******                                  1412
     142.387 |******                                   1302
     144.974 |******                                   1231
     147.608 |*****                                    1056
     150.290 |*****                                    1015
     153.021 |****                                     927
     155.801 |****                                     879
     158.632 |****                                     815
     161.514 |***                                      685
     164.449 |***                                      696
     167.437 |***                                      613
     170.479 |***                                      591
     173.577 |**                                       499
     176.731 |**                                       457
     179.942 |**                                       447
     183.211 |**                                       360
     186.540 |**                                       352
     189.929 |*                                        298
     193.380 |*                                        304
     196.894 |*                                        224
     200.472 |*                                        208
     204.114 |*                                        204
     207.823 |*                                        173
     211.599 |*                                        155
     215.443 |*                                        113
     219.358 |*                                        129
     223.344 |                                         106
     227.402 |                                         82
     231.534 |                                         67
     235.740 |                                         66
     240.024 |                                         43
     244.385 |                                         53
     248.825 |                                         30
     253.346 |                                         31
     257.950 |                                         26
     262.636 |                                         19
     267.408 |                                         25
     272.267 |                                         12
     277.214 |                                         11
     282.251 |                                         11
     287.379 |                                         11
     292.601 |                                         5
     297.917 |                                         11
     303.330 |                                         5
     308.842 |                                         6
     314.453 |                                         14
     320.167 |                                         10
     325.984 |                                         16
     331.907 |                                         11
     337.938 |                                         2
     344.078 |                                         8
     350.330 |                                         10
     356.695 |                                         11
     363.176 |                                         10
     369.775 |                                         15
     376.494 |                                         12
     383.334 |                                         14
     390.299 |                                         10
     397.391 |                                         5
     404.611 |                                         11
     411.963 |                                         2
     419.448 |                                         11
     427.069 |                                         7
     434.829 |                                         6
     442.730 |                                         6
     450.774 |                                         5
     458.964 |                                         2
     475.794 |                                         1
     484.439 |                                         2
     493.242 |                                         1
     559.501 |                                         1
 
SQL statistics:
    queries performed:
        read:                            11485432
        write:                           3281552
        other:                           1640776
        total:                           16407760
    transactions:                        820388 (1367.22 per sec.)
    queries:                             16407760 (27344.47 per sec.)
    ignored errors:                      0      (0.00 per sec.)
    reconnects:                          0      (0.00 per sec.)

General statistics:
    total time:                          600.0372s
    total number of events:              820388

Latency (ms):
         min:                                    4.30
         avg:                                   46.80
         max:                                  556.16
         95th percentile:                      112.67
         sum:                             38398062.70

Threads fairness:
    events (avg/stddev):           12818.5625/107.50
    execution time (avg/stddev):   599.9697/0.01

[root@10-10-135-172 benchmark]#

5)、清理数据

1	sysbench /usr/share/sysbench/oltp_read_write.lua --threads=64 --time=600 --histogram=on --mysql-host=10.10.135.172 --mysql-port=3306 --mysql-db=sbtest --mysql-user=root --table-size=10000000 cleanup

6)、分析收集到的状态

$ sh 2-system-status-analyzer.sh status_data/5-sec-status-2019-11-19_06-status > status.txt
$ vi status.txt
unix时间戳    时间            系统负载 QPS(数据库)
1574160560 18:49:20 18:49:20 51.53 28179.80
1574160565 18:49:25 18:49:25 51.80 26713.20
1574160570 18:49:30 18:49:30 50.86 27784.60
1574160575 18:49:35 18:49:35 51.19 26912.40
1574160580 18:49:40 18:49:40 52.30 27048.20
1574160585 18:49:45 18:49:45 52.99 26843.00
1574160590 18:49:50 18:49:50 53.87 27478.80
1574160595 18:49:55 18:49:55 54.61 28724.60
1574160600 18:50:00 18:50:00 55.68 27960.00
1574160605 18:50:05 18:50:05 55.46 25874.40
1574160610 18:50:10 18:50:10 56.07 25936.40
1574160615 18:50:15 18:50:15 52.54 25914.20
1574160620 18:50:20 18:50:20 52.66 27237.60
1574160625 18:50:25 18:50:25 52.92 27507.20
1574160630 18:50:30 18:50:30 53.89 26005.40
1574160635 18:50:35 18:50:35 55.02 26745.00
1574160640 18:50:40 18:50:40 54.86 25643.80
1574160645 18:50:45 18:50:45 55.75 24751.20
1574160650 18:50:50 18:50:50 53.69 27608.80
1574160655 18:50:55 18:50:55 52.51 26590.20
1574160660 18:51:00 18:51:00 51.83 27411.60
1574160665 18:51:05 18:51:05 49.68 28504.20
1574160670 18:51:10 18:51:10 50.27 20451.00
1574160675 18:51:15 18:51:15 46.24 1.40
1574160680 18:51:20 18:51:20 42.62 2.20
1574160685 18:51:25 18:51:25 39.21 1.40
1574160690 18:51:30 18:51:30 36.07 1.80
1574160695 18:51:35 18:51:35 33.18 2.40
1574160700 18:51:40 18:51:40 30.52 1.00

$ cat status_data/5-sec-status-2019-11-19_06-status | grep 'TS ' > load_status.txt
$ vi load_status.txt

TS 1574160295.047916883 18:44:55  18:44:55 up 1 day,  2:22,  5 users,  load average: 52.13, 24.94, 9.96
TS 1574160300.059352736 18:45:00  18:45:00 up 1 day,  2:22,  5 users,  load average: 53.08, 25.59, 10.25
TS 1574160305.042101201 18:45:05  18:45:05 up 1 day,  2:22,  5 users,  load average: 50.91, 25.60, 10.33
TS 1574160310.052530257 18:45:10  18:45:10 up 1 day,  2:22,  5 users,  load average: 51.72, 26.19, 10.60
TS 1574160315.046490819 18:45:15  18:45:15 up 1 day,  2:22,  5 users,  load average: 52.78, 26.83, 10.89
TS 1574160320.008893450 18:45:20  18:45:20 up 1 day,  2:22,  5 users,  load average: 53.68, 27.45, 11.18
TS 1574160325.203247981 18:45:25  18:45:25 up 1 day,  2:22,  5 users,  load average: 54.67, 28.09, 11.47
TS 1574160330.118228229 18:45:30  18:45:30 up 1 day,  2:22,  5 users,  load average: 55.57, 28.72, 11.77
TS 1574160335.016869072 18:45:35  18:45:35 up 1 day,  2:22,  5 users,  load average: 55.61, 29.17, 12.00
TS 1574160340.042057908 18:45:40  18:45:40 up 1 day,  2:22,  5 users,  load average: 54.84, 29.45, 12.19
TS 1574160345.056853963 18:45:45  18:45:45 up 1 day,  2:23,  5 users,  load average: 55.65, 30.04, 12.47
TS 1574160350.059495691 18:45:50  18:45:50 up 1 day,  2:23,  5 users,  load average: 55.84, 30.50, 12.72
TS 1574160355.238934528 18:45:55  18:45:55 up 1 day,  2:23,  5 users,  load average: 56.65, 31.09, 13.00
TS 1574160360.115909774 18:46:00  18:46:00 up 1 day,  2:23,  5 users,  load average: 56.76, 31.54, 13.24
TS 1574160365.067470620 18:46:05  18:46:05 up 1 day,  2:23,  5 users,  load average: 57.34, 32.08, 13.52
TS 1574160370.111400548 18:46:10  18:46:10 up 1 day,  2:23,  5 users,  load average: 55.39, 32.09, 13.62
TS 1574160375.074730081 18:46:15  18:46:15 up 1 day,  2:23,  5 users,  load average: 53.76, 32.14, 13.74
TS 1574160380.210612654 18:46:20  18:46:20 up 1 day,  2:23,  5 users,  load average: 54.34, 32.62, 13.99
TS 1574160385.102457806 18:46:25  18:46:25 up 1 day,  2:23,  5 users,  load average: 50.87, 32.26, 13.97
TS 1574160390.117591568 18:46:30  18:46:30 up 1 day,  2:23,  5 users,  load average: 50.48, 32.49, 14.14
TS 1574160395.076076309 18:46:35  18:46:35 up 1 day,  2:23,  5 users,  load average: 51.40, 32.98, 14.40
TS 1574160400.191211227 18:46:40  18:46:40 up 1 day,  2:23,  5 users,  load average: 52.09, 33.43, 14.65
TS 1574160405.153420741 18:46:45  18:46:45 up 1 day,  2:24,  5 users,  load average: 49.20, 33.14, 14.65
TS 1574160410.013108072 18:46:50  18:46:50 up 1 day,  2:24,  5 users,  load average: 49.58, 33.49, 14.87
TS 1574160415.084485731 18:46:55  18:46:55 up 1 day,  2:24,  5 users,  load average: 48.82, 33.59, 15.00
TS 1574160420.011562959 18:47:00  18:47:00 up 1 day,  2:24,  5 users,  load average: 47.55, 33.58, 15.10
TS 1574160425.018923271 18:47:05  18:47:05 up 1 day,  2:24,  5 users,  load average: 48.95, 34.11, 15.37

4、tpcc-mysql对mysql进行测试

Build binaries

cd src ; make ( you should have mysql_config available in $PATH)

Load data

create database mysqladmin create tpcc1000

create tables mysql tpcc1000 < create_table.sql

create indexes and FK ( this step can be done after loading data) mysql tpcc1000 < add_fkey_idx.sql

populate data

simple step tpcc_load -h127.0.0.1 -d tpcc1000 -u root -p "" -w 1000 |hostname:port| |dbname| |user| |password| |WAREHOUSES| ref. tpcc_load –help for all options

load data in parallel check load.sh script

Start benchmark

./tpcc_start -h127.0.0.1 -P3306 -dtpcc1000 -uroot -w1000 -c32 -r10 -l10800

|hostname| |port| |dbname| |user| |WAREHOUSES| |CONNECTIONS| |WARMUP TIME| |BENCHMARK TIME|

ref. tpcc_start –help for all options

1)、创建数据库和表结构

cd tpcc-mysql-master

mysqladmin create tpcc1000 -uroot -p123456
mysql -uroot -p123456 tpcc1000 < create_table.sql
mysql -uroot -p123456 tpcc1000 < add_fkey_idx.sql

2)、加载数据

1
2
3

./tpcc_load -h10.10.135.172 -P3306 -d tpcc1000 -u root -p 123456 -w 10
# 1 代表1个仓库大小，10代表 10个仓库大小
# sh load.sh tpcc1000 1000

加载完后查看数据量

select count(*) from tpcc1000.customer;
select count(*) from tpcc1000.district;
select count(*) from tpcc1000.history;
select count(*) from tpcc1000.item;
select count(*) from tpcc1000.new_orders;
select count(*) from tpcc1000.order_line;
select count(*) from tpcc1000.orders;
select count(*) from tpcc1000.stock;
select count(*) from tpcc1000.warehouse;

3)、运行状态收集脚本

1	sh /root/benchmark/1-collect-system-status.sh

4)、执行测试

# -w 指定仓库数量
# -c 指定并发连接数
# -r 指定开始测试前进行warmup的时间，进行预热后，测试效果更好
# -l 指定测试持续时间
# -i 指定生成报告间隔时长
# -f 指定生成的报告文件名

# 真实测试场景中，建议预热时间不小于5分钟，持续压测时长不小于30分钟，否则测试数据可能不具参考意义
# 耗时：1800, 即 30分钟
./tpcc_start -h10.10.135.172 -P3306 -dtpcc1000 -uroot -p123456 -w10 -c32 -r300 -l1800 > tpcc_output.txt

top

vmstat 1

执行结果

5)、分析收集到的状态数据

$ sh 2-system-status-analyzer.sh status_data/5-sec-status-2019-11-19_06-status > status.txt
$ vi status.txt
unix时间戳    时间              系统负载 QPS(数据库)
1574177360 2019-11-19 23:29:20 22.00 37156.60
1574177365 2019-11-19 23:29:25 20.24 36821.80
1574177370 2019-11-19 23:29:30 21.26 36879.80
1574177375 2019-11-19 23:29:35 19.56 37217.60
1574177380 2019-11-19 23:29:40 20.63 37646.80
1574177385 2019-11-19 23:29:45 21.62 35293.20
1574177390 2019-11-19 23:29:50 19.89 36457.80
1574177395 2019-11-19 23:29:55 18.30 37464.00
1574177400 2019-11-19 23:30:00 19.72 36722.60
1574177405 2019-11-19 23:30:05 20.78 37913.60
1574177410 2019-11-19 23:30:10 19.12 36294.00
1574177415 2019-11-19 23:30:15 17.58 35279.20
1574177420 2019-11-19 23:30:20 18.98 39051.20
1574177425 2019-11-19 23:30:25 20.10 37700.20
1574177430 2019-11-19 23:30:30 18.49 37632.20
1574177435 2019-11-19 23:30:35 17.01 38068.00
1574177440 2019-11-19 23:30:40 15.65 38218.40
1574177445 2019-11-19 23:30:45 14.48 34143.40
1574177450 2019-11-19 23:30:50 13.40 7794.60
1574177455 2019-11-19 23:30:55 12.40 7744.80
1574177460 2019-11-19 23:31:00 11.41 613.40
1574177465 2019-11-19 23:31:05 10.50 2.20
1574177470 2019-11-19 23:31:10 9.66 1.40
1574177475 2019-11-19 23:31:15 8.88 1.80
1574177480 2019-11-19 23:31:20 8.17 1.80
1574177485 2019-11-19 23:31:25 7.52 1.80
1574177490 2019-11-19 23:31:30 6.92 2.00
1574177495 2019-11-19 23:31:35 6.36 2.00
1574177500 2019-11-19 23:31:40 5.85 1.60

vi tpcc_output.txt

***************************************
*** ###easy### TPC-C Load Generator ***
***************************************
option h with value '10.10.135.172'
option P with value '3306'
option d with value 'tpcc1000'
option u with value 'root'
option p with value '123456'
option w with value '10'
option c with value '32'
option r with value '300'
option l with value '1800'
<Parameters>
     [server]: 10.10.135.172   -- 主机
     [port]: 3306              -- 端口
     [DBname]: tpcc1000        -- 压测的数据库
       [user]: root            -- 账号
       [pass]: 123456          -- 密码
  [warehouse]: 10              -- 仓库数
 [connection]: 32              -- 并发线程数 
     [rampup]: 300 (sec.)      -- 数据预热时长 
    [measure]: 1800 (sec.)     -- 压测时长

RAMP-UP TIME.(300 sec.)       --预热结束

MEASURING START.              --开始压测

-- 每10秒输出一次压测数据
-- 以逗号分隔，共9列
-- 第1列，第N次10秒
-- 第2列，New-Order在本轮取样时间内成功执行事务的次数(即吞吐量)
-- 第3列，New-Order在本轮取样时间内，95%事务 在响应时间内（ms）完成
-- 第4列，New-Order在本轮取样时间内，99%事务 在响应时间内完成
-- 第5列，New-Order在本轮取样时间内，本轮测试最大响应时间（ms）
-- 第6列，Payment 有效事务数（吞吐量） | 最大响应时间（ms）
-- 第7列，Order-Status 有效事务数（吞吐量） | 最大响应时间（ms）
-- 第8列，Delivery 有效事务数（吞吐量） | 最大响应时间（ms）
-- 第9列，Stock-Level 有效事务数（吞吐量） | 最大响应时间（ms）
  10, trx: 6322, 95%: 58.880, 99%: 80.384, max_rt: 465.298, 6319|311.356, 632|147.998, 633|518.363, 632|840.708
  20, trx: 6402, 95%: 57.161, 99%: 74.165, max_rt: 108.881, 6399|102.155, 640|54.569, 640|187.683, 641|125.100
  30, trx: 6215, 95%: 58.616, 99%: 83.674, max_rt: 240.631, 6224|149.658, 623|135.217, 622|332.418, 621|168.763
  40, trx: 6365, 95%: 57.109, 99%: 76.190, max_rt: 136.020, 6362|140.110, 637|35.815, 637|142.510, 636|154.135
  50, trx: 6426, 95%: 56.973, 99%: 76.281, max_rt: 131.508, 6427|171.652, 641|45.733, 640|145.872, 643|156.595
  60, trx: 6198, 95%: 58.476, 99%: 80.384, max_rt: 229.300, 6197|238.621, 620|37.124, 621|269.572, 619|261.585
  70, trx: 6418, 95%: 57.366, 99%: 76.648, max_rt: 116.301, 6421|115.735, 643|42.165, 643|172.855, 643|151.629
  80, trx: 6406, 95%: 57.815, 99%: 76.877, max_rt: 115.657, 6396|99.119, 639|39.815, 640|152.090, 640|159.341
  90, trx: 5841, 95%: 62.047, 99%: 87.229, max_rt: 290.416, 5836|291.379, 584|42.550, 585|301.866, 584|142.273
 100, trx: 6168, 95%: 56.362, 99%: 76.717, max_rt: 125.903, 6183|115.971, 618|47.143, 619|158.824, 618|162.145
 110, trx: 6249, 95%: 57.573, 99%: 78.200, max_rt: 138.199, 6232|126.211, 624|40.234, 623|155.532, 624|152.938
 120, trx: 6107, 95%: 58.511, 99%: 78.694, max_rt: 121.301, 6125|146.152, 611|37.128, 608|156.622, 609|126.521
 130, trx: 6076, 95%: 58.424, 99%: 84.227, max_rt: 346.854, 6074|266.228, 608|48.112, 608|361.008, 610|140.032
 140, trx: 6365, 95%: 55.992, 99%: 75.599, max_rt: 115.579, 6367|110.699, 637|47.943, 637|156.809, 634|126.359
....
1760, trx: 6386, 95%: 56.599, 99%: 74.588, max_rt: 115.095, 6386|103.424, 638|44.586, 640|143.890, 637|139.005
1770, trx: 6148, 95%: 59.039, 99%: 76.510, max_rt: 124.202, 6149|99.945, 615|37.548, 612|152.861, 615|157.265
1780, trx: 5831, 95%: 59.786, 99%: 82.061, max_rt: 291.887, 5826|335.447, 583|47.130, 585|365.992, 583|156.420
1790, trx: 6161, 95%: 57.676, 99%: 78.294, max_rt: 130.952, 6162|132.039, 616|46.349, 616|149.911, 615|173.092
1800, trx: 6164, 95%: 56.295, 99%: 74.098, max_rt: 117.632, 6169|131.690, 616|39.105, 616|202.839, 618|126.449

STOPPING THREADS................................          -- 结束压测

# 成功(success,简写sc)次数，延迟(late,简写lt)次数，重试(retry,简写rt)次数，失败(failure,简写fl)次数
<Raw Results>                                             -- 第一次统计结果
  [0] sc:35421 lt:1093057  rt:0  fl:0 avg_rt: 30.0 (5)    -- New-Order，新订单业务
  [1] sc:457714 lt:670742  rt:0  fl:0 avg_rt: 15.6 (5)    -- Payment，支付业务统计
  [2] sc:96544 lt:16304  rt:0  fl:0 avg_rt: 3.6 (5)       -- Order-Status，订单状态业务统计
  [3] sc:87922 lt:24927  rt:0  fl:0 avg_rt: 72.5 (80)     -- Delivery，发货业务统计
  [4] sc:1565 lt:111282  rt:0  fl:0 avg_rt: 62.8 (20)     -- Stock-Level，库存业务统计
 in 1800 sec.

<Raw Results2(sum ver.)>                                  -- 第二次统计结果，其他同上
  [0] sc:35421  lt:1093057  rt:0  fl:0
  [1] sc:457717  lt:670764  rt:0  fl:0
  [2] sc:96544  lt:16304  rt:0  fl:0
  [3] sc:87922  lt:24927  rt:0  fl:0
  [4] sc:1565  lt:111283  rt:0  fl:0

<Constraint Check> (all must be [OK])     -- 下面所有业务逻辑结果都必须为 OK 才行
 [transaction percentage]
        Payment: 43.48% (>=43.0%) [OK]    -- 支付成功次数(上述统计结果中sc + lt)必须大于43.0%，否则结果为NG，而不是OK
   Order-Status: 4.35% (>= 4.0%) [OK]     --订单状态，其他同上
       Delivery: 4.35% (>= 4.0%) [OK]     -- 发货，其他同上
    Stock-Level: 4.35% (>= 4.0%) [OK]     -- 库存，其他同上
 [response time (at least 90% passed)]    -- 响应耗时指标必须超过90%通过才行
      New-Order: 3.14%  [NG] *            -- 标准5ms，只有3.14% 响应时间合格
        Payment: 40.56%  [NG] *           -- 标准5ms，
   Order-Status: 85.55%  [NG] *           -- 标准5ms，
       Delivery: 77.91%  [NG] *           -- 标准80ms，
    Stock-Level: 1.39%  [NG] *            -- 标准20ms，

<TpmC>
                 37615.934 TpmC          -- TpmC结果值{每分钟事务数，该值是第一次统计结果中的新订单事务数除以总耗时分钟数，例如本例中是：（35421+1093057）/30 ≈ 37615.93..}；1000tpmC相当于2000个事务；

tpcc-mysql的业务逻辑及其相关的几个表作用如下：

New-Order：新订单，一次完整的订单事务，几乎涉及到全部表

Payment：支付，主要对应 orders、history 表

Order-Status：订单状态，主要对应 orders、order_line 表

Delivery：发货，主要对应 order_line 表

Stock-Level：库存，主要对应 stock 表

其它表说明:

客户：主要对应 customer 表

地区：主要对应 district 表

商品：主要对应 item 表

仓库：主要对应 warehouse 表

6)、清理数据

1	drop database tpcc1000;

7)、使用gunplot绘图

① 安装 gunplot

yum install -y gnuplot

gnuplot -V
# gnuplot 4.6 patchlevel 2

帮助文档： http://gnuplot.info/docs_4.6/gnuplot.pdf

② 准备分析脚本和绘图脚本

gunplot-analyze-tpcc.sh

#!/bin/bash
TIMESLOT=1

if [ -n "$2" ]
then
    TIMESLOT=$2
    echo "Defined $2"
fi

cat $1 | grep -v HY000 | grep -v payment | grep -v neword | \
awk -v timeslot=$TIMESLOT '\
BEGIN { FS="[,():|]"; s=0; cntr=0; aggr=0 } \
/MEASURING START/ {s=1} \
/STOPPING THREADS/ {s=0} \
/0/ { \
    if (s==1) { cntr++; aggr+=$2; } \
    if (cntr==timeslot ) { printf ("%d %3f %d\n",$1,$5,$3) ; cntr=0; aggr=0  } \
}'

解释：把 140, trx: 6365, 95%: 55.992, 99%: 75.599, max_rt: 115.579, 6367|110.699, 637|47.943, 637|156.809, 634|126.359中的 “[,():|]” 字符去掉以后，就剩下了140 trx 6365 95% 55.992 99% 75.599 max_rt 115.579 6367 110.699 637 47.943 637 156.809 634 126.359。$1就是140， $5就是55.992，打印的语法就跟c语言一样

帮助文档：man awk

③ 对 tpcc-mysql 测试生成的数据文件进行提取

1	sh gunplot-analyze-tpcc.sh tpcc_output.txt > tpcc_output_transfer.txt

④ 使用tpcc-graph-build.sh脚本生成图表

画95%的事务响应时间图：gunplot-graph-build-rt.sh

#!/bin/bash
### goto user homedir and remove previous file
rm -f '$2'
gnuplot << EOP
### set data source file
datafile = '$1'
### set graph type and size
set terminal jpeg size 720,640
### set titles
set grid x y
set xlabel "Time (sec)"
set ylabel "Response Times(sec)"
### set output filename
set output '$2'
### build graph
# plot datafile using 1:2 title "95%-rt" with lines,datafile using 1:3 title "max_rt" with lines axes x1y1
plot datafile using 1:2 title "95%-rt" with lines axes x1y1
EOP

画间隔时间内完成的事务数的图：gunplot-graph-build-trx.sh

#!/bin/bash
### goto user homedir and remove previous file
rm -f '$2'
gnuplot << EOP
### set data source file
datafile = '$1'
### set graph type and size
set terminal jpeg size 720,640
### set titles
set grid x y
set xlabel "Time (sec)"
set ylabel "Transaction Nums"
### set output filename
set output '$2'
### build graph
# plot datafile using 1:2 title "95%-rt" with lines,datafile using 1:3 title "max_rt" with lines axes x1y1
plot datafile using 1:3 title "Transaction Nums" with lines axes x1y1
EOP

1	sh gunplot-graph-build-rt.sh tpcc_output_transfer.txt tpcc_output.jpg

1	sh gunplot-graph-build-trx.sh tpcc_output_transfer.txt tpcc_output.jpg

五、mysql性能调优

可以看到tpcc-mysql基准测试中 rt项全部不合格，所以需要对mysql进行性能调优

Centos7 管理 buff/cache 方法

发表于 2019-11-17 | 分类于 linux

介绍

　　Linux服务器运行一段时间后，由于其内存管理机制，会将暂时不用的内存转为buff/cache，这样在程序使用到这一部分数据时，能够很快的取出，从而提高系统的运行效率，所以这也正是linux内存管理中非常出色的一点，所以乍一看内存剩余的非常少，但是在程序真正需要内存空间时，linux会将缓存让出给程序使用，这样达到对内存的最充分利用，所以真正剩余的内存是free+buff/cache

　　但是有些时候大量的缓存占据空间，这时候应用程序回去使用swap交换空间，从而使系统变慢，这时候需要手动去释放内存，释放内存的时候，首先执行命令 sync 将所有正在内存中的缓冲区写到磁盘中，其中包括已经修改的文件inode、已延迟的块I/O以及读写映射文件，从而确保文件系统的完整性

linux机制

　　说到清理内存，那么不得不提到/proc这一个虚拟文件系统，这里面的数据和文件都是内存中的实时数据，很多参数的获取都可以从下面相应的文件中得到，比如查看某一进程占用的内存大小和各项参数，cpu和主板的详细信息，显卡的参数等等；相应的关于内存的管理方式是在/proc/sys/vm/drop_chches文件中，一定要注意这个文件中存放的并不是具体的内存内容，而是0-3这几个数字，通过文件大小只有1B也可以知道，而这些代号分别告诉系统代表不同的含义如下：

0：0是系统默认值，默认情况下表示不释放内存，由操作系统自动管理
1：释放页缓存
2：释放dentries和inodes
3：释放所有缓存

　　所以根据上面的说明，分别将1,2,3这3个数字重定向到drop_caches中可以实现内存的释放，一般释放内存都是重定向3到文件中，释放所有的缓存

使用方法

那么下面举个例子，比如这里只释放页缓存，首先使用

free -m

查看当前内存剩余

当前内存剩余570M左右，另外buff/cache是1.3G，根据上面说的现在真正的剩余内存应该是1.8G左右，首先写缓存到文件系统：

sync

然后执行下面命令释放内存(页缓存buff/cache)：

1	echo 1 > /proc/sys/vm/drop_caches

执行完之后，再次查看内存剩余：

会发现内存被释放了，可用内存确实变为1.5G左右

　　到这里内存就释放完了，现在drop_caches中的值为1，如果现在想让操作系统重新分配内存，那么设置drop_caches的值为0即可：

1	echo 0 > /proc/sys/vm/drop_caches

但是我走到这里报错，从0可以设置为1-3 ，但是不能设置为0了。一直没有找到原因，最后直接重启服务器了，然后开机之后自己恢复成0了。

所以命令慎用！！！

另外需要注意的是，在生产环境中的服务器我们不要频繁的去释放内存，只在必要时候清理内存即可，更重要的是我们应该从应用程序层面去优化内存的利用和释放，经常清理内存可能只是暂时屏蔽的应用程序中的一些bug，所以更重要的是程序的调优，其他的交给操作系统来管理

keepalived+ip组播

发表于 2019-11-14 | 分类于 computer-network ， keepalived

开启ip组播

centos7

centos6

keepalived安装配置

2台主机

server	hostname	ip
keepalived	ka1	192.168.99.103
keepalived	ka2	192.168.99.104

1、2台分别安装keepalived

1 2	[ka1]$ yum -y install keepalived [ka2]$ yum -y install keepalived

2、修改ka1的配置

[ka1]# vim /etc/keepalived/keepalived.conf
! Configuration File for keepalived

global_defs {
   notification_email {
       root@localhost
   }
   notification_email_from root@localhost
   smtp_server 127.0.0.1
   smtp_connect_timeout 30
   router_id ka1
   vrrp_skip_check_adv_addr
   vrrp_strict
   vrrp_iptables
   vrrp_mcast_group4 224.100.100.100   #不写默认是224.0.0.18
   vrrp_garp_interval 0
   vrrp_gna_interval 0
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 11
    priority 100
    advert_int 1
    #nopreempt   #非抢占模式，当优先级更高的主机上线时，不会抢占为主服务器
    authentication {
        auth_type PASS
        auth_pass 123
    }
    virtual_ipaddress {
        192.168.0.100 dev eth0 label eth0:1
    }
}

3、修改ka2的配置

! Configuration File for keepalived

global_defs {
   notification_email {
       root@localhost
   }
   notification_email_from root@localhost
   smtp_server 127.0.0.1
   smtp_connect_timeout 30
   router_id ka2
   vrrp_skip_check_adv_addr
   vrrp_strict
   vrrp_iptables
   vrrp_mcast_group4 224.100.100.100   #不写默认是224.0.0.18
   vrrp_garp_interval 0
   vrrp_gna_interval 0
}

vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    virtual_router_id 11
    priority 80
    advert_int 1
    #nopreempt   #非抢占模式，当优先级更高的主机上线时，不会抢占为主服务器
    authentication {
        auth_type PASS
        auth_pass 123
    }
    virtual_ipaddress {
        192.168.0.100 dev eth0 label eth0:1
    }
}

4、在ka1或ka2新开个终端准备抓包

[ka1]$ tcpdump -i eth0 -nn net 224.100.100.100

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes

5、启动ka2的keepalived(先启动backup)

1	[ka2]$ systemctl restart keepalived

抓到包了。

VIP绑定上了

6、再启动ka1的keepalived(注意看抓包)

1	[ka1]$ systemctl start keepalived

可以看到，宣告的IP变成了ka1的了

VIP漂移到ka1了，因为ka1的优先级比ka2高