大纲

• 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 部署，目标服务实例部署的机器比较多而且是随机的，就没办法利用这个机制来加快镜像下载速度。

前言

很多优秀的程序员和技术人员喜欢写技术文章和技术博客，通过这样的方式分享传播知识和经验，扩大自己的知名度和影响力，吸引粉丝关注，甚至有些技术博主还通过写文章来获取广告收入，还通过这种方法获得了出版书的机会以及工作机会。因此，写技术文章是一件非常值得投入的事情，帮助了自己，也让大众受益。但是，写技术文章通常也很耗时，特别是一些优质文章，不仅需要旁征博引、构思文章结构、照顾读者受众，还需要做很多前期工作，例如搭建环境、写 Demo 代码、测试代码等等。一篇优质技术文章通常需要 3-6 个小时来完成，可花了很多时间来写文章，最终发布出来的文章得不到很多人的关注是一件相当令人沮丧的事情。因此，优质文章值得获取关注和传播，让更多的技术工作者通过阅读文章获取知识获益。每个技术博主都有自己喜欢的技术媒体平台，例如简书、知乎、掘金、CSDN、微信公众号等等。很多技术博主也喜欢将文章发布在不同的平台上，寻求最大的关注度，同时也防止自己辛辛苦苦写的文章被别人复制粘贴盗版过去。然而，在多个平台上发文是一件麻烦的事情：博主需要同时登陆多个媒体平台，将自己的文章复制一个一个粘贴过去；更麻烦的是，有些平台只支持 Markdown，有些平台只支持富文本，博主需要在这两者之间来回转换，这增加了工作量。一文多发平台 ArtiPub 就解决了这样的问题，下面将介绍开源的一文多发平台 ArtiPub。

ArtiPub 简介

ArtiPub（Article Publisher 的简称，意为” 文章发布者”）是一款开源的一文多发平台，可以帮助文章作者将编写好的文章自动发布到简书、掘金、SegmentFault、CSDN、知乎、开源中国等技术媒体平台，传播优质知识，获取最大的曝光度。ArtiPub 安装简单，提供了多种安装方式（Docker、NPM、源码），可以一键安装使用，安装一般只要 5 分钟。ArtiPub 目前支持文章编辑、文章发布、数据统计的功能，后期会加入存量文章导入、数据分析的功能。此外，ArtiPub 日后还会接入更多媒体渠道，真正做到让文章随处可阅。用户使用 ArtiPub 也很简单，只需要在浏览器上打开 ArtiPub 的 Web 界面，将文章以 Markdown 的形式输入到编辑器，然后点击一键发布，等待不到 1 分钟，文章就自动同步到各大技术媒体平台了。此外，文章的阅读、点赞、评论数据还将周期性的被同步回来，让作者可以近实时看到文章的传播情况。

前言

在分布式系统、微服务、网络请求、消息队列以及爬虫系统中，重试（Retry）机制是一种非常常见的容错手段。但如果失败后立即再次重试，可能会导致：

• 服务端压力进一步增大
• 多个客户端同时重试，引发「惊群效应」
• 网络拥塞进一步恶化
• 限流接口持续返回失败

因此，大多数系统都会采用 “退避（Backoff）算法”，即每次重试之前等待一段时间，并且随着重试次数增加，等待时间越来越长。目前最常见的两种退避算法分别是：

• 递增退避（Linear Backoff）
• 指数退避（Exponential Backoff）

大纲

• Redis 缓存与分布式锁
• Redisson 分布式锁使用教程
• Redis 分布式锁中 Lua 脚本的使用
• Java 基于 MySQL 实现分布式锁
• 基于 ZooKeeper 原生 API 实现分布式锁

前言

MySQL 实现分布式锁，常见的方案有以下几种：

• 基于唯一索引（INSERT 操作）实现
• 基于排他锁（SELECT FOR UPDATE）实现
• 基于乐观锁（CAS）实现

大纲

• Sleuth 入门教程 - 基础篇
• Sleuth 入门教程 - 中级篇
• Micrometer 入门教程 - 基础篇

大纲

• Sleuth 入门教程 - 基础篇
• Sleuth 入门教程 - 中级篇
• Micrometer 入门教程 - 基础篇

前言

在传统的 SOA 架构体系中，系统调用层级不多，调用关系也不复杂，一旦出现问题，根据异常信息可以很快定位到问题模块并进行排查。但是在微服务的世界里，实例数目成百上千，实例之间的调用关系几乎是网状结构，靠人力去监控和排查问题已经不太可能。这种情况下，一个完善的调用链路监控框架对于运维和开发来说，都是不可或缺的。

前言

• Consul 官方安装教程
• Consul Docker 官方使用教程

拉取 Consul 镜像

1
2
3
4
5

# 拉取最新版本的镜像
# docker pull consul:latest

# 或者拉取指定版本的镜像
# docker pull consul:1.7.3

ZooKeeper 的应用场景

命名服务

ZooKeeper 可以用来实现分布式命名服务。命名服务是指通过指定的名字来获取资源或者服务的地址，利用 ZooKeeper 创建一个全局的路径，这个路径就可以作为一个名字，指向集群中的节点、提供服务的地址、或者一个远程的对象等等。统一命名服务的命名结构如下图所示：

• （1）在分布式环境下，经常需要对应用 / 服务进行统一命名，以便于识别不同的服务。
  • 类似于域名与 IP 之间对应关系，IP 不容易记住，而域名容易记住。
  • 通过名称来获取资源服务的地址、服务提供者等信息。
• （2）按照层次结构组织应用 / 服务的名称。
  • 可将服务名称以及地址信息写到 ZooKeeper 上，客户端通过 ZooKeeper 获取可用服务列表。