在介绍InnoDB中的页的时候，很有必要先让大家了解一下InnoDB中的存储结构

从InnoDB存储引擎的逻辑结构看，所有数据都被逻辑地存放在一个空间内，称为表空间(tablespace)，而表空间由段（sengment）、区（extent）、页（page）组成。 在一些文档中extend又称块（block）。

一、表空间（table space）

表空间（Tablespace）是一个逻辑容器，表空间存储的对象是段，在一个表空间中可以有一个或多个段，但是一个段只能属于一个表空间。数据库由一个或多个表空间组成，表空间从管理上可以划分为系统表空间、用户表空间、撤销表空间、临时表空间等。

在 InnoDB 中存在两种表空间的类型：共享表空间和独立表空间。如果是共享表空间就意味着多张表共用一个表空间。如果是独立表空间，就意味着每张表有一个独立的表空间，也就是数据和索引信息都会保存在自己的表空间中。独立的表空间可以在不同的数据库之间进行迁移。可通过命令

mysql > show variables like 'innodb_file_per_table';

查看当前系统启用的表空间类型。目前最新版本已经默认启用独立表空间。

InnoDB把数据保存在表空间内，表空间可以看作是InnoDB存储引擎逻辑结构的最高层。本质上是一个由一个或多个磁盘文件组成的虚拟文件系统。InnoDB用表空间并不只是存储表和索引，还保存了回滚段、双写缓冲区等。

** 二、段（segment）**

段（Segment）由一个或多个区组成，区在文件系统是一个连续分配的空间（在 InnoDB 中是连续的 64 个页），不过在段中不要求区与区之间是相邻的。段是数据库中的分配单位，不同类型的数据库对象以不同的段形式存在。当我们创建数据表、索引的时候，就会相应创建对应的段，比如创建一张表时会创建一个表段，创建一个索引时会创建一个索引段。

三、区（extent）

在 InnoDB 存储引擎中，一个区会分配 64 个连续的页。因为 InnoDB 中的页大小默认是 16KB，所以一个区的大小是 64*16KB=1MB。在任何情况下每个区大小都为1MB，为了保证页的连续性，InnoDB存储引擎每次从磁盘一次申请4-5个区。默认情况下，InnoDB存储引擎的页大小为16KB，即一个区中有64个连续的页。

四、页（Page）

页是InnoDB存储引擎磁盘管理的最小单位，每个页默认16KB；InnoDB存储引擎从1.2.x版本碍事，可以通过参数innodb_page_size将页的大小设置为4K、8K、16K。若设置完成，则所有表中页的大小都为innodb_page_size，不可以再次对其进行修改，除非通过mysqldump导入和导出操作来产生新的库。

innoDB存储引擎中，常见的页类型有：

1. 数据页（B-tree Node)

2. undo页（undo Log Page）

3. 系统页 （System Page）

4. 事物数据页 （Transaction System Page）

5. 插入缓冲位图页（Insert Buffer Bitmap）

6. 插入缓冲空闲列表页（Insert Buffer Free List）

7. 未压缩的二进制大对象页（Uncompressed BLOB Page）

8. 压缩的二进制大对象页 （compressed BLOB Page）

五、行（row）

InnoDB存储引擎是按行进行存放的，每个页存放的行记录也是有硬性定义的，最多允许存放16KB/2-200，即7992行记录。

了解了整体架构，下面我们开始详细对Page来做一些介绍。

先贴一张Page完整的结构图Innodb引擎中的Page完整结构图（注意箭头)

上较的概念实在太多了，为了方便理解，可以按下面的分解一下Page的结构Page结构示意图1

每部分的意义Page结构示意图2

页结构整体上可以分为三大部分，分别为通用部分(文件头、文件尾)、存储记录空间、索引部分。

第一部分通用部分，主要指文件头和文件尾，将页的内容进行封装，通过文件头和文件尾校验的CheckSum方式来确保页的传输是完整的。

在数组中添加 10000 个元素，然后分别对这 10000 个元素进行检索，最后统计检索的时间。

数组Array

import time
# 插入数据，数组
result = []
for i in range(10000):
       result.append(i)
# 检索数据
time_start=time.time()
for i in range(10000):
       temp = result.index(i)
time_end=time.time()
print('检索时间', time_end-time_start)

运行结果：

检索时间为 1.2436728477478027 秒。

Hash哈希

import time
# 插入数据
result = {}
for i in range(1000000):
       result[i] = i
# 检索数据
time_start=time.time()
for i in range(10000):
       temp = result[i]
time_end=time.time()
print('检索时间：',time_end-time_start)

运行结果：

检索时间为 0.0019941329956054688 秒。

你能看到 Hash 方式检索差不多用了 2 毫秒的时间，检索效率提升得非常明显。这是因为 Hash 只需要一步就可以找到对应的取值，算法复杂度为 O(1)，而数组检索数据的算法复杂度为 O(n)。

目前新版本的 kubernetes dashboard （）安装了后，为了安全起见，默认情况下已经不向外提供服务，只能通过 http://localhost:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/ 本机访问。在我们学习过程中，总有些不方便，这时我们可以利用 kubectl proxy 命令来实现。

首先我们看一下此命令的一些想着参数

➜  ~ kubectl proxy -h
To proxy all of the kubernetes api and nothing else, use:

  $ kubectl proxy --api-prefix=/

To proxy only part of the kubernetes api and also some static files:

  $ kubectl proxy --www=/my/files --www-prefix=/static/ --api-prefix=/api/

The above lets you 'curl localhost:8001/api/v1/pods'.

To proxy the entire kubernetes api at a different root, use:

  $ kubectl proxy --api-prefix=/custom/

The above lets you 'curl localhost:8001/custom/api/v1/pods'

Examples:
  # Run a proxy to kubernetes apiserver on port 8011, serving static content from ./local/www/
  kubectl proxy --port=8011 --www=./local/www/

  # Run a proxy to kubernetes apiserver on an arbitrary local port.
  # The chosen port for the server will be output to stdout.
  kubectl proxy --port=0

  # Run a proxy to kubernetes apiserver, changing the api prefix to k8s-api
  # This makes e.g. the pods api available at localhost:8011/k8s-api/v1/pods/
  kubectl proxy --api-prefix=/k8s-api

Options:
      --accept-hosts='^localhost$,^127\.0\.0\.1$,^\[::1\]$': Regular expression for hosts that the proxy should accept.
      --accept-paths='^/.*': Regular expression for paths that the proxy should accept.
      --address='127.0.0.1': The IP address on which to serve on.
      --api-prefix='/': Prefix to serve the proxied API under.
      --disable-filter=false: If true, disable request filtering in the proxy. This is dangerous, and can leave you
vulnerable to XSRF attacks, when used with an accessible port.
  -p, --port=8001: The port on which to run the proxy. Set to 0 to pick a random port.
      --reject-methods='POST,PUT,PATCH': Regular expression for HTTP methods that the proxy should reject.
      --reject-paths='^/api/.*/pods/.*/exec,^/api/.*/pods/.*/attach': Regular expression for paths that the proxy should
reject.
  -u, --unix-socket='': Unix socket on which to run the proxy.
  -w, --www='': Also serve static files from the given directory under the specified prefix.
  -P, --www-prefix='/static/': Prefix to serve static files under, if static file directory is specified.

Usage:
  kubectl proxy [--port=PORT] [--www=static-dir] [--www-prefix=prefix] [--api-prefix=prefix] [options]

Use "kubectl options" for a list of global command-line options (applies to all commands).

这里我们只要关注其中的三个参数就可以了

1. RabbitMq的消息类型(6种)、 消息确认机制

2. RabbitMq中的概念及解释

•  Server(Broker): 接收客户端连接，实现AMQP协议的消息队列和路由功能的进程；
•  Virtual Host：虚拟主机的概念，类似权限控制组，一个Virtual Host里可以有多个Exchange和Queue。
•  Exchange: 交换机，接收生产者发送的消息，并根据Routing Key将消息路由到服务器中的队列Queue。
•  ExchangeType: 交换机类型决定了路由消息行为，RabbitMQ中有四种类型Exchange，分别是fanout、direct、topic 和 headers；
• Queue：消息队列，用于存储还未被消费者消费的消息；
•  Message：由Header和body组成，Header是由生产者添加的各种属性的集合，包括Message是否被持久化、优先级是多少、由哪个Message Queue接收等；body是真正需要发送的数据内容；
• BindingKey：绑定关键字，将一个特定的 Exchange 和一个特定的 Queue 绑定起来。

2.对mq有哪些理解（rabbitmq的模型，rabbitmq的特性，以及幂等问题）。

3.rabbitmq是如何来保证数据不丢失的，持久化机制，消息确认机制等等

4.消息队列的应用场景，rabbitmq是推模式还是拉模式

5. RabbitMQ的exchange有几种？ RabbitMQ的queue有几种？

6.rabbitmq队列可以连多少个消费者。

7.rabbitmq 持久化 是如何保证消消息不丢失的（ 确认机制 ）

8.RabbitMQ如何保证可靠性：

持久化+确认机制；持久化: 消息、Exchange、Queue都会持久化；确认机制，比如消息投递上去后，RabbitMQ会在存到硬盘后返回ACK，根据ACK可以判断是否投递成功，以上保证了消息的可靠。

9. 如何让你设计一个消息队列，如何设计？ 参考 https://www.jianshu.com/p/67c14aebd5b2

首先阅读这篇文章： https://blog.csdn.net/yongche_shi/article/details/51500534

之前其实已经写过一篇关于RabbitMQ持久化的 文章 ，但那篇文章侧重代码层面的写入流程，对于持久化操作何时发生以及什么时候会刷新到磁盘等问题其实都没有搞清楚，这篇文章着重于关注这些问题。

消息什么时候需要持久化？

根据 官方博文 的介绍，RabbitMQ在两种情况下会将消息写入磁盘：

1. 消息本身在 publish 的时候就要求消息写入磁盘；
2. 内存紧张 需要将部分内存中的消息转移到磁盘；

消息什么时候会刷到磁盘？

1. 写入文件前会有一个Buffer，大小为1M（1048576），数据在写入文件时，首先会写入到这个Buffer，如果Buffer已满，则会将Buffer写入到文件（未必刷到磁盘）；
2. 有个固定的刷盘时间：25ms，也就是不管Buffer满不满，每隔25ms，Buffer里的数据及未刷新到磁盘的文件内容必定会刷到磁盘；
3. 每次消息写入后，如果没有后续写入请求，则会直接将已写入的消息刷到磁盘：使用Erlang的receive x after 0来实现，只要进程的信箱里没有消息，则产生一个timeout消息，而timeout会触发刷盘操作。

消息在磁盘文件中的格式

消息保存于$MNESIA/msg_store_persistent/x.rdq文件中，其中x为数字编号，从1开始，每个文件最大为16M（16777216），超过这个大小会生成新的文件，文件编号加1。消息以以下格式存在于文件中：

<<Size:64, MsgId:16/binary, MsgBody>>

MsgId为RabbitMQ通过rabbit_guid:gen()每一个消息生成的GUID，MsgBody会包含消息对应的exchange，routing_keys，消息的内容，消息对应的协议版本，消息内容格式（二进制还是其它）等等。

文件何时删除（垃圾回收）？

PUBLISH消息时写入内容，ack消息时删除内容（更新该文件的有用数据大小），当一个文件的有用数据等于0时，删除该文件。

由于执行消息删除操作时，并不立即对在文件中对消息进行删除，也就是说消息依然在文件中，仅仅是垃圾数据而已。当垃圾数据（已经被删除的消息）比例超过一定阈值后（默认比例GARBAGE_FRACTION = 0.5即50%），并且至少有三个及以上的文件时，rabbitmq触发垃圾回收文件合并操作，以提高磁盘利用率。垃圾回收会先找到符合要求的两个文件（根据#file_summary{}中left，right找逻辑上相邻的两个文件，并且两个文件的有效数据可在一个文件中存储），然后锁定这两个文件，并先对左边文件的有效数据进行整理，再将右边文件的有效数据写入到左边文件，同时更新消息的相关信息（存储的文件，文件中的偏移量），文件的相关信息（文件的有效数据，左边文件，右边文件），最后将右边的文件删除。

我们经常使用 docker exec 命令进入到一个容器里进行一些操作，那么这个命令是如果进入到容器里的呢？想必大家都知道用到了Namespace来实现，但至于底层实现原理是什么，想必都不是特别清楚吧。

我们知道容器的本质其实就是一个进程，每个进程都有一个Pid，至于容器的Pid值可以通过 docker inspect container_id 来查看，我们这里是一个Python应用容器，我们看一下他的 Pid值

docker inspect --format '{{ .State.Pid }}'  4ddf4638572d
25686

而每个进程都有自己的Namespace，你可以通过查看宿主机的 proc 文件，看到这个 25686 进程的所有 Namespace 对应的文件

ls -l  /proc/25686/ns
total 0
lrwxrwxrwx 1 root root 0 Aug 13 14:05 cgroup -> cgroup:[4026531835]
lrwxrwxrwx 1 root root 0 Aug 13 14:05 ipc -> ipc:[4026532278]
lrwxrwxrwx 1 root root 0 Aug 13 14:05 mnt -> mnt:[4026532276]
lrwxrwxrwx 1 root root 0 Aug 13 14:05 net -> net:[4026532281]
lrwxrwxrwx 1 root root 0 Aug 13 14:05 pid -> pid:[4026532279]
lrwxrwxrwx 1 root root 0 Aug 13 14:05 pid_for_children -> pid:[4026532279]
lrwxrwxrwx 1 root root 0 Aug 13 14:05 user -> user:[4026531837]
lrwxrwxrwx 1 root root 0 Aug 13 14:05 uts -> uts:[4026532277]

可以看到，一个进程的每种 Linux Namespace，都在它对应的 /proc/[进程号]/ns 下有一个对应的虚拟文件，并且链接到一个真实的 Namespace 文件上。可以看到这个容器对应的Net Namespace Id为 4026532281

Namespace 的作用是“隔离”，它让应用进程只能看到该Namespace 内的“世界”；而 Cgroups 的作用是“限制”，它给这个“世界”围上了一圈看不见的墙。

命名空间是 Linux 内核一个强大的特性。每个容器都有自己单独的命名空间，运行在其中的应用都像是在独立的操作系统中运行一样。命名空间保证了容器之间彼此互不影响。

在docker中一共有以下几个命名空间，每个Namespace的发挥着不同的作用。

pid 命名空间

不同用户的进程就是通过 pid 命名空间隔离开的，且不同命名空间中可以有相同 pid。在同一个Namespace中只能看到当前命名空间的进程。所有的 LXC 进程在 Docker 中的父进程为Docker进程，每个 LXC 进程具有不同的命名空间。同时由于允许嵌套，因此可以很方便的实现嵌套的 Docker 容器。

net 命名空间

有了 pid 命名空间, 每个命名空间中的 pid 能够相互隔离，但是网络端口还是共享 host 的端口。网络隔离是通过 net 命名空间实现的， 每个 net 命名空间有独立的 网络设备, IP 地址, 路由表, /proc/net 目录。这样每个容器的网络就能隔离开来。Docker 默认采用 veth 的方式，将容器中的虚拟网卡同 host 上的一 个Docker 网桥 docker0 连接在一起。

ipc 命名空间

容器中进程交互还是采用了 Linux 常见的进程间交互方法(interprocess communication – IPC), 包括信号量、消息队列和共享内存等。然而同 VM 不同的是，容器的进程间交互实际上还是 host 上具有相同 pid 命名空间中的进程间交互，因此需要在 IPC 资源申请时加入命名空间信息，每个 IPC 资源有一个唯一的 32 位 id。

背景

在日常工作中，我们一般会将容器进行精简，将其大小压缩到最小，以此来提高容器部署效率，参考小米云技术 – Docker最佳实践：5个方法精简镜像。但有一个比较尴尬的问题就是对容器排障，由于容器里没有了我们日常工作中用到许多排障命令，如top、ps、netstat等，所以想排除故障的话，常用的做法是安装对应的命令，如果容器过多的话，再这样搞就有些麻烦了，特别是在一些安装包源速度很慢的情况。

解决方案

今天发现一篇文章（简化 Pod 故障诊断：kubectl-debug 介绍）介绍针对此类问题的解决方案的，这里介绍的是一个叫做 kubectl-debug 的命令，由国内知名的PingCAP公司出品的，主要用在k8s环境中的。我们知道容器里主要两大技术，一个是用cgroup来实现容器资源的限制，一个是用Namespace来实现容器的资源隔离的）。（kubectl-debug 命令是基于一个工具包（） 来实现的，其原理是利用将一个工具包容器添加到目标容器所在的Pod里，实现和目标容器的Network Namespace一致，从而达到对新旧容器进程的相互可见性，这样我们就可以直接在目标容器里操作这些命令。所以在平时开发环境中，可以很方便的利用此原理直接使用这个工具包来实现对容器的排障。

在 Kubernetes 项目中，这些容器则会被划分为一个“Pod”，Pod 里的容器共享同一个 Network Namespace、同一组数据卷，从而达到高效率交换信息的目的。这些容器应用就可以通过 Localhost 通信，通过本地磁盘目录交换文件。

netshoot包含一组强大的工具，如图所示

工具包清单

apache2-utils
bash
bind-tools
bird
bridge-utils
busybox-extras
calicoctl
conntrack-tools
ctop
curl
dhcping
drill
ethtool
file
fping
iftop
iperf
iproute2
iptables
iptraf-ng
iputils
ipvsadm
libc6-compat
liboping
mtr
net-snmp-tools
netcat-openbsd
netgen
nftables
ngrep
nmap
nmap-nping
openssl
py-crypto
py2-virtualenv
python2
scapy
socat
strace
tcpdump
tcptraceroute
util-linux
vim

看了上图不得不说几乎包含了所有的调度命令。

使用也很方便，只需要一条命令即可

$ docker run -it --net container: nicolaka/netshoot

参数 --net 是 --network 的缩写，有四种值，用法参考： https://docs.docker.com/engine/reference/run/#network-settings

最近搭建了es集群的时候，现在需要测试添加一个新的数据节点，项目是使用docker-compose命令来搭建的。

以下基于最新版本 es7.2.0进行, 配置文件目录为 es, 所以docker 在创建网络的时候，网络名称会以 es_ 前缀开始，如本例中我们在docker-composer.yaml文件中指定了网络名称为esnet,但docker生成的实例名称为 es_esnet，至于网络相关的信息可以通过 docker network --help 查看。

搭建es集群

// docker-compose.yaml 集群配置文件

version: '2.2'
services:
  es01:
    image: docker.elastic.co/elasticsearch/elasticsearch:7.2.0
    container_name: es01
    environment:
      - node.name=es01
      - node.master=true
      - node.data=true
      - discovery.seed_hosts=es02
      - cluster.initial_master_nodes=es01,es02
      - cluster.name=docker-cluster
      - bootstrap.memory_lock=true
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
    ulimits:
      memlock:
        soft: -1
        hard: -1
    volumes:
      - esdata01:/usr/share/elasticsearch/data
    ports:
      - 9200:9200
    networks:
      - esnet
  es02:
    image: docker.elastic.co/elasticsearch/elasticsearch:7.2.0
    container_name: es02
    environment:
      - node.name=es02
      - discovery.seed_hosts=es01
      - cluster.initial_master_nodes=es01,es02
      - cluster.name=docker-cluster
      - bootstrap.memory_lock=true
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
    ulimits:
      memlock:
        soft: -1
        hard: -1
    volumes:
      - esdata02:/usr/share/elasticsearch/data
    networks:
      - esnet
  es03:
    image: docker.elastic.co/elasticsearch/elasticsearch:7.2.0
    container_name: es03
    environment:
      - node.name=es03
      - discovery.seed_hosts=es01
      - cluster.initial_master_nodes=es01,es02
      - cluster.name=docker-cluster
      - bootstrap.memory_lock=true
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
    ulimits:
      memlock:
        soft: -1
        hard: -1
    volumes:
      - esdata03:/usr/share/elasticsearch/data
    networks:
      - esnet
volumes:
  esdata01:
    driver: local
  esdata02:
    driver: local
  esdata03:
    driver: local

networks:
  esnet:

集群配置了3个master节点，并同时作为数据节点使用，当节点未指定 node.master和node.data的时候，默认值为 true 。执行命令

先看一个结构体

// 写法一
type T1 struct {
	a int8
	b int64
	c int16
}

// 写法二
type T2 struct {
	a int8
	c int16
	b int64
}

对于这两个结构体，都有a、b、c三个定义完全一样的字段，只是在定义结构体的时候字段顺序不一样而已，那么两种写法有什么影响吗？

对于新手来说，感觉着没有什么区别的，只是一个书写顺序不同而已，但对于go编译器来说，则有着很大的区别，特别是在不同架构上(32位/64位）的编译器，在一定程度上对内存的使用大小和执行效率有着一定的不同。这里的主要知识点就是golang语言中的内存对齐概念（alignment guarantee），

类型的尺寸和结构体字节填充（structure padding）

Go白皮书只对以下种类的类型的尺寸进行了明确规定。

类型种类                  尺寸（字节数）
------                   ------
byte, uint8, int8        1
uint16, int16            2
uint32, int32, float32   4
uint64, int64            8
float64, complex64       8
complex128               16
uint, int                取决于编译器实现。通常在
                         32位架构上为4，在64位
                         架构上为8。
uintptr                  取决于编译器实现。但必须
                         能够存下任一个内存地址。

Go白皮书没有对其它种类的类型的尺寸最初明确规定。 请阅读值复制成本一文来获取标准编译器使用的各种其它类型的尺寸。

标准编译器（和gccgo编译器）将确保一个类型的尺寸为此类型的对齐保证的倍数。

为了满足上一节中规定的地址对齐保证要求，Go编译器可能会在结构体的相邻字段之间填充一些字节。 这使得一个结构体类型的尺寸并非等于它的各个字段类型尺寸的简单相加之和。

下面是一个展示了一些字节是如何填充到一个结构体中的例子。 首先，从上面的描述中，我们已得知（对于标准编译器来说）：

• 内置类型int8的对齐保证和尺寸均为1个字节； 内置类型int16的对齐保证和尺寸均为2个字节； 内置类型int64的尺寸为8个字节，但它的对齐保证在32位架构上为4个字节，在64位架构上为8个字节。
• 下例中的类型T1和T2的对齐保证均为它们的各个字段的最大对齐保证。 所以它们的对齐保证和内置类型int64相同，即在32位架构上为4个字节，在64位架构上为8个字节。
• 类型T1和T2尺寸需为它们的对齐保证的倍数，即在32位架构上为4n个字节，在64位架构上为8n个字节。

type T1 struct {
	a int8

	// 在64位架构上，为了让下一个字段b的地址为8字节对齐，
	// 需在在字段a这里填充7个字节。在32位架构上，为了让
	// 字段b的地址为4字节对齐，需在这里填充3个字节。

	b int64
	c int16

	// 为了让类型T1的尺寸为T1的对齐保证的倍数，
	// 在64位架构上需在这里填充6个字节，在32架构
	// 上需在这里填充2个字节。
}
// 类型T1的尺寸在64位架构上位24个字节（1+7+8+2+6），
// 在32位架构上为16个字节（1+3+8+2+2）。
// 以保存每个字段都是8（64位架构）或者4(32位架构)的的整数倍

type T2 struct {
	a int8

	// 为了让下一个字段c的地址为2字节对齐，
	// 需在字段a这里填充1个字节。

	c int16

	// 在64位架构上，为了让下一个字段b的地址为8字节对齐，
	// 需在字段c这里填充4个字节。在32位架构上，不需填充
	// 字节即可保证字段b的地址为4字节对齐的。

	b int64
}
// 类型T2的尺寸在64位架构上位16个字节（1+1+2+4+8），
// 在32位架构上为12个字节（1+1+2+8）。

从这个例子可以看出，尽管类型T1和T2拥有相同的字段集，但是它们的尺寸并不相等。**每个字段的大小都要受下一个字段大小的影响，以方便下个字段对齐。**所以建议在开发中，字段占用空间小的放在前面。T1的内存对齐T2的内存对齐

官方网站：，中文: http://kafka.apachecn.org/

注意它和其它消息系统(消息队列)在定义上的区别，以便更好的理解它的应用场景。Apache Kafka 是一款分布式流处理平台（Distributed Streaming Platform）。

术语

消息：Record。消息实体，是通信的基本单位。 主题：Topic。主题是承载消息的逻辑容器，在实际使用中多用来区分具体的业务。 分区：Partition。一个有序不变的消息序列。每个主题Topic下可以有多个分区。 消息位移：Offset。表示分区中每条消息的位置信息，是一个单调递增且不变的值。 缓存代理，Broker。Kafka集群中的一台或多台服务器统称broker。 副本：Replica。Kafka 中同一条消息能够被拷贝到多个地方以提供数据冗余，这些地方就是所谓的副本。副本还分为领导者副本和追随者副本，各自有不同的角色划分。副本是在分区层级下的，即每个分区可配置多个副本实现高可用。 生产者：Producer。向主题发布新消息的应用程序。 消费者：Consumer。从主题订阅新消息的应用程序。 消费者位移：Consumer Offset。表示消费者消费进度，每个消费者都有自己的消费者位移。 消费者组：Consumer Group。_多个消费者实例共同组成的一个组，同时消费多个分区_以实现高吞吐。 重平衡：Rebalance。消费者组内某个消费者实例挂掉后，其他消费者实例自动重新分配订阅主题分区的过程。Rebalance 是 Kafka 消费者端实现高可用的重要手段。

为什么kafka比其它消息系统有着很高的吞吐量? “零拷贝“:

rabbitMQ、activeMQ、zeroMQ、Kafka、Redis 比较: https://www.cnblogs.com/valor-xh/p/6348009.html

为了防止ES集群中单点问题，一般都需要对集群节点做高可用性，当发生单点问题时，也可以向外正常提供服务。这里主要记录一下节点的加入、离开和主节点选举。

集群安装教程请参考：

节点角色

集群是由多个节点组成的，每个节点都扮演着不同的角色，一般常用的有 Master、Data 和 client。节点角色介绍：

节点角色配置参数： node.master: true node.data: false node.ingest: false

在一个集群中，可以通过 查看到每个节点在集群中扮演的角色，一个节点可同时拥有多个角色，如值MDI，同时也是每个节点的默认值，其中的 Ingest 节点也称作预处理节点，不过在生产环境中一般将master 和 data节点分开的。所有节点默认都是支持 Ingest 操作的。节点组合参考：

新节点的加入

随着数量大的增加，有时候我们不得进行机器的扩容，这时间就需要加入一些新的机器节点，用来提高访问速度。

当一个新节点加入的时候，它通过读取 discovery.zen.ping.unicast.hosts 配置的节点获取集群状态，然后找到 master 节点，并向其发送一个join request(discovery.zen.join_timeout)。主节点接收到请求后，同步集群状态到新节点。

节点离开

这里指非 mastr 节点。 当master主节点定期ping（ping_interval 默认为1s）一个节点出现3次ping不通的情况时（ping_timeout 默认为30s），主节点会认为该节点已宕机，将该节点踢出集群。

主节点的选举

我们知道集群中master节点角色的重要性，如果此节点出现问题的话，服务基本处于不可用状态了，所以保证master节点的高可用性至关重要。

当主节点发生故障时，集群中的其他节点将会ping当前的 master eligible 节点，并从中选出一个新的主节点。 节点可以通过设置 node.master=true 来设置自己的角色为主节点。 通过配置discovery.zen.minimum_master_nodes防止集群出现脑裂。该配置通过检查集群中 master eligible 的个数来判断是否选举出一个主节点。其个数最好设置为**(number_master eligible/2)+1**，防止当主节点出问题时，一个集群分裂为两个集群。 具有最小编号的active master eligible node将会被选举为master节点。参考：

脑裂的概念：

如果你有2个Master候选节点，并设置最小Master节点数为1，当网络抖动或偶然断开时，2个Master都会认为另一个Master挂掉了，他们都被选举为主Master，则此时集群中存在两个主Master，即物理上1个集群变成了逻辑上的2个集群，而当其中一个Master再次挂掉时，即便它恢复后回到了原有的集群，在它作为主Master期间写入的数据都会丢失，因为它上面维护了Index信息。类似我们平时的投票选举一下，10个人如果赞成与返对的比例为5:5就不太好了，所以必须保证双方的票数无法完全一样才可以。

为了防止脑裂，常常设置参数为discovery.zen.minimum_master_nodes=N/2+1，其中N为集群中Master节点的个数。建议集群中Master节点的个数为奇数个，如3个或者5个。

在版本 6 和更早的版本中，还有一些其他以 discovery.zen.* 开头的选项，允许你配置 Zen Discovery 的行为。其中一些设置不再有效，已被删除。其他的已经改名。如果一个参数已经被改名，那么它的旧名称在版本 7 中就被弃用，你需要调整配置来使用新名称。

新的集群协调子系统包括一个新的故障检测机制。这意味着 discovery.zen.fd.* 开头的 Zen Discovery 错误检测设置不再有效。大多数用户应该在版本 7 或更高版本中使用默认的故障检测配置，如果需要进行任何更改，可以使用cluster.fault_detection.*

最近要搭建es集群，由于刚接触es不久，直接使用的docker构建，发现当用两个容器搭建好集群时，再添加新的es容器节点时，总是出现其它容器被kill的现象，查看容器日志未发现任何错误信息，导致一段时间非常的迷茫。

起始认为是配置不当引起了，于是一直在配置这方面找问题，网上的有些教程是直接在物理机器上或者虚拟机上进行部署，而自己的环境是docker, 通过 docker-compose 来部署的，环境有些差异。

有网友提醒有可能是由 OOM 引起的问题，因为代码是137, 使用命令 “docker inspect 容器ID” 查看了一下容器, status列显示”OOMKilled": false” ，所以从这里查看的话，并非是 OOM 引起的，起初个人分析容器的启动过程，是在启动一个容器时，dockerd应该先检查内存是否足够，如果不足够的话，则启动新窗口失败才对，而不是先将已存在的窗口killed，再去启动新容器，所以仍将OOM的原因排除掉了。

后来发现一篇文章 介绍到这个和 docker for mac 分配的内存大小有关系，试着将给 docker 分配的内存调整为4G，重新 docker-compose up 竟然解决了。

由此可见docker软件对容器启动时处理逻辑与自己分析的还是有些差异的。 可惜浪费了好几天的时间，很值的好好反思一下！

总结一下，还是基础不牢固，解决思路，分析问题不清晰，一直在配置这一块的周旋，虽然首次怀疑是OOM引起的，但在容器日志里并没有OOM的日志信息，再加上集群编排时有“ – “ES_JAVA_OPTS=-Xms512m -Xmx512m” 配置项,给es分配512M的内存大小，也忽略掉物理机器给docker分配内存大小这个因素了，所以直接将OOM的原因排除了，而未想到OOM发生时，并不保证一定在容器日志里记录的。

由于要安装一个docker服务，对外提供端口用的是9000, 和php-fpm的监听端口冲突，所以需要先停止一下php-fpm服务。

多次执行

sudo killall php-fpm

发现过一会php-fpm会自动启动，就算一个一个的进程kill -9 也一样的效果。经过分析这个应该是和php-fpm配置文件 ~/Library/LaunchAgents/[email protected] 有关。

我们知道 ~/Library/LaunchAgents 针对当前用户的启动项目录，针对这个项目里的一些配置服务有一个 launchctl 命令可以操作，其中有几个命令我们需要知道他的意思

launchctl load 启动plist运行
launchctl unload  卸载
launchctl list 查看所有启动任务

默认当用户登录后，mac系统会对当前目录 ~/Library/LaunchAgents 里的每个配置服务文件自动执行launchctl load 命令。如果我们想停止一个服务的话，则需要执行 launchctl unload 命令即可。

`$ LaunchAgents launchctl list | grep php

66054 0 [email protected]

$ LaunchAgents launchctl unload ~/Library/LaunchAgents/[email protected]

$ LaunchAgents launchctl list | grep php`

然后再用ps 查看确认php-fpm已停止。

新特新解读 | MySQL 8.0 对 count(*)的优化 新特性解读 | MySQL 8.0 正则替换 新特性解读 | MySQL 8.0 资源组 新特性解读 | MySQL 8.0 Temptable 引擎介绍

新特性解读 | MySQL 8.0 窗口函数详解

新特性解读 | MySQL 8.0 json到表的转换

新特性解读 | MySQL 8.0.16 在组复制中启用成员自动重新加入

新特性解读 | MySQL 8.0 直方图

新特性解读 | MySQL 8.0 索引特性1-函数索引

新特性解读 | MySQL 8.0 索引特性2-索引跳跃扫描

新特性解读 | MySQL 8.0 索引特性3 -倒序索引

新特性解读 | MySQL 8.0 索引特性4-不可见索引

新特性解读 | MySQL 8.0.16 组复制通讯协议的设置

新特性解读 | MySQL 8.0.16 组复制新功能：消息碎片化