高可用

Galera Cluster 实现mysql的高可用 (Percona XtraDB Cluster) # 基础搭建 # 设备：三台主机 192.168.47.101 192.168.47.102 192.168.47.103 # centos7 系统 关闭防火墙 selinux # 设置清华源用于下载 cat >/etc/yum.repos.d/pxe.repo <<eof [percona] name=percona baseurl=https://mirrors.tuna.tsinghua.edu.cn/percona/release/7Server/RPMS/x86_64 gpgcheack=0 eof #拷贝yum源 scp /etc/yum.repos.d/pxe.repo 192.168.47.102:/etc/yum.repos.d/ scp /etc/yum.repos.d/pxe.repo 192.168.47.103:/etc/yum.repos.d/ #192.168.47.101 192.168.47.102 192.168.47.103 都要安装 yum install Percona-XtraDB-Cluster-57 -y #配置mysqld.cnf文件 server-id=1 bin_log #配置wsrep.cnf文件, wsrep

写于2017-12-06 背景 ：这年小P已经参加工作4年了，在前同事Z的极力劝说下，小P加入了Z新开的公司Y，公司一共有三个人：老板Z、程序员小P、前台W。项目名为XX交易系统 小P加班加点，终于在两个月后把系统开发完成，版本为V1.0，这中间还包括需求分析（其实就是跟老板聊），概要设计。而系统的架构也是简单得不能再简单，如下图： 前台和后台都是最简单的java web，使用了当时最常用的SSH（Spring、Struts、Hibernate）框架，前端直接用了jsp（即html中嵌入java代码段）+jquery。 而这段时间，陆续入职了一个应届生X，一个美工兼前端J，老板跑市场还进展挺顺利的，刚上线注册用户数很快就突破5万了。根据市场的反鐀，很快确定V1.1版本的需求。不到一个月时间，小P三个又完成了V1.1版本的开发，V1.1比上一版本的改进在于： 1、jsp中不再用代码段的方式了，而是用JSTL标签，小J学习JSTL的语法，替小P完成View层的活，因为小P实在太忙了。 2、随着用户的增多，不能再随意重启生产服务了，而且应用层也需要高可用。 3、加cache层，降低数据库压力。 3、加了n个新功能... 而架构也改造成如下图： 加入了nginx作为负载均衡和实现前后台tomcat应用的高可用。 读多写少数据取自分布式缓存Reids，并按时间及有变更时主动做淘汰。

写于2018-02-01 互联网公司从创业、各轮融资、壮大发展、成功上市，各阶段适用于不同的技术架构，过早采用过于激进的架构可能会出现人力、成本、制度的不匹配，而采用过时的技术则会严重的掣肘业务的发展。好的架构是不断进化的，不是一开始就设计好的放之四海皆准的通用架构，但掌握其中有一些通用的原则，可以让我们少走很多弯路。 在创业初始阶段，通常你只有几号人，还没有做出一个产品投放市场，甚至你还不知道市场上反应如何，产品有无风险，这时你需要的是尽快做出第一版产品，怎么简单怎么来。你可以先不急着前后端分离，不需要专职的运维人员，如果你需要移动端，还需要找Android和IOS开发。完成这项任务，你最低需要一个Java开发（HTML + Java + 运维），一个移动端开发人员、一个美工（前期可以兼职），为什么你需要找Java开发，而不是.NET呢？第1是Java的跨平台（不会与特定操作系统绑定），第2是目前来说Java开发人员市场占有量最高，意味着你后面更容易招到人，第3是Java体系有很多开源的技术，在企业后期发展的不同阶段都或多或少能找到适用的开源产品，这能节省研发投入、缩短时间，提高产品服务质量。这个阶段，做为技术负责人的你，抛开业务层面的事情，技术上你需要关注： 版本管理：Git，分支管理？产品都还没做出来，直接在主干上堆代码吧 项目管理：Tower，跟移动端微信结合起来，简直利器

分布式ID的特性 全局唯一 不能出现重复的ID，这是最基本的要求。 递增 有利于关系数据库索引性能。 高可用 既然是服务于分布式系统，为多个服务提供ID服务，访问压力一定很大，所以需要保证高可用。 信息安全 如果ID是有规律的，就容易被恶意操作，在一些场景下需要ID无规则。 生成方案 UUID 核心思想是结合机器的网卡、当地时间、一个随机数来生成。 优点： 性能非常高，本地生成，没有网络消耗。 生成简单，没有高可用风险。 有利于信息安全，因为可读性差，无规律。 缺点： 太长，不易于存储。 有利于信息安全的同时，也有不安全性，因为基于MAC地址生成的算法可能会泄露MAC地址。 无序，对MySQL索引不利，在 InnoDB 中，无序性会导致数据位置频繁变动，性能低下。 数据库 利用数据库自增ID的特性来生成，如 MySQL 的 auto_increment 。 优点： 简单，利用数据库自有功能实现。 绝对有序。 缺点： 有重复发号的风险，例如数据库主从切换的场景。 需要特别保障其高可用。 发号性能限制于数据库性能，如需提高发号能力，需要扩充数据库，成本高。 Redis Redis 提供了自增的原子命令，可以保证唯一、有序。 优点： 简单，自有能力。 高并发环境下性能好，优于数据库。 维护成本低于数据库。 缺点： 主从切换时也可能会重复发号。 需要特别保障其高可用。 雪花算法

前言 通常来说，自动化运维有两种类型的运维方式： 定时的脚本任务， 比如定时更换云服务的 acess key secret , 定时检查 ecs 对外暴露的端口等 报警事件的紧急处理, 比如 ecs 实例发生异常重启 在传统的运维中，对于定时任务的处理通常用crontab脚本来实现，但是一旦管理的机器多了，必定会对脚本进行集中管理，这个时候对集中管理脚本的机器的可用性、脚本里面会散落密码明文等相关信息以及定时任务执行的记录都是一个很大的挑战；而对于事件驱动的报警处理，要么是通过短信报警告知运维人员，要么需要自建服务来处理报警信息, 无论是哪种方式，财务成本和运维成本都很大。本文探讨一种新的运维方式，利用函数计算做自动化运维，以极低的成本就可以获得一个高可靠，高质量的运维服务。 函数计算 阿里云 函数计算 是一个事件驱动的serverless计算服务。通过函数计算，您无需管理服务器等基础设施，只需编写代码并上传。函数计算会为您准备好计算资源，以弹性、可靠的方式运行您的代码，具体表现为： 无需采购和管理服务器等基础设施 按需付费，比如对运维管控这类低频调用的系统，财务成本通常能节约90%以上 专注业务逻辑的开发，能极大提高开发效率，比如 十分钟上线弹性高可用的图片处理服务 稳定高可用，毫秒级别弹性伸缩，快速实现底层扩容以应对峰值压力 提供日志查询、性能监控、报警等功能快速排查故障

前言 通常来说，自动化运维有两种类型的运维方式： 定时的脚本任务， 比如定时更换云服务的 acess key secret , 定时检查 ecs 对外暴露的端口等 报警事件的紧急处理, 比如 ecs 实例发生异常重启 在传统的运维中，对于定时任务的处理通常用crontab脚本来实现，但是一旦管理的机器多了，必定会对脚本进行集中管理，这个时候对集中管理脚本的机器的可用性、脚本里面会散落密码明文等相关信息以及定时任务执行的记录都是一个很大的挑战；而对于事件驱动的报警处理，要么是通过短信报警告知运维人员，要么需要自建服务来处理报警信息, 无论是哪种方式，财务成本和运维成本都很大。本文探讨一种新的运维方式，利用函数计算做自动化运维，以极低的成本就可以获得一个高可靠，高质量的运维服务。 函数计算 阿里云 函数计算 是一个事件驱动的serverless计算服务。通过函数计算，您无需管理服务器等基础设施，只需编写代码并上传。函数计算会为您准备好计算资源，以弹性、可靠的方式运行您的代码，具体表现为： 无需采购和管理服务器等基础设施 按需付费，比如对运维管控这类低频调用的系统，财务成本通常能节约90%以上 专注业务逻辑的开发，能极大提高开发效率，比如 十分钟上线弹性高可用的图片处理服务 稳定高可用，毫秒级别弹性伸缩，快速实现底层扩容以应对峰值压力 提供日志查询、性能监控、报警等功能快速排查故障

Springcloud是一款微服务框架，它基于Springboot，可以使用它用来管理纵向拆分的项目，将一个个的小项目变成微服务。下面简单的搭建一个微服务，使用eureka组件实现注册中心，使用ribbon组件实现微服务调用，使用zuul网关实现真实服务地址和访问地址的分离，其他技术后续补充。 springcloud和nginx 前面学习过nginx，它除了可以实现动静分离，还可以实现负载均衡，即可以将项目做成分布式tomcat集群，前端访问可以随机或者按照权重值访问后端服务。但是nginx有一个小缺点，如果单台服务器出现问题、或者需要添加服务器，需要修改conf.xml配置文件，或某台服务器出现问题如何容错等，ngnix是无法实现。简单来说它缺少管理者的因子，需要人为''介入''，在这种情况下，springcloud就可以弥补nginx的不足，它不仅仅可以实现分布式，负载均衡，并且对微服务有管理、容错、监听的能力。 springcloud springcloud是spring家族的一员，它是一个微服务框架，用在大型分布式应用的开发，官网： https://spring.io/projects/spring-cloud ，除了springcloud外，其他比较出名的微服务框架还有dubbo。 如果一个项目比较小，直接使用springboot，或者ssm做成单体项目就可以

by: 白马公园/naritech 本文的主旨在于配置一个尽可能简单的高可用WEB服务系统，帮助读者理清keepalived、LVS等软件的配置和使用，为进一步用好LVS树立信心，夯实基础。 本文只涉及使用LVS和Keepalived解决WEB服务的高可用和高并发，对于WEB集群中的session共享即数据一致性问题不做讨论，对WEB集群中的session共享问题感兴趣的朋友可以参考我的另外一篇文章《nginx、tomcat、redis配置session共享》 网上关于LVS和keepalived搭建高可用WEB服务的文章很多，本文的不同之处在于笔者在配置的过程中遇到了很多问题，因而走了不少弯路。所以本文的重点将放在这些问题的讲述上。 一、 系统架构 全系统包括五台服务器，均为虚拟机，安装Centos6.5操作系统，其中 hadoop01 192.168.75.88 安装keepalived，作为主负载调度器使用 hadoop02 192.168.75.89 安装keepalived，作为备用负载调度器使用 hadoop03 192.168.75.90 安装tomcat，作为真实Web服务器使用 hadoop04 192.168.75.91 安装tomcat，作为真实Web服务器使用 hadoop05 192.168.75.92 安装tomcat，作为真实Web服务器使用

最近整理了目前的MySQL高可用方案。 MySQL 高可用方案包括3大类： 共享存储 同步复制 基于复制的冗余 下面分别看下每种方案。 1.共享存储 共享存储实现了数据库服务器和存储设备的解耦。 比较典型的是SAN共享存储和DRBD磁盘复制。 1.1 SAN SAN(Storage Area Network)存储如图所示。 SAN共享存储中，如果主库发生宕机，备库可以挂载相同的文件系统，保证主库和备库使用相同的数据。 1.2 DRBD DRBD(Distributed Replicated Block Device)是Linux内核模块实现的块级别的同步复制技术，可以与SAN达到相同的共享存储效果。 2.同步复制 同步复制的基本原理是，要求数据在集群中所有节点或大多数节点上提交。 同步复制的数据库高可用方案，主要包括3种： MySQL Cluster Galera Cluster MGR 2.1 MySQL Cluster MySQL Cluster 或NDB Cluster 是MySQL 官方集群部署方案，基于NDB(Network DataBase) 存储引擎的完整的分布式数据库系统。 MySQL cluster主要由3部分组成： SQL 层的 SQL 服务器节点 Storage 层的 NDB 数据节点 负责管理各个节点的 Manage 节点 2.2 Galera

#0 系列目录# 大型分布式网站架构 大型分布式网站架构技术总结 本文是学习大型分布式网站架构的技术总结。对架构一个高性能，高可用，可伸缩，可扩展的分布式网站进行了概要性描述，并给出一个架构参考。一部分为读书笔记，一部分是个人经验总结。对大型分布式网站架构有很好的参考价值。 #1 大型网站的特点# 用户多，分布广泛 大流量，高并发 海量数据，服务高可用 安全环境恶劣，易受网络攻击 功能多，变更快，频繁发布 从小到大，渐进发展 以用户为中心 免费服务，付费体验 #2 大型网站架构目标# 高性能：提供快速的访问体验。 高可用：网站服务一直可以正常访问。 可伸缩：通过硬件增加/减少，提高/降低处理能力。 安全性：提供网站安全访问和数据加密，安全存储等策略。 扩展性：方便的通过新增/移除方式，增加/减少新的功能/模块。 敏捷性：随需应变，快速响应； #3 大型网站架构模式# 分层：一般可分为，应用层，服务层，数据层，管理层，分析层； 分割：一般按照业务/模块/功能特点进行划分，比如应用层分为首页，用户中心。 分布式：将应用分开部署（比如多台物理机），通过远程调用协同工作。 集群：一个应用/模块/功能部署多份（如：多台物理机），通过负载均衡共同提供对外访问。 缓存：将数据放在距离应用或用户最近的位置，加快访问速度。 异步：将同步的操作异步化。客户端发出请求，不等待服务端响应