目录
四、Keepalived实例--实现单主架构的LVS-DR模型
五、实例--通过Keepalived实现HAProxy高可用
一、HAProxy介绍
负载均衡（Load Balance），简称LB，是一种服务或基于硬件设备等实现的高可用反向代理技术，负载均衡将特定的业务(web服务、网络流量等)分担给指定的一个或多个后端特定的服务器或设备，从而提高了公司业务的并发处理能力、保证了业务的高可用性、方便了业务后期的水平动态扩展。
HAProxy是使用C语言开发的开源软件，具有高并发(一万以上)、高性能的TCP和HTTP负载均衡器，支持基于cookie的持久性，自动故障切换，支持正则表达式及web状态统计。
二、HAProxy基本使用
2.1，HAProxy调度算法
| 静态算法 不支持socat | static-rr |
基于权重的轮询调度,，其后端主机数量没有限制，相当于 LVS 中的 wrr |
| first |
根据服务器列表位置，自上而下调度，只有第一台服务器的连接数达到上限，新请求才会分配给下一台服务，因此会忽略服务器的权重设置 | |
| 动态算法支持socat |
roundrobin | 基于权重的轮询动态调度算法 |
|
leastconn |
加权的最少连接的动态，支持权重的运行时调整和慢启动，即根据当前连接最少的后端服务器而非权重进行优先调度,适合MySQL场景 | |
|
random |
基于随机数作为一致性 hash 的 key ，支持weight 的动态调整，权重越大越容易 获取新请求，适用于大型服务器场或经常添加或删除服务器 | |
| source 算法 |
map-based |
取模法，对 源地址进行hash计算，再基于服务器总权重的取模，不支持在线调整权重，此算法为hash-type 指定的默认值 |
| consistent |
一致性哈希，当服务器的总权重发生变化时，对调度结果影响是局部的，支持在线调整权重 | |
| uri算法 |
基于对用户请求的 URI 的左半部分或整个 uri 做 hash ，再将 hash 结果对总权重进行取模，此算法基于应用层至支持mode http | |
| url_param算法 |
对用户请求的 url 中的规定的 params 部分进行 hash计算，再将hash结果对总权重进行取模，若未指定param按 roundrobin 算法 | |
| hdr算法 |
对用户每个 http 头部 请求中的指定信息做hash，再将hash结果对总权重进行取模 | |
| rdp-cookie算法 |
对 Windows 远程桌面的负载，使用 cookie 保持会话，默认是静态，也可通过指定 hash-type 来定义使用取模法还是一致性 hash | |
2.2，HAProxy高级用法
三、高可用Keepalived介绍
3.1，Keepalived介绍
VRRP（Virtual Router Redundancy Protocol），虚拟路由冗余协议，解决静态网关单点风险。物理层面通过路由器、三层交换机实现，软件层面通过Keepalived实现。
Keepalived是高可用集群的通用无状态应用解决方案，其主要功能：
3.2，Keepalived单主架构实现
3.3，脑裂
四、Keepalived实例--实现单主架构的LVS-DR模型
五、实例--通过Keepalived实现HAProxy高可用
六、NoSQL数据库Redis
6.1，Redis简介
NoSQL 数据库，全称为 Not Only SQL，既可以适用关系型数据库也可以使用其他类型的数据存储。
Redis是一个开源的Key-Value存储系统，使用C语言开发，支持多种编程语言的API。它是一个高速缓存数据库，采用内存存储，并支持持久化，能够提供高性能的数据读写操作。
| Redis常见应用场景 | |
| 缓存 | 缓存RDBMS中数据,比如网站的查询结果、商品信息、微博、新闻、消息 |
| Session 共享 | 实现Web集群中的多服务器间的session共享 |
| 计数器 | 商品访问排行榜、浏览数、粉丝数、关注、点赞、评论等和次数相关的数值统计场景 |
| 社交 | 朋友圈、共同好友、可能认识他们等 |
| 地理位置 | 基于地理信息系统实现摇一摇、附近的人、外卖等功能 |
| 消息队列 | ELK等日志系统缓存、业务的订阅/发布系统 |
| 名称 | 概念 | 解决方法 |
| 缓存穿透 | 缓存和Redis数据库中没有， MySQL关系数据库也没有的数据，被请求访问 | 在接口层增加校验，如用户鉴权校验 对无法查询的数据短期定义key-null |
| 缓存击穿 | 缓存和Redis数据库中没有， MySQL数据库中有的数据，被请求访问 | 设置热点数据永远不过期 |
| 缓存雪崩 | 缓存中数据大批量到过期时间， 而查询数据量巨大，引起数据库压力过大甚至宕机 | 设置热点数据永远不过期 缓存数据的过期时间设置随机 若数据库为分布式，热点数据均匀 分布不同缓存数据库 |
6.2，Redis持久化
| 方法 | RDB（Redis DataBase） | AOF（AppendOnlyFile） |
| 概念 |
基于某个时间点的快照， 只保留一个最新版本， 相当于MySQL 的完全备份 | 初次启动时进行完全备份， 后续将持续执行增量性备份 |
| 实现 方式 |
save： 同步， 不推荐， 使用主进程完成，会阻赛其它命令 bgsave：异步后台执行 ， 会开启子进程，不会阻赛其它命令 | bgrewriteaof：会自动开启，也可手动执行，对数据进行重新整理 |
| 优点 |
1，只保存某个时间点的数据，恢复无需额外操作，适合灾备处理 2，在大集群时恢复速度较AOF快 | 1，数据安全性相对较高，每秒自动执行 2，写入操作采用append模式，宕机也不会损坏数据 3，会自动重写，重写操作绝对安全 4，AOF有记录所有操作的日志文件，可用于数据重建 |
| 缺点 | 1，不能实时保存，存在少量数据丢失风险 2，在数据集较大时，子进程可能会非常耗时，导致客户端长时间等待 | 1，AOF会记录重复操作，数据量大 2，AOF在恢复大数据集的速度比 RDB慢 3，fsync策略是appendfsync no时, AOF保存到磁盘的速度可能会慢于RDB 4，更易出现BUG |
6.3，Redis使用介绍
| 数据类型 | 特点 |
| 字符串string | 基本数据类型，能包含任意类型的数据，单个值最大512M字节 |
| 列表list | 有序，可重复，可实现队列和栈 |
| 集合set | 无序，不可重复，实现集合操作（与sinter，或sunion，非sdiff） |
| 有序集合zset | 有序，无重复元素，由score(不可重复)和value组成，用于实现排行榜 |
| 字典hash | 无序，每个元素都是键值对，可存储复杂数据 |
七、实例--构建Redis主从哨兵模式
7.1，主从复制优化
Redis的主从同步是非阻塞的，即同步过程不会影响主服务器的正常访问；其主从复制分为全量同步和增量同步两种，主节点重启会导致全量同步,从节点重启只会导致增量同步。
7.2，常见主从复制故障
7.3，实例--构筑主从哨兵模式
八、实例--三节点Redis集群搭建
哨兵只能解决Redis高可用，实现自动故障转移，无法解决单主节点的写入性能瓶颈，使用分布式集群可解决该问题（建立Cluster时，节点需要清空数据，且网络中不能有哨兵主从）
Redis cluster的从节点是只读连接的，也就是说集群模式中的从节点是拒绝任何读写请求的。并且当多个节点运行一段时间后,可能会出现倾斜现象，某个节点数据偏多，内存消耗更大，或者用户请求访问更多，主要原因如下：