redis 集群设计一种方案

最近，在做一个管理2亿用户数据的平台方案，根据我们业务的需求，采用http协议，这样很自然地，我们就是用了webserver, nginx+fast_cgi ,后端缓存我们选择了redis.但对于2亿的用户处理，我们的缓存不能是一两台就能够的，最后我们决定使用8个redis来缓存我们目前的数据。这样问题就来了：

服务器组耦合度很大，不利于开发，维护，

       我们的应用进程要去访问8个 redis，那么如果每个应用，都来直接读写这个8个 redis的话，那么整个服务器组链接将是一张网状结构，这对整个服务器组的耦合度来说是比较大的。

容灾导致服务器组整体性能下降

     因为我们前端是PHPserver，它是没有状态的，使用用一致hash的计算方式。那么当某一个redis挂了，我看webserver是怎么来重新hash一致的。只能是请求的时间，才知道redis挂了，这时才能重新启用一致hash的另外的算法来读写redis。这样的效率对前段的webserver的效率来说是很大的，导致前端webserver的吞吐量成倍下降。

基于以上的考虑：

    我准备在前端的webserver的应用层跟后端的数据缓存层（redis)中加一层，数据控制层，叫他DC 层。这一层用C++写，这么一来，前端的业务层的所有对数据缓存的操作，全部转向DC层，这样，前端业务层的跟数据层分离，业务层不再需要知道数据到底是存在那个redis上，系统的耦合度就降下来了。如果出现redis宕机的情况，DC层很容易知道，DC层是用长连接到redis上的，这种情况下也不会出现系统整体性能下降的问题。

具体DC层的设计，在下一篇。。。。