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),以便在副本创建确认后将“写”请求视为“完成”。
  • 命名空间:所有不同类型的数据都可以存储在同一群集中的不同命名空间下,就是这样的层次结构:命名空间 > 集 > 记录。
  • SSD或内存存储:Aerospike有两种模式:SSD与内存。Redis仅在内存中,这意味着大规模扩展变得非常昂贵,而Aerospike可以通过使用SSD存储提供具有竞争力的性能。

基准测试

我对Redis和Aerospike进行了测试比较。首先,吞吐量是最重要的参数,因为我们每秒有来自投标人的数十万个请求。

我在GCE中使用Debian 9创建了一个具有16个vCPU和14.4GB内存的虚拟机(大多数travel audience基础设施都是托管在Google Cloud Platform上),并在那里设置了Redis和Aerospike。

我按照以下链接设置了Aerospike和基准测试:

Install on Debian This tutorial covers installing Aerospike on a Debian system.

Benchmarks Use the Aerospike Go client benchmark tool to generate load on an Aerospike cluster and calculate performance metrics.

我还下载了Go基准测试,因为我们所有的RTB应用程序都是用Go编写的。

这是安装Redis的链接:

Redis Quick Start - Redis The suggested way of installing Redis is compiling it from sources, as Redis has no dependencies other than a working…

然后,我只运行了redis-server并能够使用redis-benchmark工具。

我决定分别运行“写入”和“读取”基准。基准测试写入/读取100万行,将8个字节写入值(int64)和50个并行的客户端连接。

“写”基准:

Redis:

redis-benchmark -t set -n 1000000 -d 8 -c 50
====== SET ======
1000000 requests completed in 7.66 seconds
50 parallel clients
8 bytes payload
keep alive: 1
99.92% <= 1 milliseconds
100.00% <= 2 milliseconds
100.00% <= 2 milliseconds
130497.20 requests per second

Aerospike:

./benchmark -w I -c 50
2018/01/17 14:05:33 Setting number of CPUs to use: 16
2018/01/17 14:05:33 benchmark.go:181: hosts: 127.0.0.1
2018/01/17 14:05:33 benchmark.go:182: port: 3000
2018/01/17 14:05:33 benchmark.go:183: namespace: test
2018/01/17 14:05:33 benchmark.go:184: set: testset
2018/01/17 14:05:33 benchmark.go:185: keys/records: 1000000
2018/01/17 14:05:33 benchmark.go:186: object spec: I, size: 0
2018/01/17 14:05:33 benchmark.go:187: random bin values false
2018/01/17 14:05:33 benchmark.go:188: workload: Initialize 100% of records
2018/01/17 14:05:33 benchmark.go:189: concurrency: 50
2018/01/17 14:05:33 benchmark.go:190: max throughput unlimited
2018/01/17 14:05:33 benchmark.go:191: timeout 0 ms
2018/01/17 14:05:33 benchmark.go:192: max retries 2
2018/01/17 14:05:33 benchmark.go:193: debug: false
2018/01/17 14:05:33 benchmark.go:194: latency: 0:0
2018/01/17 14:05:33 benchmark.go:137: Nodes Found: [BB90512440A0142]
2018/01/17 14:05:34 benchmark.go:712: write(tps=436881 timeouts=0 errors=0 totalCount=436881)
2018/01/17 14:05:35 benchmark.go:712: write(tps=442889 timeouts=0 errors=0 totalCount=879770)
2018/01/17 14:05:36 benchmark.go:712: write(tps=120230 timeouts=0 errors=0 totalCount=1000000)

“读”基准:

Redis:

redis-benchmark -t get -n 1000000 -d 8 -c 50
====== GET ======
1000000 requests completed in 7.47 seconds
50 parallel clients
8 bytes payload
keep alive: 1
99.90% <= 1 milliseconds
100.00% <= 1 milliseconds
133850.89 requests per second

Aerospike:

./benchmark -w RU:100 -c 50
2018/01/17 14:03:55 Setting number of CPUs to use: 16
2018/01/17 14:03:55 benchmark.go:181: hosts: 127.0.0.1
2018/01/17 14:03:55 benchmark.go:182: port: 3000
2018/01/17 14:03:55 benchmark.go:183: namespace: test
2018/01/17 14:03:55 benchmark.go:184: set: testset
2018/01/17 14:03:55 benchmark.go:185: keys/records: 1000000
2018/01/17 14:03:55 benchmark.go:186: object spec: I, size: 0
2018/01/17 14:03:55 benchmark.go:187: random bin values false
2018/01/17 14:03:55 benchmark.go:188: workload: Read 100%, Write 0%
2018/01/17 14:03:55 benchmark.go:189: concurrency: 50
2018/01/17 14:03:55 benchmark.go:190: max throughput unlimited
2018/01/17 14:03:55 benchmark.go:191: timeout 0 ms
2018/01/17 14:03:55 benchmark.go:192: max retries 2
2018/01/17 14:03:55 benchmark.go:193: debug: false
2018/01/17 14:03:55 benchmark.go:194: latency: 0:0
2018/01/17 14:03:55 benchmark.go:137: Nodes Found: [BB90512440A0142]
2018/01/17 14:03:57 benchmark.go:717: write(tps=0 timeouts=0 errors=0) read(tps=446765 timeouts=0 errors=0) total(tps=446765 timeouts=0 errors=0, count=446765)
2018/01/17 14:03:58 benchmark.go:717: write(tps=0 timeouts=0 errors=0) read(tps=503307 timeouts=0 errors=0) total(tps=503307 timeouts=0 errors=0, count=950072)
2018/01/17 14:03:59 benchmark.go:717: write(tps=0 timeouts=0 errors=0) read(tps=487852 timeouts=0 errors=0) total(tps=487852 timeouts=0 errors=0, count=1437924)

从读写基准测试中,您可以看到Redis TPS(每秒事务数)与Aerospike TPS之间存在显着差距:

Aerospike每秒430,000写操作,而Redis每秒130,000写操作

VS.

Aerospike每秒读取480,000次,而Redis每秒读取133,000次

设置集群

我们决定继续使用Aerospike,并在GCE中设置3个节点的集群,其复制因子为2,我们已经将一些最常用的数据从Redis实时切换到了Aerospike。

每个名称空间均配置为具有未分区的SSD磁盘,并且data-in-memory(数据在内存中)参数设置为true。因此,基本上当节点启动时,它将立即将所有数据加载到内存中,然后开始处理请求。这种设置可以使节点更快地启动,并且仅从内存中提供数据(尽管Aerospike具有自己的在内存中缓存数据的机制,当第一次检索记录时,会从SSD抓取记录,然后将其驻留在内存中以供后续请求使用)。

我们使用Prometheus指标以及Aerospike管理控制台,从而我们可以更好地了解集群中的状况。

节点上的所有硬件/软件升级都可以轻松完成,一个接一个地切换节点。这意味着,当您进行升级或删除/添加节点时,只需等待数据迁移、平衡完成即可。Aerospike集群负责其他所有工作。

缺点

除了Aerospike带来的好处(与Redis相比),我还不得不提到缺点:

  • 行数限制:社区版每个节点每个命名空间的行数限制为40亿行,我们目前可以使用它。限制的完整列表可以在这里找到 申博在线娱乐登入/www_aerospike_com/docs/guide/limitations.html
  • 不支持事务:在我们的具体情况下可能更是一个设计问题,我们必须处理来自Google PubSub消息队列的实体(该消息队列不保证消息顺序)。我们需要处理消息版本并将其存储在Aerospike中。因此,要保存每个实体,我们必须在Aerospike中进行多次写入。通常,缺少ACID事务的支持是为使用Aerospike这样高性能数据库付出的代价(没有交易数据库会那么快)。换句话说,Aerospike的generation是一个很好的折中方案。(注:Aerospike现在支持强一致性,甚至支持在不同地区分布的集群中的强一致性。这个用户的分享更加显示出使用Aerospike的益处)
  • 不稳定的Go客户端库:我们的Aerospike Go客户端会不时产生2到3倍的Go例程,并且这些例程保持停滞状态。这意味着它们会消耗更多的内存,并且永远不会释放它。(注:Aerospike的新版本中也解决了这个问题)