本文依据我在〖deeplus直播第247期〗线上分享演讲内容整顿而成。

明天将分享的内容分为以下4个方面：

  • 一、缘起
  • 二、介绍多样的容器化技术
  • 三、Redis介绍
  • 四、Redis容器化计划的比照

一、缘起

首先咱们先聊一下为什么明天我会分享这个主题。我和敌人一起组织了一个 Redis技术交换群，到当初曾经经营了6年左右的工夫，其中某一天在群里有一个小伙伴就抛出来一个问题：

他问大家线上的Redis有没有应用Docker装置？Docker应用Host的网络模式、磁盘应用本地挂载模式这种计划怎么样？这里的话咱们临时先不说这个计划如何，因为在明天的分享之后，我置信大家对于这个计划应该会有一个更清晰的意识和评估。

二、介绍多样的容器化技术

1、chroot和jails

在容器化技术方面，其实历史很长远了。尽管咱们当初用的容器化技术，或者说 k8s，还有云原生的概念是近几年才火起来的，然而实际上就容器化技术的倒退来说，其实是很早的了。比如说最早的时候来自chroot，chroot大家可能都用过，或者都有理解过，在1979年的时候它是来自Unix，它次要的性能是能够批改过程和子过程的/。

通过应用chroot达到什么样成果呢？应用chroot加某一个目录，而后再启动一个过程，那么这个过程本人所看到的 / ,就是咱们平时所说的 / 目录，这个 / 就会是咱们方才指定的文件夹，或者说方才指定的门路。这样子的话能够无效的爱护咱们操作系统下面的一些文件，或者说权限和平安相干的货色。

在2000年的时候，呈现了一个新的技术，叫做jails，其实它曾经具备了sandbox，就是沙箱环境的雏形。应用jails的话，能够让一个过程或者说创立的环境领有独立的网络接口和IP地址，而当咱们提到应用jails的话，咱们必定会想到一个问题，就是如果你有了独立的网络接口和IP地址，这样的话就不能发原始的套接字，通常跟原始的套接字接触得比拟多的就是咱们应用的Ping命令。默认的状况下，这样子是不容许应用原始的套接字的，而有本人的网络接口和IP地址，这个感觉上就像是咱们罕用的虚拟机。

2、Linux VServer和OpenVZ

接下来在2001年的时候，在Linux社区当中就呈现了一个新的技术叫做Linux VServer。Linux VServer有时候能够简写成lvs，然而和咱们平时用到的4层的代理lvs其实是不一样的。它其实是对Linux内核的一种Patch，它是须要批改Linux内核，批改实现之后，咱们能够让它支持系统级的虚拟化，同时应用Linux VServer的话，它能够共享零碎调用，它是没有仿真开销的，也就是说咱们罕用的一些零碎调用、零碎调用的一些函数都是能够共享的。

在2005年的时候，呈现的一个新的技术—OpenVZ。OpenVZ其实和Linux VServer有很大的类似点，它也是对内核的一种Patch，这两种技术最大的变动就是它对Linux打了很多的Patch，加了很多新的性能，然而在2005年的时候，没有把这些全副都合并到Linux的骨干当中，而且在应用OpenVZ的时候，它能够容许每个过程能够有本人的/proc或者说本人的/sys。

其实咱们大家都晓得在Linux当中，比如说启动一个过程，你在他的/proc/self上面，你就能够看到过程相干的信息。如果你有了本人独立的/proc，其实你就能够达到和其余的过程隔离开的成果。

接下来另外一个显著的特点就是它有独立的users和groups，也就是说你能够有独立的用户或者独立的组，而且这个是能够和零碎当中其余的用户或者组独立开的。

其次的话OpenVZ是有商业应用的，就是有很多国外的主机和各种VPS都是用OpenVZ这种技术计划。

3、namespace 和 cgroups

到了2002年的时候，新的技术是namespace。在Linux当中咱们有了新的技术叫做namespace，namespace能够达到过程组内的特定资源的隔离。因为咱们平时用到的namespace其实有很多种，比如说有PID、net等，而且如果你不在雷同的namespace上面的话，是看不到其余过程特定的资源的。

到了2013年的时候，产生了一个新的namespace的个性，就是user namespace。其实当有了user namespace，就和上文提到的OpenVZ实现的独立用户和组的性能是比拟像的。

对于namespace的操作当中，通常会有三种。

1）Clone

能够指定子过程在什么namespace上面。

2）Unshare

它是与其余过程不共享的，unshare再加一个-net，就能够与其余的过程独立开，不共享本人的net，不共享本人的网络的namespace。

3）Setns

就是为过程设置 namespace。

到了2008年，cgroups开始被引入到Linux内核当中，它能够用于隔离过程组的资源应用，比如说能够隔离CPU、内存、磁盘，还有网络，尤其是他在2013年和user namespace进行了一次组合之后，并且进行了从新的设计，这个时候，就变得更现代化了，就像咱们当初常常应用到的Docker的相干个性，其实都来自于这个时候。所以说cgroups和namespace形成古代容器技术的根底。

4、LXC 和 CloudFoundry

在2008年的时候，新的一项技术叫做LXC, 咱们也会叫他Linux Container（以下均简称LXC）。上文咱们提到了很多容器化的技术，比方Linux VServer、OpenVZ，然而这些都是通过打Patch来实现的，而LXC是首个能够间接和上游的Linux内核独特工作的。

LXC是能够反对特权容器的，意思就是说能够在机器下面去做uid map、gid map，去做映射，而且不须要都拿root用户去启动，这样子就具备了很大的便利性。而且这种形式能够让你的被攻击面大大放大。LXC反对的这几种比拟惯例的操作，就是LXC-start，能够用来启动container，LXC-attach就能够进入container当中。

到2011年的时候，CloudFoundry开始呈现了，他实际上是应用了LXC和 Warden这两项技术的组合，在这个时候不得不提到的，就是他的技术架构是CS的模式，也就是说还有一个客户端和server端，而 Warden容器，它通常是有两层，一层是只读os的，就是只读的操作系统的文件系统，另外一层是用于应用程序和其依赖的非长久化的读写层，就是这两层的组合。

咱们之前提到的技术，大多数都是针对于某一台机器的，就是对于单机的。CloudFoundry它最大的不同就是它能够治理跨计算机的容器集群，这其实就曾经有了古代容器技术的相干个性了。

5、LMCTFY和systemd-nspawn

在2013年的时候， Google开源了本人的容器化的解决方案，叫做LMCTFY。这个计划是能够反对CPU、内存还有设施的隔离。而且它是反对子容器的，能够让应用程序去感知到本人以后是处在容器当中的。另外还能够再为本人创立一个子容器，然而随着2013年倒退之后，它逐步发现只依附本人不停的做这些技术，就相当于单打独斗，倒退始终是无限的，所以它逐渐的将本人的次要精力放在形象和移植上，把本人的外围个性都移植到了libcontainer。而libcontainer之后就是Docker的运行时的一个外围，再之后就是被Docker捐到了OCI，再而后就倒退到了runC。这部分内容咱们稍后再具体解说。

大家都晓得服务器它必定是有一个 PID为1的过程。就是它的初始过程、守护过程，而古代的操作系统的话，大多数大家都应用的是systemd，同样systemd它也提供了一种容器化的解决方案，叫做 systemd-nspawn。这个技术的话，它是能够和systemd相干的工具链进行联合的。

systemd除了有咱们平时用到的systemctl之类的，还有systemd machine ctl，它能够去治理机器，这个机器反对两种次要的接口，一种是治理容器相干的接口，另外一种是治理虚拟机相干的接口。

而咱们通常来讲，就是说systemd提供的容器技术解决方案，它是容许咱们通过machine ctl去容器去进行交互的，比如说你能够通过machine ctl start，去启动一个systemd反对的容器，或者通过 machine ctl stop，去关掉它，而在这种技术下，它是反对资源还有网络等隔离的，其实它最次要的是systemd ns，它其实是应用namespace去做隔离。对于资源方面是来自于systemd，systemd是能够应用cgroups去做资源隔离的，其实这也是这两种两种技术计划的组合。

6、Docker

而在2013年Docker也呈现了。通常来讲，Docker是容器时代的引领者，为什么这么说呢？因为Docker在2013年呈现的时候，他首先提到了标准化的部署单元，就是Docker image。同时它还推出了DockerHub，就是地方镜像仓库。容许所有人通过DockerHub去下载事后曾经构建好的Docker image，并且通过一行Docker run就能够启动这个容器。

在泛滥应用起来比拟繁琐、比较复杂的技术下，Docker这时提出来，你只须要一行Docker run，就能够启动一个容器，它大大简化了大家启动容器的复杂度，晋升了便捷性。

所以Docker这项技术就开始风靡寰球。而Docker它次要提供的一些性能是什么呢？比如说资源的隔离和治理。而且Docker在0.9之前，它的容器运行时是LXC，在0.9之后，他就开始把LXC替换掉，替换成了libcontainer，而这个libcontainer其实就是咱们在上文提到的Google的 LMCTFY。再之后libcontainer捐给了OCI。而那之后Docker当初的容器运行时是什么呢？是containerd。containerd的更上层是runc，runc的外围其实就是libcontainer。

而到了2014年的时候， Google发现大多数的容器化解决方案，其实都只提供了单机的解决方案，同时因为Docker也是CS架构的，所以它须要有一个Docker demand，它是须要有守护过程存在的，而这个守护过程的话，是须要用root用户去启动的，而root用户启动的守护过程，其实是减少了被攻击面，所以 Docker的平安问题也被很多人诟病。

在这个时候 Google就发现了这个点，并且把本人的Borg零碎去做了开源，开源版本就是Kubernetes。Google还联结了一些公司，组建了一个云原生基金会（CNCF）。

7、Kubernetes

通常来讲Kubernetes是云原生利用的基石，也就是说在Kubernetes呈现之后，咱们的云原生技术开始逐渐地倒退起来，逐渐地引领了潮流，Kubernetes提供了一些次要的个性。

它能够反对比拟灵便的调度、管制和治理，而这个调度程序的话，除了它默认的以外，也能够比拟不便的去对它做扩大，比如说咱们能够本人去写本人的调度程序，或者说亲和性、反亲和性，这些其实都是咱们比拟罕用到的一些个性。

还有包含他提供的一些服务，比如说内置的 DNS、kube-DNS或者说当初的CoreDNS，通过域名的形式去做服务发现，以及Kubernetes当中有很多的控制器。它能够将集群的状态调整至咱们预期的状态，就比如说有一个pod挂掉了，它能够主动的把它再复原到咱们预期想要的样子。

另外就是它反对丰盛的资源品种，比如说几个次要的层级，最小的是pod，再往上有deployment，或者有StatefulSets，相似于这样子的资源。

最初一点是它让咱们更加喜爱它的因素，就是它有丰盛的CRD的拓展，即能够通过本人去写一些自定义的资源，而后对它进行扩大，比方CRD。

8、更多的容器化技术

除了方才咱们提到的这些次要的技术以外，其实还有很多咱们没有提到的一些容器化的技术，比如说像runc，上文咱们没有太多的介绍，还有containerd。containerd其实也是Docker开源进去的本人的外围，他的指标是做一个标准化工业可用的容器运行时，还有CoreOS开源进去的解决方案叫做rkt。而rkt瞄准的点就是上文提到的Docker相干的平安问题。然而rkt当初我的项目曾经终止了。

还有红帽(Red Hat)开源进去的 podman， podman是一种能够用它来启动容器，能够用它去治理容器，而且没有守护过程，所以就安全性来讲的话，podman能够说比Docker的安全性直观上来看的话会好一些，然而它的便捷性来讲的话，就要大打折扣了。比如说容器的重启、开机起之类的，然而咱们都是有一些不同的解决方案的。

在2017年的时候，这个时候有一个 Kata Container，而这个Kata Container它有一段倒退过程，最开始是英特尔，英特尔在搞本人的容器运行时，还有一家初创公司叫做hyper.sh，这家公司也在搞本人的容器运行时，这两家公司瞄准的都是做更平安的容器，他们应用的底层的技术都是基于K8S。而之后这两家公司做了合并，hyper.sh它开源进去的一个解决方案是runv，被英特尔看上了之后就诞生了 Kata Container。在2018年的时候，AWS开源进去本人的Firecracker。

这两项技术和咱们上文提到的机器上的容器化技术其实大有不同，因为它的底层其实相当于是虚拟机，而咱们通常来讲，都认为它是轻量级虚拟机的一种容器化的技术。以上就是对于多样的容器化技术的介绍。

三、Redis介绍

接下来进入对于Redis相干的介绍，以下是从Redis的官网下面摘抄的一段介绍。

1、Redis应用的次要场景

其实Redis当初是应用最宽泛的一种KV型数据库。而咱们在应用它的时候，次要的应用场景可能有以下几种：

  • 把它当缓存应用，把它放在数据库之前，把它当做缓存去应用；
  • 把它当DB来用，这种就是须要把真正的拿它来存数据做长久化。
  • 做音讯队列，它反对的数据类型也比拟多，这里就不再做介绍了。

2、Redis的特点

  • 它是一个单线程的模型，它其实是能够有多个线程的，然而它的worker线程只有一个，在Redis6.0开始，它反对了io多线程，但io多线程只是能够有多线程去解决有网络相干的局部，实际上你真正去解决数据还是单线程，所以整体而言，咱们依然把它叫做单线程模型。
  • Redis的数据其实都在内存外头，它是一个内存型的数据库。
  • 与HA相干， Redis想要做HA，咱们以前在做 Redis的HA次要靠Redis sentinel，而前面在Redis进去cluster之后，咱们次要靠Redis cluster去做HA,这是两种次要HA的解决方案。

四、Redis容器化计划的比照

当咱们提到做 Redis运维相干的时候，咱们有哪些须要思考的点：

  • 部署，如何疾速的部署，如何可能疾速的部署，而且还要去治理监听的端口，让端口不起抵触,还有日志和长久化文件之类的,这部分都属于部署相干的内容；
  • 扩/缩容，也是咱们常常会遇到的问题；
  • 监控和报警；
  • 故障和复原。

以上都是咱们最关注的几个方面。我接下来就对这几个方面去做一些介绍。

1、部署

当咱们提到去做单机多实例的时候，Redis作单机多实例去部署的时候，首先第一点就是咱们心愿可能有过程级别的资源隔离，咱们某一个节点下面所有部署的Redis实例，能够有本人的资源，能够不受别的实例的影响，这就是对于过程级别的资源隔离。

过程级别的资源隔离，它其实次要分为两个方面，一方面是CPU，另一方面是内存，其次的话咱们心愿在单机下面咱们也能够有本人的端口治理，或者说咱们能够有独立的网络资源隔离的相干的技术。

在这种状况下，首先咱们提到说过程级别的资源隔离，咱们介绍了那么多的容器化相干技术，咱们曾经晓得了，反对过程级别的资源隔离的话，有最简略的一种计划就是用cgroups，如果想要去做网络资源隔离的话，咱们有namespace，也就是说所有反对cgroups和 namespace的这种打算的解决方案，都能够满足咱们这个中央的需要。

再有一种计划就是虚拟化的计划，也就是咱们上文提到比如说Kata Container，Kata Container这种基于虚拟化的形式，因为虚拟化的计划其实大家都有所接触，大家都晓得就是虚拟化的这种技术，其实默认状况下，刚开始全副都做隔离。

所以对于部署而言，如果你应用的是比如说像Docker，比如说你想应用的像 systemd-nspawn这些它都能够既用到cgroups，又用到了 namespace，是都能够去用的，只不过是你须要思考一些便捷性，比如说你如果是应用Docker的话，进行一个Docker命令跑过来，而后只有让它映射到不同的端口，其实就完结了。

如果你应用是systemd-nspawn，这样子的话，你须要去写一些配置文件。如果你要是去用一些虚拟化的解决方案的话，同样的也须要去筹备一些镜像。

2、扩/缩容

对于扩/缩容，其实会有两种最次要的场景，一种场景就是单实例 maxmemory 调整，就是咱们最大内存的调整。还有一种是对于咱们的集群化的集群解决方案，就是Redis Cluster。对于这种集群规模，咱们有扩/缩容的话，会有两方面的变动。

一方面是 Node，就是咱们的节点的变更，如果会新增节点，也可能会去移除节点。

另外一种就是Slot的变更，就是心愿把我的 slot 去做一些迁徙，当然这些和Node节点会是相干的，因为当咱们去做扩容的时候，咱们把Redis Cluster当中的一些Node节点增多，增多了之后，就能够不给他调配Slot，或者说我想要让某些Slot集中到某些节点下面，其实这些需要也是同样存在的。

那咱们来看一下，如果你过后想要去做maxmemory的调整，如果咱们是前提曾经做了容器化，想通过 cgroups去对它做资源的限度，就须要有一个能够反对动静调整 cgroups配额的解决方案。

比如说咱们用到Docker update，它是能够间接批改某个实例，或者说其中的某一个容器的cgroups资源的一些限度，比如说咱们能够Docker update，给它指定新的内存，能够限度它最大可用内存，当你把它的可用内存数调大，接下来你就能够对实例去调整它的 maxmemory ，也就是说对于单实例 maxmemory，其实最次要的就是须要有cgroups的技术，向cgroups的技术提供一些反对。

对于集群节点的变更的话，这个局部稍后再做具体介绍。

3、监控报警

第三点就是监控报警，不论是应用物理机也好，或者应用云环境也好，或者应用任何解决方案都好，监控报警咱们最想要失去的成果就是，它能够主动发现。

咱们心愿当启动一个实例之后，咱们就能够立马晓得这个实例A他曾经起来了，并且晓得他的状态是什么，而监控报警的话，这部分其实是不依赖于特定的容器化技术的，就即便是在纯正的物理机上部署，也能够通过一些解决方案主动的发现它，主动的把它注册到咱们的监控零碎当中去，所以它是属于监控报警的这部分，其实它是不依赖于特定的容器技术的，但惟一的一个问题就是说如果说应用了容器化的计划，能够让罕用的 Redis exporter，配合Prometheus去做监控，能够让 Redis exporter和 Redis server，这两个过程能够处于同一个网络的命名空间。

如果他们两个处于同一个网络的命名空间的话，能够间接通过127.0.0.1:6379，而后间接去联通它,如果咱们应用的是k8s的话，能够间接把它俩放到一个pod当中，然而这些都无关紧要，因为它是不依赖于特定的容器化技术的，你能够应用任何你想要用的技术，都能够去做监控和报警。

4、故障复原

最初咱们提到的局部是故障和复原。在这个局部我认为最次要的有三个方面：

  • 第一个是实例的重启。

有可能在某些状况下，某些场景下，你的实例在运行过程当中它可能会宕掉，如果你想让他主动重启的话，你须要有一个过程治理的工具。对于咱们而言，上文咱们提到了systemd，systemd是能够反对对于某一个过程的主动拉起的，还能够反对过程挂掉之后主动拉起， 能够 restart，或者你应用Docker，它也有一个restart policy，能够指定他为 always或者指定为on-failure，而后让它在挂掉的时候再把它给拉起来。

如果你应用的是k8s，那么就更简略了，能够主动拉起来。

  • 第二个是主从切换。

主从切换相对来说是一个常态，但在这里我也把它列到故障复原当中，是因为可能在主从切换的过程当中，有可能你的集群情况曾经不衰弱了，是会有这种状况存在的。那主从切换的时候咱们须要做什么？第一方面，须要让他可能有数据的长久化，另一方面在主从切换的时候，有可能会遇到一种状况，就是资源不够，导致主从切换失败，在这种状况下，其实和咱们上文后面提到的扩/缩容其实是相干的，所以在这种状况下就必须得给他加资源，而最好的方法是能够主动给他加资源。

在k8s当中，想要让它主动加资源，咱们通常会给他设置它的request和limit，就是资源的配额，心愿它能主动的加起来，咱们通常把他叫做vpa。

  • 第三个是数据恢复。

通常来讲，比如说咱们开了 RDB和AOF，而且心愿咱们的数据能够保留下来，以便于在咱们数据恢复的时候能够间接开始应用。所以数据长久化也是一方面。

咱们去做容器化的时候，咱们须要思考哪些点？如果说你是应用Docker的话，你须要去挂一个券，而后你能够把这个数据去做长久化，比如说你应用systemd-nspawn也须要有一个文件目录去把这个数据做继续化。

如果你应用的是k8s的话，在挂券的时候，你会有各种各样的抉择，比如说你能够去挂 ceph的RDB、s3或者一个本地的某一个文件目录。然而为了更高的可靠性，可能会应用正本数更多的分布式存储。

5、Node节点变更

接下来，咱们来聊一下上文咱们在提到服务扩/缩容的时候，提到的对于Node节点变更，比如说我想要让我的某一个Redis cluster，去裁减一些节点，裁减节点的时候，那就意味着你必须可能退出集群，可能和集群失常通信，这才阐明你真正的退出到了集群当中。

而咱们也晓得在Redis cluster当中，你要去做集群，最大的一个问题就是k8s，k8s当中做服务发现其实它都是大多数通过一个域名，而咱们的Redis当中，比如说咱们的NodeIP，它其实只反对IP，它并不反对咱们的域名。

所以如果说Node节点变更，须要做的事件就是容许咱们动静地去把NodeIP写到咱们的集群配置当中。

如果想要让它有一个残缺的生命周期，以下截图是来自于一个叫Kubedb的operator，在下图中能够看到，Redis这个中央提供了最次要的三个局部：

  • PVCs，PVCs就是做数据的长久化。
  • Services，Services就是做服务发现。
  • StatefulSets，StatefulSets其实就是k8s当中的一种资源，而这资源它对于咱们的有状态利用会更敌对一些。

其实在整个内容当中还有一点没有介绍的是什么呢？就是Redis背地的公司叫做Redis Labs，它提供了一种商业化的计划，就是Redis Enterprise一种解决方案。其实也是在k8s的解决方案之上的，也是用了Redis operator。他的计划和Kubedb这种计划根本相似，因为外围还都是用的StatefulSets，而后再加上本人的Controller，去实现这个事件。

五、总结

咱们来看一下明天的总结。如果是咱们单机应用的话，咱们能够交给Docker或者其余反对cgroups或者namespace资源管理的工具。因为当你应用了cgroups、namespace的话，你能够做到资源的隔离，能够防止网络的端口的抵触之类的事件都能够实现。

而如果是像我在上文提到的小伙伴提到的那个问题：他打算应用主机的网络，仅仅是想让Docker去做一个过程治理，而且你也不心愿引入新的内容。那么systemd或者systemd-nspawn都是能够思考的，因为这也是容器化的解决方案。

如果是在简单场景下的调度和治理的话，比方想要有很大的规模，并且想要有更灵便的调度和治理，我举荐你应用的是Kubernetes operator，比如说Kubedb，其实也是一种解决方案。如果你的场景没有那么简单，比较简单，其实原生的Kubernetes StatefulSets略微做一些调整和批改，也是能够满足你的需要。

以上就是我明天分享的次要内容了，感激大家的参加。

>>>>

Q&A

Q1：请问Redis集群如果用三台物理机做，每台运行2个实例，如何保障每台物理机的实例不是互为主从的？

A1 ： 这个问题其实咱们通常状况下大家也都会遇到。第一点如果你是应用物理机来做，并且你每台机器下面运行两个实例，三台机器每个机器下面运行2个实例，一共有6个实例。这6个实例你是否能够保障它每个相互都不为主从的，其实是能够间接保障。

惟一的问题就是如果说这是一个集群，而后产生故障转移，产生节点的被动切换，就十分有可能存在你的主从产生了变更。其实这个中央的话其实我更加倡议，如果你发现了这种问题的话，你手动去做切换，因为物理机环境去做这个事件，目前我还没看到有什么特地好的解决办法。

Q2 : 请问k8s 中扩容时，如何减少新节点。扩容和调配slot的步骤如何自动化的进行？

A2 ： 咱们离开两步来讲，第一局部是减少新节点，减少新节点的话，方才我其实在过程外头曾经提到了，减少完新的节点之后，首先你肯定要让它可能和集群去做通信，然而这个中央就是须要你去批改集群的配置文件，而后你须要他有一个NodeIP，因为之间是通过IP去做通信的，所以你须要去批改它的配置文件，把它的 NodeIP加进去，这样子他才能够和集群当中的其余节点去做通信，然而这个局部的话，我更举荐的是用operator去做。

Q3 : 请问如果不必Redis operator，也不应用分布式存储，k8s如何部署cluster集群呢？

A3 ： 不必Redis operator其实也是能够的，方才我也介绍过，有两种模式，一种模式就是用StatefulSets，这种模式的话相对来说会比拟稳当一些。同时它的最次要的局部依然是批改配置，你须要在你的Redis的容器镜像当中，你能够给它加一个init容器，而后能够在这个局部先给他做一次批改配置的操作，这是能够的。批改完配置的操作之后，再把它给拉起来，这样子他才能够退出到集群当中。

Q4 : 请问网络提早在不同网络模型下有什么区别？

A4 ： 如果咱们间接应用物理机的网络，通常来讲，咱们不认为这种形式有提早，就是主机网络个别状况下咱们会疏忽掉它的提早，然而如果你应用的是overlay的这种网络模型的话，因为它是覆盖层的网络，所以你在去做发包解包的时候，当然是会有不同的资源的损耗，性能的损耗都是有的。

Q5 : 请问个别倡议公司专用一个Redis集群，还是各零碎独立集群？

A5 ： 这个问题当然是倡议各个系统独立集群了，咱们来举一个最简略的例子，比如说你在其中用到了list，咱们都晓得Redis就有一个ziplist的配置项，他其实跟你的存储和你的性能是有关系的。如果你是公司的所有的货色都用同一个集群，那你批改了Redis集群的配置的话，很可能会影响到所有的服务。但如果你是每个零碎独立用一个Redis群的话，彼此之间互不影响，也不会呈现某一个利用不小心把集群给打挂了，而后造成连锁反应的状况。

Q6 : 请问Redis长久化，在生产中如何思考呢？

A6 ： 这部分货色我是这样想的。如果你真的须要去做长久化，一方面Redis提供了两种外围，一种是 RDB，另外一种是AOF，如果说你的数据很多的话，相应你的RDB可能会变得很大。如果你是去做长久化，我通常倡议就是两个外头去做一次衡量。因为通常来讲，即便你是应用物理机的环境，我也倡议你的存储目录能够放到一个独立的盘外头，或者说你能够去挂在一个分布式的存储，然而前提是你须要保障它的性能，因为你不能因为它的写入性能而连累你的集群，所以更加举荐的就是你能够全都把它们关上，然而如果你数据其实没那么重要，你能够你只开AOF。

Q7 : 请问生产级别的ceph牢靠不？

A7 ： 其实ceph的可靠性这个问题，很多人都探讨过，就我集体而言，ceph 的可靠性是有保障的。我这边在用的 ceph 很多，并且存了很多比拟外围的数据，ceph 的可靠性是 ok 的。

重点在于说你能不能搞得定他，而且有一家公司其实大家可能有所理解，叫做SUSE，就是一个Linux的一个发行版，这家公司其实提供了一个企业级的存储解决方案，并且它的底层其实还是用的ceph，其实这也是失常的，只有有专人去搞这个事件，而后把它解决掉，我感觉ceph足够稳固的。

顺便提一下，如果你应用的是 k8s 的话，当初有一个我的项目叫做 rook，它其实提供了一个 ceph 的 operator，这种计划其实当初曾经算是相对来说比拟很稳固的了，举荐大家尝试一下。

Q8: 请问申请内存、限度内存、还有自身Redis内存怎么配置比拟好？

A8： 这里须要思考几个问题，首先咱们先说Redis自身的内存，其实要看你的理论业务的应用场景，或者说你业务的理论需要，你必定不可能让你的Redis的实例或者Redis集群的内存都占满。

如果是占满的话，你就须要开启lru去做驱赶之类的事件，这是一方面。另一方面就是申请内存，其实我了解你这个中央要问的问题应该是指，在k8s环境上面，在k8s上面一个是request的，一个是limit，limit必定是你的可用限度的内存，限度内存你肯定须要思考到Redis自身还要用到的一些内存。

欢送订阅我的文章公众号【MoeLove】