ElasticSearch面试题 1.为什么要使用Elasticsearch? 因为在我们商城中的数据，将来会非常多，所以采用以往的模糊查询，模糊查询前置配置，会放弃索引，导致商品查询是全表扫面，在百万级别的数据库中，效率非常低下，而我们使用ES做一个全文索引，我们将经常查询的商品的某些字段，比如说商品名，描述、价格还有id这些字段我们放入我们索引库里，可以提高查询速度。 ...

一、DockerHub 官网链接 https://hub.docker.com/ 二、Dockerfile 关键字 注意: dockerfile 的关键字必须都是大写才能使用 FROM 指定基础镜像，当前新镜像是基于哪个镜像的。其中，scratch是个空镜像，这个镜像是虚拟的概念,并不实际存在,它表示一个空白的镜像，当前镜像没有依赖于其他镜像 ...

安装 Windows 此处下载 双击exe 一直下一步安装 Linux Linux 默认安装的Git 版本一般为1.8*, 可以通过以下方式升级 首先，把老版本的 Git 卸掉。 1 2 sudo yum -y remove git sudo yum -y remove git-* 添加 End Point 到 CentOS 7 仓库 yum -y install https://packages.endpointdev.com/rhel/7/os/x86_64/endpoint-repo.x86_64.rpm yum -y install git check version git version 配置Git Set your name. git config --global user.name "Your Name" Set your email address. git config --global user.email "user@exmample.com" Verify the settings. git config --list Git 配置SSH key 连接Github HTTPS URL 和 SSH URL 在使用 git clone 项目时，可以使用仓库的 HTTPS URL 也可以 使用 SSH URL HTTPS URL，例如：https://github.com/<username>/<repo name>.git SSH URL，例如：git@github.com:<username>/<repo name>.git ...

哈希 哈希（Hash）也称为散列，是把任意长度的输入通过哈希算法变换为固定长度的输出，这个输出值也就是散列值。 哈希表是根据键值对（key value）而直接进行访问的数据结构，通过将键值对映射到表中一个位置来访问记录，以加快查询速度。映射函数又称为散列函数，存放记录的数组叫做哈希表。 ...

Linux修改主机名修改hostname的方法 临时修改Linux主机名的方法 hostname newname 执行命令后发现没有变化。重新开终端即可显示，你也可以通过uname -n命令来查看当前的主机名。 永久修改Linux主机名的方法 ...

ShardedKV 介绍 有关 shardkv，其可以算是一个 multi-raft 的实现，只是缺少了物理节点的抽象概念。在实际的生产系统中，不同 raft 组的成员可能存在于一个物理节点上，而且一般情况下都是一个物理节点拥有一个状态机，不同 raft 组使用不同地命名空间或前缀来操作同一个状态机。基于此，下文所提到的的节点都代指 raft 组的某个成员，而不代指某个物理节点。比如节点宕机代指 raft 组的某个成员被 kill 掉，而不是指某个物理节点宕机，从而可能影响多个 raft 的成员。 ...

介绍 在lab2的Raft函数库之上，搭建一个能够容错的key/value存储服务，需要提供强一致性保证。 强一致性介绍 对于单个请求，整个服务需要表现得像个单机服务，并且对状态机的修改基于之前所有的请求。对于并发的请求，返回的值和最终的状态必须相同，就好像所有请求都是串行的一样。即使有些请求发生在了同一时间，那么也应当一个一个响应。此外，在一个请求被执行之前，这之前的请求都必须已经被完成（在技术上我们也叫着线性化（linearizability））。 kv服务支持三种操作：Put, Append, Get。通过在内存维护一个简单的键/值对数据库，键和值都是字符串； ...

介绍 linearizable read 简单的说就是不返回 stale 数据，具体可以参考Strong consistency models Read Index 机制就是 Leader 在收到读请求时进行如下几步： 如果 Leader 在当前任期还没有提交过日志，先提交一条空日志 Leader 保存记录当前 commit index 作为 readIndex 通过心跳，询问成员自己还是不是 Leader，如果收到过半的确认，则可确信自己仍是 Leader 等待 Apply Index 超过 readIndex 读取数据，响应 Client etcd不仅实现了leader上的read only query，同时也实现了follower上的read only query，原理是一样的，只不过读请求到达follower时，commit index是需要向leader去要的，leader返回commit index给follower之前，同样，需要走上面的ReadIndex流程，因为leader同样需要check自己到底还是不是leader ...

如果允许提交之前任期的日志，将导致什么问题? 我们将论文中的上图展开: (a): S1 是leader，将黄色的日志2同步到了S2，然后S1崩溃。 (b): S5 在任期 3 里通过 S3、S4 和自己的选票赢得选举，将蓝色日志3存储到本地，然后崩溃了。 (c): S1重新启动，选举成功。注意在这时，如果允许提交之前任期的日志，将首先开始同步过往任期的日志，即将S1上的本地黄色的日志2同步到了S3。这时黄色的节点2已经同步到了集群多数节点，然后S1写了一条新日志4，然后S1又崩溃了。 接下来会出现两种不同的情况: (d1): S5重新当选，如果允许提交之前任期的日志，就开始同步往期日志，将本地的蓝色日志3同步到所有的节点。结果已经被同步到半数以上节点的黄色日志2被覆盖了。这说明，如果允许“提交之前任期的日志”，会可能出现即便已经同步到半数以上节点的日志被覆盖，这是不允许的。 (d2): 反之，如果在崩溃之前，S1不去同步往期的日志，而是首先同步自己任期内的日志4到所有节点，就不会导致黄色日志2被覆盖。因为leader同步日志的流程中，会通过不断的向后重试的方式，将日志同步到其他所有follower，只要日志4被复制成功，在它之前的日志2就会被复制成功。（d2）是想说明：不能直接提交过往任期的日志，即便已经被多数通过，但是可以先同步一条自己任内的日志，如果这条日志通过，就能带着前面的日志一起通过，这是（c）和（d2）两个图的区别。图（c）中，S1先去提交过往任期的日志2，图（d2）中，S1先去提交自己任内的日志4。 假如 s1 提交的话，则 index 为 2，term 为 2 的 entry 就被应用到状态机中了，是不可改变了，此时 s1 如果挂了，来到 term5，s5 是可以被选为 leader 的，因为按照之前的 log 比对策略来说，s5 的最后一个 log 的 term 是 3 比 s2 s3 s4 的最后一个 log 的 term 都大。一旦 s5 被选举为 leader，即 d 场景，s5 会复制 index 为 2,term 为 3 的 entry 到上述机器上，这时候就会造成之前 s1 已经提交的 index 为 2 的位置被重新覆盖，因此违背了一致性。 ...

Mulit Raft Group 通过对 Raft 协议的描述我们知道：用户在对一组 Raft 系统进行更新操作时必须先经过 Leader，再由 Leader 同步给大多数 Follower。而在实际运用中，一组 Raft 的 Leader 往往存在单点的流量瓶颈，流量高便无法承载，同时每个节点都是全量数据，所以会受到节点的存储限制而导致容量瓶颈，无法扩展。 ...