互联网架构 - 高可用和负载均衡

本文主要介绍互联网架构中的高可用及负载均衡，参考文章高可用、负载均衡、异构负载均衡

高可用HA（High Availability）是在互联网架构设计中必须考虑。高可用是指通过设计来减少系统不能提供服务的时间。

高可用实现的核心思想是冗余和故障自动转移。

下面是典型的互联网分层架构：

下面我们看看各层怎么实现高可用。

客户端 -> 反向代理层

通过反向代理层的冗余来实现。这里以nginx为例，提供多个nginx，对外使用统一的VIP，并使用keepalived进行存活探测。当一台nginx挂掉，keepalived将流量导向shadow nginx，从而实现高可用。

反向代理层 -> 站点层

通过站点层冗余来实现高可用。nginx.conf里能够配置多个web后端，并且nginx能够探测到多个后端的存活性。当一个web server挂掉，nginx能探测到并自动进行故障转移，将流量导向其他web server。

站点层 -> 服务层

站点层到服务层的高可用通过服务层的冗余来实现的。“服务连接池”会与多个下游服务建立连接，每次请求会“随机”选取连接来访问下游服务。服务连接池能够自动进行故障转移。

服务层 -> 缓存层

服务层到缓存层的高可用通过缓存数据的冗余来实现，方法分为缓存双读写或者支持主从同步的缓存集群来实现。注意：缓存层并不一定要求高可用，只是为了加快访问DB速度。

缓存双读写：

主从同步的缓存集群：redis支持master-slave，并使用redis sentinel来做监控master，slave节点的存活性，自动故障转移以及master promotion。

服务层 -> 数据库层

服务层到数据库层的高可用是通过数据库的冗余来实现，包括主从复制，DB sharding，联合，冗余设计。使用keepalived存活探测并使用相同VIP提供服务。

知识点插入=========>

对于订单交易，包含seller和buyer两个方面。若使用分库分表，使用seller_id分库分表，则查询buyer_id需要查询所有数据库；反之，亦然。这时，可以分别创建2个表T1和T2，分别seller_id和buyer_id来分库分表。

T(buyer_id, seller_id, oid);

//数据冗余满足不同查询需求
T1(buyer_id, seller_id, oid)
T2(seller_id, buyer_id, oid)