原文：http://www.csdn.net/article/2014-03-25/2818965
常见KV存储系统
与互联网时代不同，社交时代和移动互联网时代的互联网产品，拥有海量的读写请求和爆发式增长的数据和用户。传统关系型数据库的性能、可扩展性和数据结构的灵活性逐渐成为瓶颈。NoSQL型数据库在近些年风生水起，越来越受到开发者的关注。NoSQL无须遵循关系型数据库的ACID理论，简单灵活的数据结构和操作使其具备与生俱来的高性能和可扩展性。常见的NoSQL产品有KV（key-value）型、文档型、列存储型、图存储型、对象存储型、XML数据库型等，图1为各种类型NoSQL数据库的代表产品和介绍。
图1 常见NoSQL存储
KV型存储系统是最常用的NoSQL存储系统之一。Memcached和Redis是其最具代表的两个产品。本文将详细介绍Memcached和Redis的常用场景及如何构建一个高可用和自动弹性伸缩的KV存储系统。
Cache加DB是最常见的存储层架构。时间局部性原理指出正在被访问的数据很可能会在近期再次被访问。根据这一原理应用程序将最近访问过的数据保存在Cache中，每次读取请求首先访问Cache，若Cache中保存有该数据则直接获取数据返回给前端。若Cache中该数据不存在则从DB获取数据并将该数据保存到Cache；若数据被更新或删除则将Cache中对应数据置为失效。使用Cache能够很好地缓解DB的读请求压力。KV存储系统既可以应用在Cache层也可以应用在DB层。
Memcached使用内存作为存储介质，因为内存数据的易失性Memcached主要应用在Cache层。Memcached常见的应用场景是存储一些读取频繁但更新较少的数据，如静态网页、系统配置及规则数据、活跃用户的基本数据和个性化定制数据、准实时统计信息等。并不是所有场景都适合Memcached加DB的架构，在某些场景下这一架构存在一些局限。例如这一架构不能提升写的性能，写数据时还是数据直接存储到DB，同时需要将Cache中数据置为失效，所以对以写请求为主的应用使用Cache提升性能的效果并不是很明显。如果应用的热点数据或者活跃用户分布较为分散也会降低Cache的命中率。如果遇到机器宕机，内存数据会丢失，那么机器重启后需要一段时间重新建立热点数据，建立热点数据的过程中会对DB会造成较大的压力，严重时会导致系统雪崩。
相比Memcached，Redis做了一些优化。首先，Redis对数据做了持久化，支持AOF和RDB两种持久化方式，机器重启后能通过持久化数据自动重建内存。其次，Redis支持主从复制，主机会自动将数据同步到从机，可以进行读写分离，主机负责写操作，从机负责读操作。那样既增加了系统的读写性能又提升了数据的可靠性。再次，Redis除了支持string类型的value外还支持string、hash、set、sorted set、list等类型的数据结构。因此，Redis既可以应用在Cache层，也可以替换或者部分替换DB存储持久化数据。使用Redis作为Cache时机器宕机后热点数据不会丢失，无须像Memcached一样重建热点数据。相比Cache加DB的架构方式，使用Redis存储持久化数据不仅能够提升读性能，还能提升写性能，而且不存在热点数据分布是否集中而影响命中率的问题。Redis丰富的数据结构也使其拥有更加丰富的应用场景。Redis的命令都是原子性的，可以简单地利用INCR和DECR实现计数功能。使用list可以实现获取最近N个数的操作。sort set支持对数据排序，可以应用在排行榜中。set集合可以应用到数据排重。Redis还支持过期时间设置，可以应用到需要设定精确过期时间的应用。只要可以使用Redis支持的数据结构表示的场景，就可以使用Redis进行存储。但Redis不是万能的，它不支持关系型数据库复杂的SQL操作。某些场景下，可结合Redis和关系型DB，将简单查询相关的数据保存在Redis中，复杂SQL操作由关系型DB完成。
虽然Redis集很多优点于一身，但在实际运营中也存在一些问题。首先，Redis不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的IP才能恢复。如果主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，降低了系统的可用性。其次，Redis的主从复制采用全量复制，复制过程中主机会fork出一个子进程对内存做一份快照，并将子进程的内存快照保持为文件发送给从机，这一过程需要确保主机有足够多的空余内存。若快照文件较大，对集群的服务能力会产生较大的影响，而且复制过程是在从机新加入集群或者从机和主机网络断开重连时都会进行，也就是网络波动都会造成主机和从机间的一次全量的数据复制，这对实际的系统运营造成了不小的麻烦。最后，Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。为避免这一问题，运维人员在系统上线时必须确保有足够的空间，这对资源造成了很大的浪费。
所以本文提出一种构建高可用和自动弹性伸缩的KV存储系统的方法。该系统以内存作为主要存储介质，兼容Memcached和Redis常用协议，拥有超高读写性能、高可用性，能自动容错和恢复，具备负载均衡、自动弹性伸缩等特性。
系统整体架构
系统采用分布式设计，数据存储在多个存储节点上。分布式设计的优势在于存储空间和计算资源不受单机的限制。系统包含以下四个节点。
- 路由节点接受客户端的请求，根据请求key的hash值将请求转发到对应的存储节点上。
- 存储节点对外提供数据读写服务，并以心跳的形式将自身的统计信息上报给管理节点。
- 管理节点负责管理所有的路由信息和存储节点，决策存储节点的容错和恢复、负载均衡以及弹性伸缩等。
- 搬迁节点负责处理数据复制和迁移，包括全量和增量复制、负载均衡和弹性伸缩中的数据迁移。
为提高系统的可用性，除路由节点外的所有节点均采用一主一备的形式。路由节点为无状态节点，可以同时存在多个节点，可以在路由节点前加一个LVS模块做负载均衡和容错。系统整体架构如图2所示。
图2 系统整体架构
关键技术点
数据分布
系统采用分布式存储设计，数据分布在多台存储节点上，分布策略采用一致性hash算法。所谓一致性hash是指将以[0, N]的整数集合组成的hash值空间映射成一个环，存储节点和key同时映射到该hash值空间，将key存储在顺时针方向第一个节点上。
当存储节点数较少时，存储节点在环上的分布可能较为集中，导致映射到存储节点的key数量不均衡，可能会导致部分存储节点负载较高，而部分存储节点负载较低的情况出现。为解决这一问题，可将每个存储节点映射为多个虚拟节点，如将每个存储节点映射为3个虚拟节点，然后将虚拟节点映射到hash环上，就增加了环上节点的分布数目，使节点分布更加均衡。
增加虚拟节点后，key和存储节点映射关系也由原来的key→hash环→存储节点转换成了key→hash环→虚拟节点→存储节点。映射关系如图3所示。
图3 带虚拟节点的一致性hash过程
除了平衡性外，一致性hash另一个重要特性是单调性。单调性是指如果集群中新增加了新的节点，则原先映射到旧节点的key部分会映射到新节点，但不会被映射到其他旧节点，这就保证了集群中节点变化时尽可能少的key发生迁移。普通的hash算法往往比较难满足单调性，如简单的取模hash算法：x = Hash(key) mod (N)，N表示存储节点的数目。当节点从3个增加到4个时，几乎所有的key都发生了迁移。
自动容错和恢复
存储节点每隔T秒会向管理节点上报一个心跳，管理节点根据上报的心跳来判断存储节点的存活状态。若存储节点主节点发生宕机，则存储节点主节点停止上报心跳，而备节点继续上报心跳。主节点连续N次未向管理节点上报心跳，则管理节点认为主节点已宕机，将备节点切换为主节点，并且取消主备节点间的数据同步。此时，路由节点继续访问主节点会导致超时，路由节点就会向管理节点重新获取一份最新的路由表，最新的路由表会使用备节点的IP替换主节点的IP。那样新的请求就会发往新的主节点。
当主节点宕机后，T*N秒内服务的发往主节点的读写请求都会失败，等备节点切换为主节点后系统恢复正常。若备节点宕机，则主节点和备节点间的同步会失败，管理节点会通知主节点取消数据同步。在一般的主节点或备节点宕机的情况下，服务只会出现若干秒的异常，只有主节点和备节点同时宕机的极端情况出现时服务才会出现较长时间的不可用。相比只使用一个节点对外服务的或节点故障时需要手动切换的存储系统，采用一主一备和自动容灾的存储系统可用性会高很多，而且该存储系统数据有两份备份，即便其中一个节点磁盘损坏，数据也不会丢失。
当某个节点发生宕机或磁盘损坏时，需要以最快的速度恢复集群的节点数目，防止剩下的节点出现故障。节点恢复的模式有两种：全量恢复模式和增量恢复模式。采用增量恢复模式时，若节点出现故障后很快恢复重启了，则正常节点和故障节点间的数据只有较少一部分不一致，此时只需要将不一致的数据从正常节点复制到恢复的故障节点即可。相比全量复制，增量复制速度更快，对集群的影响也更小。若节点出现了不可恢复的故障，如磁盘损坏等，则需要采用全量复制的模式。管理节点首先会从集群中寻找一个空闲节点，然后再进行节点间的数据全量复制。
确定全量复制还是增量复制可以采用自动加手动的模式，例如可以设置以M小时为界，若M小时内故障恢复，则采用增量恢复的模式，否则采用全量恢复的模式，以防止运维人员在机器故障时未接受到告警或其他情况延误了节点恢复的时间。还可以采用手动触发的模式，若运维人员发现故障节点为磁盘损坏，较难恢复节点后可以直接触发全量复制，以避免不必要的等待时间。节点间的全量和增量复制由管理节点通知搬迁节点完成。自动容错和恢复过程如图4所示。
图4 容错和恢复
负载均衡和弹性伸缩
存储节点随同心跳还会同时上报I/O、容量等统计指标信息。在实际运营过程中可能会出现活跃用户或用户数据分布均匀的情况，导致存储节点间的负载和容量分布不均衡，造成系统资源的浪费。解决这一问题的方法是将负载较低或容量占用较大的存储节点的部分key搬迁到负载较低或容量占用较小的存储节点中。管理节点会根据存储节点上报的统计信息判断当前机器中是否有不均衡的情况出现。若集群中出现不均衡的情况，则管理节点通知搬迁节点搬迁数据，将集群中负载最高或容量最大的存储节点的部分key迁移到负载最低或容量最小的存储节点中。在“数据分布”一节已介绍了key的映射方式为key→hash环→虚拟节点→存储节点。也就是每个存储节点中包含有多个虚拟节点，迁移数据时可以以虚拟节点为单位进行迁移，源存储节点中若干个虚拟节点下的所有key迁移到目的存储节点中并且修改虚拟节点和存储节点的映射关系。具体迁移哪些虚拟节点由管理节点根据两个节点的负载和容量情况确定。
当集群负载或容量达到集群上限时，管理节点会为集群新增节点以提升集群的计算能力和存储空间。当新节点加入到集群时会导致节点间的数据重新分配，根据一致性hash的单调性原理，只有部分旧节点的数据会被映射到新节点，而旧节点之间不会发生数据迁移。那样，整个集群在新增节点时会保证尽可能少的数据发生迁移。当集群负载活容量低于某个阈值时，为避免资源的浪费，管理节点会删除集群中的部分节点，删除节点的过程也满足单调性，即删除节点的数据被映射到了旧节点，而旧节点间不会出现节点间的数据迁移。这就是系统的自动弹性伸缩功能，能根据集群的负载和容量情况自动增加和删除存储节点，这一过程对前端是完全透明的，而且不需要人工干预。
图5以新增节点为例，描述了为何一致性hash在新增节点后能够满足单调性。 当节点3加入集群后，将节点3对应的虚拟节点映射到hash环上，只有原本映射到节点3虚拟节点顺时针第一个虚拟节点的部分数据会被重新映射到节点3的虚拟节点中，而其他虚拟节点中存储的数据不发生迁移。
图5 集群新增节点
总结
存储系统的可用性和容量大小问题是产品运营中很重要的两个问题，让存储系统具备高可用和自动弹性伸缩功能不仅能够让存储系统具备应对机器宕机、磁盘损坏、用户和数据暴涨的问题的能力，还能极大减少运维人员的工作量和运维过程中产生的风险，以确保系统能够更加持久、稳定地运行。
作者吴斌炜，先后在腾讯云平台部和UCloud存储部门工作，现为UCloud UMem产品技术负责人，专注于云存储和云计算领域。
评论