集群效应

使用哨兵模式 可以达到redis高可用目的，但是此时的每个Redis存有集群中的所有数据，从而导致集群的总数据存储量受限于可用存储内存最小的节点，形成了木桶效应。 在redis3.0之前，我们需要通过客户端（写代码）去做分片（数据拆分成多份），通过hash方式对key进行分片存储，客户端分片虽然能够解决各个节点的存储压力，但维护成本较高、增加、移除节点比较繁琐。 因此在redis3.0版本开始提供了Redis cluster集群功能，集群的特点在于拥有和单机实例一样的性能，同时提供了数据分片存储的支持，以及在主Redis数据库故障后自动故障转移恢复的支持。 哨兵 和 集群 是两个独立的功能，当不需要对数据进行分片使用哨兵就够了，如果要进行水平扩容，redis cluster是一个比较好的方式； 1.拓扑结构 一个 Redis Cluster 由多个Redis节点构成，不同节点组的redis数据没有交集，也就是每个一节点组对应数据的一个分片，节点组内部分为主备两类节点，对应master和slave节点，两者数据准实时一致，通过异步化的主备复制机制来保证。一个节点组有且只有一个master节点，同时可以有0（没有）到多个slave节点，在这个节点组中只有master节点对用户提供些服务； 2.Redis的数据分区 Redis cluster从Redis 3.0版本开始支持； Redis

redis高可用的集群模式 使用集群，只需要将每个数据库节点的cluster-enable配置打开即可。每个集群中至少需要三个主数据库才能正常运行。即使使用哨兵，redis每个实例也是全量存储，每个redis存储的内容都是完整的数据，浪费内存且有木桶效应。为了最大化利用内存，可以采用集群，就是分布式存储。即每台redis存储不同的内容。集群至少需要3主3从，且每个实例使用不同的配置文件，主从不用配置，集群会自己选。 修改每个实例的配置文件： 集群的运行： 节点的握手方式：在A节点上执行cluster <ip> <port>命令（IP，port是B节点的地址），通过ping-pong方式来确定两个节点的握手。 集群的每个数据库都被分为16384个槽，通过cluster addslots命令可以将一个或多个槽分配给节点。只有所有16384个槽被分配完了，当前集群才是上线状态，只要有一个槽没有被分配，集群就是下线状态。 每个节点都有自己的slots数组(clusterNode.slots)来决定自己处理哪些槽，同时节点也会将自己的slots数组告知其他节点，这样每个节点处理的槽的分配在整个集群都是透明的。 clusterState结构中的slots数组(clusterState.slots)记录了集群中所有16384个槽的指派信息，slots数组包含16383个项

即使有了主从复制，每个数据库都要保存整个集群中的所有数据，容易形成木桶效应。 使用Jedis实现了分片集群，由客户端控制哪些key数据保存在哪个数据库中，如果在水平扩容时必须手动进行数据迁移，而且需要将整个集群停止服务，这样做非常不好的。 Redis3.0版本的一大特性就是集群，接下来一起来看看Redis集群。 架构： Redis集群特征： 1. 所有的Redis节点彼此互联（PING-PONG机制），内部使用二进制协议优化传输速度和带宽。 2. 节点的Fail时通过集群中超过半数的节点检测失效时才生效。 3. 客户端与Redis节点直连，不需要通过中间Proxy代理层，客户端不需要连接集群所有节点，连接集群中任何一个节点可用即可。 4. Redis-Cluster把所有的物理节点映射到[0-16383]Slot（插槽）上，Cluster负责维护Node -> Slot -> Value Redis集群配置文件设置： 1. 沿用不同的端口，6379，6380，6381 2. 开启集群，cluster-enabled yes 3. 指定集群的配置文件： cluster-config-file "node-xxx.conf" 来源： https://www.cnblogs.com/fubinhnust/p/11960596.html

现实中redis需要若干台redis服务器的支持： （1）从结构上，单个Redis服务器会产生单点故障，同时一台服务器需要承受所有的请求负载。这就需要为数据生成多个副本并分配在不同的服务器上。 （2）从容量上，单个Redis服务器的内存非常容易成为存储瓶颈，所以需要进行数据分片。 同时拥有多个Redis服务器后就会面临如何管理集群的问题，包括如何增加节点，故障恢复等操作。 1. 复制 通过持久化功能，Redis保证了即使在服务器重启的情况下也不会损失(或少量损失)数据。 但是由于数据是存储在一台服务器上的，如果这台服务器出现硬盘故障等问题，也会导致数据丢失。为了避免单点故障，通常的做法是将数据库复制多个副本部署在不同的服务器上，这样即使有一台服务器出现故障，其他服务器依然可以继续提供服务。为此， Redis提供了复制(replication)功能，可以实现当一台服务器中的数据更新后，自动更新的数据同步到其他数据库上 。 2. 哨兵 在一个典型的一主多从的Redis系统中，从数据库在整个系统中起到了数据冗余备份和读写分离的作用。当主数据库遇到异常中断服务后，开发者可以通过手动的方式选择一个从数据库升级为主数据库，以使得系统能够继续提供服务。然而整个过程相对麻烦且需要人工介入，难以实现自动化。为此， Redis2.8中提供了哨兵工具来实现自动的系统监控和故障恢复功能 。 3. 集群：

名字服务就是服务间“你寻我，我寻你”的爱情游戏，因为它总是为彼此找到最佳"伴侣"，不是么？ 在之前的文章中多次提到名字服务这个概念，也很多人在问这是个什么东西？为什么我老是提起它？首先因为太重要了，直接决定着运维自动化平台的水平、简单与复杂；其次我做这么多年运维，对名字服务有着很深的情节（可能觉得它很酷），终于这次在自己负责的业务里面落地，也有了实践的经验，避免来虚的；最后，它能把技术架构对可运维性的理念表现得淋漓尽致,是一个自维护架构的重要标尺。 在11年左右，当时也提出基于某统一的server框架自动构建名字服务中心的做法，把容器服务和腾讯的一个调度中心L5（后面会介绍）进行集成，降低运维工作量。也许是因为当年自己思考不成熟和全面，最终这个方案没有走向实施，有些可惜。不过在目前的单位，遇到一位大牛，最初提出想法，上面支持就开始做了，运维就需要这样的研发拍档。 首先需要讲几个概念： 1、服务 是一个、组、类功能或者接口的业务描述，比如说注册用户、发送短信。转化到技术层面上就会对应一个api或者接口，此时会触发一次远程的RPC调用，函数内的功能不是。 2、服务实例 服务实例是服务对应的一组IP和端口的简称。当前端服务需要请求后端某服务的时候，此时需要先找到对应的服务运行实例，也就是进程和端口，然后才能建立connection，从而发起请求。 3、服务注册

PS ：主要罗列的是问题点，以及对应的一些解决方案，仅供参考。。。 相关链接： 阿里全链路压测 有赞全链路压测 京东全链路压测 饿了么全链路压测 滴滴全链路压测解决之道 美团全链路压测自动化实践 逻辑思维在全链路压测方面的实践 一、什么是全链路压测 基于实际的生产业务场景、系统环境，模拟海量的用户请求和数据对整个业务链进行压力测试，并持续调优的过程。 二、全链路压测解决什么问题 针对业务场景越发复杂化、海量数据冲击下整个业务系统链的可用性、服务能力的瓶颈，让技术更好的服务业务，创造更多的价值。 三、面对的问题点以及解决方案 1、业务模型梳理 首先应该明确的是：全链路压测针对的是现代越来越复杂的业务场景和全链路的系统依赖。所以首先应该将核心业务和非核心业务进行拆分，确认流量高峰针对的是哪些业务场景和模块， 针对性的进行扩容准备，而不是为了解决海量流量冲击而所有的系统服务集群扩容几十倍，这样会造成不必要的成本投入。 2、数据模型构建 数据构建和准备，应该考虑这几点问题： ①、数据的真实性和可用性 可以从生产环境完全移植一份当量的数据包，作为压测的基础数据，然后基于基础数据，通过分析历史数据增长趋势，预估当前可能的数据量； ②、数据脱敏 基于生产环境的全链路压测，必须考虑的一点是不能产生脏数据，以免对生产造成影响，影响用户体验等，因此在数据准备时需要进行数据脱敏； ③、数据隔离 同样

【51CTO.com原创稿件】Kubernetes是Google开源的一个容器编排引擎，它支持自动化部署、大规模可伸缩、应用容器化管理。伴随着云原生技术的迅速崛起，如今Kubernetes 事实上已经成为应用容器化平台的标准，越来越受到企业的青睐，在生产中也应用的越来越广泛。 我们的容器平台建设从2016年开始，大致经历了探索预研、体系建设和平台落地这样三个阶段。 下面就从Kubernetes的网络、存储、集群管理和监控与运维几个方面来分享下我们容器云平台建设走过的历程，希望给大家一些思考和启发。 一、kubernetes网络 容器网络发展到现在，已经是双雄会的格局。双雄会其实指的就是Docker的CNM和Google、CoreOS、Kuberenetes主导的CNI。首先明确一点，CNM和CNI并不是网络实现，他们是网络规范和网络体系，从研发的角度他们就是一堆接口，你底层是用Flannel也好、用Calico也好，他们并不关心，CNM和CNI关心的是网络管理的问题。 网络需求调研发现，业务部门主要关注以下几点：1、容器网络与物理网络打通2、速度越快越好3、改动越少越好4、尽可能少的风险点。 容器的网络方案大体可分为协议栈层级、穿越形态、隔离方式这三种形式。 协议层级：二层比较好理解，在以前传统的机房或虚拟化场景中比较常见，就是基于桥接的 ARP+MAC 学习，它最大的缺陷是广播

Kubernetes是Google开源的一个容器编排引擎，它支持自动化部署、大规模可伸缩、应用容器化管理。伴随着云原生技术的迅速崛起，如今Kubernetes 事实上已经成为应用容器化平台的标准，越来越受到企业的青睐，在生产中也应用的也越来越广泛。 我们的容器平台建设从2016年开始，大致经历了探索预研、体系建设和平台落地这样三个阶段。 下面就从Kubernetes的网络、存储、集群管理和监控与运维几个方面来分享下我们容器云平台建设走过的历程，希望给大家一些思考和启发。 一、 kubernetes网络 容器网络发展到现在，已经是双雄会的格局。双雄会其实指的就是Docker的CNM和Google、CoreOS、Kuberenetes主导的CNI。首先明确一点，CNM和CNI并不是网络实现，他们是网络规范和网络体系，从研发的角度他们就是一堆接口，你底层是用Flannel也好、用Calico也好，他们并不关心，CNM和CNI关心的是网络管理的问题。 网络需求调研发现，业务部门主要关注以下几点：1、容器网络与物理网络打通2、速度越快越好3、改动越少越好4、尽可能少的风险点。 容器的网络方案大体可分为协议栈层级、穿越形态、隔离方式这三种形式 协议栈层级：二层比较好理解，在以前传统的机房或虚拟化场景中比较常见，就是基于桥接的 ARP+MAC 学习，它最大的缺陷是广播。因为二层的广播