怎样用集群方式开发app项目？
由于Redis出众的性能，其在众多的移动互联网企业中得到广泛的应用。Redis在3.0版本前只支持单实例模式，虽然现在的服务器内存可以达到100GB、200GB的规模，但是单实例模式限制了Redis没法满足业务的需求（例如新浪微博就曾经在用Redis存储了超过1TB的数据）Redis的开发者antirez早在博客上提出Redis3.0版本中加入集群的功能，但3.0版本等到2015才发布正式版。各大企业在3.0版本还没发布前为了解决Redis的存储瓶颈，纷纷推出了各自的Redis集群方案。这些方案的核心思想是把数据分片(sharding)存储在多个Redis实例中每片就是个Redis的实例。深圳APP开发公司下面介绍Redis的集群解决方案。
一、APP开发集群解决方案之客户端分片
客户端分片是把分片的逻辑放在Redis客户端实现，通过Redis客户端预先定义好的路由规则，把对key的访问转发到不同的Redis的实例中，最后把返回结果汇集。这种方案的模式如图7-15所示。
APP制作集群解决方案示意图7-15客户端分片的模式
客户端分片的好处是所有的逻辑都是可控，不依赖于第三方分布式中司件。开发人员清楚怎么实现分片、路由的规则．不用担心踩坑。客户端分片的方案有下面的坏处
·这是一种静态的分片方案，需要增加或者减少Redis实例的数量，都需要手工调整分片的程序。
·可运维性差，集群的数据出了任何问题都需要运维人员（查看Redis实例的部分）和开发人员（查看客户端的分片逻辑部分）一起合作，延迟了解决问题的速度，增加了跨部门沟通的成本。
·在不同的客户端程序中，维护相同的分片逻辑成本巨大。例如，系统中有两套业务系统共用套Redis集群，一套业务系统用Jaya实现，另一套业务系统用PHP实现。为了保证分片逻辑的致性，在Jaya客户端中实现的分片逻辑也需要在PHP客户端实现次。把相同的逻辑在不同的系统中分别实现，这种设计本来就非常糟糕，而且需要耗费巨大的开发成本保证两套业务系统分片逻辑的一致性。
二、APP开发之Twemproxy方案
Twemproxy是由Twitter开源的Redis代理，其基本原理是：Redis客户端把请求发送到Twemproxy，Twemproxy根据路由规则发送到正确的Redis实例，最后Twemproxy把结果汇集返回给客户端。
Twelnproxy通过引入了一个代理层，将多个Redis实例进行统管理，使Redis客户端只需要在Twemproxy上进行操作，而不需要关心后面有多少个Redis实例，从而实现了Redis的集群。APP制作集群解决方案Twemproxy集群架构如图7-16所示。
APP集群解决方案示意图7-16Twemproxy集群架构
Twemproxy的优点如下：
·客户端像连接Redis实例样连接Twemproxy，不需要改任何的代码逻辑。
·支持无效Redis实例的自动删除。
·Twemproxy与Redis实例保持连接，减少了客户端与Redis实例的连接数。
Twelnproxy有如下不足：
·由于Redis客户端的每个请求都经过Twemproxy代理才能到达Redis服务器，这个过程中会产生性能损失。
·没有友好的监控管理后台界面，不利于运维监控。
·最大的问题是Twemproxy无法平滑地增加Redis实例。对于运维人员来说，当因为业务需要增加Redis实例时工作量非常大。Twelnproxy作为最被广泛使用、最久经考验、稳定性最高的Redis代理，在业界被广泛使用。
三、APP开发集群解决方案之Codis
Twemproxy不能平滑增加Redis实例的问题带来了很大的不便，于是豌豆荚自主研发了Codis，一个支持平滑增加Redis实例的Redis代理软件，其基于Go和C语言开发，并于2014年11月在Github上开源。
Codis包含下面4个部分。
·CodisProxy:Redis客户端连接到Redis实例的代理，实现了Redis的协议，Redis客户端连接到CodisProxy进行各种操作。Codis Proxy是无状态的，可以用keepalived等负载均衡软件部署多个CodisProxy实现高可用。
·CodisRedis:Codis项目维护的Redis分支，添加了slot和原子的数据迁移命令。Codis上层的CodisProxy和Codisconfig只有与这个版本的Redis通信才能正常运行。
·Codisconfig:Codis管理工具。可以添加删除CodisRedis节点，添加删除CodisProxy，数据迁移等操作。另外，Codisconfig自带了HTTP server，里面集成了一个管理界面，方便运维人员观察Codis集群的状态和进行相关的操作，极大提高了运维的方便性，弥补了Twemproxy的缺点。
·ZooKeeper:分布式的、开源的应用程序协调服务，是Hadoop和Hbase的重要组件，其为分布式应用提供致性服务，提供的功能包括：配置维护、名字服务、分布式同步、组服务等。Codis依赖于Zool:eeper存储数据路由表的信息和Codis P roxy节点的元信息。另外，Codisconfig发起的命令都会通Zookeeper同步到Codis P roxy的节点。Codis的架构如图7-17所示
APP开发集群方案示意图7-17Codis的架构图
在图7-17的Codis的架构图中，Codis引入了Redis Seryer G roup，其通过指定了个主CodisRedis和个或多个从CodisRedis．实现了Redis集群的高可用。当个主CodisRedis挂掉时，Codis不会自动把个从CodisRedis提升为主CodisRedis，这涉及到数据的一致性问题。
(Redis本身的数据同步是采用主从异步复制，当数据在主CodisRedis写入成功时，^CodisRedis是否己读入这个数据是没法保证的)，需要管理员在管理界面上手动把从CodisRedis提升为主CodisRedis。
如果觉得麻烦，豌豆荚也提供了个工具Codis-ha，这个工具会在检测到主CodisRedis挂掉的时候将其下线并提升个从CodisRedis为主CodisRedis。
Codis中采用预分片的形式，启动的时候就创建了1024个slot，1个slot相当于1个箱子，每个箱子有个固定的编号，范围是l-1024。slot这个箱子用作存放Key，至于Key存放到哪个箱子，可以通过算法“crc32(key)%1024”获得个数字，这个数字的范围定是1--1024之间，Key就放到这个数字对应的slot。例如，如果某个Key通过算法“crc32(key)%1024”得到的数字是5，就放到编码为5的slot（箱子）。一个slot只能放一个'Redis Seryer Group，不能把1个slot放到多个Redis Seryer Group中。一个Redis Seryer Group最少可以存放1个slot，最大可以存放1024i'slot。因此，Codis中最多可以指定1024一个Redis Seryer Group。
Codis最大的优势在于支持平滑增加（减少）RedisSeryerGroup（Redis实例，能安全、透明地迁移数据，这也是Codis有别于Twemproxy等静态的分布式Redis解决方案的地方。Codis增加了RedisSeryerGroup后，就牵涉到slot的迁移问题。例如，系统有两个RedisSeryerGroup．RedisSeryerGroup和slot的对应关系如下。
当增加了个RedisSeryer Group，slot就要重新分配了。Codis分配slot有两种方法。
第一种：通过Codis管理工具Codisconfig手动重新，指定每个Redis Seryer Group所对应的slot的范围，例如可以指定Redis。Seryer Group和slot的新的对应关系如下。
第二种：通过Codis管理工具Codisconfig的rebalance功能，会自动根据每个RedisSeryerGroup的内存对slot进行迁移，以实现数据的均衡。好了APP开发公司本文关于APP项目制作怎样使用集群模式的经验知识本文就分享到这里。谢谢你的关注。博纳网络编辑整理。
