高可用

原文：http://www.uml.org.cn/sjjm/sjjm-MySql.asp MySQl MySQL高可用数据库内核深度优化的四重定制 MySQL数据表存储引擎类型及特性 MySQL分布式数据库高可用架构、复制机制、多机房 Mysql高并发优化 我必须得告诉大家的MySQL优化原理 MySQL注入攻击与防御 腾讯云：MySQL数据库的高可用性分析 一步一步打造MySQL高可用平台 MySQL 日志管理详解 MySQL锁解决并发问题详解 MySQL的配置与管理 MySQL日志管理 MySQL 5.7新特性介绍 MySQL数据库读写分离中间件Atlas 京东MySQL数据库主从切换自动化 全面了解MySql中的事务 MySQL NULL值简介 MySQL备份的持续验证：还原备份 初识MySQL存储过程 优步工程团队对容器化MySQL的应用 MySQL NULL值简介 MySQL备份的持续验证：还原备份 MySQL SQL语句优化技巧 MySQL简单主从方案及暴露的问题 Uber为什么从Postgres迁移到MySQL 一种MySQL到HBase的迁移策略的研究与实现 MySQL 索引详解大全 MYSQL企业常用架构与调优经验分享 SQL优化之六脉神剑 MySQL 大表优化方案探讨 mysql 数据库引擎 MySQL数据库事务隔离级别 MySQL 用户权限详细汇总

前言： HAProxy HAProxy主要是提供高可用性、负载均衡以及基于TCP(4层)和HTTP(7层)应用的代理，支持虚拟主机，它是免费、快速并且可靠的一种解决方案。特别适用于那些负载特大的web站点，这些站点通常又需要会话保持或七层处理。HAProxy运行在时下的硬件上，完全可以支持数以万计的并发连接。并且它的运行模式使得它可以很简单安全的整合进当前的架构中，同时可以保护web服务器不被暴露到网络上。 Keepalived Keepalived是一个基于VRRP协议来实现的LVS服务高可用方案，可以利用其来避免单点故障。一个LVS服务会有2台服务器运行Keepalived，一台为主服务器（MASTER），一台为备份服务器（BACKUP），但是对外表现为一个虚拟IP，主服务器会发送特定的消息给备份服务器，当备份服务器收不到这个消息的时候，即主服务器宕机的时候，备份服务器就会接管虚拟IP，继续提供服务，从而保证了高可用性。 环境准备： 10.0.0.7 web01 10.0.0.8 web02 10.0.0.3 lib0110.0.0.4 lib0210.0.0.55 VIP centOS 7 通过部署haproxy负载均衡，keepalived lib01与lib02实现高可用 首先lib01上部署haproxy负载均衡关闭selinux、关闭iptables 1）安装常用软件

高可用性机制 RocketMQ分布式集群是通过Master和Slave的配合达到高可用的 Master和Slave的区别:Broker配置文件中,参数brokerId的值为0带包这个Broker是Master,大于0是Slave Master角色的Broker支持读和写,Slave角色的Broker仅支持读 消费高可用 有了主从结构之后,内部实现了自动切换,当Master不可用或繁忙的时候,会自动切换到Slave读,折旧达到了消费端的高可用 发送高可用 创建Topic时,把Topic的多个Message Queue创建在多个Broker组上,当一个Broker的Master不可用后,其他组的Master任然可用, 如果需要把Slave转换成Master,需要手动停止Slave角色的Broker,更改配置文件,用新的配置文件启动Broker 消息主从复制 如果一个Broker组有Master和Slave,消息需要从Master复制到Slave上,有同步和异步两个 复制方式 同步复制:等Master和Slave都写入成功后才反馈给客户端成功状态 异步复制:只要Master写入成功后就反馈给客户端成功的状态 配置:通过Broker配置文件中的brokerRole参数进行设置 Master有ASYNC_MASTER,SYNC_MASTER两个配置 Slave只有SLAVE 总结

1.电商案例原因 分布式大型网站，目前看主要有几类： 1.大型门户，比如网易，新浪等； 2.SNS网站，比如校内，开心网等； 3.电商网站：比如阿里巴巴，京东商城，国美在线，汽车之家等。大型门户一般是新闻类信息，可以使用CDN，静态化等方式优化，开心网等交互性比较多，可能会引入更多的NOSQL，分布式缓存，使用高性能的通信框架等。 电商网站具备以上两类的特点，比如产品详情可以采用CDN，静态化，交互性高的需要采用NOSQL等技术。 因此，我们采用电商网站作为案例，进行分析。 2 电商网站需求 客户需求： 建立一个全品类的电子商务网站（B2C），用户可以在线购买商品，可以在线支付，也可以货到付款； （1）用户购买时可以在线与客服沟通； （2）用户收到商品后，可以给商品打分，评价； （3）目前有成熟的进销存系统；需要与网站对接； （4）希望能够支持3~5年，业务的发展； （5）预计3~5年用户数达到1000万； （6）定期举办双11，双12,三八男人节等活动； （7）其他的功能参考京东或国美在线等网站。 客户就是客户，不会告诉你具体要什么，只会告诉你他想要什么，我们很多时候要引导，挖掘客户的需求。好在提供了明确的参考网站。因此，下一步要进行大量的分析，结合行业，以及参考网站，给客户提供方案。 需求管理传统的做法，会使用用例图或模块图（需求列表）进行需求的描述

前言： spring-cloud为基础的微服务架构，所有的微服务都需要注册到注册中心，如果这个注册中心阻塞或者崩了，那么整个系统都无法继续正常提供服务，所以，这里就需要对注册中心进行集群，换言之，高可用（HA） 前提： 阅读并完成第一个注册中心的项目，环境无需改变。本文是模拟的高可用，可以复制两个注册中心的项目单独修改各自的配置文件达到同样的效果 修改hosts，在文件末添加两行如下： 127.0.0.1 peer1127.0.0.1 peer2 推荐使用notepad++，如果是win10会提醒提权限，确定，然后保存即可。 项目搭建： 打开注册中心的项目，在src/resources下创建一个application-peer1.properties [url=] [/url] #应用名spring.application.name=eureka-server#提供服务端口1111server.port=1111#提供服务的域名，这里在hosts文件中修改了eureka.instance.hostname=peer1#向第二个注册中心注册自己eureka.client.service-url.defaultZone=http://peer2:1112/eureka/ [url=] [/url] 在src/resources下创建一个application-peer2

转载来自于： Borg/Mesos/Yarn三大主流资源管理与调度系统对比 0. 前言 Mesos（Twitter）、YARN（apache）和Borg(google)三个资源管理与调度系统可以说是目前资源管理和调度系统的先导者，现有的大多数资源管理和调度系统都从这三个系统中吸纳设计思想。对这三个系统的对比总结有助于更好的了解目前资源管理与调度系统的状态和未来的发展趋势。 需要特别说明的是，borg系统所提出的思想直接影响了资源管理和调度系统的发展，例如其提出的在线任务和离线任务混合部署的思路以及资源超售的思路领先行业十余年。直到今天一些业界的系统才开始在混部方面进行探索，而borg早在十多年前就已经提出并在内部系统中进行成熟使用。 对于这三个系统最早出现的应该是borg，其是谷歌内部的资源管理系统，但是一直没有对外公开，直到2015年才发表论文进行说明。接着是Mesos系统，发表于2012年左右，YARN系统发表于2013年，这三个系统无论是在架构设计还是针对的场景、实现思路上都存在较大的差异，下面将针对不同的维度进行阐述。 1. 架构方面 borg架构 Mesos架构 YARN架构 相同之处：三种架构都是基于master/slave架构进行设计的，master主要负责全局的资源分配，slave节点主要负责本节点的各项信息收集、汇报工作。但是具体的实现细节方面还有很大差别。

RabbitMQ的集群方案有以下几种： 1.普通的集群 exchange，buindling再所有的节点上都会保存一份，但是queue只会存储在其中的一个节点上，但是所有的节点都会存储一份queue的meta信息。因为这样有两个好处： 1）存储空间。如果每一个节点上都有全部的消息，有多少个节点就会有多少个消息总量的copy。加入一个队列的消息占用的空间是1G，那么三个节点就是3G 2) 性能。消息需要在节点之间传输会有很大的网络开销。如果消息设置了durable即持久化，还会增加很大的磁盘负载 队列存储的节点取决于，创建队列的客户端当时所连接的节点。如果生产者连接的是另外一个节点，将会把消息转发到存储该队列的节点上。如果消费者连接了非存储队列的节点取数据，者从存储消息的节点拉去数据。所以： 1)创建队列都连到了一个节点上，所有的队列都存储在一个节点上。 2)存消息的节点挂掉了，consumer只能等到节点恢复后才能读到消息。 3）设A,B节点，queue数据在A上：可以向A或B生产或消费消息。但是一旦往B生产消息时A挂了，client是不会收到任何错误信息的并可以继续发送，而实际上消息是被丢弃了。一旦此时client挂了后在连接B会报节点A不存在而失败。在B读也是类似的，在client批量取到的数据读完之前是不会感知A有没有挂掉，等到读取下一批数据时一旦A挂掉会报错。

你能聊聊redis cluster集群模式的原理吗？ 1、面试题redis集群模式的工作原理能说一下么？在集群模式下，redis的key是如何寻址的？分布式寻址都有哪些算法？了解一致性hash算法吗？ 2、面试官心理分析 在以前，如果前几年的时候，一般来说，redis如果要搞几个节点，每个节点存储一部分的数据，得借助一些中间件来实现，比如说有codis，或者twemproxy，都有。有一些redis中间件，你读写redis中间件，redis中间件负责将你的数据分布式存储在多台机器上的redis实例中。这两年，redis不断在发展，redis也不断的有新的版本，redis cluster，redis集群模式，你可以做到在多台机器上，部署多个redis实例，每个实例存储一部分的数据，同时每个redis实例可以挂redis从实例，自动确保说，如果redis主实例挂了，会自动切换到redis从实例顶上来。现在redis的新版本，大家都是用redis cluster的，也就是redis原生支持的redis集群模式，那么面试官肯定会就redis cluster对你来个几连炮。要是你没用过redis cluster，正常，以前很多人用codis之类的客户端来支持集群，但是起码你得研究一下redis cluster吧。 redis如何在保持读写分离+高可用的架构下，还能横向扩容支持1T+的海量数据

使用 3 台阿里云服务器（k8s-master0, k8s-master1, k8s-master2）作为 master 节点搭建高可用集群，负载均衡用的是阿里云 SLB ，需要注意的是由于阿里云负载均衡不支持后端服务器自己转发给自己，所以 master 节点的 control-plane-endpoint 不能走负载均衡。 先在 k8s-master0 上安装好 k8s ，安装步骤见 Ubuntu 安装 k8s 三驾马车 kubelet kubeadm kubectl ，然后打快照创建阿里云 ecs 镜像。 确定 control-plane-endpoint 主机名，这里假设是 k8s-api ，在 k8s-master0 的 hosts 中添加 k8s-api 的解析。 10.0.1.81 k8s-api 在 k8s-master0 上创建集群， kubeadm init \ --control-plane-endpoint "k8s-api:6443" --upload-certs \ --image-repository registry.aliyuncs.com/google_containers \ --pod-network-cidr=192.168.0.0/16 \ --v=6 创建成功后会出现下面的提示 Your Kubernetes control-plane

参考: 龙果学院 http://www.roncoo.com/share.html?hamc=hLPG8QsaaWVOl2Z76wpJHp3JBbZZF%2Bywm5vEfPp9LbLkAjAnB%2BnHpF8rHqMAsZ9U%2Ff1CcK%2Fi%2BOWuJ8pVcwcq6A%3D%3D 一、场景需求 二、Keepalived 简要介绍 Keepalived 是一种高性能的服务器高可用或热备解决方案，Keepalived 可以用来防止服务器单点故障的发生，通过配合 Nginx 可以实现 web 前端服务的高可用。 Keepalived 以 VRRP 协议为实现基础，用 VRRP 协议来实现高可用性(HA)。VRRP(VirtualRouter Redundancy Protocol)协议是用于实现路由器冗余的协议，VRRP 协议将两台或多台路由器设备虚拟成一个设备，对外提供虚拟路由器 IP(一个或多个)，而在路由器组内部，如果实际拥有这个对外 IP 的路由器如果工作正常的话就是 MASTER，或者是通过 算法 选举产生，MASTER 实现针对虚拟路由器 IP 的各种网络功能， 如 ARP 请求，ICMP，以及数据的转发等；其他设备不拥有该虚拟 IP，状态是 BACKUP，除了接收 MASTER 的VRRP 状态通告信息外，不执行对外的网络功能。当主机失效时，BACKUP