前言

• Meson 官网
• Meson 官方文档
• Meson GitHub 项目

Meson 介绍

Meson 的简介

Meson（The Meson Build System）是个项目构建系统，类似的构建系统有 Makefile、CMake、automake …。 Meson 是一个由 Python 实现的开源项目，其思想是，开发人员花费在构建调试上的每一秒都是浪费，同样等待构建过程直到真正开始编译都是不值得的。因此，Meson 的设计目的是在用户友好的同时不损害性能，Meson 提供客户语言（custom language）作为主要工具，用户可以使用它完成项目构建的描述。客户语言的设计目标是简单（simplicity）、清晰（clarity）、简洁（conciseness），其中很多灵感来源于 Python 语言。Meson 的另个一主要设计目的是为现代编程工具提供优秀的支持和最好的实现。这包括一些特性如：单元测试（unit testing）、代码覆盖率报告（code coverage reporting）、头文件预编译（precompiled headers）。用户不需要寻找第三方宏指令（third party macros）或编写 Shell 脚本来实现这些特性，Meson 可以开箱即用。Meson 相比 CMake 来说，不仅仅支持 C/C++，还支持多种编程语言。如今，很多项目都由 CMake 转向到了 Meson，例如 DPDK 和 Mapnik。

前言

• Codis GitHub
• Codis 官方中文文档

分布式解决方案介绍

• Redis Sentinel

  • 用户体量较小时，可以选择 Redis Sentinel，单主 Redis 实例足以支撑业务。

• Redis Cluster

  • Redis 官方提供的集群方案，用户体量较大时，可以选择 Redis Cluster，通过分片技术可以使用更多的内存。

• Twemprox

  • Twitter 开源的一个 Redis 和 Memcached 代理服务器，主要用于管理 Redis 和 Memcached 集群，减少客户端与 Cache 服务器直接连接的数量。

• Codis

  • 一个 Redis 代理中间件，当客户端向 Codis 发送指令时，Codis 会将指令转发到后面的 Redis 实例来执行，并将结果返回给客户端。
  • 一个 Codis 实例可以连接多个 Redis 实例，也可以启动多个 Codis 实例来支撑，每个 Codis 节点都是对等的，这样可以增加整体的 QPS 需求，还能起到容灾功能。

• 客户端分片

  • 该方案在 Redis Cluster 还没出现之前使用得比较多，现在基本很少使用了。
  • 分片逻辑在业务代码层实现，创建几个毫无关联的 Redis 实例，在代码层对 Key 进行 Hash 计算，然后去对应的 Redis 实例操作数据。
  • 该方案对 Hash 算法的要求比较高，需要考虑节点失效后的替代算法方案、数据震荡后的自动脚本恢复、实例的监控等等。

大纲

• MySQL 存储过程的使用
• MySQL 事件调度器的使用

存储过程的介绍

• 存储过程是在数据库中存储的一组预编译的 SQL 语句，可以在需要时多次调用。
• 存储过程只在创建时进行编译，以后每次执行存储过程都不需再重新编译，而一般的 SQl 语句每执行一次就编译一次，因此使用存储过程可以大大提高数据库的执行速度。
• 通常，复杂的业务逻辑需要多条 SQL 语句。这些语句要分别地从客户端发送到服务器，当客户端和服务器之间的操作有很多时，将产生大量的网络传输。如果将这些操作放在一个存储过程中，那么客户端和服务器之间的网络传输就会大大减少，从而降低了网络负载。

前言

软件环境

前言

消息队列中间件选择时要根据项目的实际需求，考虑系统的吞吐量、延迟、可靠性、可扩展性等因素。

消息中间件产品对比一

系统级命令

获取符合规则的键名列表

KEYS 命令需要遍历 Redis 中的所有键，当键的数量较多时会严重影响性能，在生产环境中应该禁用该命令。

1

KEYS pattern

示例：

1
2

redis> KEYS *
1) "book"

前言

负载均衡的实现

• TCP 层实现的负载均衡，例如：LVS（调度性能强悍）
• 应用层实现的负载均衡，例如：Nginx、Haproxy、Apache、Varnish、Squid、Ribbon

Keepalived 概述

Keepalived 简介

  Keepalived 是 Linux 下一个轻量级别的高可用开源解决方案，高可用 (High Avalilability)，其实两种不同的含义：广义来讲，是指整个系统的高可用行，狭义的来讲就是之主机的冗余和接管，它与 HeartBeat RoseHA 实现相同类似的功能，都可以实现服务或者网络的高可用；但是又有差别，HeartBeat 是一个专业的、功能完善的高可用软件，它提供了 HA 软件所需的基本功能，比如：心跳检测、资源接管、检测集群中的服务、在集群节点转移共享 IP 地址的所有者等等。HeartBeat 功能强大，但是部署和使用相对比较麻烦，与 HeartBeat 相比，Keepalived 主要是通过虚拟路由冗余来实现高可用功能，虽然它没有 HeartBeat 功能强大，但是 Keepalived 部署和使用非常的简单，所有配置只需要一个配置文件即可以完成。Keepalived 实现了轻量级的高可用，一般用于前端高可用，且不需要共享存储，一般常用于两个节点的高可用。而 Heartbeat 用于服务的高可用，且需要共享存储，一般用于多节点的高可用。

  Keepalived 起初是专为 LVS 设计的，用来管理并监控 LVS 集群系统中各个服务节点的状态，后来又加入了可以实现高可用的 VRRP 功能。因此，Keepalived 除了能够管理 LVS 软件外，还可以实现任意两台主机之间，例如 Master 和 Backup 主机之间的故障转移和自动切换，这个主机可以是普通的不能停机的业务服务器，也可以是 LVS 负载均衡、Nginx 反向代理这样的服务器。Keepalived 软件主要是通过 VRRP 协议实现高可用功能的，VRRP 是 Virtual Router Redundancy Protocol（虚拟路由冗余协议）的缩写，VRRP 出现的目的就是为了解决静态路由的单点故障问题的，它能保证当个别节点宕机时，整个网络可以不间断、稳定地运行。所以，Keepalived 一方面具有配置管理 LVS 的功能，同时还具有对 LVS 下面节点进行健康检查的功能，另一方面也可以实现系统网络服务的高可用功能。

大纲

• MySQL 锁的使用
• MySQL 索引的使用
• MySQL 索引的底层数据结构详解
• MySQL 索引的最左前缀原则详解

索引的介绍

索引是一种特殊的文件（InnoDB 数据表上的索引是表空间的一个组成部分），包含了对数据表里所有记录的引用指针。索引分单列索引和组合索引。单列索引，即一个索引只包含单个列，一个表可以有多个单列索引，但这不是组合索引。组合索引，即一个索引包含多个列。创建索引时，需要确保该索引是应用在 SQL 查询语句的条件 (一般是 WHERE、JOIN 子句的条件)。

索引的类型

• FULLTEXT：即为全文索引，目前只有 MyISAM 引擎支持，其可以在 CREATE TABLE，ALTER TABLE，CREATE INDEX 使用，不过目前只有 CHAR、VARCHAR、TEXT 列上可以创建全文索引
• HASH：由于 HASH 的唯一性及类似键值对的形式，很适合作为索引，HASH 索引可以一次定位，不需要像树形索引那样逐层查找，因此具有极高的效率。但是，这种高效是有条件的，即只在 = 和 in 条件下才高效，对于范围查询、排序及组合索引仍然效率不高
• BTREE：一种将索引值按一定的算法，存入一个树形的数据结构中（二叉树），每次查询都是从树的入口 Root 开始，依次遍历 Node，获取 Leaf，这是 MySQL 里默认和最常用的索引类型
• RTREE：在 MySQL 很少使用，仅支持 geometry 数据类型，支持该类型的存储引擎有 MyISAM、BDb、InnoDb、NDb、Archive

Puppeteer 介绍

Puppeteer 是什么

Puppeteer 是一个 NodeJs 库，它提供了一个高级 API 来通过 DevTools 协议控制 Chromium 或 Chrome。相比较 Selenium 或是 PhantomJs，它最大的特点就是完全可以在内存中模拟 DOM 操作，即在 V8 引擎中处理而不打开浏览器，而且关键的是该项目是 Chrome 团队在维护，会拥有更好的兼容性和前景，更多资料可参考以下站点：Puppeteer Github、Puppeteer 中文文档、DevTools Protocol 文档、Chromium 命令行启动参数。

Puppeteer 的功能

• 生成页面的截图和 PDF
• 自动提交表单，进行 UI 测试，键盘输入等
• 捕获网站的时间线跟踪，用来帮助分析性能问题
• 抓取 SPA（单页应用），并生成预渲染内容，即 “SSR”（服务器端渲染）
• 创建一个最新的自动化测试环境，使用最新的 JavaScript 和浏览器功能，直接在最新版本的 Chrome 中运行测试
• 测试浏览器扩展，Chrome / Chromium 扩展当前只能在非无头模式下使用，目前还无法测试扩展弹出窗口或内容脚本

前言

容器化技术的出现标准化了服务的基础设施，统一了应用的打包分发、部署及操作系统相关类库等，解决了测试及生产部署时环境差异的问题，更方便分析排查问题。对运维来说，由于镜像的不可变性，更容易进行服务部署升级及回滚。另外利用诸如 Kubemetes 之类的容器管理平台，更容易实现一键部署、扩容、缩容等操作，更能将微服务架构、DevOps、不可变基础设施的思想落地下来。本文重点讲述 Spring Cloud 如何使用 Docker 实现容器化。

Java 服务 Docker 化

基础镜像选择

操作系统层面，可以选择传统的 Centos、Ubuntu 或者轻量级的 Alpine。其中 Ubuntu 16.04 版本的镜像大小约为 113M，压缩后大约 43M；Centos 7 版本的镜像大小约为 199M，压缩后大约为 73M；而 Alpine 3.7 版本镜像大小约为 4.15M，压缩后约为 2M。关于基础镜像的选择，一个是考虑镜像大小，一个是只提供最小的依赖包。关于第二点，不同的服务应用依赖包是不同的，这里不再展开，只从镜像大小角度考虑的话，Alpine 是首选，镜像小，远程推拉镜像的速度快，更为方便，这里建议釆用 Alpine 镜像作为基础镜像。从 Docker 镜像分层缓存的机制来考虑，如果选择了比较大的基础镜像，DockerFile 编写时可以适当分层，然后集中在几台镜像打包机上处理镜像打包及上传，这样可以充分利用打包机镜像分层缓存的机制，减少上传镜像的耗时。但是对于分布式服务的 Docker 部署，目标服务实例部署的机器比较多而且是随机的，就没办法利用这个机制来加快镜像下载速度。