之前有提到过我们竞价服务预算控制模块的问题。
这几天看了一下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集群的场景。
Read full article from 再看预算控制模块
No comments:
Post a Comment