高可用

作者知乎id：一路走好 本人目前做图的底层存储引擎“分片和副本分布式可扩展”相关的研究，来满足业务的快速增长。 本文内容大量来自被我阅读的文章。感谢王建奎博士~~ 华为 先来说说最神秘的华为吧，华为的图数据库构建在多模数据库中，由高斯实验室负责原型研发，图数据库的 headcount 由任总钦点，图数据库在华为重要性可想而知，但是由于华为保密要求严格，凡事都不让对外说。技术领先，设计方案简单高效。其他朋友不方便多跟我说，不过团队从现在到前后会新增 至少 20 个 headcount，任总有要求，非招人不可大有可为呀。如果有想去上海工作的朋友，欢迎联系我，我帮你联系我的朋友。 费马科技 洪春涛学长在北京BDTC2017中国大数据技术大会上深入分析了当时图数据库和图计算领域的难点、现状以及费马在2个领域的优化和产品能力。我当时真的对那几个优化数字感到震惊费马的性能真的非常好，团队也非常专业。京东金融是他们的一个客户案例（详细可查看：https://fma-ai.cn/case）。 费马科技是一个专注图数据库和图计算的创业公司，主打：快如闪电的高性能图数据存储及分析平台。 LightGraph 是费马科技自主研发的图数据库产品。其主要特点是单机大数据量，高吞吐率，以及灵活的 API，同时支持高效的在线事务处理（OLTP）和在线分析处理（OLAP）。LightGraph支持 TB

Logstash基于Nginx的HA高可用架构 应用场景 架构图 Nginx安装 Nginx配置 logstash配置 总结 应用场景 最近，在项目当中部署在客户端的logstash在采集日志的时候由于日志量过大，并且没有开启本地磁盘持久化操作，logstash限制了一部分filebeat的日志数据传输，导致数据有丢失的现象，为了能够更好的满足客户端采集收集日志的高可用需求，今天介绍下如何在客户端基于nginx做一个logstash的高可用。 架构图 简单介绍下架构图： 客户端安装多个filebeat对应用日志进行监控并发送给nginx ； nginx监听端口，转发请求给logstash ； logstash监听nginx转发的端口 ； logstash打开本地磁盘持久化配置 ； Nginx安装 yum install -y gcc-c++ #会自动安装依赖gcc 和更新（或安装）依赖 libgcc yum install -y pcre pcre-devel yum install -y zlib zlib-devel yum -y install openssl openssl-devel cd /usr/local wget https://nginx.org/download/nginx-1.16.0.tar.gz tar -xvf nginx-1.16.0.tar.gz

proxmox VE私有云平台，既可以在物理节点单独部署，也可以数个物理节点组成高可用集群。虽然单节点的proxmox VE平台可用性较差，但在某种场景下，可满足特定的需求。比如对可用性要求不高的测试环境、资金预算紧张且访问量小的应用…。 这里有个重要的概念需要区分一下，那就是proxmox VE集群与高可用。Proxmox VE集群是针对物理节点，建立起集群后，方便统一管理，即用浏览器访问任意物理节点地址，皆可对集群的所有节点以及其它计算资源进行管理；proxmox VE高可用是建立在物理节点集群之上，依赖共享存储（使用ceph分布式存储去中心化，提供底层可用性及IO性能）来保证物理节点创建的虚拟机的可用性。通俗地说，proxmox VE高可用集群所创建的虚拟机镜像位于共享存储（如ceph、nfs等），各物理节点提供计算资源（cpu、内存、网络等），一旦某物理节点故障，运行其上的所有被配置成高可用属性的虚拟机，就会自动漂移到其它正常的物理节点，对外继续提供服务。 场景描述 某小型创业项目，办公室拉了一条专线，ISP服务方提供了一个唯一的公网ip。有一台1u的dell R410机架式服务器，配置、性能一般。要用此有限条件，实现如下功能：  在此物理机部署多个php、java应用；  根据应用部署多个独立的mysql数据库服务器；  内网网皆能访问这些应用。 要达到上述目标

1. 裂脑介绍 两个节点互相认为对方已挂掉，然后开始争抢共享资源，结果会导致系统混乱，数据损坏。这就是脑裂问题。 2.如何产生的裂脑现象 高可用服务器之间 心跳线链路 故障，导致无法正常通信。 1.心跳线坏了（包括断了，老化）。 2.网卡即相关驱动坏了，IP配置及冲突问题（网卡直连） 3.心跳线间连接的设备故障（网卡及交换机） 高可用服务器对上开启了iptables防火墙阻挡了心跳信息传输。 高可用服务器对上心跳网卡地址等信息配置不正确，导致发送心跳失败。 其他服务器配置不当等原因，如心跳方式不同，心跳广播冲突，软件BUG 3 .解决方案 同时使用串行电缆和以太网电缆连接，同时用两条心跳线路，这样一条线路坏了，另一个还是好的，依然能传送心跳消息。 当检测到裂脑时强行关闭一个心跳节点（这个功能需特殊设备支持，如fence,stonith）。相当于备节点接收不到心跳信息，发送关机命令通过单独的线路关闭主节点电源。 做好对裂脑的监控报警（如邮件及手机短信等），在问题发生时人为的第一时间介入仲裁，降低损失。例如：百度的监控报警短信就有上行和下行的区别。报警信息到管理员手机上，就可以通过回复对应的字符串等操作就可以返回给服务器，让服务器根据指令自动执行处理相关故障 4.监测裂脑的脚本 原理：master主机能ping通且slave主机有VIP地址就是裂脑现象 #!/bin/sh while

MHA高可用集群 文章目录 一、MHA 简介： 二、部署 MHA： 第一步：三台主从服务器安装 mysql 第二步：修改 mysql 的主配置文件：/etc/my.cnf ，注意三台服务器的 server-id 不能一样 第三步：三台服务器启动 mysql 服务 第四步：配置 Mysql 主从同步（一主两从） 第五步：安装 MHA 第六步：启动 MHA 一、MHA 简介： MHA（Master High Availability） （1）简介 目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton（现就职于Facebook公司）开发，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。 （2）该软件由两部分组成： MHA Manager（管理节点）和MHA Node（数据节点）。MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave节点上。MHA Node运行在每台MySQL服务器上，MHA Manager会定时探测集群中的master节点，当master出现故障时

原文: 003.MySQL高可用主从复制新增slave 一 基础环境 主机名 系统版本 MySQL版本 主机IP master CentOS 6.8 MySQL 5.6 172.24.8.10 slave01 CentOS 6.8 MySQL 5.6 172.24.8.11 slave02 CentOS 6.8 MySQL 5.6 172.24.8.20 二 新增slave2方案 2.1 方案1:-复制主库 复制主库要步骤： 将内存中的数据同步到表中； 锁定表,不让出现新数据； 备份； 解锁； 将备份传送到slave02，在slave02上同步数据； slave2上设置相应的master_log_file和master-log_pos。 2.2 方案2：复制从库 停止从库slave01：mysql> stop slave； 看当前从库的状态，mysql> show slave status;记下 Relay_Master_Log_file 和 Exec_Master_Log_Pos； 备份从库数据 将备份传送到slave02，在slave2上同步数据； slave02上设置相应的master_log_file和master-log_pos。 注意：此方案中master_log_file和master-log_pos也和slave中一样，指向主库。 2.3 方案对比

初始需求 元数据的存储（小数据） 分布式、高可用 读多写少、高性能读 有序访问 设计 单机层面 节点数据结构的选取 树结构，每个节点是一个ZNode 数据保存在内存中 优点：高效读写 为什么ZK不擅长存储大的数据？ 单机高效写磁盘 高效写磁盘的两种方式： 顺序写磁盘 预分配磁盘空间 ZK每次写磁盘，先申请固定大小的磁盘空间，之后再写磁盘，大大提升写入性能。 顺序写数据 每次写入操作，ZooKeeper会附加一个数字标签，表明ZooKeeper中的事务顺序 高可用、宕机可恢复 快照+事务日志 什么时候记录事务日志？ 如何快照？新起线程，不影响主流程 分布式层面 顺序写数据 一主多从结构，只有一台master服务器对外提供写服务，每次写记录ZXID事务Id。原子写，保证mei yo 如何保证数据强一致 写的策略，半数以上机器写成功后返回。 写数据流程，非Leader节点会把请求转发给leader，写成功后leader再通知该节点。 ZAB协议：初始阶段/宕机恢复（原子广播） 如何提高读的性能 follower节点，observer节点都可以对外提供读数据能力 怎么保证读取的强一致？ 客户端在调用前，可以先申请连接的主机同步leader数据，调用sync()方法 。 水平扩容 ZK做的不好的地方。 ZooKeeper 在水平扩容扩容方面做得并不十分完美，需要进行整个集群的重启

一个复杂的系统往往都是从一个小而简的系统发展衍化而来，为了满足日益增长的业务需求，不断的增加系统的复杂度，从单体架构逐步发展为分布式架构，而分布式系统架构的设计主要关注：高性能，高可用，高拓展 分布式事务 高可用是指系统无中断的执行功能的能了，代表了系统的可用程度，是进行系统设计时必须要遵守的准则之一。 而高可用的实现方案，无外乎就是冗余，就存储的高可用而言，问题不在于如何进行数据备份，而在于如何规避数据不一致对业务造成的影响 对于分布式系统而言，要保证分布式系统中的数据一致性就需要一种方案，可以保证数据在子系统中始终保持一致，避免业务出现问题，这种实现方案就叫做分布式事务，要么一起成功，要么一起失败，必须是一个整体性的事务 理论基础 ​ 在讲解具体方案之前，有必要了解一下分布式中数据设计需要遵循的理论基础，CAP理论和BACS理论，为后面的实践铺平道路 CAP理论 CAP：Consistency Acailability Partition tolerance 的简写 Consistency：一致性 对某个客户端来说，读操作能够返回最新的写操作结果 Acailability：可用性 非故障节点在合理的时间内返回合理的响应 Partition tolerance：分区容错性 当出现网络分区后，系统能够继续提供服务 你知道什么是网络分区吗 ~~

在关于 高并发负载均衡 一文中已经提到，企业在解决高并发问题时，一般有两个方向的处理策略，软件、硬件，硬件上添加负载均衡器分发大量请求，软件上可在高并发瓶颈处：数据库+web服务器两处添加解决方案，其中web服务器前面一层最常用的的添加负载方案就是使用nginx实现负载均衡。 一、负载均衡的作用 1、转发功能 按照一定的算法【权重、轮询】，将客户端请求转发到不同应用服务器上，减轻单个服务器压力，提高系统并发量。 2、故障移除 通过心跳检测的方式，判断应用服务器当前是否可以正常工作，如果服务器期宕掉，自动将请求发送到其他应用服务器。 3、恢复添加 如检测到发生故障的应用服务器恢复工作，自动将其添加到处理用户请求队伍中。 二、Nginx实现负载均衡 同样使用两个tomcat模拟两台应用服务器，端口号分别为8080 和8081 1、Nginx的负载分发策略 Nginx 的 upstream目前支持的分配算法： 1)、轮询 ——1：1 轮流处理请求（默认） 每个请求按时间顺序逐一分配到不同的应用服务器，如果应用服务器down掉，自动剔除，剩下的继续轮询。 2)、权重 ——you can you up 通过配置权重，指定轮询几率，权重和访问比率成正比，用于应用服务器性能不均的情况。 3)、ip_哈希算法 每个请求按访问ip的hash结果分配，这样每个访客固定访问一个应用服务器

Redis 简介 Redis 是一个高性能的key-value数据库。支持 复杂的数据结构 ，支持 持久化 ，支持 主从集群 ，支持 高可用 ，支持 较大的value存储 ... Redis是一个nosql，非关系型数据库。 Redis 与其他 key - value 缓存产品有以下几个特点： Reids是基于内存读写的。 Redis支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用。 Redis不仅仅支持简单的key-value类型的数据，同时还提供list，set，zset，hash等数据结构的存储。 Redis支持数据的备份，即master-slave模式的数据备份。 何时使用Redis? 1.业务数据常用吗？命中率如何？如果命中率很低，就没有必要写入缓存。 2.业务数据是读操作多，还是写操作多？如果写操作多的话，需要频繁写入数据库，也没有必要使用缓存。 3.业务数据大小？如果业务数据是近G的文件，会给缓存带来很大压力。 Redis 优势 性能极高 – Redis能读的速度是110000次/s,写的速度是81000次/s 。 丰富的数据类型 – Redis支持二进制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 数据类型操作。 原子 – Redis的所有操作都是原子性的