Redis缓存的设计、性能、应用与数据集群同步

Redis持久化的方式

redis提供了两种持久化的方式，分别是RDB (Redis DataBase) 和AOF (Append Only File)
1.RDB
简而言之，就是在不同的时间点，将redis存储的数据生成快照并存储到磁盘等介质上

2.AOF
换了一个角度来实现持久化，那就是将redis执行过的所有写指令记录下来，在下次redis重新启动时，只要把这些写指令从前到后再重复执行一遍，就可以实现数据恢复了。
其实RDB和AOF两种方式也可以同时使用，在这种情况下，如果redis重启的话，则会优先采用AOF方式来进行数据恢复，这是因为AOF方式的数据恢复完整度更高。如果你没有数据持久化的需求，也完全可以关闭RDB和AOF方式，这样的话，redis将变成个纯内存数据库，+持久化 就像memcache一样。

Redis常见性能问题和解决方案
1.Master最好不要做任何持久化工作，如RDB内存快照和AOF日志文件
2.如果数据比较重要，某个Slave开启AOF备份数据，策略设置为每秒同步一次
3.为了主从复制的速度和连接的稳定性，Master和Slave最好在同一个局域网内
4.尽量避免在压力很大的主库上增加从库
5.主从复制不要用图状结构，用单向链表结构更为稳定，即: Master <- Slave1 <- Slave2 < Slave3...。这样的结构方便解决单点故障问题，实现Slave对Master的替换。如果Master挂了，可以立刻启用Slave1做Master，其他不变。

Redis的适用场景
1.会话缓存 (Session Cache)
最常用的一种使用Redis的情景是会话缓存 (session cache) 。用Redis缓存会话比其他存储(如Memcached) 的优势在于:Redis提供持久化。当维护一个不是严格要求一致性的缓存时，如果用户的购物车信息全部丢失，大部分人都会不高兴的，现在，他们还会这样吗?
幸运的是，随着 Redis 这些年的改进，很容易找到怎么恰当的使用Redis来缓存会话的文档。甚至广为人知的商业平台Magento也提供Redis的插件。
2.队列
Reids在内存存储警领域的一大优点是提供List 和 set 操作，这使得Redis能作为一个很好的消息队列平台来使用。Redis作为队列使用的操作，就类似于本地程序语言 (如Pvthon) 对 list 的 push/pop 操作
如果你快速的在Google中搜索Redis queues”，你马上就能找到大量的开源项目，这些项目的目的就是利用Redis创建非常好的后端工具，以满足各种队列需求。

3.全页缓存 (FPC)
除基本的会话token之外，Redis还提供很简便的FPC平台。回到一致性问题，即使重启了Redis实例，因为有磁盘的持久化，用广也不会看到页面加载速度的下降，这是一个极大改进，类似PHP本地FPC.
再次以Magento为例，Magento提供一个插件来使用Redis作为全页缓存后端，此外，对WordPress的用户来说，Pantheon有一人非常好的插件 wp-redis，这个插件能帮助你以最快速度加载你曾浏览过的页面。
4.排行榜/计数器
Redis在内存中对数字进行递增或递减的操作实现的非常好。集合(Set)和有序集合 (Sorted Set)也使得我们在执行这些操作的时候变的非常简单，Redis只是正好提供了这两种数据结构。所以，我们要从排序集合中获取到排名最靠前的10个用户-我们称之为“user scores”，我们只需要像下面一样执行即可:
当然，这是假定你是根据你用户的分数做递增的排序。如果你想返回用户及用户的分数，你需要这样执行: ZRANGEuser scores 0 10 WITHSCORES.

Redis的高可用策略 (单点故障避免策略)
1.高可用 (High Availability)
当一台服务器停止服务后，对于业务及用户毫无影响。停止服务的原因可能由于网卡、路由器、机房、CPU负载过高、内存溢出、自然灾害等不可预期的原因导致，在很多时候也称单点问题
2.主备方式
这种通常是一台主机、一台或多台备机，在正常情况下主机对外提供服务，并把数据同步到备机，当主机宕机后，备机立刻开始服务。Redis HA中使用比较多的是keepalived，它使主机备机对外提供同一个虚拟P，客户端通过虚拟IP进行数据操作，正常期间主机一直对外提供服务，岩机后VIP自动漂移到备机上。
优点是对客户端毫无影响，仍然通过VIP操作。
缺点也很明显，在绝大多数时间内备机是一直没使用，被浪费着的.
3.主从方式
这种采取一主多从的办法，主从之间进行数据同步。当Master宕机后，通过选举算法(Paxos、Raft)从slave中选举出新Master继续对外提供服务，主机恢复后以slave的身份重新加入。
主从另一个目的是进行读写分离，这是当单机读写压力过高的一种通用型解决方案。其主机的角色只提供写操作或少量的读，把多余读请求通过负载均衡算法分流到单个或多个slave服务器上。
缺点是主机宕机后，Slave虽然被选举成新Master了，但对外提供的IP服务地址却发生变化了，意味着会影响到客户端。解决这种情况需要一些额外的工作，在当主机地址发生变化后及时通知到客户端，客户端收到新地址后，使用新地址继续发送新请求。

4.方案选择
主备(keepalived)方案配置简单、人力成本小，在数据量少、压力小的情况下推荐使用。如果数据量比较大，不希望过多浪费机器，还希望在宕机后，做一些自定义的措施，比如报警、记日志、数据迁移等操作，推荐使用主从方式，因为和主从搭配的般还有个管理监控中心

 Redis的数据同步方式

无论是主备还是主从都牵扯到数据同步的问题，这也分2种情况:
同步方式:当主机收到客户端写操作后，以同步方式把数据同步到从机上，当从机也成功写入后，主机才返回给客户端成功，也称数据强一致性。很显然这种方式性能会降低不少，当从机很多时，可以不用每台都同步，　　主机同步某一台从机后从机再把数据分发同步到其他从机上，这样提高主机性能分担同步压力。在redis中是支持这样配置的，一台master，一台salve，同时这台salve又作为其他slave的master.
异步方式:主机接收到写操作后，直接返回成功，然后在后台用异步方式把数据同步到从机上。这种同步性能比较好，但无法保证数据的完整性，比如在异步同步过程中主机突然宕机了，也称这种方式为数据弱一致性。Redis主从同步采用的是异步方式，因此会有少量丢数据的危险。还有种弱一致性的特例叫最终一致性，这块详细内容可参见CAF原理及一致性模型。

分布式与集群
1.集群时代
至少部署两台Redis服务器构成一个小的集群，主要有2个目的
高可用性:在主机挂掉后，自动故障转移，使前端服务对用户无影响。。

读写分离:将主机读压力分流到从机上

可在客户端组件上实现负载均衡，根据不同服务器的运行情况，分担不同比例的读请求压力。

2.Redis集群
分布式
缓存数据量不断增加时，单机内存不够使用，需要把数据切分不同部分，分布到多台服务器上。可在客户端对数据进行分片，数据分片算法详见一致性Hash详解、虚拟桶分片。

 大规模分布式集群时代

当数据量持续增加时，应用可根据不同场景下的业务申请对应的分布式集群。这块最关键的是缓存治理这块，其中最重要的部分是加入了代理服务。应用通过代理访问真实的Redis服务器进行读写，这样做的好处是:
避免越来越多的客户端直接访问Redis服务器难以管理，而造成风险
在代理这一层可以做对应的安全措施，比如限流、授权、分片。
避免客户端越来越多的逻辑代码，不但臃肿升级还比较麻烦
代理这层无状态的，可任意扩展节点，对于客户端来说，访问代理跟访问单机Redis一样。