本文将会从实际应用场景出发，介绍一致性哈希算法（Consistent Hashing）及其在分布式系统中的应用。首先本文会描述一个在日常开发中经常会遇到的问题场景，借此介绍一致性哈希算法以及这个算法如何解决此问题；接下来会对这个算法进行相对详细的描述，并讨论一些如虚拟节点等与此算法应用相关的话题。
假设我们有一个网站，最近发现随着流量增加，服务器压力越来越大，之前直接读写数据库的方式不太给力了，于是我们想引入Memcached作为缓存机制。现在我们一共有三台机器可以作为Memcached服务器，如下图所示。
很显然，最简单的策略是将每一次Memcached请求随机发送到一台Memcached服务器，但是这种策略可能会带来两个问题：一是同一份数据可能被存在不同的机器上而造成数据冗余，二是有可能某数据已经被缓存但是访问却没有命中，因为无法保证对相同key的所有访问都被发送到相同的服务器。因此，随机策略无论是时间效率还是空间效率都非常不好。
Continue reading在Redis中存储数据时，经常使用string和hash这两种类型，至于这两者有什么不同，底层实现有何区别，推荐参考：https://segmentfault.com/a/1190000019552836
在介绍InnoDB中的页的时候，很有必要先让大家了解一下InnoDB中的存储结构
从InnoDB存储引擎的逻辑结构看，所有数据都被逻辑地存放在一个空间内，称为表空间(tablespace)，而表空间由段（sengment）、区（extent）、页（page）组成。 在一些文档中extend又称块（block）。
一、表空间（table space）
表空间（Tablespace）是一个逻辑容器，表空间存储的对象是段，在一个表空间中可以有一个或多个段，但是一个段只能属于一个表空间。数据库由一个或多个表空间组成，表空间从管理上可以划分为系统表空间、用户表空间、撤销表空间、临时表空间等。
在 InnoDB 中存在两种表空间的类型：共享表空间和独立表空间。如果是共享表空间就意味着多张表共用一个表空间。如果是独立表空间，就意味着每张表有一个独立的表空间，也就是数据和索引信息都会保存在自己的表空间中。独立的表空间可以在不同的数据库之间进行迁移。可通过命令
Continue reading在数组中添加 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 （https://github.com/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).
这里我们只要关注其中的三个参数就可以了
--accept-hosts='^localhost$,^127\.0\.0\.1$,^\[::1\]$': Regular expression for hosts that the proxy should accept. --address='127.0.0.1': The IP address on which to serve on. --port=8001: The port on which to run the proxy. Set to 0 to pick a random port.
–accept-hosts 表示哪些客户端访问,默认只允许 localhost 和 127.0.0.1
–address 表示本机绑定的ip地址，如果值为0.0.0.0 则表示不限，通过任何ip都可以访问.
a
–port 表示代理的接口，如果值为0的话，则随机一个端口
这里为了外网访问，可设置如下
nohup kubectl proxy --address='0.0.0.0' --port=8888 --accept-hosts='^*$'
这时就实现了通过外网访问
http://192.168.0.107:8888/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/
其实说白了，只要你把基本的命令参数搞清楚了，实现起来就方便了，就看你基础牢不牢。
2. RabbitMq中的概念及解释
2. 对mq有哪些理解（rabbitmq的模型，rabbitmq的特性，以及幂等问题），面试官问幂等如何解决（回答把token存在redis里头，然后检测是否存在token），面试官追问，难道不会有并发存token的情况吗（回答redis是单线程的，会有顺序，set同一个值成功会返回操作的行数）。
3.rabbitmq交换机有哪几种模式，他是如何来保证数据不丢失的，持久化机制，消息确认机制等等
4.消息队列的应用场景，rabbitmq是推模式还是拉模式
5.RabbitMQ的exchange有几种？RabbitMQ的queue有几种？
6.rabbitmq队列可以连多少个消费者。
7.rabbitmq 交换机 持久化 确认机制 消息丢失处理
8.RabbitMQ如何保证可靠性：持久化+确认机制，持久化:消息、Exchange、Queue都会持久化，确认机制，比如消息投递上去后，RabbitMQ会在存到硬盘后返回ACK，根据ACK可以判断是否投递成功，以上保证了消息的可靠。
9. 如何让你设计一个消息队列，如何设计？
首先阅读这篇文章：https://blog.csdn.net/yongche_shi/article/details/51500534
之前其实已经写过一篇关于RabbitMQ持久化的 文章 ，但那篇文章侧重代码层面的写入流程，对于持久化操作何时发生以及什么时候会刷新到磁盘等问题其实都没有搞清楚，这篇文章着重于关注这些问题。
根据 官方博文 的介绍，RabbitMQ在两种情况下会将消息写入磁盘：
消息保存于$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
进入容器的命令为
$ docker exec -it 4ddf4638572d /bin/sh
对于我们执行的 /bin/sh 命令，进程PID在宿主机器上是可以看到的。
$ ps aux | grep /bin/bash root 28499 0.0 0.0 19944 3612 pts/0 S 14:15 0:00 /bin/bash
实际上，Linux Namespace 创建的隔离空间虽然看不见摸不着，但一个进程的 Namespace 信息在宿主机上是确确实实存在的，并且是以一个文件的方式存在。
我们现在看一下这两个进程对应的Namespace信息
ls -l /proc/28499/ns/net lrwxrwxrwx 1 root root 0 Aug 13 14:18 /proc/28499/ns/net -> net:[4026532281] $ ls -l /proc/25686/ns/net lrwxrwxrwx 1 root root 0 Aug 13 14:05 /proc/25686/ns/net -> net:[4026532281]
在 /proc/[PID]/ns/net 目录下，这个 PID=28499 进程，与我们前面的 Docker 容器进程（PID=25686）指向的 Network Namespace 文件完全一样。这说明这两个进程，共享了这个名叫 net:[4026532281] 的 Network Namespace。
此外，Docker 还专门提供了一个参数，可以让你启动一个容器并“加入”到另一个容器的 Network Namespace 里，这个参数就是 -net，比如:
docker run -it --net container:4ddf4638572d busybox ifconfig
这样，我们新启动的这个容器，就会直接加入到 ID=4ddf4638572d 的容器，也就是我们前面的创建的 Python 应用容器（PID=25686）的 Network Namespace 中。参考文章：docker容器调试利器nicolaka/netshoot
而如果我指定–net=host，就意味着这个容器不会为进程启用 Network Namespace。这就意味着，这个容器拆除了 Network Namespace 的“隔离墙”，所以，它会和宿主机上的其他普通进程一样，直接共享宿主机的网络栈。这就为容器直接操作和使用宿主机网络提供了一个渠道。
现在我们知道了 docker exec 的原理，那么对于 docker run -v /home:/test … 是如何实际目录挂载的呢？
Namespace 的作用是“隔离”，它让应用进程只能看到该Namespace 内的“世界”；而 Cgroups 的作用是“限制”，它给这个“世界”围上了一圈看不见的墙。
命名空间是 Linux 内核一个强大的特性。每个容器都有自己单独的命名空间，运行在其中的应用都像是在独立的操作系统中运行一样。命名空间保证了容器之间彼此互不影响。
在docker中一共有以下几个命名空间，每个Namespace的发挥着不同的作用。
不同用户的进程就是通过 pid 命名空间隔离开的，且不同命名空间中可以有相同 pid。在同一个Namespace中只能看到当前命名空间的进程。所有的 LXC 进程在 Docker 中的父进程为Docker进程，每个 LXC 进程具有不同的命名空间。同时由于允许嵌套，因此可以很方便的实现嵌套的 Docker 容器。
有了 pid 命名空间, 每个命名空间中的 pid 能够相互隔离，但是网络端口还是共享 host 的端口。网络隔离是通过 net 命名空间实现的， 每个 net 命名空间有独立的 网络设备, IP 地址, 路由表, /proc/net 目录。这样每个容器的网络就能隔离开来。Docker 默认采用 veth 的方式，将容器中的虚拟网卡同 host 上的一 个Docker 网桥 docker0 连接在一起。
容器中进程交互还是采用了 Linux 常见的进程间交互方法(interprocess communication – IPC), 包括信号量、消息队列和共享内存等。然而同 VM 不同的是，容器的进程间交互实际上还是 host 上具有相同 pid 命名空间中的进程间交互，因此需要在 IPC 资源申请时加入命名空间信息，每个 IPC 资源有一个唯一的 32 位 id。
类似 chroot，将一个进程放到一个特定的目录执行。mnt 命名空间允许不同命名空间的进程看到的文件结构不同，这样每个命名空间 中的进程所看到的文件目录就被隔离开了。同 chroot 不同，每个命名空间中的容器在 /proc/mounts 的信息只包含所在命名空间的 mount point。
UTS(“UNIX Time-sharing System”) 命名空间允许每个容器拥有独立的 hostname 和 domain name, 使其在网络上可以被视作一个独立的节点而非 主机上的一个进程。
每个容器可以有不同的用户和组 id, 也就是说可以在容器内用容器内部的用户执行程序而非主机上的用户。
*注：更多关于 Linux 上命名空间的信息，请阅读 这篇文章。
…
在日常工作中，我们一般会将容器进行精简，将其大小压缩到最小，以此来提高容器部署效率，参考小米云技术 – Docker最佳实践：5个方法精简镜像。但有一个比较尴尬的问题就是对容器排障，由于容器里没有了我们日常工作中用到许多排障命令，如top、ps、netstat等，所以想排除故障的话，常用的做法是安装对应的命令，如果容器过多的话，再这样搞就有些麻烦了，特别是在一些安装包源速度很慢的情况。
今天发现一篇文章（简化 Pod 故障诊断：kubectl-debug 介绍）介绍针对此类问题的解决方案的，这里介绍的是一个叫做 kubectl-debug 的命令，主要由国内知名的PingCAP公司出品的，主要是用在k8s环境中的。我们知道容器里主要两大技术，一个是用cgroup来实现容器资源的限制，一个是用Namespace来实现容器的资源隔离的）。（kubectl-debug 命令是基于一个工具包（https://github.com/nicolaka/netshoot） 来实现的，其原理是利用将一个工具包容器添加到目标容器所在的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:<container_name> nicolaka/netshoot
参数 --net 是 --network 的缩写，有四种值，用法参考：https://docs.docker.com/engine/reference/run/#network-settings
执行命令后，会自动创建一个镜像为 nicolaka/netshoot 的容器，
Docker 提供的这个 --net 参数，可以让你启动一个容器并“加入”到另一个容器的 Network Namespace 里，并共享一个网络栈，即Namespace 和目标容器的一样，这样就实现了合并命令工具到目标容器 里。如果执行命令 hostname 命令的话，结果显示的是目标 “容器ID” 。此时就可以在容器里执行常用的一些ps、 top、netstat、iftop 之类的命令。
➜ ~ docker run -it --rm --network container:mysql80 nicolaka/netshoot
dP dP dP
88 88 88
88d888b. .d8888b. d8888P .d8888b. 88d888b. .d8888b. .d8888b. d8888P
88' `88 88ooood8 88 Y8ooooo. 88' `88 88' `88 88' `88 88
88 88 88. ... 88 88 88 88 88. .88 88. .88 88
dP dP `88888P' dP `88888P' dP dP `88888P' `88888P' dP
Welcome to Netshoot! (github.com/nicolaka/netshoot)
root @ /
[1] 🐳 → ls
bin dev etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var
root @ /
[2] 🐳 → hostname
7ff422d3f75d
root @ /
[3] 🐳 → ps
PID USER TIME COMMAND
1 root 0:00 /bin/bash -l
15 root 0:00 ps
root @ /
[4] 🐳 → netstat -an | grep LISTEN
tcp 0 0 :::33060 :::* LISTEN
tcp 0 0 :::3306 :::* LISTEN
unix 2 [ ACC ] STREAM LISTENING 18007 /var/run/mysqld/mysqld.sock
unix 2 [ ACC ] STREAM LISTENING 19694 /var/run/mysqld/mysqlx.sock
root @ /
[5] 🐳 →
上面我们添加了--rm 参数，主要是为了使用完毕后，及时清除临时容器相关的资源。这里我们将临时容器的Namespace和mysql80 容器相同
mysql80容器的ID为 7ff422d3f75d，即hostname 命令的输出结果。
现在我们先不要从这个容器里退出，再开启一个新终端进入到临时容器(bb47226c955e)里
➜ ~ docker exec -it bb4 /bin/bash
bash-5.0# hostname
7ff422d3f75d
bash-5.0# ps
PID USER TIME COMMAND
1 root 0:00 /bin/bash -l
22 root 0:00 /bin/bash
28 root 0:00 ps
bash-5.0# netstat -an | grep LISTEN
tcp 0 0 :::33060 :::* LISTEN
tcp 0 0 :::3306 :::* LISTEN
unix 2 [ ACC ] STREAM LISTENING 18007 /var/run/mysqld/mysqld.sock
unix 2 [ ACC ] STREAM LISTENING 19694 /var/run/mysqld/mysqlx.sock
bash-5.0#
从hostname和进程ID的结果来看，进入的还是msyql80容器。
最后执行 exit 或者 logout 命令退出容器，此时临时容器及其volume将自动被删除(参数–rm)。
这里主要考察了容器的Namespace隔离性的原理，通过将一个容器所有进程加入到目标容器的Namespace，从而实现了两个容器进程的相互可见。
这里抛出另一个问题，如果两个容器都存在一个一模一样的进程，这个时候会出错吗？如果不会的话，为什么(应用存储路径不一样？或者进程PID不一样)？我们可见的是哪个容器的里程，临时容器还是目标容器呢？
把一个进程分配到一个指定的Namespace下的原理请参考：https://time.geekbang.org/column/article/18119