高可用

来源： B 站 亿级流量电商详情页系统实战（第二版） 电商网站详情页架构： P3 ：架构 1 ：页面静态化架构； 小电商，静态页面少 Velocity/FreeMarker/Thymeleaf 模板 模板 + 数据 = 》最终的页面 如果模板或数据有变更，则需要重新渲染生成页面 html- 》推送 nginx P4 ：大型网站详情页架构 P5: 支撑高可用、高可靠、备份恢复 Redis 重要性 商品详情页的缓存架构： redis 架构： 1 ）高并发、高可用：海量数据，备份，随时可以恢复，缓存架构如果支撑这些， 首先， Redis 架构支撑：每秒几十万访问 QPS ， 99.99% 高可用， TB 级海量数据，备份和恢复，缓存架构就成功一半了。 最简单模式：存取 Redis 1 ）解决各种各样高并发场景下缓存面临的难题，缓存架构中不断引入各种解决方案和技术，解决高并发问题。 2 ）解决各种各样缓存架构本身面临的高可用问题，缓存架构中引入各种解决方案和技术，解决高可用问题。 P6: 指导虚拟机搭建 4 个节点 CentOS 集群 VirtualBox +CentOS6.5 内存 1G ，网卡选择桥接， 1 、配置网络 // 红色是 VI 的操作，紧随其后是具体命令 ; 先通过 DHCP 动态分配 IP ，然后将分配 IP （ ifconfig 查询结果）通过 static

openstack基础架构 为什么要用 Openstack kvm宿主机 2000台 查看每一个宿主机有多少台虚拟机? 查看每一个宿主机还剩多少资源? 查看每一台宿主机,每一个虚拟机的ip地址? excel 资产管理 cmdb kvm管理平台,数据库工具 Openstack 信息:宿主机,总配置,剩余的总配置 虚拟机的信息,配置信息,ip地址,操作系统 带计费功能的kvm管理平台,openstack ceilometer计费 ecs IAAS层 自动化管理kvm宿主机,云主机定制化操作 服务器， 20核心 1T内存 96T 资源浪费，linux环境特别乱，，kvm虚拟机 使用脚本自动化部署openstack M版 需要的脚本软件下载链接 提取码: v4nf 部署openstack 克隆一台openstack模板机: all-in-one 4G内存,开启虚拟化,挂载centos7.6的光盘 保证磁盘启动成功 修改网卡配置文件 IP 为10.0.0.11 上传选中的环境软件 解压openstack_rpm.tar.gz的压缩包 执行脚本 脚本执行完成后访问提示的网站 域为 default 用户名为admin 密码为ADMIN_PASS 创建一台实例 启动实例 可以上网 创建项目 测试是否可以连接 连接成功 添加规则 手动添加镜像 增加一个计算节点 按上面的添加步骤添加一台IP为10.0

​ 本文是Spring Cloud专栏的第五篇文章，了解前四篇文章内容有助于更好的理解本文： Spring Cloud第一篇 | Spring Cloud前言及其常用组件介绍概览 Spring Cloud第二篇 | 使用并认识Eureka注册中心 Spring Cloud第三篇 | 搭建高可用Eureka注册中心 Spring Cloud第四篇 | 客户端负载均衡Ribbon 一、微服务高可用技术 大型复杂的分布式系统中，高可用相关的技术架构非常重要。 高可用架构非常重要的一个环节，就是如何将分布式系统中的各个服务打造成高可用的服务，从而足以应对分布式系统环境中的各种各样的问题，避免整个分布式系统被某个服务的故障给拖垮。 比如： 服务间的调用超时 服务间的调用失败 要解决这些棘手的分布式系统可用性问题，就涉及到了高可用分布式系统中的很多重要的技术，包括： 资源隔离 限流与过载保护 熔断 优雅降级 容错 超时控制 监控运维 二、服务降级、熔断、限流概念 1、服务雪崩效应 服务雪崩效应产生与服务堆积在同一个线程池中，因为所有的请求都是同一个线程池进行处理，这时候如果在高并发情况下，所有的请求全部访问同一个接口，这时候可能会导致其他服务没有线程进行接受请求，这就是服务雪崩效应效应。 2、服务降级 在高并发情况下，防止用户一直等待，使用服务降级方式(直接返回一个友好的提示给客户端

一、目标和方式 1.目标： 　　 1）大型互联网应用的架构设计和业务处理 　　2）掌握PXC集群MySQL方案的原理 　　3）掌握PXC集群的强一致性 　　4）掌握PXC集群的高可用方案 2.分析方式 ：由浅入深，循序渐进；案例有小到大，逐步扩展 二、硬件环境需求 1.win /Linux/ MacOS 2.Docker虚拟机 3.内存8GB以上 三、单节点数据库的弊端 1.大型互联网程序用户群里庞大，所以架构必须要特殊设计 2.单节点的数据库无法满足性能上的要求，就像校园网查成绩的时候，如果1万人同时查，你可能拿到就是一个白屏，无论你是收费的还是免费的数据库，单节点都满足不了这种并发需求 3.单节点的数据库没有冗余设计，无法满足高可用，一旦这个机器出现问题，没有其他节点的数据库顶替，那网站将无法正常访问 单节点数据库测试，5000个连接，5000个并发查询，平均就1个连接1个查询，安装好数据库，配置好环境变量，[mysqld]下面配置最大连接量为6000（max_connections=6000），执行下面的命令： mysqlslap -hlocalhost -uroot -pabc123456 -P3306 --concurrency=5000 --iterations=1 --auto-generate-sql --auto-generate-sql-load-type

目录： 1·Memcached 主主复制概念 2·Memcached 高可用的实现 3·案例部署 4·总结 Memcached 主主复制概念 （1）主主复制概念： Memcached 主主复制是指在任意一台 Memcached 服务器修改数据都会被同步到另外一台，但是 Memcached API 客户端无法判断连接到那一台 Memcached 服务器，所有需要设置 VIP 地址，提供给 Memcached API 客户端进行连接。 （2）文章推荐： 知道了主主复制，那么需要了解 Memcached 是什么，还有一些最基本的情况，比如： 1） Memcached 功能 2）Memcached 特征 3）Memcached 储存方式 可以看看上篇文章 Memcached 高性能缓存对象 Memcached 高可用的实现 （1）怎么实现 Memcached 的高可用 1）这里就需要牵扯到主主复制的概念了，因为Memcached 主主复制这种架构，在程序连接的时候不会知道应该连接哪一个主服务器，所以需要在前端加上 VIP 地址，实现高可用架构。这里可以用 Keepalived 实现，所以说，Keepalived 的作用就是来检测 Memcached 服务器的状态是否正常。 2）Keepalived 会不断的检测 Memcached 主服务器的 11211端口，如果检测到 Memcached

一、MHA介绍 MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton（现就职于Facebook公司）开发，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。 MHA还提供在线主库切换的功能，能够安全地切换当前运行的主库到一个新的主库中（通过将从库提升为主库），大概0.5-2秒内即可完成。 自动故障检测和自动故障转移 MHA能够在一个已经存在的复制环境中监控MySQL，当检测到Master故障后能够实现自动故障转移，通过鉴定出最“新”的Salve的relay log，并将其应用到所有的Slave，这样MHA就能够保证各个slave之间的数据一致性，即使有些slave在主库崩溃时还没有收到最新的relay log事件。一个slave节点能否成为候选的主节点可通过在配置文件中配置它的优先级。由于master能够保证各个slave之间的数据一致性，所以所有的slave节点都有希望成为主节点。在通常的replication环境中由于复制中断而极容易产生的数据一致性问题，在MHA中将不会发生。

前言 2011年毕玄和竹庄两位大神将HBase引入阿里技术体系，2014年接力棒转到东8区第一位HBase commiter天梧手中，多年来与淘宝、旺旺、菜鸟、支付宝、高德、大文娱、阿里妈妈等几乎全BU合作伙伴携手共进，支撑了双十一大屏、支付宝账单、支付宝风控、物流详情等核心业务。 2018年双十一，HBase全天处理请求2.4万亿行，单集群吞吐达到千万级别。从一个婴儿成长为青年，阿里HBase摔过很多次，甚至头破血流，我们在客户的信任之下幸运的成长，感激涕零。 2017年开始阿里HBase走向公有云，我们有计划的在逐步将阿里内部的高可用技术提供给外部客户，目前已经上线了同城主备，将作为我们后续高可用能力发展的一个基础平台。 本文分四个部分回顾阿里HBase在高可用方面的发展：大集群、MTTF&MTTR、容灾、极致体验，希望能给大家带来一些共鸣和思考。 大集群 一个业务一个集群在初期很简便，但随着业务增多会加重运维负担，更重要的是无法有效利用资源。 首先每一个集群都要有Zookeeper、Master、NameNode这三种角色，固定的消耗3台机器。其次有些业务重计算轻存储，有些业务重存储轻计算，分离模式无法削峰填谷。因此从2013年开始阿里HBase就走向了大集群模式，单集群节点规模达到700+。 隔离性是大集群的关键难题。保障A业务异常流量不会冲击到B业务，是非常重要的能力

文章目录 个人感受 个人解毒（du） 基础篇 (6讲) 01高并发系统：它的通用设计方法是什么？ 02 | 架构分层：我们为什么一定要这么做？ 03 | 系统设计目标（一）：如何提升系统性能？ 04 | 系统设计目标（二）：系统怎样做到高可用？ 05 | 系统设计目标（三）：如何让系统易于扩展？ 07 | 池化技术：如何减少频繁创建数据库连接的性能损耗？ 08 | 数据库优化方案（一）：查询请求增加时，如何做主从分离？ 09 | 数据库优化方案（二）：写入数据量增加时，如何实现分库分表？ 10 | 发号器：如何保证分库分表后ID的全局唯一性？ 11 | NoSQL：在高并发场景下，数据库和NoSQL如何做到互补？ 演进篇 · 缓存篇 (6讲) 12 | 缓存：数据库成为瓶颈后，动态数据的查询要如何加速？ 13 | 缓存的使用姿势（一）：如何选择缓存的读写策略？ 14 | 缓存的使用姿势（二）：缓存如何做到高可用？ 15 | 缓存的使用姿势（三）：缓存穿透了怎么办？ 16 | CDN：静态资源如何加速？ 加餐 | 数据的迁移应该如何做？ 演进篇 · 消息队列篇 (6讲) 17 | 消息队列：秒杀时如何处理每秒上万次的下单请求？ 18 | 消息投递：如何保证消息仅仅被消费一次？ 19 | 消息队列：如何降低消息队列系统中消息的延迟？ 演进篇 · 分布式服务篇 (9讲) 21 |

简单介绍 当要将配置中心部署到生产环境中时，与服务注册中心一样，我们也希望它是一个高可用的应用。Spring Cloud Config实现服务端的高可用非常简单，主要有以下两种方式。 传统模式 ：不需要为这些服务端做任何额外的配置，只需要遵守一个配置规则，将所有的Config Server都指向同一个Git仓库，这样所有的配置内容就通过统一的共享文件系统来维护。而客户端在指定Config Server位置时，只需要配置Config Server上层的负载均衡设备地址即可， 就如下图所示的结构。 服务模式 ：除了上面这种传统的实现模式之外，我们也可以将Config Server作为一个普通的微服务应用，纳入Eureka的服务治理体系中。这样我们的微服务应用就可以通过配置中心的服务名来获取配置信息，这种方式比起传统的实现模式来说更加有利于维护，因为对于服务端的负载均衡配置和客户端的配置中心指定都通过服务治理机制一并解决了，既实现了高可用，也实现了自维护。由于这部分的实现需要客户端的配合，具体示例读者可详细阅读 “客户端详解 ”一节中的 “服务化配置中心” 小节。 原理描述   通过上图我们能看到配置服务其实是从本地的Git仓库中获取的信息，Git本地库通过pull命令同步远程库中的内容。当配置中心客户端重新启动的时候会显示的执行pull命令来拉取最新的配置信息

2011年毕玄和竹庄两位大神将HBase引入阿里技术体系，2014年接力棒转到东8区第一位HBase commiter天梧手中，多年来与淘宝、旺旺、菜鸟、支付宝、高德、大文娱、阿里妈妈等几乎全BU合作伙伴携手共进，支撑了双十一大屏、支付宝账单、支付宝风控、物流详情等核心业务。 2018年双十一，HBase全天处理请求2.4万亿行，单集群吞吐达到千万级别。从一个婴儿成长为青年，阿里HBase摔过很多次，甚至头破血流，我们在客户的信任之下幸运的成长，感激涕零。 2017年开始阿里HBase走向公有云，我们有计划的在逐步将阿里内部的高可用技术提供给外部客户，目前已经上线了同城主备，将作为我们后续高可用能力发展的一个基础平台。 本文分四个部分回顾阿里HBase在高可用方面的发展：大集群、MTTF&MTTR、容灾、极致体验，希望能给大家带来一些共鸣和思考。 大集群 一个业务一个集群在初期很简便，但随着业务增多会加重运维负担，更重要的是无法有效利用资源。 首先每一个集群都要有Zookeeper、Master、NameNode这三种角色，固定的消耗3台机器。其次有些业务重计算轻存储，有些业务重存储轻计算，分离模式无法削峰填谷。因此从2013年开始阿里HBase就走向了大集群模式，单集群节点规模达到700+。 隔离性是大集群的关键难题。保障A业务异常流量不会冲击到B业务，是非常重要的能力