基于Aerospike的用户数据管理系统实践

2015-05-12  FreeWheel

基于Aerospike的用户数据管理系统实践

作者：王敏

‍ 在互联网广告行业中，根据用户的信息和购买兴趣进行精准广告投放已成为一个基本需求。为了满足这一需求，需要搭建一个支持高并发、低延迟、可扩展的用户数据库，这是很多实时广告系统面临的一个技术挑战。

FreeWheel的用户数据库目前存储着6亿多条用户数据，每天更新的数据约1亿条，要求达到10ms量级的用户数据读取性能。我们在用户数据库的架构设计上做过很多尝试和改进，本文介绍了我们最近基于Aerospike的一些实践。

Aerospike’s Technology

如上图所示，Aerospike主要分为3层：

Client Layer，Distribution Layer 和 Data Storage Layer

• Client Layer可以访问Aerospike Server中的数据（读、写操作等）。Aerospike Client包含了多种高效的开源语言（比如：C、Golang、Libevent、Python等等)。Aerospike Client 端能够监控cluster的所有nodes，并且能自动感知nodes的更新，同时掌握数据在cluster内的分布。Aerospike Client 具有以下特点：

  o 高效性：Client的基础架构确保request都能直接到相应的nodes读写数据，进而减少响应时间。

  o 稳定性：如果nodes出错，不需要重启Client 端，并且保持服务的正确性。

  o 链接池：为了减少频繁的Open/Close TCP 操作，Client会在内部维护一个链接池保持长链接。

• Distribution Layer 负责管理cluster内数据平衡分布、备份、容错和不同cluster之间的数据同步。基于“shared nothing”的架构，如果要提升Aerospike cluster的性能，只需要简单的向cluster添加新的server，并且不需要停止当前的服务。Distribution Layer主要包含3个模块：

  o Cluster Management Module：基于“Paxos-like consensus voting process”算法来管理和维护cluster内的nodes，并且用“heartbeat”（含active 和 passive）来监听nodes的状态。

  o Data Migration Module：当有node添加或移除时，该模块保证数据的重新分布。

  o Transaction Processing Module：确保读写的一致性，写操作先写Replica，再写Master。

• Data Storage Layer负责数据储存，Aerospike是schema-less的key-value 数据库，数据存储模式如下：

  o 命名空间：数据存在namespace中（类比RDBMS中的database）；namespace可以分为不同的sets（tables）和records（rows）；每条record包含一个唯一的key和一个或多个bins值（columns）。

  o 索引：Aeorpsike Indexes包含Primary Indexes和Second Indexes。为了更高的性能，Aerospike Indexes都只存在内存中并不会存在SSD中。

  o 磁盘：与其它基于文件系统数据库的不同之处，Aerospike为了达到更好的性能选择了raw device —— 直接访问SSD中的raw blocks，同时Aerospike特别优化小块读，大块写和并行SSD来增加响应速度和吞吐量。

• Aerospike Cross Data-Center Replication （XDR）：除了基本的Aerospike Server外，Aerospike还提供跨数据中心数据同步的功能。

  o 实时性：Aerospike XDR同步的基本单位是record。

  o 稳定性：类似于Aerospike Client， XDR也具有良好的稳定性和错误处理，无论是local cluster的node错误还是remote cluster的node错误，XDR都能保证服务的正确。

FreeWheel用户数据库一方面要维护大量的用户数据，并根据用户数据实时投放广告，另一方面每天还有大量用户数据更新并实时地同步到所有数据中心，所以我们对用户数据库的响应速度、稳定性和可扩展性都有极高的要求。经过对不同数据库的调研和性能评估，Aerospike不仅在性能上最优，而且能够方便地动态扩展，因此我们最终选择了Aerospike作为存储用户信息的数据库，并根据我们的业务需求对 Aerospike的功能进行了以下定制：

• 在Aerospike Client端，为了更快的响应速度，我们选择了Aerospike Libevent，实现了异步和同步的读写操作。

• 在Aerospike Server 端，设置Replication factor=2，在确保当有一个node错误时服务的稳定性，并且避免硬件的浪费。同时在保持单机性能的情况下通过增加nodes数量，扩展Aerospike性能。

• 在Aerospike Storage端，因为Aerospike要求不同的namespace必须在不同的物理设备上，所以我们只创建了必要的namespaces，动态的添加sets来分区不同的数据。在满足MegaCLI测试结果的情况下，为了更好的分离硬件和数据，我们选择了RAID 5，保证磁盘的损坏不影响数据。

由于我们需要实时同步大量用户数据到所有的数据中心，基于Aerospike XDR的功能，我们建立了如下数据流的拓扑图，减少不同数据中心的依赖：

Aerospike Data Flow in Freewheel

切换到Aerospike后，我们的广告投放系统不仅在响应速度上有很大的提升，而且跨数据中心同步平均延迟控制在毫秒级，基本到达实时更新的需求。下图是切换到Aerospike前后响应时间大于100ms的广告决策数量变化。

Switching to Aerospike

作者简介：

王敏，2012年毕业于北京大学计算机系，获工学硕士学位，2013年加入Freehweel，现任广告预测组资深工程师，主要负责用户数据管理系统的架构设计和开发工作。联系方式：[email protected]。

王敏说：

aerospike的一个问题，tcp connection会比较多，以及如果xdr的话都是by record,可能会很多小包（根据你的存的内容）

然后xdr的性能也是有点瓶颈，普通的read/write performance倒是没有问题

普通的read/write performance的瓶颈更容易在带宽上

另外开始建立好namespace,加新namespace好费劲

对于内存、磁盘的使用量建议不要超过60%