再看预算控制模块

2015-05-28

之前有提到过我们竞价服务预算控制模块的问题。

这几天看了一下redis集群,老大让看看把这部分数据迁到集群中。一看吓一跳:算钱相关的,居然redis用作存储,这胆子也是够肥的!

数据量其实很小,不过之前还是业务层做的hash分到多个redis实例中的,但是没有主从。如果redis挂了,预算就完全不受控,然后就没法跟客户交待了。

首先明确一点:redis是一个AP的系统,不保证C,而且...是会丢数据的。如果切换到redis集群可以解决的是容错和可用性问题。但是不会解决的是一致性以及数据不丢。

redis为什么会丢数据?从单机的角度,写aof是周期性的,只有fsync刷盘之后,数据才是真正的持久化了,期间进程挂掉或者突然断什么等意外都可能导致数据丢失。升到集群之后,由于是先回复请求,再异步写副本的,数据也会丢。比如说master回复client写ok,然后master挂了,数据还没有写到slave。接着slave提升为master,这次写就丢失了。

对redis集群做了一个简单的测试,跟单个实例相比,读的性能基本上没有损失。但是写操作性能降低很大。

因为要多一份异步写副本操作,平均到每个实例的处理能力下降了好多。比如在我们内网机器上测试单实例的set操作,不开pipeline,无slave,大概是7-8w的qps。测试3主3从的redis集群,整集群的吞吐量大概才12w,平均到每个实例不到4w了。3个master的CPU跑满之后,slave的CPU大概在40~50%的样子。

回头再看我们的业务,每投出一次广告,都要修改预算数据。而读是周期性(比如10秒)由dispatch读出,再走消息队列同步到竞价服务那边。所以,这是一个写远高于读场景。

总结一下,换到集群是满足了可用性。但是一致性方面,不适合算钱的业务。另外业务模型上面主要是写操作对redis集群也不算啥优势,虽然以现在的的压力完全没任何问题。做肯定是能做,不过这里并不是一个比较适合redis集群的场景。

redis