网站中怎么做视频直播,在线简易网页制作网站,个性化网站制作,如何利用微信进行企业网站推广文章目录 美团在KV存储squirrel优化和改进在水平方向1、对Gossip协议进行优化 在垂直扩展方面1、forkless RDB数据复制优化2、使用多线程#xff0c;充分利用机器的多核能力 在高可用方面 美团持久化kv存储celler优化和改进水平扩展优化1、使用bulkload进行数据导入2、线程模型… 文章目录 美团在KV存储squirrel优化和改进在水平方向1、对Gossip协议进行优化 在垂直扩展方面1、forkless RDB数据复制优化2、使用多线程充分利用机器的多核能力 在高可用方面 美团持久化kv存储celler优化和改进水平扩展优化1、使用bulkload进行数据导入2、线程模型调度优化 知识点解释1、对于哨兵架构的redis虽然也使用一致性hash进行扩所容但为什么有可能在扩缩容导致数据丢失2、为什么对于kv存储服务当集群数量达到一定规模之后再水平扩容会遇到哪些问题如何解决3、mget操作在大集群中可能会有木桶效应如何解决4、什么是Gossip协议应用场景和优缺点分别是什么 Reference 美团在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集群节点的管理 SlaveMaster自己点做容灾
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存储挑战与架构实践
