Redis集群解决方案调研

最近因项目需求，调研了Redis集群解决方案。

所参与的项目是分布式对象存储系统，在今年计划进行新版本开发，要增加多数据中心相关功能，以提高系统的容灾性。

为了保证用户数据在不同数据中心的全局唯一性，需要增加类似元数据服务器的模块，来提供全局用户数据服务。在但数据中心版本中，有一个类似元数据服务器的模块来提供该服务，后端数据存储采用的是Hbase，并用Memcached做了分布式缓存来提高系统性能。

由于Hbase依赖HDFS，而我们在设计元数据服务器时，想尽量保证其简单、尽量少依赖其它较为厚重的模块，所以考虑是否能用Redis内存数据库的性能优势及其持久化的功能来代替Hbase+Memcached的组合，然后就有了本次调研。

在调研Redis解决方案之前，首先要弄清数据存储的CAP理论，C:数据一致性，A:数据可用性，P：分区容忍性。

结合CAP理论以及本项目用户相关元数据的数据量，首先要考虑的就是分区容忍性，因此必须是分布式的解决方案；其次是数据可用性，因此必须有良好的性能，而且在某个节点挂掉后，整个系统依然能正常对外提供服务；再就是数据一致性，要保证数据备份的所有副本保持一致。

有了以上前提，在进行本次调研时，直接查找Redis Cluster相关内容。

业界在生产环境中进行大规模使用的，有两种方案：一是豌豆荚的Codis(git)，两一个是Twitter的Twemproxy(git)。还有一种解决方案是Redis官方的Cluster，由于出来的时间不长，所以没多少人使用。相关对比网络上资料很多，可以直接查找。

调研之后感觉Codis可能更适合我们的项目。但有一点在调研之前还是被忽略掉了，就是数据的可用性。Redis的数据备份方案，大致有三种：一是AOF，一是RDB，还有就是基于Master Slave进行数据的备份。通过分析三种备份方案，发现Redis为了保证其良好的性能，都采用了异步备份的方式，这导致数据存在丢失的风险。虽然AOF可以做到每1秒钟刷一次磁盘，且性能可以得到保证，但1秒的数据丢失风险在生产环境也是不被允许的。

最后查到了豌豆荚的架构师介绍其Codis业务的PPT，发现他们在使用时也只是以Codis在提供前端缓存，后端还有持久化的存储方案。所以最终放弃了使用Codis来代替Hbase+Memcached的方案。