高可用

很多网站都使用Redis作为自己的缓存系统，网站要做到高可用，它使用的缓存系统自然也必须支持高可用，这里就介绍一下Redis的高可用方案Sentinel。 Sentinel是Redis官方提供的一种高可用方案（除了Sentinel，Redis Cluster是另一种方案），它可以自动监控Redis master/slave的运行状态，如果发现master无法访问了，就会启动failover把其中一台可以访问的slave切换为master，并且通过pub/sub事件通知Redis客户端新的master的ip地址。 支持Sentinel的Redis客户端（例如java得Jedis）会在连接Redis服务器的时候向Sentinel询问master的ip，并且会在收到master切换的pub/sub事件后自动重新连接到新的master。 对调用Redis客户端的业务系统来说，这些都是完全透明的。 下图是redis sentinel的部署和运行机制 下图是master宕机后，failover的发起流程 现在我们来实战一下，我们的例子中有3台server，3个sentinel，1个master和2个slave。由于我们只有3台server,所以每个sentinel和一个master或者slave放在一个server上。采用的部署结构如下图所示 安装Redis Redis安装路径：~

摘自： https://www.cnblogs.com/mayou18/p/9829876.html 聊聊微服务的服务注册与发现 来源：阿里中间件团队分享 更多文章请关注 MAYOU18 聊起微服务的服务注册与发现，很多人立马就会脱口而出 zk、etcd、consul、eureka 这些组件，进而聊到 CAP 如何取舍，性能如何，高可用和容灾是怎么实现的。 引言 聊起微服务的服务注册与发现，很多人立马就会脱口而出 zk、etcd、consul、eureka 这些组件，进而聊到 CAP 如何取舍，性能如何，高可用和容灾是怎么实现的。 在这之前，站在组件使用者的角度，我想先问这么几个问题： 注册的 IP 和端口怎么确定 ？ 实现服务治理还需要注册哪些信息 ？ 如何进行优雅的服务注册与服务下线 ？ 注册服务的健康检查是如何做的 ？ 当服务有节点退出或新的节点加入时，订阅者能不能及时收到通知 ? 我能方便地查看某个应用发布和订阅了哪些服务，以及所订阅的服务有哪些节点吗 ？ 看完这些问题后，您也许会发现，对于服务注册与发现，首先应该关注的是服务注册发现本身的功能，然后才是性能和高可用。 一个好的服务注册发现中间件，应该是能完整地满足服务开发和治理的基础功能，然后才是性能和高可用。如果没有想清楚前面的功能，再高的可用性和性能都是浮云。最后，安全也同样重要。 服务端的性能如何 ？

1. 使用JAVA的UUID生成 算法的核心思想是结合机器的网卡、当地时间、一个随记数来生成UUID。 优点：本地生成，生成简单，性能好，没有高可用风险 缺点：长度过长，字母和数字组合，存储冗余，且无序不可读，查询效率低 2. 数据库自增ID 使用数据库的id自增策略，如 MySQL 的 auto_increment、oracle的sequence。并且可以使用两台数据库分别设置不同步长，生成不重复ID的策略来实现高可用。 优点：数据库生成的ID绝对有序，高可用实现方式简单 缺点：需要独立部署数据库实例，成本高，实时操作数据库，大并发时存在性能瓶颈问题 3. 数据库+程序（批量生成ID） 一次按需批量生成多个ID，每次生成都需要访问数据库，将数据库修改为最大的ID值，并在内存中记录当前值及最大值。 优点：避免了每次生成ID都要访问数据库并带来压力，提高了性能 缺点：属于本地生成策略，存在单点故障，如果服务器宕机，重启服务造成ID不连续 4. Redis生成ID Redis的所有命令操作都是单线程的，本身提供像 incr 和 increby 这样的自增原子命令，所以能保证生成的 ID 肯定是唯一有序的。 优点：不依赖于数据库，灵活方便，且性能优于数据库；数字ID天然排序，对分页或者需要排序的结果很有帮助。 缺点：如果系统中没有Redis，还需要引入新的组件，增加系统复杂度

1.1、Keepalived简介 ​ Keepalived是Linux下一个轻量级别的高可用解决方案。高可用(High Avalilability,HA)，其实两种不同的含义： 广义来讲，是指整个系统的高可用行，狭义的来讲就是之主机的冗余和接管 。它与HeartBeat RoseHA 实现相同类似的功能，都可以实现服务或者网络的高可用，但是又有差别，HeartBeat是一个专业的、功能完善的高可用软件，它提供了HA 软件所需的基本功能，比如：心跳检测、资源接管，检测集群中的服务，在集群节点转移共享IP地址的所有者等等。HeartBeat功能强大，但是部署和使用相对比较麻烦，与HeartBeat相比，Keepalived主要是通过虚拟路由冗余来实现高可用功能，虽然它没有HeartBeat功能强大，但是Keepalived部署和使用非常的简单，所有配置只需要一个配置文件即可以完成。 1.2、Keepalived是什么 ​ Keepalived起初是为LVS设计 专门 用来 监控集群系统 中各个 服务节点的状态 ，它根据TCP/IP参考模型的第三、第四层、第五层交换机制检测每个服务节点的状态，如果某个服务器节点出现异常，或者工作出现故,Keepalived将检测到，并将出现的故障的服务器节点从集群系统中剔除，这些工作全部是自动完成的，不需要人工干涉

1、什么是 nginx 高可用？ “高可用性”（High Availability）通常来描述一个系统经过专门的设计，从而减少停工时间，而保持其服务的高度可用性。Nginx于Keepalived可以实现高可用，实现双机热备+自动切换； 2、但是怎么实现 实现双机热备+自动切换 呢？ 　　需要在服务器安装 keepalive，以及编写脚本；以下开始搭建 3、环境准备 3.1　　 （1）需要两台 nginx 服务器 （2）需要 keepalived （3）需要虚拟 ip 3.2 配置高可用的准备工作 　　（ 1）需要两台服务器 192.168.2.112 和 192.168.2.113 　　 （2）在两台服务器安装 nginx （3）在两台服务器安装 keepalived 4、在两台服务器安装 keepalived 　　 （1）使用 yum 命令进行安装 yum install keepalived –y （2）安装之后，在 etc 里面生成目录 keepalived，有文件 keepalived.conf 5、完成高可用配置（主从配置） （1）修改/etc/keepalived/keepalivec.conf 配置文件 global_defs { notification_email { acassen@firewall.loc failover@firewall.loc

1、谈谈Redis的主从复制流程 有几个重点： 主节点负责写，从节点负责读，slave node 主要用来进行横向扩容，做读写分离，扩容的 slave node 可以提高读的吞吐量。 必须开启 master node 的持久化，不建议用 slave node 作为 master node 的数据热备，因为那样的话，如果你关掉 master 的持久化，可能在 master 宕机重启的时候数据是空的，然后可能一经过复制， slave node 的数据也丢了。 当启动一个 slave node 的时候，它会发送一个 PSYNC 命令给 master node。 slave node 初次连接到 master node，那么会触发一次 full resynchronization 全量复制。此时 master 会启动一个后台线程，开始生成一份 RDB 快照文件，同时还会将从客户端 client 新收到的所有写命令缓存在内存中。 断点续传是通过offset机制。 如果 master node 重启或者数据出现了变化，那么 slave node 应该根据不同的 run id 区分。 更详细见：https://github.com/doocs/advanced-java/blob/master/docs/high-concurrency/redis-master-slave.md 2

介绍：Redis 是一个开源的使用 ANSI C 语言编写、遵守 BSD 协议、支持网络、可基于内存亦可持久化的日志型、Key-Value 数据库，并提供多种语言的 API的非关系型数据库。 传统数据库遵循 ACID 规则。而 Nosql（Not Only SQL 的缩写，是对不同于传统的关系型数据库的数据库管理系统的统称） 一般为分布式而分布式一般遵循 CAP 定理。 Github 源码：https://github.com/antirez/redis Redis 官网：https://redis.io/ Redis支持的数据类型？ String字符串： 格式: set key value string类型是二进制安全的。意思是redis的string可以包含任何数据。比如jpg图片或者序列化的对象 。 string类型是Redis最基本的数据类型，一个键最大能存储512MB。 Hash（哈希） 格式: hmset name key1 value1 key2 value2 Redis hash 是一个键值(key=>value)对集合。 Redis hash是一个string类型的field和value的映射表，hash特别适合用于存储对象。 List（列表） Redis 列表是简单的字符串列表，按照插入顺序排序。你可以添加一个元素到列表的头部（左边）或者尾部（右边） 格式:

转载自：中华石杉公众号 关键词 ：高性能、动静分离、热点优化、系统优化、一致性（库存扣减准确性）、高并发读写、高可用（流量削峰、）、缓存失效和命中率 前言 秒杀大家都不陌生。自2011年首次出现以来，无论是双十一购物还是 12306 抢票，秒杀场景已随处可见。 简单来说，秒杀就是在同一时刻大量请求争抢购买同一商品并完成交易的过程。 从架构视角来看，秒杀系统本质是一个高性能、高一致、高可用的三高系统。而打造并维护一个超大流量的秒杀系统需要进行哪些关注，就是本文讨论的话题。 整体思考 首先从高维度出发，整体思考问题。秒杀无外乎解决两个核心问题，一是并发读，一是并发写，对应到架构设计，就是高可用、一致性和高性能的要求。 关于秒杀系统的设计思考，本文即基于此 3 层依次推进，简述如下： 高性能。 秒杀涉及高读和高写的支持，如何支撑高并发，如何抵抗高IOPS？核心优化理念其实是类似的：高读就尽量"少读"或"读少"，高写就数据拆分。 本文将从动静分离、热点优化以及服务端性能优化 3 个方面展开 一致性。 秒杀的核心关注是商品库存，有限的商品在同一时间被多个请求同时扣减，而且要保证准确性，显而易见是一个难题。 如何做到既不多又不少？本文将从业界通用的几种减库存方案切入，讨论一致性设计的核心逻辑 高可用。 大型分布式系统在实际运行过程中面对的工况是非常复杂的，业务流量的突增、依赖服务的不稳定

低读低写并发、低数据量方案 方案一：双机高可用方案 1.数据库架构图 2.特点 一台机器A作为读写库，另一台B作为备份库；A库故障后B库作为读写库；A库恢复后A作为备库。 3.开发说明 此种情况下，数据源配置中的数据库IP地址，可采用虚拟的IP地址。虚拟IP地址由两台数据库机器上的keepalive配置，并互相检测心跳。当其中一台故障后，虚拟IP地址会自动漂移到另外一台正常的库上。 数据库的主备配置、故障排除和数据补全，需要DBA和运维人员来维护。而程序代码或配置并不需要修改。 具体配置可参考资料： http://lizhenliang.blog.51cto.com/7876557/1362313 http://database.51cto.com/art/201012/237204.htm http://gaoke.iteye.com/blog/2283890 4.适应场景 读和写都不高的场景（单表数据低于500万），双机高可用。 5.优缺点 优点是一个机器故障了可以自动切换；缺点是只有一个库在工作，读写并未分离，并发有限制。 方案二：主从结构方案 1.数据库架构图 2.特点 一台机器A作为写库，另一台B作为读库；A库故障后B库充当读写，A修复后，B库为写库，A库为读库。 3.开发说明 这种方案的实现，要借助数据库中间件Mycat来实现，Mycat的datahost配置如下

概述 在现有企业中80%公司大部分使用的是redis单机服务，在实际的场景当中单一节点的redis容易面临风险。 面临问题 机器故障。我们部署到一台 Redis 服务器，当发生机器故障时，需要迁移到另外一台服务器并且要保证数据是同步的。而数据是最重要的，如果你不在乎，基本上也就不会使用 Redis 了。 容量瓶颈。当我们有需求需要扩容 Redis 内存时，从 16G 的内存升到 64G，单机肯定是满足不了。当然，你可以重新买个 128G 的新机器。 解决办法 　　要实现分布式数据库的更大的存储容量和承受高并发访问量，我们会将原来集中式数据库的数据分别存储到其他多个网络节点上。 　　Redis 为了解决这个单一节点的问题，也会把数据复制多个副本部署到其他节点上进行复制，实现 Redis的高可用，实现对数据的冗余备份，从而保证数据和服务的高可用。 主从复制 什么是主从复制 　　主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(master)，后者称为从节点(slave),数据的复制是单向的，只能由主节点到从节点。 　　默认情况下，每台Redis服务器都是主节点；且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点。 主从复制的作用 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。 故障恢复