再看预算控制模块
source link: https://www.zenlife.tk/%E5%86%8D%E7%9C%8B%E9%A2%84%E7%AE%97%E6%8E%A7%E5%88%B6%E6%A8%A1%E5%9D%97.md
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
再看预算控制模块
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集群的场景。
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK