美团KV存储squirrel和Celler学习


美团在Redis Cluster和阿里的开源项目Tair基础上,分别自研开发了Squirrel和Celler两款KV存储系统。Squirrel全内存、高吞吐和低延迟,适合业务的数据量小,对延迟敏感,建议用 Squirrel ;Celler持久化、大容量、数据高可靠,适合数据量大,对延迟不是特别敏感,成本更低的Cellar 。

美团在KV存储squirrel优化和改进

在这里插入图片描述

KV存储主要的两个问题是,数据量增后的扩张性和随着节点增加后的可用性如何保证。squrriel分别在水平方向扩展和垂直方向扩展优化。

在水平方向

1、对Gossip协议进行优化

使用markle tree 对每个节点的数据进行摘要,将集群中Gossip协议通信传输数据量减少了90%以上。同时使用单独的心跳线程更新拓扑结构元数据,对于工作线程只对拓扑元数据进行读,可以做到无锁读,gosssip的请求处理对业务请求完全没有影响。

在垂直扩展方面

1、forkless RDB数据复制优化

Redis在的RDB过程中是通过系统的fork()函数创建一个子进程,创建的子进程拥有和父进程相同的资源和数据(系统的copy on write思想),然后让子进程对拥有的内存数据进行持久化。fork过程非常快,通常在秒级别完成,但对于一个通常几十毫秒KV系统来说也是影响很大的,尤其要求响应非常高的系统往往也是不可以接受。forkless 不需要创建子进程,使用工作线程将每次数据变成写到一个持久化队列里面,实时同步对数据的变更,相比fork好处是,即使在RDB过程中,也不会阻塞工作线程,但如果变更数据很多时,需要占用工作工作线程时间,如果有大kv需要复制,可能也会造成单个用户请求耗时增加。

2、使用多线程,充分利用机器的多核能力

squirrle的多线程方案吞吐比社区IO的多线程提升70%,相比社区单线程提升3倍多,具体原因没有太理解。

在高可用方面

多机房部署进行融灾,但为了降低多机房部署维护的难度,并同时实现为存活节点过半选主过程,增加不存储数据的见证节点单独部署在一个机房。对于跨地域容灾,使用双向数据同步,对数据双向同步遇到的循环复制和数据冲突问题,分别使用同步数据带上clusterId和基于时间戳的last write win策略进行解决。

美团持久化kv存储celler优化和改进

在这里插入图片描述
OB:只提供客户端集群节点元数据查询功能,可以水平扩展
ZooKeeper:分布式仲裁
Master:集群节点的管理
Slave:Master自己点,做容灾

kv存储希结构本身比较简单,基于内存的读写实现存储系统的高效性是kv系统设计的其中一个初衷原因,基于内存的存储系统受限于存储断电的丢失性和内存有限性,在有些场景,需要同时兼顾安全性、数据量和高效性。通过一定策略将热点数据缓存到内存中,将冷数据持久化到磁盘中,可以兼顾高效性和安全性。首先celler使用中心化方式进行集群管理和节点间数据同步,节点之间不用使用gossip进行通信,每个节点向管理中心发送心跳,理论上不存在水平扩展问题。但对单个节点来说,却存在水平扩展的问题。

水平扩展优化

1、使用bulkload进行数据导入

Celler是基于LSM-tree进行数据导入,存在写入放大的问题,为了解决这个问题,先将客户端数据使用对象存储(因为是直接从本地传输数据到对象存储服务器,突然理解为什么平时公司为什么对大数据问题,让客户端做数据的上传,然后只上传文件地址给服务端),将存储地址从客户端发送给服务器,服务器根据地址从对象存储服务器中获取数据,避免客户端网络不稳定可能导致的大数据传输失败问题。

2、线程模型调度优化

为了隔离开离线请求、快慢请求,使用四个队列和四个线程池分别处理,分别处理读快、读慢和写快写慢四种请求,保证对核心请求处理的效率。

知识点解释

1、对于哨兵架构的redis虽然也使用一致性hash进行扩所容,但为什么有可能在扩缩容导致数据丢失?

哨兵架构主要是为了保证高可用,但一个节点宕机,快速选择新的节点作为主节点。扩缩容主要有数据重分配和数据迁移过程中数据一致性问题,一致性hash只能减少扩缩容时数据迁移量,并不能保证数据迁移过程中一致性问题。数据迁移过程中,除了网络问题,如果迁移过程没有被正确管理,比如迁移过程中旧数据的更新并没有同步到新节点,会造成数据丢失。

2、为什么对于kv存储服务,当集群数量达到一定规模之后,再水平扩容会遇到哪些问题,如何解决?

管理复杂度增加,大规模节点中发现有问题的节点更加困难,更难保证数据的负载均衡;性能问题,集群节点内数据通信增加,网络宽带可能成为瓶颈,客户端访问数据分布在不同节点上,导致整体延时增加;数据一致性,在多个解节点维持事物的ACID更加困难,达到最终一致性延迟增高。其中一个有效解决方案是集群分区,根据业务场景,将数据划分到不同集群。

3、mget操作在大集群中可能会有木桶效应,如何解决?

mget是可以一次批量获取多个key的值。在大集群中,第一、节点数据可能分布不均匀,一致性hash只可以相对均匀维持数据的分布均匀;第二,节点性能差异,每个节点硬件、网络都会有差异,批量查询时,整个结果响应耗时以最差节点返回结果为准;第三,网络延迟的增加,如果同时请求多个数据中心的数据,整个查询延时会增加。针对这三个主要问题,可以定期重新分布数据;所有节点尽量使用相同的硬件和网络,对于热点key进行多副本处理或者升级硬件提升机器性能;减小单次mget查询的数据量,对于可以预测的热点key单独请求,缩短单次查询的耗时。

4、什么是Gossip协议,应用场景和优缺点分别是什么?

Gossip协议是分布式环境中节点之间信息交换的算法,使用过程要考虑如何避免循环传递,例如使用版本号和时间戳,分布式Id或者设置生存时间。工作原理,每个节点定期与周围节点交换信息,信息交换可以是单向,也可以是双向,每次选择交换节点事随机选取的,每次交换信息后会更新自身信息,并将更新信息在后续交换中传播。优点、去中心化,扩展性强,因为每次只用和部分节点进行交换,即使在大的分布式环境中依然可以使用,容错性高,即使某个节点出现故障,整个集群的消息依然可以保持正常交流。缺点、第一、冗余通信,同一个节点同一个更新信息,可能被通知多次;第二,全局达到一致性的时间会更长,由于每一轮只通知n个节点,过了一个周期后才会选择n个节点通知,需要经过多个周期之后,才有可能达到整个集群的一致性;第三、可能有些有些信息在某些节点不会被通知到,可以通过改进节点选择算法,或者调整更新频率或者范围(偶尔进行一次全局广播)。

Reference

美团大规模KV存储挑战与架构实践

  • 20
    点赞
  • 30
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值