快捷搜索:    as  交警  美女  大公  美食  88888  名称

奇虎360陈宗志:开源能让项目走得更长久

Pika 是360 DBA和基础架构组联合开发的类 Redis 存储系统,完全支持 Redis 协议,用户不需要修改任何代码,就可以将服务迁移至 Pika。在 Pika 的开发过程中,有哪些值得我们学习和借鉴的地方?Pika 的优势和特点又是什么呢?本期,【开源访谈】邀请到了 360 平台部基础架构技术经理陈宗志,和大家聊聊 Pika 的开源之路。

【本期嘉宾】

陈宗志, 360 平台部基础架构技术经理,毕业于天津大学软件学院,毕业后先后在美团,百度,360 工作。曾负责设计实现了 Bada,Pika,Floyd 等一系列存储相关的产品,开发设计团队内部的基础库 Pink,Mario 等等。目前主要负责 360 基础机构组内部的基础组件 Bada,Pika,Zeppelin,Ceph,Qconf 等开发和维护。

【访谈实录】

1、先简单介绍一下自己。(学习工作经历,以及主要负责的领域)

我叫陈宗志,目前在 360 Web 平台部基础架构组担任技术经理,在 360 工作将近4年。毕业于天津大学软件学院,毕业后先后在美团,百度,360 工作。

目前主要负责 360 基础机构组内部的基础组件 Bada,Pika,Zeppelin,Ceph,Qconf 等开发和维护。Bada,Pika,Zeppelin,Ceph,Qconf 几乎使用在 360 所有业务线中,每天承担百亿级别的访问。其中 我们已开源 Pika,Zeppelin,Qconf 项目。我们还开源了我们团队开发的一些基础组件,比如在我们团队稳定使用 3 年多的网络编程库 pink,基于 raft 协议实现的一致性协议库 floyd,基于 rocksdb 实现的高性能的多数据结构存储引擎 nemo 等等。

自己对存储,内核,分布式系统有一定的了解,所以对这些领域比较感兴趣。

2、简单谈谈 Pika 项目开发的初衷是什么?(项目开发背景)

因为 Redis 提供了丰富的多数据结构的接口,因此 Redis 在公司内部大量使用。用户把越来越多的数据存储在 Redis 中,慢慢线上就会有 50G,80G 大小这样的 Redis。

DBA 在运维管理这个大容量 Redis 的过程中慢慢遇到的诸多问题,比如:恢复时间长,一主多从,主从切换代价大,缓冲区容易写满,内存价格昂贵等等。因此 DBA 就和我们基础架构团队一起解决这类问题,因此就有了Pika。

所以 Pika 是 DBA 需求,基础架构组开发的大容量、高性能、持久化、支持多数据结构的类 Redis 存储系统。由于 Pika 有专门的 DBA 同学进行把关,因此 Pika 的可用性,可维护性应该是同类产品中最好的,这也是为什么 Pika 短期内有大量的内部、外部业务接入的原因。

3、Pika 作为类 Redis 存储系统,与 Redis 相比,有哪些优势?又有哪些缺点?

优势

大容量存储:Pika 数据容量受制于磁盘,最大使用空间等于磁盘空间的大小,而 Redis 数据容量受限于主机内存。

秒级启动:Pika 在写入的时候,数据是落盘的。Pika 重启不用加载所有数据到内存,不需要进行回放数据操作。而 Redis 启动需要将所有数据从磁盘加载到内存,随着容量增加,启动时间递增到分钟级甚至更长时间。

秒级备份:Pika 的备份方式是将所有数据文件做快照。Redis 无论是用 RDB 还是 AOF 的方式来实现数据备份的目的,都需要将全量的数据写入到磁盘,备份速度慢。

秒删数据:Pika 的数据删除是标记删除,Pika Key 的元信息上有版本信息,表示当前 key 的有效版本,已删除的数据在 Compact 合并数据的过程中删除。而单线程的 Redis 在大量删除数据时候会影响线上业务,删除大对象会阻塞住 Redis 的主线程,删除速度慢。

同步续传:Pika 写入数据会有 write2file 日志文件,只要该文件未删除,无需全量同步数据,均可断点续传数据。而 Redis 一旦主从同步缓冲区被循环重写,容易导致全量数据重传。

高压缩比:Pika 存储的数据默认会被压缩,相对于 Redis,Pika 有 5~10 倍的压缩比。所以 Redis 的数据存储到 Pika,数据体积会小很多。

高性价比:相对于 Redis 使用昂贵的内存成本,Pika 使用磁盘存储数据,性价比极高。

缺点

您可能还会对下面的文章感兴趣: