［读书笔记］大型分布式网站架构设计与实践.分布式缓存

前言：本书是对分布式系统架构涉及到的相关技术的一本科普书籍。由于很难作为开发参考，只能但求了解。所以通篇浅读，对分布式系统进行大致的了解。因为写的非常好，感觉非常有意思，自己也做不出总结。所谓的读书笔记也就演变成了摘抄。

简介

一个大型、稳健、成熟的分布式系统的背后，往往会设计众多的支撑系统，我们将这些支撑系统成为分布式系统的基础设施。除了前面所介绍的分布式协作及配置管理系统ZooKeeper，我们进行系统架构设计所依赖的基础设施，还包括分布式缓存系统、持久化存储、分布式消息系统、搜索引擎、以及CDN系统、负载均衡系统、运维自动化系统等，还有实时计算系统、离线计算系统、分布式文件系统、日志收集系统、监控系统、数据仓库等。

分布式缓存

在高并发环境下，大量的读、写请求涌向数据库，磁盘的处理速度与内存显然不在一个量级，从减轻数据库的压力和提供系统响应速度两个角度来考虑，一般都会在数据库之前加一层缓存。由于单台机器的内存资源和承载能力有限，并且如果大量使用本地缓存，也会使相同的数据被不同的节点存储多份，对内存资源造成较大的浪费，因此才催生出了分布式缓存。
接下来将介绍分布式缓存的典型代表memcache，以及分布式缓存的应用场景。最为典型的场景莫过于分布式session。

memcache

memcache是一款开源的高性能的分布式内容对象缓存系统，被许多大型网站所采用，用于在应用中减少对数据库的访问，提高应用的访问速度，并降低数据库的负载。为了在内存中提供数据的高速查找能力，memcache使用key-value形式存储和访问数据，在内存中维护一张巨大的HashTable，使得对数据查询的时间复杂度降低到O(1)，保证了对数据的高性能访问。内存的空间总是有限的，当内存没有更多的空间来存储新的数据时，memcache就会使用LRU(Least Recently Used)算法，将最近不常访问的数据淘汰掉，以腾出空间来存放新的数据。memcache存储支持的数据格式也是灵活多样的，通过对象的序列化机制，可以将更高层的对象转换成为二进制数据，存储在缓存服务器中，当前端应用需要时，又可以通过二进制内容反序列化，将数据还原成原有对象。

memcache客户端与服务端通过构建在TCP协议之上的memcache协议来进行通信，协议支持两种数据的传递，这两种数据分别为文本行和非结构化数据。文本行主要用来承载客户端的命令及服务端的响应，而非结构化数据则主要用于客户端和服务端数据的传递。由于非结构化数据采用字节流的形式在客户端和服务端之间进行传输和存储，因此使用方式非常灵活，缓存数据存储几乎没有任何限制，并且服务端也不需要关心存储的具体内容及字节序。

memcache的分布式实现

memcache本身并不是一种分布式的缓存系统，它的分布式是由访问它的客户端来实现的。一种比较简单的实现方式是根据缓存的key来进行Hash，当后端有N台缓存服务器时，访问的服务器为hash(key)%N，这样可以将前端的请求均衡地映射到后端的缓存服务器。但这样也会导致一个问题，一旦后端某台缓存服务器宕机，或者是由于集群压力过大，需要新增缓存服务器时，大部分的key将会重新分布。对于高并发系统来说，这可能会演变成一场灾难，所有的请求将如洪水般疯狂地涌向后端的数据库服务器，而数据库服务器的不可用，将会导致整个应用的不可用，形成所谓的“雪崩效应”。

consistent Hash算法

使用consistent Hash算法能够在一定程度上改善上述问题。该算法早在1997年就在论文Consistent hashing and random trees中被提出，它能够在移除/添加一台缓存服务器时，尽可能小地改变已存在的key映射关系，避免大量key的重新映射。

consistent Hash的原理是这样的，它将Hash函数的值域空间组织成一个圆环，假设Hash函数的值域空间为0~（2的32次方-1），也就是Hash值是一个32位的无符号整型，整个空间按照顺时针的方向进行组织，然后对相应的服务器节点进行Hash，将他们映射到Hash环上，假设有4台服务器分别为node1，node2，node3，node4，它们在环上的位置如图所示。

接下来使用相同的Hash函数，计算出对应的key的Hash值在环上对应的位置。根据consistent Hash算法，按照顺时针方向，分布在node1与node2之间的key，它们的访问请求会被定位到node2，而node2与node4之间的key，访问请求会被定位到node4，以此类推。
假设有新的节点node5增加进来时，假设它被Hash到node2与node4之间，那么受影响的只有node2和node5之间的key，它们将被重新映射到node5，而其他key的映射关系将不会发生改变，这样避免了大量key的重新映射。
当然上面描绘的知识一种理想的情况，各个节点在环上分布得十分均匀。正常情况下，当节点数据较少时，节点的分布可能十分不均匀，从而导致数据访问的倾斜，大量的key被映射到同一台服务器上。为了避免这种情况的出现，可以引入虚拟节点的机制，对每一个服务器节点都计算多个Hash值，每一个Hash值都对应环上一个节点的位置，该节点称为虚拟节点，而key的映射方式不变，只是多了一步从虚拟节点再映射到真实节点的过程。这样，如果虚拟节点的数量足够多，即使只有很少的实际节点，也能够使key分布得相对均衡。

分布式session

对于大型分布式网站来说，支撑其业务的远远不止一台服务器，而是一个分布式集群，请求在不同服务器之间跳转。那么如何保持服务器之间的session同步呢？传统网站一般通过将一部分数据存储在cookie中，来规避分布式环境下session的操作。这样做的弊端很多，一方面cookie的安全性一直广为诟病，另一方面cookie存储数据的大小是有限制的。随着移动互联网的发展，很多情况下还得兼顾移动端的session需求，使得采用cookie来进行session同步的方式的弊端更为凸显。分布式session正是在这种情况下应运而生的。
对于系统可靠性要求较高的用户，可以将session持久化到DB中，这样可以保证宕机时会话不易丢失，但缺点也是显而易见的，系统的整体吞吐将受到很大的影响。另一种解决方案便是将session统一存储到缓存集群上，如memcache，这样可以保证较高的读、写性能，这一点对于并发量大的系统来说非常重要；并且从安全性考虑，session比较是有有效期的，使用缓存存储，也便于利用缓存的失效机制。使用缓存的缺点是，一旦缓存重启，里面保存的会话也就丢失了，需要重新建立会话。