Aerospike VS. Redis, 案例分享_aerospike vs rocksdb performance comparison

Aerospike VS. Redis, 案例分享

Redis在中国有成熟的社区，大多数企业都或多或少用到Redis, 但我相信大家也会发现Redis有很多不尽如人意的地方，如果有一款K-V数据库能给您带来更快的读写速度，更可靠的安全保障以及更低的总体拥有成本，为什么不多了解一下Aerospike呢？

今天我想给大家分享一个来自我们的客户Travel audience 的案例！

“Travel audience”是一个数字广告平台；这意味着我们将在全球范围内不断投放大量广告。在本文中，我想谈一谈我们投标部门面临的一些挑战。

我们的竞标者参加了实时广告环境中网页上广告位的拍卖。我们每秒处理约60–70k个出价请求，每个请求的处理时间应少于75ms。为了处理系统上的高负载，我们一直在使用Postgres在后台刷新内存中的数据，并在Redis中使用实时数据。（技术公司中通常使用的数据库集包括RDBMS，例如Postgres，MySQL以及缓存解决方案。）

来自SSP（供应方平台）的每个请求都会导致对缓存的多个查询。吞吐量（每秒处理的事务）和延迟（响应时间）是重要的指标，此缓存必须满足RTB应用程序的需要。

随着时间的流逝，广告系列的数量在增加，我们投放广告的用户数量也在增加，预算也在增加。这就是为什么我们必须保持灵活性，以便根据负载扩展我们的系统。

挑战

我们的Redis缓存层由运行在不同端口上的几个Redis数据库（5-6）组成，每个数据库都有1个主节点和大约10个从属节点。从某个时候开始，我们注意到使用Redis时越来越多的问题。这是我们面临的一些问题：

· 一个主设备，多个从设备 – “写”吞吐量受运行主节点的一台服务器的限制。

· Redis是单线程的，这意味着我们在CPU方面没有垂直可扩展性。

· 实时主从同步问题 - 由于在主节点上进行了大量写入操作，因此所有更改都必须与从节点同步。由于无法同步大量数据并同时将数据提供给来自RTB应用程序的读取请求，导致从节点必须脱机进行同步。

· 在同一个数据库中没有方便的方法来存储多种不同类型的数据 - 我们不得不将不同的实体存储在不同的Redis实例（instance）中，这样我们就必须处理不同端口上的多个连接。

解决方案

我试图找到一种可以满足我们所有需求的解决方案，同时仍要保持灵活性和易用性。

经过广泛的研究，我深刻的了解Aerospike可以真正满足我们的需求；我在上一份工作中已经有了一些使用Aerospike的经验。因此，我们在这个项目上开始采用Aerospike。

Aerospike的好处包括：

· 分区 - 默认情况下，它具有4096个分区，分布在群集中的所有节点上。这对于我们 “写”吞吐量有很大提升。

· Aerospike是多线程的 - 可以最有效地利用我们的资源。

· 主副本同步没有停机时间 - 您可以配置“写”规则（policy），以便在副