读书笔记：网站架构之伸缩性篇
目录：
一、网站架构的伸缩性设计
二、应用服务器
三、分布式缓存服务器
四、数据库服务器
PS：本文为《大型网站技术架构 & 核心原理与案例分析（李智慧 著）》一书的读书笔记
// =======================================================================================
网站架构的伸缩性设计
*：伸缩性：指不需要修改网站软硬件设计，仅通过改变服务器数量就可以扩大或缩小网站处理能力
一、不同功能通行物理分离实现伸缩（初级）
*：功能纵向划分：接入、应用、缓存、数据库等
*：功能横向划分：登陆模块、商品模块、订单模块等，粒度可以非常小
二、单一功能通过集群实现伸缩（高级）
*：随着网站规模发展，即使分离到最小粒度独立部署，单一服务器也不能满足业务规模需求，则必须使用集群
*：应用服务器、数据服务器等由于对数据管理的不同，伸缩性的实现技术差别也非常大
// ===========================================================
应用服务器的伸缩性
一、实现负载均衡的几种基础技术
1、HTTP重定向（少用）：
*：通过HTTP返回302并设置location重定向。
*：缺点为需要2次HTTP请求且浪费IP，基本重定向不会用在负载均衡
2、DNS域名解析（第一级负载均衡）：
*：在DNS服务器上，为一个域名配置多个IP。
*：优点为可让DNS服务提供商维护，由于DNS服务器分布全国，故常用于基于地理位置的第一级负载均衡。缺点为不易及时更新
3、应用层负载均衡（简单灵活）：
*：反向代理服务器配置外网内网2个IP，请求在http协议层由用户进程转发
*：Nginx就是使用这种方式。缺点为性能可能成为瓶颈
4、IP层负载均衡：
*：同样需外网内网2个IP，服务器操作系统内核进程获取网络包时就修改其目的IP地址，而不用给用户进程
*：性能相对较好
5、数据链路层负载均衡（优秀）：
*：通过负载均衡服务器在数据链路层修改请求的mac地址为应用服务器的mac地址来实现
*：优点为应用服务器的IP（虚拟IP）和负载均衡服务器的IP一致，这样就可将请求直接返回给用户而不用返回给负载均衡服务器，故又称为直接路由方式（DR）。
*：是大型网站使用最广的方法，著名的开源产品是LVS（Linux Virtual Server）
二、负载均衡算法
1、轮询（Round Robin）
2、加权（重要）
3、随机
4、最少连接：记录每个应用服务器当前的连接数
5、源地址Hash：来源IP地址进行Hash计算得到应用服务器标识
// ===========================================================
分布式缓存服务器的伸缩性
一、Memcached的访问模式
1、应用程序
*：调用Memcached客户端提供的API，如<Get，"Key">
2、Memcached客户端
*：接收应用程序请求，路由算法结合Memcached服务器列表，将请求输入的Key计算得出数据应写入哪台服务器
*：API调用通信模块和目标服务器通信获取数据
3、Memcached服务器
二、Memcached的伸缩性挑战
1、挑战：如何处理服务器上下线的影响
*：分布式缓存服务器中缓存的数据各不相同，会导致新上线服务器没有数据，新下线服务器还缓存着许多热点数据
2、关键：路由算法的设计（Key到服务器的映射）
*：余数Hash，即缓存数据Key的Hash值除以服务器数量。负载均衡没问题，但伸缩性差（3台扩容到4台，有75%数据不能命中！导致数据库压力突然暴涨）
*：要使得新加入服务器不影响大部分缓存数据的正确命中，较流行的方法为一致性Hash算法
三、一致性Hash算法
1、一致性Hash环数据结构实现Key到服务器的映射
*：长度为0-2^32的整数环，将服务器节点置于Hash环上，然后Key的Hash值顺时针查找最近的服务器节点。（3台扩容到4台，只有25%不能命中）
*：一致性Hash环通常用二叉查找树实现，查找过程实质是在二叉查找树上查找不小于查找数的最小值，且树的最右边叶子节点和最左边叶子节点相连，构成环
*：负载不均衡问题：服务器的Hash值在Hash环上固定为某个位置，任2个服务器的位置间距不确定
2、通过增加虚拟层来解决一致性Hash环负载不均衡问题
*：将每台物理缓存服务器虚拟为一组虚拟缓存服务器，将虚拟缓存服务器的Hash值放在Hash环上，Key在环上先找到虚拟服务器节点再得到物理服务器信息
*：最终结果是新加入一台缓存服务器，将会较为均匀地影响（分摊）到原集群中已存在的所有服务器
*：一台物理缓存服务器虚拟为几个虚拟缓存服务器节点合适：经验值为150
// ===========================================================
数据库服务器的伸缩性
一、关系数据库集群的伸缩性设计
*：由于关系型数据库支持SQL，不是简单的Key-Value数据模型，不能简单讲数据分机器存储，故伸缩性的设计更复杂些
1、数据分库
*：由于不能进行跨机器的Join，所以一般按业务分库，不同业务不熟在不同的数据库服务器上，从业务层面减少数据关联
2、数据分表
*：同个业务也有可能一张表很大，比如Facebook的用户数据库，这时候就需要再通过分表的方法将不同表放在不同的数据库服务器上
*：常用的方法比如用户ID取模等，也有支持数据分表的分布式数据库产品（实质为分解SQL），比如Colar。
*：Colar为一个分布式关系数据库访问代理，介于应用服务器和数据库服务器之间，根据SQL和分库规则来分解SQL
二、NoSQL数据库的伸缩性设计
*：NoSQL是指非关系的，分布式的数据库设计模式，是对关系型数据库的一种补充。
*：NOSQL放弃了关系型数据库的两大基础：SQL语言和事务一致性ACID，而强化大型网站更关注的特性：高可用和可伸缩性
*：HBase为可伸缩海量数据储存而设计，实现面向在线业务的实时数据访问延迟。其伸缩性主要依赖可分裂的HRegion和HDFS实现