很早以前就听说过redis社区推崇一种哨兵模式的高可用集群部署模式，今天花时间研究了一下，正好记录下来。
由于集群中每个实例都需要保存路由信息，彼此不断传播通信更新，也造成通信成本进而影响集群规模。
翻译自 Is Cluster API Really the Future of Kubernetes Deployment? 。
Kubernetes是一个开源的容器编排系统，可以用于管理和部署容器化的应用程序。而Helm则是一个Kubernetes的包管理工具，可以方便地安装、升级和管理Kubernetes的应用程序。
Kubernetes是一个流行的容器编排系统，可以方便地部署和管理应用程序。Redis是一个流行的内存数据库，支持高可用性和扩展性。在本文中，我们将介绍如何在Kubernetes上安装Redis集群。
Redis的主从复制模式下， 一旦主节点由于故障不能提供服务， 需要人工将从节点晋升为主节点， 同时还要通知应用方更新主节点地址， 对于很多应用场景这种故障处理的方式是无法接受的。 1. 哨兵模式介绍 Sentinel(哨兵)进程是用于监控redis集群中Master主服务器工作的状态 在Master主服务器发生故障的时候，可以实现Master和Slave服务器的切换，保证系统的高可用（HA） 其已经被集成在redis2.6+的版本中，Redis的哨兵模式到了2.8版本之后就稳定了下来。
当一个集群的不同部分在同一时间都认为自己是活动的时候，我们就可以将这个现象称为脑裂症状。通俗的说，就是比如当你的 cluster 里面有两个结点，它们都知道在这个 cluster 里需要选举出一个 master。那么当它们两之间的通信完全没有问题的时候，就会达成共识，选出其中一个作为 master。但是如果它们之间的通信出了问题，那么两个结点都会觉得现在没有 master，所以每个都把自己选举成 master，于是 cluster 里面就会有两个 master。
是备份关系， 我们操作主库，数据也会同步到从库。 如果主库机器坏了，从库可以上。就好比你 D盘的片丢了，但是你移动硬盘里边备份有。
Redis 集群不支持那些需要同时处理多个键的 Redis 命令， 因为执行这些命令需要在多个 Redis 节点之间移动数据， 并且在高负载的情况下， 这些命令将降低Redis集群的性能， 并导致不可预测的行为。
2019年4月18日至20日，第九届中国开源黑客松活动在深圳鹏城实验室举办，这是一场持续3日，集结多位社区专家的技术分享大会。
Redis是一种高性能的开源内存数据库，它提供了多种数据结构和API，可以用于构建各种不同类型的应用程序。Redis哨兵是一种Redis高可用性(HA)解决方案，它使用主从复制和自动故障转移(Auto Failover)机制来确保Redis集群的可用性。在本文中，我们将详细介绍如何安装Redis哨兵集群。
哈希(hash，键值对形式) 链表(list，元素有序可以重复) 集合(set,元素无序且不可重复，可以进行交、并、差运算) 有序集合(zset，元素有序的集合) 字符串(String,可以存储字符串、数字、二进制数等)
每个Mater 都可以拥有多个slave.当Master掉线后,redis cluster集群会从多个Slave中选举出来一个新的Matser作为代替,而旧的Master重新上线后变成 Master 的Slave.
笔者用过 helm，它是Kubernetes下的包管理器，相当于apt-get、yum、brew这样的软件工具，用的是 helm（v2）版本，下面所介绍的 helm指的都是 v2 版本。通过使用 helm 解决了安装和部署复杂的 Kubernetes 应用，比如经常使用的 memecache、redis、MySQL。也解决过部分粉丝在用 helm 部署程序过程遇到一些问题，其中有几个粉丝一再建议我写一篇文章介绍下 helm，其实我是不想写的，究其原因有两点，第一、helm 官网和镜像仓库介绍非常详尽，当然安装也非常简单。第二、helm 如果想深入使用，必须搞明白 go 的模板语法，对于大多数用户来说，只是用来管理不同环境的编排文件，现在又要学一门模板语言，有一定的学习成本，所以就这点我是不太认可 helm 的。当然很多人会说，不如直接选择 Kubernetes 集成的 Kustomize，不用安装任何多余程序，即可完成不同环境应用配置和打包，但从本质上来说，helm 和 Kustomize 是有一定区别的，Kustomize 利用base+overlay的思想生成最终的描述文件，对原有yaml 编排文件不用怎么修改，即可无缝集成，使用上更简单。而 helm 则又分为仓库、helm 客户端、tiller 服务端，使用过程中，在底层定义模板，外层赋值。使用起来更复杂，但不可否认 helm 更强大，它不仅能够完成不同环境应用的打包和配置，更是对应用进行全生命周期的管理，比如查看历史部署版本、回退、升级等；另外支持应用程序的查找、以及应用程序依赖关系定制化等功能。之前介绍过 Kustomize 的使用，下文结合 redis-ha 安装部署介绍下 helm，使你对 Kustomize 和 helm 之间的功能点有一个更清楚的认识。
在启用了HDFS HA的集群，2个NameNode节点上一般都会部署三个角色：NameNode，JournalNode和Failover Controller。在实际生产中，我们有时会碰到一个情况，你不小心删掉了某个NameNode节点上的所有角色包括NameNode，JournalNode和Failover Controller，或者你不小心通过Cloudera Manager直接从主机管理列表里移除了该NameNode节点，然后你想再把这个节点加回去的时候，发现无论如何HDFS服务都没办法正常使用了。本文Fayson会在一个HDFS HA的CDH集群中模拟这种情况，然后尝试去解决，即先删除一个NameNode，然后如何通过配置将该NameNode重新加回到HDFS服务中。
假死：心跳出现超时可能是master挂了，但是也可能是master，zookeeper之间网络出现了问题，也同样可能导致。这种情况就是假死，master并未死掉，但是与ZooKeeper之间的网络出现问题导致Zookeeper认为其挂掉了然后通知其他节点进行切换，这样slaver中就有一个成为了master，但是原本的master并未死掉，这时候client也获得master切换的消息，但是仍然会有一些延时，zookeeper需要通讯需要一个一个通知，这时候整个系统就很混乱可能有一部分client已经通知到了连接到新的master上去了，有的client仍然连接在老的master上如果同时有两个client需要对master的同一个数据更新并且刚好这两个client此刻分别连接在新老的master上，就会出现很严重问题。
工作中需要向外部提供一些诸如MySQL、Redis、MongoDB、Kafka之类的基础PaaS服务。以前每做一个PaaS都要自己去实现工作节点管理、实例调度、实例运维、实例监控等功能模块，实在是太累。这次花了些时间想了下，感觉基于Kubernetes做这个会简单很多。下面概要性地梳理下基于Kubernetes构建基础PaaS服务的过程。
-多年互联网运维工作经验，曾负责过大规模集群架构自动化运维管理工作。 -擅长Web集群架构与自动化运维，曾负责国内某大型金融公司运维工作。 -devops项目经理兼DBA。 -开发过一套自动化运维平台（功能如下）： 1)整合了各个公有云API，自主创建云主机。 2)ELK自动化收集日志功能。 3)Saltstack自动化运维统一配置管理工具。 4)Git、Jenkins自动化代码上线及自动化测试平台。 5)堡垒机，连接Linux、Windows平台及日志审计。 6)SQL执行及审批流程。 7)慢查询日志分析web界面。
这实际上是一种静态分片技术。Redis实例的增减，都得手工调整分片程序。基于此分片机制的开源产品，现在仍不多见。这种方式下，可运维性较差。出现故障，定位和解决都得研发和运维配合着解决，故障时间变长。
概述 在传统的虚机/物理机环境里, 如果我们想要对一个有状态应用扩容, 我们需要做哪些步骤? 申请虚机/物理机 安装依赖 下载安装包 按规范配置主机名, hosts 配置网络: 包括域名, DNS,
上周在kubernetes里发布了一个redis PaaS服务，不过其它同学简单测了一下，虽说功能上没啥问题，但性能相比物理上运行的Redis集群差太远，而且随着redis的分片数增加，性能并不能很好地线性增长，增长到一定程度就停止了，这个是需求方不能接受的，于是本周接了活，对部署在kubernetes中的redis服务进行性能优化。
大家好，我是小碗汤，今天分享一篇搭建一个高可用镜像仓库的教程。详细中夹杂着简单~。篇幅较长，兄弟们不妨耐心看完~
Kubernetes平台是围绕控制器的软件设计模式构建的，该控制器是管理两个实体之间数据流的软件组件。在Kubernetes中，控制器监视在一个资源中发现的声明状态的更改，然后通过创建或更改其他下游资源来响应状态更改请求。由于控制器对帐过程连续发生，因此此过程称为“主动对帐”。如图1所示。
在现代分布式系统中，高可用性（High Availability，HA）是至关重要的。当一个关键组件出现故障时，系统需要能够自动切换到备用组件，以确保持续的服务可用性。Redis是一个流行的内存数据库，它提供了很多强大的功能，但在保障高可用性方面，Redis哨兵（Sentinel）是一个不可或缺的组件。本文将深入探讨Redis哨兵的主要功能，为您展示如何使用它来构建高可用的Redis集群。
集群真是好好玩，最近一段时间天天搞集群，redis缓存服务集群啦，solr搜索服务集群啦，，，巴拉巴拉 今天说说zookeeper，之前搭建了一个redis集群，用了6台机子，有些朋友电脑跑步起来，
Redis 不管主从版还是集群规格，replica作为备库不对外提供服务，只有在发生HA的时候，replica提升为master后才承担读写流量。这种架构读写请求都在master上完成，一致性较高，但性能受到master数量的限制。经常有用户数据较少，但因为流量或者并发太高而不得不升级到更大的集群规格。
在启用了HDFS HA的集群，2个NameNode节点上一般都会部署三个角色：NameNode，JournalNode和Failover Controller。在实际生产中，我们有时会碰到一个情况，你不小心删掉了某个NameNode节点上的所有角色包括NameNode，JournalNode和Failover Controller，或者你不小心通过Cloudera Manager直接从主机管理列表里移除了该NameNode节点，然后你想再把这个节点加回去的时候，发现无论如何HDFS服务都没办法正常使用了。本文Fayson会在一个HDFS HA的CDH集群中模拟这种情况，然后尝试去解决，即先删除一个NameNode，然后这时HDFS会故障，我们来看看如何恢复故障。有兴趣的读者可以注意本文的处理方式与上篇文章《0526-6.1-如果你不小心删了一个NameNode1》的区别，上篇文章是比较健康的将删掉的NameNode再加回去，本文提供的是手动将HDFS HA回退，最后只会保留一个NameNode，也算另一种思路，万一你使用《0526-6.1-如果你不小心删了一个NameNode1》中的方法没办法恢复呢，是吧。
Redis（代表REmote DIctionary Server）是一种开源的内存中数据存储，通常用作数据库，缓存或消息代理。它可以存储和操作高级数据类型，例如列表，地图，集合和排序集合。由于Redis接受多种格式的密钥，因此可以在服务器上执行操作，从而减少了客户端的工作量。它仅将磁盘用于持久性，而将数据库完全保存在内存中。Redis是一种流行的数据存储解决方案，并被GitHub，Pinterest，Snapchat，Twitter，StackOverflow，Flickr等技术巨头所使用。
这一部分介绍了核心概念，并讨论了如何将Argo CD作为SRE进行操作。 本书的这一部分包括以下章节:
Loki Operator 前段时间小白在《Loki多租户模式下的方案》文中说到日志分区存储的方案时，引入了一个Loki控制器来帮助平台租户创建自己独占资源的Loki实例。一个月过去了，之前埋下的这
kubernetes自定义资源对象再极大程度提高了API Server的可扩展性，让企业能够根据业务需求通过CRD编写controller或者operator来实现生产中各种特殊场景。随着k8s的版本升级，CRD的功能也越来越完善，下面对其中几点进行说明。
现实世界有许多的Key-Value数据库，它们都被广泛应用于很多系统。比如，我们能够用Memcached数据库存储一个MySQL查询结果集给后续相同的查询使用，用MongoDB存储文档以得到更好的查询性能等等。 针对不同的场景，我们应该选不同的Key-Value数据库，没有一个Key-Value数据库适用于所有解决方案，但是如果你仅仅想要一个简单、易于使用、快速、支持多种强大数据结构的Key-Value数据库，Redis可能是你作为开始的一个很好的选择。 Redis是一个先进的Key-Value缓存和数据库
Redis代表REmote DIctionary Server是一种开源的内存中数据存储，通常用作数据库，缓存或消息代理。它可以存储和操作高级数据类型，例如列表，地图，集合和排序集合。由于Redis接受多种格式的密钥，因此可以在服务器上执行操作，从而减少了客户端的工作量。它仅将磁盘用于持久性，而将数据库完全保存在内存中。Redis是一种流行的数据存储解决方案，并被GitHub，Pinterest，Snapchat，Twitter，StackOverflow，Flickr等技术巨头所使用。
https://github.com/macrozheng/mall-learning/tree/master/document/redis-cluster
Redis 是一个开源（BSD许可）的，内存中的数据结构存储系统，通俗的来讲就是基于内存的高性能K/V数据库。 Redis 作为一个key—value储存系统。支持储存的value类型相对更多，包括string(字符串)、list(链表)、set(集合)、zset(sorted set --有序集合)和hash（哈希散列）。
考虑到我们这很多微服务依赖的redis的压力并不大（大量1-4G实例），轻量级的redis主从即可满足需求，使用社区现有解决方案，基本不会增加运维成本。
伴随着Docker技术的兴起，以及容器集群管理平台Mesos、Kubernetes、Swarm、Rancher等的大行其道，仿佛PaaS平台及其相关技术一下进入了黄金时期，各种各样的技术组合，各种各样的技术验证，以及伴随着容器相关的创业公司布道，仿佛只要有了PaaS平台及其相关的技术，就能解决一切的企业IT问题。但是，企业IT，尤其是非互联网传统企业，PaaS平台的构建与业务上云是一个长期的过程，绝不是一个docker+kubernetes/Mesos/Swarm构建完以后就能完成的，IaaS年代是这样，PaaS年代也是这样。
过去几年容器逐渐成为了打包和部署代码的流行的方式。容器镜像解决很多现有的打包和部署工具所带来的问题，初次以外，还为我们提供了构建分布式应用的全新的思路。就如SOA提倡将应用拆分为模块化的内聚的服务，容器应当进一步提倡将这些服务拆分为紧密协作的模块化容器。通过构建应用边界，容器使用户能够使用模块化，可重用的组件构建其服务，从而使得服务比单机容器构建的应用程序更可靠，更具可扩展性并且构建速度更快。
如果一个master挂了，那么剩余的2个master会发起投票选举，从挂了的master对应的slave中选举出一个新的master，发生故障的master不会参与投票，这个要注意。
一主(master)二从(slave)三哨兵(sentinel)的配置目标, 如下
随着网络攻击者变得更有组织性、更有能力并利用新的切入点，威胁也在升级。如果认为勒索软件威胁将针对备份本身，企业有一些重要的选择来决定如何可靠地保护他们的数据和用户数据以实现业务连续性和法规遵从性。
假设我们在一台主从机器上配置了200G内存，但是业务需求是需要500G的时候，主从结构+哨兵可以实现高可用故障切换+冗余备份，但是并不能解决数据容量的问题，用哨兵，redis每个实例也是全量存储，每个redis存储的内容都是完整的数据，浪费内存且有木桶效应。
采用主从（master-replica）模式搭建。主节点提供日常服务访问，备节点提供HA高可用，当主节点发生故障，系统会自动在30秒内切换至备节点，保证业务平稳运行。
本系列文章将整理到我在GitHub上的《Java面试指南》仓库，更多精彩内容请到我的仓库里查看
一、主从复制 使用异步复制 一个服务器可以有多个从服务器 从服务器也可以有自己的从服务器 复制功能不会阻塞主服务器 可以通过服务功能来上主服务器免于持久化操作，由从服务器去执行持久化操作即可。
工作中需要将原本部署在物理机或虚拟机上的一些基础服务搬到kubernetes中，在搬的过程中遇到了不少坑，笔者在此特别分享一下所遇到的问题及相应的解决方法~ 一、异常网络引起的问题 之前使用redis-operator在kubernetes中部署了一套Redis集群，可测试的同事使用redis-benchmark随便一压测，这个集群就会出问题。经过艰苦的问题查找过程，终于发现了问题，原来是两个虚拟机之间的网络存在异常。 经验教训，在测试前可用iperf3先测试下node节点之间，pod节点
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
